| |
| STD 3 | Requirements for Internet Hosts |
| |
|
| |
| STD 5 | Internet Protocol |
| |
|
| |
| STD 6 | User Datagram Protocol |
| |
| Authors: | J. Postel. |
| Date: | August 1980 |
| Formats: | txt |
| Also: | RFC 0768 |
|
|
|
| |
| STD 7 | Transmission Control Protocol (TCP) |
| |
|
|
This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793.This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits fromRFC 793 have also been updated based on RFC 3168. |
|
| |
| 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 |
| |
| Authors: | J. Postel. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0862 |
|
|
|
| |
| STD 21 | Discard Protocol |
| |
| Authors: | J. Postel. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0863 |
|
|
|
| |
| STD 22 | Character Generator Protocol |
| |
| Authors: | J. Postel. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0864 |
|
|
|
| |
| STD 23 | Quote of the Day Protocol |
| |
| Authors: | J. Postel. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0865 |
|
|
|
| |
| STD 24 | Active users |
| |
| Authors: | J. Postel. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0866 |
|
|
|
| |
| STD 25 | Daytime Protocol |
| |
| Authors: | J. Postel. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0867 |
|
|
|
| |
| STD 26 | Time Protocol |
| |
| Authors: | J. Postel, K. Harrenstien. |
| Date: | May 1983 |
| Formats: | txt |
| Also: | RFC 0868 |
|
|
|
| |
| STD 27 | Telnet Binary Transmission |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt |
| Obsoletes: | NIC_15389 |
| Also: | RFC 0856 |
|
|
|
| |
| STD 28 | Telnet Echo Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt |
| Obsoletes: | NIC_15390 |
| Also: | RFC 0857 |
|
|
|
| |
| STD 29 | Telnet Suppress Go Ahead Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt |
| 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 |
| Obsoletes: | NIC_16238 |
| Also: | RFC 0860 |
|
|
|
| |
| STD 32 | Telnet Extended Options: List Option |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | May 1983 |
| Formats: | txt |
| 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 |
| |
| Authors: | D. Katz. |
| Date: | January 1993 |
| Formats: | txt |
| Also: | RFC 1390 |
|
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 | An 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 |
| Also: | RFC 0903 |
|
|
|
| |
| STD 39 | [Was BBN Report 1822 (IMP/Host Interface) |
| |
| Authors: | Now Historic. |
| Date: | ] December 1981 |
| Formats: | txt |
|
|
|
| |
| STD 40 | Host Access Protocol specification |
| |
| Authors: | Bolt Beranek and Newman Laboratories. |
| Date: | July 1984 |
| Formats: | txt |
| Updated by: | RFC 1221 |
| Also: | RFC 0907 |
|
|
|
| |
| STD 41 | A Standard for the Transmission of IP Datagrams over Ethernet Networks |
| |
| Authors: | C. Hornig. |
| Date: | April 1984 |
| Formats: | txt |
| Also: | RFC 0894 |
|
|
|
| |
| STD 42 | Standard for the transmission of IP datagrams over experimental Ethernet networks |
| |
| Authors: | J. Postel. |
| Date: | April 1984 |
| Formats: | txt |
| Also: | RFC 0895 |
|
|
|
| |
| STD 43 | Standard for the transmission of IP datagrams over IEEE 802 networks |
| |
| Authors: | J. Postel, J.K. Reynolds. |
| Date: | February 1988 |
| Formats: | txt |
| Obsoletes: | RFC 0948 |
| Also: | RFC 1042 |
|
|
|
| |
| STD 44 | DCN Local-Network Protocols |
| |
| Authors: | D.L. Mills. |
| Date: | December 1983 |
| Formats: | txt |
| Also: | RFC 0891 |
|
|
|
| |
| STD 45 | Internet Protocol on Network System's HYPERchannel: Protocol Specification |
| |
| Authors: | K. Hardwick, J. Lekashman. |
| Date: | February 1988 |
| Formats: | txt |
| Updated by: | RFC 5494 |
| Also: | RFC 1044 |
|
|
|
| |
| STD 46 | Transmitting IP traffic over ARCNET networks |
| |
|
| |
| STD 47 | Nonstandard for transmission of IP datagrams over serial lines: SLIP |
| |
| Authors: | J.L. Romkey. |
| Date: | June 1988 |
| Formats: | txt |
| Also: | RFC 1055 |
|
|
|
| |
| STD 48 | Standard for the transmission of IP datagrams over NetBIOS networks |
| |
| Authors: | L.J. McLaughlin. |
| Date: | February 1989 |
| Formats: | txt |
| Also: | RFC 1088 |
|
|
|
| |
| STD 49 | Conversations with S. Crocker (UCLA) |
| |
| Authors: | L.J. McLaughlin. |
| Date: | November 1989 |
| Formats: | txt |
| 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 |
| 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 |
| |
| Authors: | G. Malkin. |
| Date: | November 1994 |
| Formats: | txt |
| Also: | RFC 1722 |
|
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 |
| 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 |
| 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 |
| |
| Authors: | H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. |
| Date: | July 2003 |
| Formats: | txt |
| Obsoletes: | RFC 1889 |
| Updated by: | RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860 |
| Also: | RFC 3550 |
|
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 |
| 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. |
|
| |
| STD 73 | The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
This memo obsoletes "The Multipart/Report Content Type for theReporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". |
|
| |
| STD 74 | Automated Updates of DNS Security (DNSSEC) Trust Anchors |
| |
| Authors: | M. StJohns. |
| Date: | September 2007 |
| Formats: | txt |
| Also: | RFC 5011 |
|
This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).
This mechanism will require changes to resolver management behavior(but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. |
|
| |
| STD 75 | Extension Mechanisms for DNS (EDNS(0)) |
| |
|
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletesRFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. |
|
| |
| STD 76 | DomainKeys Identified Mail (DKIM) Signatures |
| |
|
|
DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.
This memo obsoletes RFC 4871 and RFC 5672. |
|
| |
| STD 77 | Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information |
| |
| Authors: | B. Claise, Ed., B. Trammell, Ed., P. Aitken. |
| Date: | September 2013 |
| Formats: | txt |
| Obsoletes: | RFC 5101 |
| Also: | RFC 7011 |
|
This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process. This document obsoletes RFC 5101. |
|
| |
| STD 78 | Simple Network Management Protocol (SNMP) Security |
| |
|
|
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
This document updates RFC 3411. |
|
| |
| STD 79 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
RFC 3580 provides guidelines for the use of the Remote AuthenticationDial-In User Service (RADIUS) within IEEE 802 local area networks(LANs). This document defines additional attributes for use withinIEEE 802 networks and clarifies the usage of the EAP-Key-NameAttribute and the Called-Station-Id Attribute. This document updatesRFCs 3580 and 4072. |
|
| |
| STD 80 | ASCII format for network interchange |
| |
| Authors: | V.G. Cerf. |
| Date: | October 1969 |
| Formats: | txt |
| Also: | RFC 0020 |
|
|
|
| |
| STD 81 | A One-Way Delay Metric for IP Performance Metrics (IPPM) |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. |
| Date: | January 2016 |
| Formats: | txt |
| Obsoletes: | RFC 2679 |
| Also: | RFC 7679 |
|
This memo defines a metric for one-way delay of packets acrossInternet paths. It builds on notions introduced and discussed in theIP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makesRFC 2679 obsolete. |
|
| |
| STD 82 | A One-Way Loss Metric for IP Performance Metrics (IPPM) |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. |
| Date: | January 2016 |
| Formats: | txt |
| Obsoletes: | RFC 2680 |
| Also: | RFC 7680 |
|
This memo defines a metric for one-way loss of packets acrossInternet paths. It builds on notions introduced and discussed in theIP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makesRFC 2680 obsolete. |
|
| |
| STD 83 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
| Authors: | B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng. |
| Date: | March 2016 |
| Formats: | txt |
| Obsoletes: | RFC 4601 |
| Updated by: | RFC 8736, RFC 9436 |
| Also: | RFC 7761 |
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.
This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM MulticastBorder Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. |
|
| |
| STD 84 | Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) |
| |
|
|
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol(LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.
This document is a rewrite of RFC 4447 for publication as an InternetStandard. |
|
| |
| STD 85 | Message Disposition Notification |
| |
|
|
This memo defines a MIME content type that may be used by a Mail UserAgent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.This content type is intended to be machine processable. Additional message header fields are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and are often referred to as "read receipts,""acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.
This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461(Original-Recipient header field generation requirement). |
|
| |
| STD 86 | Internet Protocol, Version 6 (IPv6) Specification |
| |
|
|
This document specifies version 6 of the Internet Protocol (IPv6).It obsoletes RFC 2460. |
|
| |
| STD 87 | Path MTU Discovery for IP version 6 |
| |
| Authors: | J. McCann, S. Deering, J. Mogul, R. Hinden, Ed.. |
| Date: | July 2017 |
| Formats: | txt |
| Obsoletes: | RFC 1981 |
| Also: | RFC 8201 |
|
This document describes Path MTU Discovery (PMTUD) for IP version 6.It is largely derived from RFC 1191, which describes Path MTUDiscovery for IP version 4. It obsoletes RFC 1981. |
|
| |
| STD 88 | DNS Extensions to Support IP Version 6 |
| |
|
|
This document defines the changes that need to be made to the DomainName System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. |
|
| |
| STD 89 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| |
|
|
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is theInternet Control Message Protocol for Internet Protocol version 6(IPv6). |
|
| |
| STD 90 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| STD 91 | Network Configuration Access Control Model |
| |
|
|
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.
This document obsoletes RFC 6536. |
|
| |
| STD 92 | Internet Printing Protocol/1.1 |
| |
|
|
The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called"application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/orHTTPS. The IPP data model and operation semantics are described in"Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).
This document obsoletes RFCs 2910 and 3382. |
|
| |
| STD 93 | Secret Key Transaction Authentication for DNS (TSIG) |
| |
| Authors: | F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O. Gudmundsson, B. Wellington. |
| Date: | November 2020 |
| Formats: | txt |
| Obsoletes: | RFC 2845, RFC 4635 |
| Also: | RFC 8945 |
|
This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.
No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.
This document obsoletes RFCs 2845 and 4635. |
|
| |
| STD 94 | Concise Binary Object Representation (CBOR) |
| |
| Authors: | C. Bormann, P. Hoffman. |
| Date: | December 2020 |
| Formats: | txt |
| Obsoletes: | RFC 7049 |
| Also: | RFC 8949 |
|
The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.
This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. |
|
| |
| STD 95 | RDAP |
| |
|
|
This document is one of a collection that together describes theRegistration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. |
|
| |
| STD 96 | CBOR Object Signing and Encryption (COSE): Structures and Process |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
This document, along with RFC 9053, obsoletes RFC 8152. |
|
| |
| STD 97 | HTTP Semantics |
| |
| Authors: | R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. |
| Date: | June 2022 |
| Formats: | txt |
| Obsoletes: | RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694 |
| Updates: | RFC 3864 |
| Also: | RFC 9110 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232,7233, 7235, 7538, 7615, 7694, and portions of 7230. |
|
| |
| STD 98 | HTTP Caching |
| |
| Authors: | R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. |
| Date: | June 2022 |
| Formats: | txt |
| Obsoletes: | RFC 7234 |
| Also: | RFC 9111 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.
This document obsoletes RFC 7234. |
|
