| |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK] |
|
| |
| RFC 1490 | Multiprotocol Interconnect over Frame Relay |
| |
|
|
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. 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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 html json |
| 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 json html |
| 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 html json |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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) |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 html json |
| 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 html pdf json |
| 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 |
| |
|
|
"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 json html |
| 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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 html json |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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 json html |
| Obsoletes: | RFC 1771 |
| Updated by: | RFC 4724, RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072, RFC 9687 |
| 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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2461 |
| Updated by: | RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131, RFC 9685 |
| 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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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. |
|
