| |
| STD 1 | 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. |
|
| |
| STD 3 | Requirements for Internet Hosts |
| |
|
| |
| STD 5 | Internet Protocol |
| |
|
| |
| STD 6 | User Datagram Protocol |
| |
|
| |
| STD 7 | Transmission Control Protocol |
| |
|
| |
| STD 8 | Telnet Protocol |
| |
|
| |
| STD 9 | File Transfer Protocol |
| |
|
| |
| STD 10 | Simple Mail Transfer Protocol |
| |
|
| |
| STD 11 | STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES |
| |
|
| |
| STD 13 | Domain Name System |
| |
|
| |
| STD 16 | Structure of Management Information |
| |
|
| |
| STD 17 | Management Information Base for Network Management of TCP/IP-based internets:MIB-II |
| |
|
| |
| STD 19 | NetBIOS Service Protocols |
| |
|
| |
| STD 20 | Echo Protocol |
| |
|
| |
| STD 21 | Discard Protocol |
| |
|
| |
| STD 22 | Character Generator Protocol |
| |
|
| |
| STD 23 | Quote of the Day Protocol |
| |
|
| |
| STD 24 | Active users |
| |
|
| |
| STD 25 | Daytime Protocol |
| |
|
| |
| STD 26 | Time Protocol |
| |
| Authors: | J. Postel, K. Harrenstien. |
| Date: | May 1983 |
| Formats: | txt pdf |
| Also: | RFC 0868 |
|
|
|
| |
| STD 27 | Telnet Binary Transmission |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt pdf |
| Obsoletes: | NIC 15389 |
| Also: | RFC 0856 |
|
|
|
| |
| STD 28 | Telnet Echo Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt pdf |
| Obsoletes: | NIC 15390 |
| Also: | RFC 0857 |
|
|
|
| |
| STD 29 | Telnet Suppress Go Ahead Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt pdf |
| Obsoletes: | NIC 15392 |
| Also: | RFC 0858 |
|
|
|
| |
| STD 30 | Telnet Status Option |
| |
|
| |
| STD 31 | Telnet Timing Mark Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt pdf |
| Obsoletes: | NIC 16238 |
| Also: | RFC 0860 |
|
|
|
| |
| STD 32 | Telnet Extended Options: List Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt pdf |
| Obsoletes: | NIC 16239 |
| Also: | RFC 0861 |
|
|
|
| |
| STD 33 | The TFTP Protocol (Revision 2) |
| |
|
| |
| STD 35 | ISO Transport Service on top of the TCP Version: 3 |
| |
|
| |
| STD 36 | Transmission of IP and ARP over FDDI Networks |
| |
|
|
This memo defines a method of encapsulating the Internet Protocol(IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks.
This RFC is the product of the IP over FDDI Working Group of theInternet Engineering Task Force (IETF). |
|
| |
| STD 37 | Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware |
| |
|
| |
| STD 38 | A Reverse Address Resolution Protocol |
| |
| Authors: | R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. |
| Date: | June 1984 |
| Formats: | txt pdf |
| Also: | RFC 0903 |
|
|
|
| |
| STD 39 | [Was BBN Report 1822 (IMP/Host Interface) |
| |
| Authors: | Now Historic. |
| Date: | ] December 1981 |
| Formats: | txt pdf |
|
|
|
| |
| STD 40 | Host Access Protocol specification |
| |
| Authors: | Bolt Beranek and Newman Laboratories. |
| Date: | July 1984 |
| Formats: | txt pdf |
| Updated by: | RFC 1221 |
| Also: | RFC 0907 |
|
|
|
| |
| STD 41 | A Standard for the Transmission of IP Datagrams over Ethernet Networks |
| |
|
| |
| STD 42 | Standard for the transmission of IP datagrams over experimental Ethernet networks |
| |
|
| |
| STD 43 | Standard for the transmission of IP datagrams over IEEE 802 networks |
| |
|
| |
| STD 44 | DCN Local-Network Protocols |
| |
|
| |
| STD 45 | Internet Protocol on Network System's HYPERchannel: Protocol Specification |
| |
|
| |
| STD 46 | Transmitting IP traffic over ARCNET networks |
| |
|
| |
| STD 47 | Nonstandard for transmission of IP datagrams over serial lines: SLIP |
| |
|
| |
| STD 48 | Standard for the transmission of IP datagrams over NetBIOS networks |
| |
| Authors: | L.J. McLaughlin. |
| Date: | February 1989 |
| Formats: | txt pdf |
| Also: | RFC 1088 |
|
|
|
| |
| STD 49 | Conversations with S. Crocker (UCLA) |
| |
| Authors: | L.J. McLaughlin. |
| Date: | November 1989 |
| Formats: | txt pdf |
| Also: | RFC 1132 |
|
|
|
| |
| STD 51 | The Point-to-Point Protocol (PPP) |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. |
|
| |
| STD 52 | The Transmission of IP Datagrams over the SMDS Service |
| |
| Authors: | D. Piscitello, J. Lawrence. |
| Date: | March 1991 |
| Formats: | txt pdf |
| Also: | RFC 1209 |
|
This memo describes an initial use of IP and ARP in an SMDS service environment configured as a logical IP subnetwork, LIS (described below). The encapsulation method used is described, as well as various service-specific issues. This memo does not preclude subsequent treatment of the SMDS Service in configurations other thanLIS; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents. This document considers only directly connected IP end-stations or routers; issues raised by MAC level bridging are beyond the scope of this paper. |
|
| |
| STD 53 | Post Office Protocol - Version 3 |
| |
|
| |
| STD 54 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
The differences between this memo and RFC 2178 are explained inAppendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| STD 55 | Multiprotocol Interconnect over Frame Relay |
| |
|
|
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing.
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use. |
|
| |
| STD 56 | RIP Version 2 |
| |
|
|
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security.
A companion document will define the SNMP MIB objects for RIP-2 [2].An additional document will define cryptographic security improvements for RIP-2 [3]. |
|
| |
| STD 57 | RIP Version 2 Protocol Applicability Statement |
| |
|
|
As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet.This report is a prerequisite to advancing RIP-2 on the standards track. |
|
| |
| STD 58 | Structure of Management Information Version 2 (SMIv2) |
| |
|
| |
| STD 59 | Remote Network Monitoring 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 remote network monitoring devices.
This memo obsoletes RFC 1757. This memo extends that specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. |
|
| |
| STD 60 | SMTP Service Extension for Command Pipelining |
| |
|
|
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission ControlProtocol (TCP) send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. |
|
| |
| STD 61 | A One-Time Password System |
| |
| Authors: | N. Haller, C. Metz, P. Nesser, M. Straw. |
| Date: | February 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1938 |
| Also: | RFC 2289 |
|
|
|
| |
| STD 62 | Simple Network Management Protocol Version 3 (SNMPv3) |
| |
| Authors: | D. Harrington, R. Presuhn, B. Wijnen, J. Case, D. Levi, P. Meyer, B. Stewart, U. Blumenthal, K. McCloghrie. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2571, RFC 2572, RFC 2573, RFC 2574, RFC 2575, RFC 1905, RFC 1906, RFC 1907 |
| Also: | RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418 |
|
This document describes an architecture for describing Simple NetworkManagement Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are anSNMP engine containing a Message Processing Subsystem, a SecuritySubsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. |
|
| |
| STD 63 | UTF-8, a transformation format of ISO 10646 |
| |
|
|
ISO/IEC 10646-1 defines a large character set called the UniversalCharacter Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.This memo obsoletes and replaces RFC 2279. |
|
| |
| STD 64 | RTP: A Transport Protocol for Real-Time Applications |
| |
|
|
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP andRTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. |
|
| |
| STD 65 | RTP Profile for Audio and Video Conferences with Minimal Control |
| |
|
|
This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
This memorandum obsoletes RFC 1890. It is mostly backwards- compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. |
|
| |
| STD 66 | Uniform Resource Identifier (URI): Generic Syntax |
| |
|
|
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on theInternet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. |
|
| |
| STD 67 | XDR: External Data Representation Standard |
| |
|
|
This document describes the External Data Representation Standard(XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. |
|
| |
| STD 68 | Augmented BNF for Syntax Specifications: ABNF |
| |
|
|
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form(BNF), called Augmented BNF (ABNF), has been popular among manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity with reasonable representational power. The differences between standard BNF andABNF involve naming rules, repetition, alternatives, order- independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. |
|
| |
| STD 69 | The Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. |
|
| |
| STD 70 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| STD 71 | SMTP Service Extension for 8-bit MIME Transport |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, D. Crocker, Ed.. |
| Date: | March 2011 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1652 |
| Also: | RFC 6152 |
|
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of theUS-ASCII octet range (hex 00-7F) may be relayed using SMTP. |
|
| |
| STD 72 | Message Submission for Mail |
| |
|
|
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay is unaffected, and continues to use SMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. |
|
