| |
| RFC 951 | Bootstrap Protocol |
| |
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
|
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK] |
|
| |
| RFC 1247 | OSPF Version 2 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
|
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 |
| |
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
| |
|
|
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 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
|
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 |
| |
|
|
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) |
| |
|
|
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 |
|
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 |
|
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 |
|
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 |
| |
|
|
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 |
|
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 |
|
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 |
| Status: | DRAFT STANDARD |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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, K. Tesink, Eds.. |
| Date: | August 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1304 |
| Status: | DRAFT STANDARD |
|
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 |
|
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 |
|
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 |
| |
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
| Status: | DRAFT STANDARD |
|
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 |
|
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 |
|
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 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
|
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 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
| For |
| |
