Internet Documents

RFCs

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

 
RFC 951 Bootstrap Protocol
 
Authors:W.J. Croft, J. Gilmore.
Date:September 1985
Formats:txt pdf
Updated by:RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494
Status:DRAFT STANDARD
DOI:10.17487/RFC 0951
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
 
RFC 954 NICNAME/WHOIS
 
Authors:K. Harrenstien, M.K. Stahl, E.J. Feinler.
Date:October 1985
Formats:txt pdf
Obsoletes:RFC 0812
Obsoleted by:RFC 3912
Status:DRAFT STANDARD
DOI:10.17487/RFC 0954
This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.
 
RFC 1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links
 
Authors:D. Perkins.
Date:July 1990
Formats:txt pdf
Obsoletes:RFC 1134
Obsoleted by:RFC 1331
Status:DRAFT STANDARD
DOI:10.17487/RFC 1171
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:

1. A method for encapsulating datagrams over serial links.

2. An extensible Link Control Protocol (LCP).

3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.

This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).

The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed.

 
RFC 1184 Telnet Linemode Option
 
Authors:D.A. Borman.
Date:October 1990
Formats:txt pdf
Obsoletes:RFC 1116
Status:DRAFT STANDARD
DOI:10.17487/RFC 1184
This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]
 
RFC 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks
 
Authors:D. Katz.
Date:October 1990
Formats:txt pdf
Obsoletes:RFC 1103
Status:DRAFT STANDARD
DOI:10.17487/RFC 1188
This document specifies a method for the use of IP and ARP on FDDI networks. The encapsulation method used is described, as well as various media-specific issues.
 
RFC 1191 Path MTU discovery
 
Authors:J.C. Mogul, S.E. Deering.
Date:November 1990
Formats:txt pdf
Obsoletes:RFC 1063
Status:DRAFT STANDARD
DOI:10.17487/RFC 1191
This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.
 
RFC 1194 Finger User Information Protocol
 
Authors:D.P. Zimmerman.
Date:November 1990
Formats:txt pdf
Obsoletes:RFC 0742
Obsoleted by:RFC 1196, RFC 1288
Status:DRAFT STANDARD
DOI:10.17487/RFC 1194
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.

Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.

 
RFC 1196 Finger User Information Protocol
 
Authors:D.P. Zimmerman.
Date:December 1990
Formats:txt pdf
Obsoletes:RFC 1194, RFC 0742
Obsoleted by:RFC 1288
Status:DRAFT STANDARD
DOI:10.17487/RFC 1196
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.

Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194.

 
RFC 1225 Post Office Protocol: Version 3
 
Authors:M.T. Rose.
Date:May 1991
Formats:txt pdf
Obsoletes:RFC 1081
Obsoleted by:RFC 1460
Status:DRAFT STANDARD
DOI:10.17487/RFC 1225
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]
 
RFC 1247 OSPF Version 2
 
Authors:J. Moy.
Date:July 1991
Formats:txt pdf ps
Obsoletes:RFC 1131
Obsoleted by:RFC 1583
Updated by:RFC 1349
Also:RFC 1245, RFC 1246
Status:DRAFT STANDARD
DOI:10.17487/RFC 1247
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]
 
RFC 1288 The Finger User Information Protocol
 
Authors:D. Zimmerman.
Date:December 1991
Formats:txt pdf
Obsoletes:RFC 1196, RFC 1194, RFC 0742
Status:DRAFT STANDARD
DOI:10.17487/RFC 1288
This memo describes the Finger user information protocol. This is a simple protocol which provides an interface to a remote user information program.

Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.

This edition corrects and clarifies RFC 1196.

 
RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis
 
Authors:D. Mills.
Date:March 1992
Formats:txt tar pdf
Obsoletes:RFC 0958, RFC 1059, RFC 1119
Obsoleted by:RFC 5905
Status:DRAFT STANDARD
DOI:10.17487/RFC 1305
This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]
 
RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode
 
Authors:A. Malis, D. Robinson, R. Ullmann.
Date:August 1992
Formats:txt pdf
Obsoletes:RFC 0877
Status:DRAFT STANDARD
DOI:10.17487/RFC 1356
This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment withISO/IEC and CCITT standards. It is a replacement for RFC 877, "AStandard for the Transmission of IP Datagrams Over Public DataNetworks" [1].

It was written to correct several ambiguities in the InternetStandard for IP/X.25 (RFC 877), to align it with ISO/IEC standards that have been written following RFC 877, to allow interoperable multiprotocol operation between routers and bridges over X.25, and to add some additional remarks based upon practical experience with the specification over the 8 years since that RFC.

The substantive change to the IP encapsulation is an increase in the allowed IP datagram Maximum Transmission Unit from 576 to 1600, to reflect existing practice.

This document also specifies the Internet encapsulation for protocols, including IP, on the packet mode of the ISDN. It applies to the use of Internet protocols on the ISDN in the circuit mode only when the circuit is established as an end-to-end X.25 connection.

 
RFC 1395 BOOTP Vendor Information Extensions
 
Authors:J. Reynolds.
Date:January 1993
Formats:txt pdf
Obsoletes:RFC 1084, RFC 1048
Obsoleted by:RFC 1497, RFC 1533
Updates:RFC 0951
Status:DRAFT STANDARD
DOI:10.17487/RFC 1395
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).
 
RFC 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types
 
Authors:F. Kastenholz.
Date:January 1993
Formats:txt pdf
Obsoletes:RFC 1284
Obsoleted by:RFC 1623
Status:DRAFT STANDARD
DOI:10.17487/RFC 1398
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 ethernet-like objects.
 
RFC 1460 Post Office Protocol - Version 3
 
Authors:M. Rose.
Date:June 1993
Formats:txt pdf
Obsoletes:RFC 1225
Obsoleted by:RFC 1725
Status:DRAFT STANDARD
DOI:10.17487/RFC 1460
This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK]
 
RFC 1490 Multiprotocol Interconnect over Frame Relay
 
Authors:T. Bradley, C. Brown, A. Malis.
Date:July 1993
Formats:txt pdf
Obsoletes:RFC 1294
Obsoleted by:RFC 2427
Status:DRAFT STANDARD
DOI:10.17487/RFC 1490
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU.

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.

 
RFC 1493 Definitions of Managed Objects for Bridges
 
Authors:E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie.
Date:July 1993
Formats:txt pdf
Obsoletes:RFC 1286
Obsoleted by:RFC 4188
Status:DRAFT STANDARD
DOI:10.17487/RFC 1493
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 MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging.Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.
 
RFC 1497 BOOTP Vendor Information Extensions
 
Authors:J. Reynolds.
Date:August 1993
Formats:txt pdf
Obsoletes:RFC 1395, RFC 1084, RFC 1048
Obsoleted by:RFC 1533
Updates:RFC 0951
Status:DRAFT STANDARD
DOI:10.17487/RFC 1497
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).
 
RFC 1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices
 
Authors:D. McMaster, K. McCloghrie.
Date:September 1993
Formats:txt pdf
Obsoletes:RFC 1368
Obsoleted by:RFC 2108
Status:DRAFT STANDARD
DOI:10.17487/RFC 1516
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 IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs."
 
RFC 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
 
Authors:N. Borenstein, N. Freed.
Date:September 1993
Formats:txt pdf ps
Obsoletes:RFC 1341
Obsoleted by:RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
Updated by:RFC 1590
Status:DRAFT STANDARD
DOI:10.17487/RFC 1521
STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC822.

In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi- font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.

This document does NOT extend Internet mail header fields to permit anything other than US-ASCII text data. Such extensions are the subject of a companion document [RFC-1522].

This document is a revision of RFC 1341. Significant differences from RFC 1341 are summarized in Appendix H.

 
RFC 1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
 
Authors:K. Moore.
Date:September 1993
Formats:txt pdf
Obsoletes:RFC 1342
Obsoleted by:RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
Status:DRAFT STANDARD
DOI:10.17487/RFC 1522
This memo describes an extension to the message format defined in RFC1521 [1], to allow the representation of character sets other thanASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.
 
RFC 1534 Interoperation Between DHCP and BOOTP
 
Authors:R. Droms.
Date:October 1993
Formats:txt pdf
Status:DRAFT STANDARD
DOI:10.17487/RFC 1534
DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants.
 
RFC 1542 Clarifications and Extensions for the Bootstrap Protocol
 
Authors:W. Wimer.
Date:October 1993
Formats:txt pdf
Obsoletes:RFC 1532
Updates:RFC 0951
Status:DRAFT STANDARD
DOI:10.17487/RFC 1542
Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. Due to some errors introduced into RFC 1532 in the editorial process, this memo is reissued as RFC 1542.

In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these.

 
RFC 1548 The Point-to-Point Protocol (PPP)
 
Authors:W. Simpson.
Date:December 1993
Formats:txt pdf
Obsoletes:RFC 1331
Obsoleted by:RFC 1661
Updated by:RFC 1570
Status:DRAFT STANDARD
DOI:10.17487/RFC 1548
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.

This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1549 PPP in HDLC Framing
 
Authors:W. Simpson, Ed..
Date:December 1993
Formats:txt pdf
Obsoleted by:RFC 1662
Status:DRAFT STANDARD
DOI:10.17487/RFC 1549
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1559 DECnet Phase IV MIB Extensions
 
Authors:J. Saperia.
Date:December 1993
Formats:txt pdf
Obsoletes:RFC 1289
Status:DRAFT STANDARD
DOI:10.17487/RFC 1559
This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]
 
RFC 1575 An Echo Function for CLNP (ISO 8473)
 
Authors:S. Hares, C. Wittbrodt.
Date:February 1994
Formats:txt pdf
Obsoletes:RFC 1139
Status:DRAFT STANDARD
DOI:10.17487/RFC 1575
This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of anEcho function to ISO 8473" an integral part of Version 2 of ISO 8473.
 
RFC 1583 OSPF Version 2
 
Authors:J. Moy.
Date:March 1994
Formats:txt pdf ps
Obsoletes:RFC 1247
Obsoleted by:RFC 2178
Status:DRAFT STANDARD
DOI:10.17487/RFC 1583
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. Separate routes can be calculated for each IP Type of Service. 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.

OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in AppendixE. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate.

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

 
RFC 1629 Guidelines for OSI NSAP Allocation in the Internet
 
Authors:R. Colella, R. Callon, E. Gardner, Y. Rekhter.
Date:May 1994
Formats:txt pdf
Obsoletes:RFC 1237
Status:DRAFT STANDARD
DOI:10.17487/RFC 1629
CLNP is currently being deployed in the Internet. This is useful to support OSI and DECnet(tm) traffic. In addition, CLNP has been proposed as a possible IPng candidate, to provide a long-term solution to IP address exhaustion. Required as part of the CLNP infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocatingNSAP addresses in the Internet.

The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration.

 
RFC 1651 SMTP Service Extensions
 
Authors:J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1425
Obsoleted by:RFC 1869
Status:DRAFT STANDARD
DOI:10.17487/RFC 1651
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]
 
RFC 1652 SMTP Service Extension for 8bit-MIMEtransport
 
Authors:J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1426
Obsoleted by:RFC 6152
Status:DRAFT STANDARD
DOI:10.17487/RFC 1652
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP.
 
RFC 1653 SMTP Service Extension for Message Size Declaration
 
Authors:J. Klensin, N. Freed, K. Moore.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1427
Obsoleted by:RFC 1870
Status:DRAFT STANDARD
DOI:10.17487/RFC 1653
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.
 
RFC 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2
 
Authors:S. Willis, J. Burruss, J. Chu, Ed..
Date:July 1994
Formats:txt pdf
Obsoleted by:RFC 4273
Status:DRAFT STANDARD
DOI:10.17487/RFC 1657
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 the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]
 
RFC 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2
 
Authors:B. Stewart.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1316
Status:DRAFT STANDARD
DOI:10.17487/RFC 1658
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]
 
RFC 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2
 
Authors:B. Stewart.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1317
Status:DRAFT STANDARD
DOI:10.17487/RFC 1659
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]
 
RFC 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2
 
Authors:B. Stewart.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1318
Status:DRAFT STANDARD
DOI:10.17487/RFC 1660
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]
 
RFC 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2
 
Authors:T. Brown, Ed., K. Tesink, Ed..
Date:August 1994
Formats:txt pdf
Obsoletes:RFC 1304
Status:DRAFT STANDARD
DOI:10.17487/RFC 1694
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 objects for SMDS access interfaces. This includes the following access protocols:

SIP [13]SIP/DXI [18] and [20]SIP/FR [19]SIP/ATM [24]

This memo replaces RFC 1304 [12], and defines a MIB module which is both compliant to the SNMPv2 SMI and semantically-identical to the existing RFC 1304-based definitions.

This memo also assumes application of the MIB II Interfaces group as defined in [9].

 
RFC 1724 RIP Version 2 MIB Extension
 
Authors:G. Malkin, F. Baker.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1389
Status:DRAFT STANDARD
DOI:10.17487/RFC 1724
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 RIP Version 2.
 
RFC 1743 IEEE 802.5 MIB using SMIv2
 
Authors:K. McCloghrie, E. Decker.
Date:December 1994
Formats:txt pdf
Obsoletes:RFC 1231
Obsoleted by:RFC 1748
Status:DRAFT STANDARD
DOI:10.17487/RFC 1743
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 subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
 
RFC 1748 IEEE 802.5 MIB using SMIv2
 
Authors:K. McCloghrie, E. Decker.
Date:December 1994
Formats:txt pdf
Obsoletes:RFC 1743, RFC 1231
Updated by:RFC 1749
Status:DRAFT STANDARD
DOI:10.17487/RFC 1748
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 subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
 
RFC 1757 Remote Network Monitoring Management Information Base
 
Authors:S. Waldbusser.
Date:February 1995
Formats:txt pdf
Obsoletes:RFC 1271
Obsoleted by:RFC 2819
Status:DRAFT STANDARD
DOI:10.17487/RFC 1757
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.
 
RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP)
 
Authors:S. Senum.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1376
Status:DRAFT STANDARD
DOI:10.17487/RFC 1762
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 configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc).

 
RFC 1771 A Border Gateway Protocol 4 (BGP-4)
 
Authors:Y. Rekhter, T. Li.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1654
Obsoleted by:RFC 4271
Status:DRAFT STANDARD
DOI:10.17487/RFC 1771
This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet.
 
RFC 1772 Application of the Border Gateway Protocol in the Internet
 
Authors:Y. Rekhter, P. Gross.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1655
Status:DRAFT STANDARD
DOI:10.17487/RFC 1772
This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" 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 (bgp@ans.net).

 
RFC 1832 XDR: External Data Representation Standard
 
Authors:R. Srinivasan.
Date:August 1995
Formats:txt pdf
Obsoleted by:RFC 4506
Status:DRAFT STANDARD
DOI:10.17487/RFC 1832
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]
 
RFC 1850 OSPF Version 2 Management Information Base
 
Authors:F. Baker, R. Coltun.
Date:November 1995
Formats:txt pdf
Obsoletes:RFC 1253
Obsoleted by:RFC 4750
Status:DRAFT STANDARD
DOI:10.17487/RFC 1850
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 the Open Shortest PathFirst Routing Protocol.
 
RFC 1864 The Content-MD5 Header Field
 
Authors:J. Myers, M. Rose.
Date:October 1995
Formats:txt pdf
Obsoletes:RFC 1544
Status:DRAFT STANDARD
DOI:10.17487/RFC 1864
This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.
 
RFC 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1442
Obsoleted by:RFC 2578
Status:DRAFT STANDARD
DOI:10.17487/RFC 1902
It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]
 
RFC 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1443
Obsoleted by:RFC 2579
Status:DRAFT STANDARD
DOI:10.17487/RFC 1903
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]
 
RFC 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1444
Obsoleted by:RFC 2580
Status:DRAFT STANDARD
DOI:10.17487/RFC 1904
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]
 
RFC 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1448
Obsoleted by:RFC 3416
Status:DRAFT STANDARD
DOI:10.17487/RFC 1905
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]
 
RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1449
Obsoleted by:RFC 3417
Status:DRAFT STANDARD
DOI:10.17487/RFC 1906
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]
 
RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1450
Obsoleted by:RFC 3418
Status:DRAFT STANDARD
DOI:10.17487/RFC 1907
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]
 
RFC 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Obsoletes:RFC 1452
Obsoleted by:RFC 2576
Status:DRAFT STANDARD
DOI:10.17487/RFC 1908
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1>. [STANDARDS-TRACK]
 
RFC 1981 Path MTU Discovery for IP version 6
 
Authors:J. McCann, S. Deering, J. Mogul.
Date:August 1996
Formats:txt pdf
Obsoleted by:RFC 8201
Status:DRAFT STANDARD
DOI:10.17487/RFC 1981
This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery forIP version 4.
 
RFC 1989 PPP Link Quality Monitoring
 
Authors:W. Simpson.
Date:August 1996
Formats:txt pdf
Obsoletes:RFC 1333
Status:DRAFT STANDARD
DOI:10.17487/RFC 1989
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.

This document defines a protocol for generating Link-Quality-Reports.

 
RFC 1990 The PPP Multilink Protocol (MP)
 
Authors:K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti.
Date:August 1996
Formats:txt pdf
Obsoletes:RFC 1717
Status:DRAFT STANDARD
DOI:10.17487/RFC 1990
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.

The differences between the current PPP Multilink specification (RFC1717) and this memo are explained in Section 11. Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations.

 
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP)
 
Authors:W. Simpson.
Date:August 1996
Formats:txt pdf
Obsoletes:RFC 1334
Updated by:RFC 2484
Status:DRAFT STANDARD
DOI:10.17487/RFC 1994
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.

This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key.

 
RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
 
Authors:N. Freed, N. Borenstein.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Updated by:RFC 2184, RFC 2231, RFC 5335, RFC 6532
Status:DRAFT STANDARD
DOI:10.17487/RFC 2045
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other thanUS-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other thanUS-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in

Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions.

 
RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
 
Authors:N. Freed, N. Borenstein.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Updated by:RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098
Status:DRAFT STANDARD
DOI:10.17487/RFC 2046
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other thanUS-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other thanUS-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document,RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.

 
RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
 
Authors:K. Moore.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Updated by:RFC 2184, RFC 2231
Status:DRAFT STANDARD
DOI:10.17487/RFC 2047
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other than US-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other than US-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data inInternet mail header fields.

Other documents in this series include:

+ RFC 2045, which specifies the various headers used to describe the structure of MIME messages.

+ RFC 2046, which defines the general structure of the MIME media typing system and defines an initial set of media types,

+ RFC 2048, which specifies various IANA registration procedures for MIME-related facilities, and

+ RFC 2049, which describes MIME conformance criteria and provides some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions.

 
RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
 
Authors:N. Freed, N. Borenstein.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1521, RFC 1522, RFC 1590
Status:DRAFT STANDARD
DOI:10.17487/RFC 2049
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for

(1) textual message bodies in character sets other thanUS-ASCII,

(2) an extensible set of different formats for non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other thanUS-ASCII.

These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-

ASCII text data in Internet mail header fields. The fourth document,RFC 2048, specifies various IANA registration procedures for MIME- related facilities. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. Appendix B of this document describes differences and changes from previous versions.

 
RFC 2067 IP over HIPPI
 
Authors:J. Renwick.
Date:January 1997
Formats:txt pdf
Status:DRAFT STANDARD
DOI:10.17487/RFC 2067
ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation ofIEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. ANSI X3.222-1993 (HIPPI-SC[4]) describes the operation of HIPPI physical switches. The ANSI committee responsible for these standards chose to leave HIPPI networking issues largely outside the scope of their standards; this document describes the use of HIPPI switches as IP local area networks.

This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. RFC 1374 has been aProposed Standard since November, 1992, with at least 10 implementations of IP encapsulation and HIPPI switch discipline. No major changes to it are required. However, the ARP part of RFC 1374 has not had sufficient implementation experience to be advanced toDraft Standard. The present document contains all of RFC 1374 except for the description ARP, which has been moved into a separate document.

 
RFC 2115 Management Information Base for Frame Relay DTEs Using SMIv2
 
Authors:C. Brown, F. Baker.
Date:September 1997
Formats:txt pdf
Obsoletes:RFC 1315
Status:DRAFT STANDARD
DOI:10.17487/RFC 2115
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 Frame Relay interfaces on DTEs. [STANDARDS-TRACK]
 
RFC 2131 Dynamic Host Configuration Protocol
 
Authors:R. Droms.
Date:March 1997
Formats:txt pdf
Obsoletes:RFC 1541
Updated by:RFC 3396, RFC 4361, RFC 5494, RFC 6842
Status:DRAFT STANDARD
DOI:10.17487/RFC 2131
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9].
 
RFC 2132 DHCP Options and BOOTP Vendor Extensions
 
Authors:S. Alexander, R. Droms.
Date:March 1997
Formats:txt pdf
Obsoletes:RFC 1533
Updated by:RFC 3442, RFC 3942, RFC 4361, RFC 4833, RFC 5494
Status:DRAFT STANDARD
DOI:10.17487/RFC 2132
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called"options."

This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in- notes/iana/assignments [22].

All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions.

 
RFC 2178 OSPF Version 2
 
Authors:J. Moy.
Date:July 1997
Formats:txt pdf
Obsoletes:RFC 1583
Obsoleted by:RFC 2328
Status:DRAFT STANDARD
DOI:10.17487/RFC 2178
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 1583 are explained inAppendix G. All differences are backward-compatible in nature.Implementations of this memo and of RFC 1583 will interoperate.

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

 
RFC 2197 SMTP Service Extension for Command Pipelining
 
Authors:N. Freed.
Date:September 1997
Formats:txt pdf
Obsoletes:RFC 1854
Obsoleted by:RFC 2920
Status:DRAFT STANDARD
DOI:10.17487/RFC 2197
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]
 
RFC 2279 UTF-8, a transformation format of ISO 10646
 
Authors:F. Yergeau.
Date:January 1998
Formats:txt pdf
Obsoletes:RFC 2044
Obsoleted by:RFC 3629
Status:DRAFT STANDARD
DOI:10.17487/RFC 2279
ISO/IEC 10646-1 defines a multi-octet character set called theUniversal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, 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 updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards.
 
RFC 2347 TFTP Option Extension
 
Authors:G. Malkin, A. Harkin.
Date:May 1998
Formats:txt pdf
Obsoletes:RFC 1782
Updates:RFC 1350
Status:DRAFT STANDARD
DOI:10.17487/RFC 2347
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.
 
RFC 2348 TFTP Blocksize Option
 
Authors:G. Malkin, A. Harkin.
Date:May 1998
Formats:txt pdf
Obsoletes:RFC 1783
Updates:RFC 1350
Status:DRAFT STANDARD
DOI:10.17487/RFC 2348
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-octet blocksize is not the most efficient for use on a LAN whose MTU may 1500 octets or greater.

This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2].

 
RFC 2349 TFTP Timeout Interval and Transfer Size Options
 
Authors:G. Malkin, A. Harkin.
Date:May 1998
Formats:txt pdf
Obsoletes:RFC 1784
Updates:RFC 1350
Status:DRAFT STANDARD
DOI:10.17487/RFC 2349
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.

This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2].

 
RFC 2355 TN3270 Enhancements
 
Authors:B. Kelly.
Date:June 1998
Formats:txt pdf
Obsoletes:RFC 1647
Updated by:RFC 6270
Status:DRAFT STANDARD
DOI:10.17487/RFC 2355
This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.

This protocol is negotiated under the TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime Option as defined in RFC 1041[1].

 
RFC 2390 Inverse Address Resolution Protocol
 
Authors:T. Bradley, C. Brown, A. Malis.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 1293
Status:DRAFT STANDARD
DOI:10.17487/RFC 2390
This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]
 
RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
 
Authors:T. Berners-Lee, R. Fielding, L. Masinter.
Date:August 1998
Formats:txt pdf
Obsoleted by:RFC 3986
Updates:RFC 1808, RFC 1738
Updated by:RFC 2732
Status:DRAFT STANDARD
DOI:10.17487/RFC 2396
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808.

This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme.

 
RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
 
Authors:S. Deering, R. Hinden.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1883
Obsoleted by:RFC 8200
Updated by:RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112
Status:DRAFT STANDARD
DOI:10.17487/RFC 2460
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.
 
RFC 2461 Neighbor Discovery for IP Version 6 (IPv6)
 
Authors:T. Narten, E. Nordmark, W. Simpson.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1970
Obsoleted by:RFC 4861
Updated by:RFC 4311
Status:DRAFT STANDARD
DOI:10.17487/RFC 2461
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.
 
RFC 2462 IPv6 Stateless Address Autoconfiguration
 
Authors:S. Thomson, T. Narten.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1971
Obsoleted by:RFC 4862
Status:DRAFT STANDARD
DOI:10.17487/RFC 2462
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.
 
RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
 
Authors:A. Conta, S. Deering.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1885
Obsoleted by:RFC 4443
Status:DRAFT STANDARD
DOI:10.17487/RFC 2463
This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6).
 
RFC 2571 An Architecture for Describing SNMP Management Frameworks
 
Authors:B. Wijnen, D. Harrington, R. Presuhn.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2271
Obsoleted by:RFC 3411
Status:DRAFT STANDARD
DOI:10.17487/RFC 2571
This document describes an architecture for describing SNMPManagement 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 an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.
 
RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
 
Authors:J. Case, D. Harrington, R. Presuhn, B. Wijnen.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2272
Obsoleted by:RFC 3412
Status:DRAFT STANDARD
DOI:10.17487/RFC 2572
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2571]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.
 
RFC 2573 SNMP Applications
 
Authors:D. Levi, P. Meyer, B. Stewart.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2273
Obsoleted by:RFC 3413
Status:DRAFT STANDARD
DOI:10.17487/RFC 2573
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2571]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.

This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.

 
RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
 
Authors:U. Blumenthal, B. Wijnen.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2274
Obsoleted by:RFC 3414
Status:DRAFT STANDARD
DOI:10.17487/RFC 2574
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2571]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.
 
RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
 
Authors:B. Wijnen, R. Presuhn, K. McCloghrie.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2275
Obsoleted by:RFC 3415
Status:DRAFT STANDARD
DOI:10.17487/RFC 2575
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2571]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.
 
RFC 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0
 
Authors:R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser.
Date:June 1999
Formats:txt pdf
Status:DRAFT STANDARD
DOI:10.17487/RFC 2613
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 in switched networks environments.
 
RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1
 
Authors:R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.
Date:June 1999
Formats:txt ps pdf
Obsoletes:RFC 2068
Obsoleted by:RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235
Updated by:RFC 2817, RFC 5785, RFC 6266, RFC 6585
Status:DRAFT STANDARD
DOI:10.17487/RFC 2616
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].

 
RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
 
Authors:J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart.
Date:June 1999
Formats:txt pdf
Obsoletes:RFC 2069
Obsoleted by:RFC 7235, RFC 7615, RFC 7616, RFC 7617
Status:DRAFT STANDARD
DOI:10.17487/RFC 2617
"HTTP/1.0", includes the specification for a Basic AccessAuthentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.

This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "DigestAccess Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified byRFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.

Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.

 
RFC 2741 Agent Extensibility (AgentX) Protocol Version 1
 
Authors:M. Daniele, B. Wijnen, M. Ellison, D. Francisco.
Date:January 2000
Formats:txt pdf
Obsoletes:RFC 2257
Status:DRAFT STANDARD
DOI:10.17487/RFC 2741
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processesSNMP protocol messages. This memo obsoletes RFC 2257.
 
RFC 2742 Definitions of Managed Objects for Extensible SNMP Agents
 
Authors:L. Heintz, S. Gudur, M. Ellison.
Date:January 2000
Formats:txt pdf
Status:DRAFT STANDARD
DOI:10.17487/RFC 2742
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 objects managing SNMP agents that use theAgent Extensibility (AgentX) Protocol.

This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions.

 
RFC 2790 Host Resources MIB
 
Authors:S. Waldbusser, P. Grillo.
Date:March 2000
Formats:txt pdf
Obsoletes:RFC 1514
Status:DRAFT STANDARD
DOI:10.17487/RFC 2790
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the HostResources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.

This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix.

 
RFC 2863 The Interfaces Group MIB
 
Authors:K. McCloghrie, F. Kastenholz.
Date:June 2000
Formats:txt pdf
Obsoletes:RFC 2233
Status:DRAFT STANDARD
DOI:10.17487/RFC 2863
This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS TRACK]
 
RFC 2865 Remote Authentication Dial In User Service (RADIUS)
 
Authors:C. Rigney, S. Willens, A. Rubens, W. Simpson.
Date:June 2000
Formats:txt pdf
Obsoletes:RFC 2138
Updated by:RFC 2868, RFC 3575, RFC 5080, RFC 6929, RFC 8044
Status:DRAFT STANDARD
DOI:10.17487/RFC 2865
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server.
 
RFC 2895 Remote Network Monitoring MIB Protocol Identifier Reference
 
Authors:A. Bierman, C. Bucci, R. Iddon.
Date:August 2000
Formats:txt pdf
Obsoletes:RFC 2074
Updated by:RFC 3395
Status:DRAFT STANDARD
DOI:10.17487/RFC 2895
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network MonitoringManagement Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.

The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON ProtocolIdentifier Macros document [RFC2896] now contains the non-normative portion of that specification.

This document obsoletes RFC 2074.

 
RFC 3191 Minimal GSTN address format in Internet Mail
 
Authors:C. Allocchio.
Date:October 2001
Formats:txt pdf
Obsoletes:RFC 2303
Updates:RFC 2846
Status:DRAFT STANDARD
DOI:10.17487/RFC 3191
This memo describes a simple method of encoding Global SwitchedTelephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services.
 
RFC 3192 Minimal FAX address format in Internet Mail
 
Authors:C. Allocchio.
Date:October 2001
Formats:txt pdf
Obsoletes:RFC 2304
Updates:RFC 2846
Status:DRAFT STANDARD
DOI:10.17487/RFC 3192
This memo describes a simple method of encoding Global SwitchedTelephone Network (GSTN) addresses of facsimile devices in the local-part of Internet email addresses.
 
RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing
 
Authors:D. Eastlake 3rd, J. Reagle, D. Solo.
Date:March 2002
Formats:txt pdf
Obsoletes:RFC 3075
Status:DRAFT STANDARD
DOI:10.17487/RFC 3275
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.
 
RFC 3282 Content Language Headers
 
Authors:H. Alvestrand.
Date:May 2002
Formats:txt pdf
Obsoletes:RFC 1766
Status:DRAFT STANDARD
DOI:10.17487/RFC 3282
This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC822-like headers, like MIME body parts or Web documents, and an"Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language.
 
RFC 3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
 
Authors:G. Parsons, J. Rafferty.
Date:September 2002
Formats:txt pdf
Obsoletes:RFC 2302
Status:DRAFT STANDARD
DOI:10.17487/RFC 3302
This document describes the registration of the MIME sub-type image/tiff. This document refines an earlier sub-type registration in RFC 1528.

This document obsoletes RFC 2302.

 
RFC 3392 Capabilities Advertisement with BGP-4
 
Authors:R. Chandra, J. Scudder.
Date:November 2002
Formats:txt pdf
Obsoletes:RFC 2842
Obsoleted by:RFC 5492
Status:DRAFT STANDARD
DOI:10.17487/RFC 3392
This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 2842.

 
RFC 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
 
Authors:K. Moore.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1891
Updated by:RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098
Status:DRAFT STANDARD
DOI:10.17487/RFC 3461
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service, which allows an SMTP client to specify (a) thatDelivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
 
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
 
Authors:G. Vaudreuil.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1892
Obsoleted by:RFC 6522
Updated by:RFC 5337
Status:DRAFT STANDARD
DOI:10.17487/RFC 3462
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.

This document is part of a four document set describing the delivery status report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure.

 
RFC 3463 Enhanced Mail System Status Codes
 
Authors:G. Vaudreuil.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1893
Updated by:RFC 3886, RFC 4468, RFC 4865, RFC 4954, RFC 5248
Status:DRAFT STANDARD
DOI:10.17487/RFC 3463
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in theDelivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status.
 
RFC 3464 An Extensible Message Format for Delivery Status Notifications
 
Authors:K. Moore, G. Vaudreuil.
Date:January 2003
Formats:txt pdf
Obsoletes:RFC 1894
Updated by:RFC 4865, RFC 5337, RFC 6533
Status:DRAFT STANDARD
DOI:10.17487/RFC 3464
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network(LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.

 
RFC 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type
 
Authors:K. Tesink.
Date:September 2003
Formats:txt pdf
Obsoletes:RFC 2558
Status:DRAFT STANDARD
DOI:10.17487/RFC 3592
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 Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types.

This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause.

 
RFC 3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
 
Authors:K. Tesink, Ed..
Date:September 2003
Formats:txt pdf
Obsoletes:RFC 2493
Status:DRAFT STANDARD
DOI:10.17487/RFC 3593
This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals.

This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause.

 
RFC 3768 Virtual Router Redundancy Protocol (VRRP)
 
Authors:R. Hinden, Ed..
Date:April 2004
Formats:txt pdf
Obsoletes:RFC 2338
Obsoleted by:RFC 5798
Status:DRAFT STANDARD
DOI:10.17487/RFC 3768
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.
 
RFC 3798 Message Disposition Notification
 
Authors:T. Hansen, Ed., G. Vaudreuil, Ed..
Date:May 2004
Formats:txt pdf
Obsoletes:RFC 2298
Obsoleted by:RFC 8098
Updates:RFC 3461, RFC 2046
Updated by:RFC 5337, RFC 6533
Status:DRAFT STANDARD
DOI:10.17487/RFC 3798
This memo defines a MIME content-type that may be used by a mail user agent (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 headers 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 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 multi- protocol 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.

 
RFC 3801 Voice Profile for Internet Mail - version 2 (VPIMv2)
 
Authors:G. Vaudreuil, G. Parsons.
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2421, RFC 2423
Status:DRAFT STANDARD
DOI:10.17487/RFC 3801
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional InternetEmail-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.

This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in AppendixF. Appendix A summarizes the protocol profiles of this version ofVPIM.

 
RFC 3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration
 
Authors:G. Vaudreuil, G. Parsons.
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2422
Status:DRAFT STANDARD
DOI:10.17487/RFC 3802
This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T inRecommendation G.726.
 
RFC 3803 Content Duration MIME Header Definition
 
Authors:G. Vaudreuil, G. Parsons.
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2424
Status:DRAFT STANDARD
DOI:10.17487/RFC 3803
This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*).
 
RFC 3848 ESMTP and LMTP Transmission Types Registration
 
Authors:C. Newman.
Date:July 2004
Formats:txt pdf
Status:DRAFT STANDARD
DOI:10.17487/RFC 3848
This registers seven new mail transmission types (ESMTPA, ESMTPS,ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message.
 
RFC 3912 WHOIS Protocol Specification
 
Authors:L. Daigle.
Date:September 2004
Formats:txt pdf
Obsoletes:RFC 0954, RFC 0812
Status:DRAFT STANDARD
DOI:10.17487/RFC 3912
This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954.
 
RFC 3949 File Format for Internet Fax
 
Authors:R. Buckley, D. Venable, L. McIntyre, G. Parsons, J. Rafferty.
Date:February 2005
Formats:txt pdf
Obsoletes:RFC 2301
Status:DRAFT STANDARD
DOI:10.17487/RFC 3949
This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.

This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the InternationalTelecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group(JBIG) profiles (Profiles S, F, J) for black-and-white fax and baseJPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C,L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations.

 
RFC 3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration
 
Authors:L. McIntyre, G. Parsons, J. Rafferty.
Date:February 2005
Formats:txt pdf
Obsoletes:RFC 3250
Status:DRAFT STANDARD
DOI:10.17487/RFC 3950
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions.
 
RFC 3965 A Simple Mode of Facsimile Using Internet Mail
 
Authors:K. Toyoda, H. Ohno, J. Murai, D. Wing.
Date:December 2004
Formats:txt pdf
Obsoletes:RFC 2305
Status:DRAFT STANDARD
DOI:10.17487/RFC 3965
This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow.The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet MailExtensions (MIME), and Tagged Image File Format (TIFF) for Facsimile.It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.

This document is a revision of RFC 2305. There have been no technical changes.

 
RFC 4234 Augmented BNF for Syntax Specifications: ABNF
 
Authors:D. Crocker, Ed., P. Overell.
Date:October 2005
Formats:txt pdf
Obsoletes:RFC 2234
Obsoleted by:RFC 5234
Status:DRAFT STANDARD
DOI:10.17487/RFC 4234
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.
 
RFC 4271 A Border Gateway Protocol 4 (BGP-4)
 
Authors:Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed..
Date:January 2006
Formats:txt pdf
Obsoletes:RFC 1771
Updated by:RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212
Status:DRAFT STANDARD
DOI:10.17487/RFC 4271
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list ofAutonomous Systems (ASes) that reachability information traverses.This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation ofAS paths.

This document obsoletes RFC 1771.

 
RFC 4291 IP Version 6 Addressing Architecture
 
Authors:R. Hinden, S. Deering.
Date:February 2006
Formats:txt pdf
Obsoletes:RFC 3513
Updated by:RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064
Status:DRAFT STANDARD
DOI:10.17487/RFC 4291
This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.

This document obsoletes RFC 3513, "IP Version 6 AddressingArchitecture".

 
RFC 4409 Message Submission for Mail
 
Authors:R. Gellens, J. Klensin.
Date:April 2006
Formats:txt pdf
Obsoletes:RFC 2476
Obsoleted by:RFC 6409
Status:DRAFT STANDARD
DOI:10.17487/RFC 4409
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 and final delivery are unaffected, and continue to useSMTP 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.

 
RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
 
Authors:T. Bates, E. Chen, R. Chandra.
Date:April 2006
Formats:txt pdf
Obsoletes:RFC 2796, RFC 1966
Updated by:RFC 7606
Status:DRAFT STANDARD
DOI:10.17487/RFC 4456
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.

This document describes the use and design of a method known as"route reflection" to alleviate the need for "full mesh" Internal BGP(IBGP).

This document obsoletes RFC 2796 and RFC 1966.

 
RFC 4502 Remote Network Monitoring Management Information Base Version 2
 
Authors:S. Waldbusser.
Date:May 2006
Formats:txt pdf
Obsoletes:RFC 2021
Updates:RFC 3273
Status:DRAFT STANDARD
DOI:10.17487/RFC 4502
This document 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 document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module.

 
RFC 4760 Multiprotocol Extensions for BGP-4
 
Authors:T. Bates, R. Chandra, D. Katz, Y. Rekhter.
Date:January 2007
Formats:txt pdf
Obsoletes:RFC 2858
Updated by:RFC 7606
Status:DRAFT STANDARD
DOI:10.17487/RFC 4760
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6,IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
 
RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
 
Authors:T. Narten, E. Nordmark, W. Simpson, H. Soliman.
Date:September 2007
Formats:txt pdf
Obsoletes:RFC 2461
Updated by:RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425
Status:DRAFT STANDARD
DOI:10.17487/RFC 4861
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.
 
RFC 4862 IPv6 Stateless Address Autoconfiguration
 
Authors:S. Thomson, T. Narten, T. Jinmei.
Date:September 2007
Formats:txt pdf
Obsoletes:RFC 2462
Updated by:RFC 7527
Status:DRAFT STANDARD
DOI:10.17487/RFC 4862
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the DuplicateAddress Detection procedure to verify the uniqueness of the addresses on a link.
 
RFC 4930 Extensible Provisioning Protocol (EPP)
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3730
Obsoleted by:RFC 5730
Status:DRAFT STANDARD
DOI:10.17487/RFC 4930
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 3730.
 
RFC 4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3731
Obsoleted by:RFC 5731
Status:DRAFT STANDARD
DOI:10.17487/RFC 4931
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 3731.
 
RFC 4932 Extensible Provisioning Protocol (EPP) Host Mapping
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3732
Obsoleted by:RFC 5732
Status:DRAFT STANDARD
DOI:10.17487/RFC 4932
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 3732.
 
RFC 4933 Extensible Provisioning Protocol (EPP) Contact Mapping
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3733
Obsoleted by:RFC 5733
Status:DRAFT STANDARD
DOI:10.17487/RFC 4933
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733.
 
RFC 4934 Extensible Provisioning Protocol (EPP) Transport Over TCP
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3734
Obsoleted by:RFC 5734
Status:DRAFT STANDARD
DOI:10.17487/RFC 4934
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 3734.
 
RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
Authors:T. Narten, R. Draves, S. Krishnan.
Date:September 2007
Formats:txt pdf
Obsoletes:RFC 3041
Status:DRAFT STANDARD
DOI:10.17487/RFC 4941
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
 
RFC 5036 LDP Specification
 
Authors:L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed..
Date:October 2007
Formats:txt pdf
Obsoletes:RFC 3036
Updated by:RFC 6720, RFC 6790, RFC 7358, RFC 7552
Status:DRAFT STANDARD
DOI:10.17487/RFC 5036
The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
 
RFC 5065 Autonomous System Confederations for BGP
 
Authors:P. Traina, D. McPherson, J. Scudder.
Date:August 2007
Formats:txt pdf
Obsoletes:RFC 3065
Status:DRAFT STANDARD
DOI:10.17487/RFC 5065
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.

This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

This document obsoletes RFC 3065.

 
RFC 5072 IP Version 6 over PPP
 
Authors:S. Varada, Ed., D. Haskins, E. Allen.
Date:September 2007
Formats:txt pdf
Obsoletes:RFC 2472
Updated by:RFC 8064
Status:DRAFT STANDARD
DOI:10.17487/RFC 5072
The Point-to-Point Protocol (PPP) 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 method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.

It also specifies the conditions for performing Duplicate AddressDetection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.

This document obsoletes RFC 2472.

 
RFC 5321 Simple Mail Transfer Protocol
 
Authors:J. Klensin.
Date:October 2008
Formats:txt pdf
Obsoletes:RFC 2821
Updates:RFC 1123
Updated by:RFC 7504
Status:DRAFT STANDARD
DOI:10.17487/RFC 5321
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments.
 
RFC 5322 Internet Message Format
 
Authors:P. Resnick, Ed..
Date:October 2008
Formats:txt pdf
Obsoletes:RFC 2822
Updates:RFC 4021
Updated by:RFC 6854
Status:DRAFT STANDARD
DOI:10.17487/RFC 5322
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself supersededRequest For Comments (RFC) 822, "Standard for the Format of ARPAInternet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.
 
RFC 5492 Capabilities Advertisement with BGP-4
 
Authors:J. Scudder, R. Chandra.
Date:February 2009
Formats:txt pdf
Obsoletes:RFC 3392
Status:DRAFT STANDARD
DOI:10.17487/RFC 5492
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392.

 
RFC 5531 RPC: Remote Procedure Call Protocol Specification Version 2
 
Authors:R. Thurlow.
Date:May 2009
Formats:txt pdf
Obsoletes:RFC 1831
Status:DRAFT STANDARD
DOI:10.17487/RFC 5531
This document describes the Open Network Computing (ONC) RemoteProcedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831.
 
RFC 5681 TCP Congestion Control
 
Authors:M. Allman, V. Paxson, E. Blanton.
Date:September 2009
Formats:txt pdf
Obsoletes:RFC 2581
Status:DRAFT STANDARD
DOI:10.17487/RFC 5681
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581.