Internet Documents


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

STD 3 Requirements for Internet Hosts
Authors:R. Braden, Ed..
Date:October 1989
Formats:txt html pdf
Also:RFC 1122, RFC 1123
STD 5 Internet Protocol
Authors:J. Postel.
Date:September 1981
Formats:txt html pdf
Also:RFC 0791, RFC 0792, RFC 0919, RFC 0922, RFC 0950, RFC 1112
STD 6 User Datagram Protocol
Authors:J. Postel.
Date:August 1980
Formats:txt html pdf
Also:RFC 0768
STD 7 Transmission Control Protocol
Authors:J. Postel.
Date:September 1981
Formats:txt html pdf
Obsoletes:RFC 0761
Updated by:RFC 1122, RFC 3168, RFC 6093, RFC 6528
Also:RFC 0793
STD 8 Telnet Protocol
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Also:RFC 0854, RFC 0855
STD 9 File Transfer Protocol
Authors:J. Postel, J. Reynolds.
Date:October 1985
Formats:txt html pdf
Obsoletes:RFC 0765
Updated by:RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151
Also:RFC 0959
STD 10 Simple Mail Transfer Protocol
Authors:J. Postel.
Date:August 1982
Formats:txt html pdf
Obsoletes:RFC 0788, RFC 0780, RFC 0772
Obsoleted by:RFC 2821
Also:RFC 0821, RFC 0974, RFC 1869, RFC 1870
Authors:D. Crocker.
Date:August 1982
Formats:txt html pdf
Obsoletes:RFC 0733
Obsoleted by:RFC 2822
Updated by:RFC 1123, RFC 2156, RFC 1327, RFC 1138, RFC 1148
Also:RFC 0822
STD 13 Domain Name System
Authors:P. Mockapetris.
Date:November 1987
Formats:txt html pdf
Also:RFC 1034, RFC 1035
STD 16 Structure of Management Information
Authors:M. Rose, K. McCloghrie.
Date:May 1990
Formats:txt html pdf
Obsoletes:RFC 1065
Also:RFC 1155, RFC 1212
STD 17 Management Information Base for Network Management of TCP/IP-based internets: MIB-II
Authors:K. McCloghrie, M. Rose.
Date:March 1991
Formats:txt html pdf
Obsoletes:RFC 1158
Updated by:RFC 2011, RFC 2012, RFC 2013
Also:RFC 1213
STD 19 NetBIOS Service Protocols
Authors:NetBIOS Working Group.
Date:March 1987
Formats:txt html pdf
Also:RFC 1001, RFC 1002
STD 20 Echo Protocol
Authors:J. Postel.
Date:May 1983
Formats:txt html pdf
Also:RFC 0862
STD 21 Discard Protocol
Authors:J. Postel.
Date:May 1983
Formats:txt html pdf
Also:RFC 0863
STD 22 Character Generator Protocol
Authors:J. Postel.
Date:May 1983
Formats:txt html pdf
Also:RFC 0864
STD 23 Quote of the Day Protocol
Authors:J. Postel.
Date:May 1983
Formats:txt html pdf
Also:RFC 0865
STD 24 Active users
Authors:J. Postel.
Date:May 1983
Formats:txt html pdf
Also:RFC 0866
STD 25 Daytime Protocol
Authors:J. Postel.
Date:May 1983
Formats:txt html pdf
Also:RFC 0867
STD 26 Time Protocol
Authors:J. Postel, K. Harrenstien.
Date:May 1983
Formats:txt html pdf
Also:RFC 0868
STD 27 Telnet Binary Transmission
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Obsoletes:NIC 15389
Also:RFC 0856
STD 28 Telnet Echo Option
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Obsoletes:NIC 15390
Also:RFC 0857
STD 29 Telnet Suppress Go Ahead Option
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Obsoletes:NIC 15392
Also:RFC 0858
STD 30 Telnet Status Option
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Obsoletes:RFC 0651
Also:RFC 0859
STD 31 Telnet Timing Mark Option
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Obsoletes:NIC 16238
Also:RFC 0860
STD 32 Telnet Extended Options: List Option
Authors:J. Postel, J. Reynolds.
Date:May 1983
Formats:txt html pdf
Obsoletes:NIC 16239
Also:RFC 0861
STD 33 The TFTP Protocol (Revision 2)
Authors:K. Sollins.
Date:July 1992
Formats:txt html pdf
Obsoletes:RFC 0783
Updated by:RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349
Also:RFC 1350
STD 35 ISO Transport Service on top of the TCP Version: 3
Authors:M.T. Rose, D.E. Cass.
Date:May 1987
Formats:txt html pdf
Obsoletes:RFC 0983
Updated by:RFC 2126
Also:RFC 1006
STD 36 Transmission of IP and ARP over FDDI Networks
Authors:D. Katz.
Date:January 1993
Formats:txt html pdf
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
Authors:D. Plummer.
Date:November 1982
Formats:txt html pdf
Updated by:RFC 5227, RFC 5494
Also:RFC 0826
STD 38 A Reverse Address Resolution Protocol
Authors:R. Finlayson, T. Mann, J.C. Mogul, M. Theimer.
Date:June 1984
Formats:txt html pdf
Also:RFC 0903
STD 39 [Was BBN Report 1822 (IMP/Host Interface)
Authors:Now Historic.
Date:] December 1981
Formats:txt html pdf
STD 40 Host Access Protocol specification
Authors:Bolt Beranek, Newman Laboratories.
Date:July 1984
Formats:txt html pdf
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 html pdf
Also:RFC 0894
STD 42 Standard for the transmission of IP datagrams over experimental Ethernet networks
Authors:J. Postel.
Date:April 1984
Formats:txt html pdf
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 html pdf
Obsoletes:RFC 0948
Also:RFC 1042
STD 44 DCN Local-Network Protocols
Authors:D.L. Mills.
Date:December 1983
Formats:txt html pdf
Also:RFC 0891
STD 45 Internet Protocol on Network System's HYPERchannel: Protocol Specification
Authors:K. Hardwick, J. Lekashman.
Date:February 1988
Formats:txt html pdf
Updated by:RFC 5494
Also:RFC 1044
STD 46 Transmitting IP traffic over ARCNET networks
Authors:D. Provan.
Date:February 1991
Formats:txt html pdf
Obsoletes:RFC 1051
Also:RFC 1201
STD 47 Nonstandard for transmission of IP datagrams over serial lines: SLIP
Authors:J.L. Romkey.
Date:June 1988
Formats:txt html pdf
Also:RFC 1055
STD 48 Standard for the transmission of IP datagrams over NetBIOS networks
Authors:L.J. McLaughlin.
Date:February 1989
Formats:txt html pdf
Also:RFC 1088
STD 49 Conversations with S. Crocker (UCLA)
Authors:L.J. McLaughlin.
Date:November 1989
Formats:txt html pdf
Also:RFC 1132
STD 51 The Point-to-Point Protocol (PPP)
Authors:W. Simpson, Ed..
Date:July 1994
Formats:txt html pdf
Obsoletes:RFC 1549
Also:RFC 1661, RFC 1662
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 html 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
Authors:J. Myers, M. Rose.
Date:May 1996
Formats:txt html pdf
Obsoletes:RFC 1725
Also:RFC 1939
STD 54 OSPF Version 2
Authors:J. Moy.
Date:April 1998
Formats:txt html pdf
Obsoletes:RFC 2178
Updated by:RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042
Also:RFC 2328
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

STD 55 Multiprotocol Interconnect over Frame Relay
Authors:C. Brown, A. Malis.
Date:September 1998
Formats:txt html pdf
Obsoletes:RFC 1490, RFC 1294
Also:RFC 2427
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
Authors:G. Malkin.
Date:November 1998
Formats:txt html pdf
Obsoletes:RFC 1723
Also:RFC 2453
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 html pdf
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)
Authors:K. McCloghrie, D. Perkins, J. Schoenwaelder.
Date:April 1999
Formats:txt html pdf
Obsoletes:RFC 1902
Also:RFC 2578, RFC 2579, RFC 2580
STD 59 Remote Network Monitoring Management Information Base
Authors:S. Waldbusser.
Date:May 2000
Formats:txt html pdf
Obsoletes:RFC 1757
Also:RFC 2819
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
Authors:N. Freed.
Date:September 2000
Formats:txt html pdf
Obsoletes:RFC 2197
Also:RFC 2920
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 html 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 html 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
Authors:F. Yergeau.
Date:November 2003
Formats:txt html pdf
Obsoletes:RFC 2279
Also:RFC 3629
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 html pdf
Obsoletes:RFC 1889
Updated by:RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108
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
Authors:H. Schulzrinne, S. Casner.
Date:July 2003
Formats:txt html pdf
Obsoletes:RFC 1890
Updated by:RFC 5761, RFC 7007
Also:RFC 3551
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
Authors:T. Berners-Lee, R. Fielding, L. Masinter.
Date:January 2005
Formats:txt html pdf
Obsoletes:RFC 2732, RFC 2396, RFC 1808
Updates:RFC 1738
Updated by:RFC 6874, RFC 7320, RFC 8820
Also:RFC 3986
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
Authors:M. Eisler, Ed..
Date:May 2006
Formats:txt html pdf
Obsoletes:RFC 1832
Also:RFC 4506
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
Authors:D. Crocker, Ed., P. Overell.
Date:January 2008
Formats:txt html pdf
Obsoletes:RFC 4234
Updated by:RFC 7405
Also:RFC 5234
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)
Formats:txt html pdf
Also:RFC 5730, RFC 5731, RFC 5732, RFC 5733, RFC 5734
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)
Authors:R. Housley.
Date:September 2009
Formats:txt html pdf
Obsoletes:RFC 3852
Also:RFC 5652
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 html 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
Authors:R. Gellens, J. Klensin.
Date:November 2011
Formats:txt html pdf
Obsoletes:RFC 4409
Updated by:RFC 8314
Also:RFC 6409
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
Authors:M. Kucherawy, Ed..
Date:January 2012
Formats:txt html pdf
Obsoletes:RFC 3462
Updated by:RFC 6533
Also:RFC 6522
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 html pdf
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))
Authors:J. Damas, M. Graff, P. Vixie.
Date:April 2013
Formats:txt html pdf
Obsoletes:RFC 2671, RFC 2673
Also:RFC 6891
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
Authors:D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed..
Date:September 2011
Formats:txt html pdf
Obsoletes:RFC 4871, RFC 5672
Updated by:RFC 8301, RFC 8463, RFC 8553, RFC 8616
Also:RFC 6376
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 html pdf
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
Authors:J. Schoenwaelder, D. Harrington, W. Hardaker.
Date:February 2014
Formats:txt html pdf
Also:RFC 5343, RFC 5590, RFC 5591, RFC 6353
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)
Authors:C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen.
Date:October 2014
Formats:txt html pdf
Obsoletes:RFC 5996
Updated by:RFC 7427, RFC 7670, RFC 8247
Also:RFC 7296
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 html pdf
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 html pdf
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 html pdf
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 html pdf
Obsoletes:RFC 4601
Updated by:RFC 8736
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)
Authors:L. Martini, Ed., G. Heron, Ed..
Date:February 2017
Formats:txt html pdf
Obsoletes:RFC 4447, RFC 6723
Also:RFC 8077
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
Authors:T. Hansen, Ed., A. Melnikov, Ed..
Date:February 2017
Formats:txt html pdf
Obsoletes:RFC 3798
Updates:RFC 2046, RFC 3461
Also:RFC 8098
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
Authors:S. Deering, R. Hinden.
Date:July 2017
Formats:txt html pdf
Obsoletes:RFC 2460
Also:RFC 8200
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 html pdf
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
Authors:S. Thomson, C. Huitema, V. Ksinant, M. Souissi.
Date:October 2003
Formats:txt html pdf
Obsoletes:RFC 3152, RFC 1886
Also:RFC 3596
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
Authors:A. Conta, S. Deering, M. Gupta, Ed..
Date:March 2006
Formats:txt html pdf
Obsoletes:RFC 2463
Updates:RFC 2780
Updated by:RFC 4884
Also:RFC 4443
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
Authors:T. Bray, Ed..
Date:December 2017
Formats:txt html pdf
Obsoletes:RFC 7159
Also:RFC 8259
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
Authors:A. Bierman, M. Bjorklund.
Date:March 2018
Formats:txt html pdf
Obsoletes:RFC 6536
Also:RFC 8341
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.