Internet Documents RFCs RFCs All Documents STDs Internet Standards Documents BCPs Best Current Practice Documents FYIs Informational Documents

RFC 698	Telnet extended ASCII option
	Authors: T. Mock. Date: July 1975 Formats: txt pdf Obsoleted by: RFC 5198 Status: PROPOSED STANDARD Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.
RFC 726	Remote Controlled Transmission and Echoing Telnet option
	Authors: J. Postel, D. Crocker. Date: March 1977 Formats: txt pdf Status: PROPOSED STANDARD
RFC 727	Telnet logout option
	Authors: M.R. Crispin. Date: April 1977 Formats: txt pdf Status: PROPOSED STANDARD
RFC 735	Revised Telnet byte macro option
	Authors: D. Crocker, R.H. Gumpertz. Date: November 1977 Formats: txt pdf Obsoletes: RFC 0729 Status: PROPOSED STANDARD
RFC 736	Telnet SUPDUP option
	Authors: M.R. Crispin. Date: October 1977 Formats: txt pdf Status: PROPOSED STANDARD
RFC 749	Telnet SUPDUP-Output option
	Authors: B. Greenberg. Date: September 1978 Formats: txt pdf Status: PROPOSED STANDARD
RFC 779	Telnet send-location option
	Authors: E. Killian. Date: April 1981 Formats: txt pdf Status: PROPOSED STANDARD
RFC 885	Telnet end of record option
	Authors: J. Postel. Date: December 1983 Formats: txt pdf Status: PROPOSED STANDARD This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.
RFC 927	TACACS user identification Telnet option
	Authors: B.A. Anderson. Date: December 1984 Formats: txt pdf Status: PROPOSED STANDARD The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC 933	Output marking Telnet option
	Authors: S. Silverman. Date: January 1985 Formats: txt pdf Status: PROPOSED STANDARD This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.
RFC 946	Telnet terminal location number option
	Authors: R. Nedved. Date: May 1985 Formats: txt pdf Status: PROPOSED STANDARD Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC 977	Network News Transfer Protocol
	Authors: B. Kantor, P. Lapsley. Date: February 1986 Formats: txt pdf Obsoleted by: RFC 3977 Status: PROPOSED STANDARD NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC 1041	Telnet 3270 regime option
	Authors: Y. Rekhter. Date: January 1988 Formats: txt pdf Updated by: RFC 6270 Status: PROPOSED STANDARD This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.
RFC 1043	Telnet Data Entry Terminal option: DODIIS implementation
	Authors: A. Yasuda, T. Thompson. Date: February 1988 Formats: txt pdf Updates: RFC 0732 Status: PROPOSED STANDARD This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.
RFC 1053	Telnet X.3 PAD option
	Authors: S. Levy, T. Jacobson. Date: April 1988 Formats: txt pdf Status: PROPOSED STANDARD This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.
RFC 1073	Telnet window size option
	Authors: D. Waitzman. Date: October 1988 Formats: txt pdf Status: PROPOSED STANDARD This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.
RFC 1079	Telnet terminal speed option
	Authors: C.L. Hedrick. Date: December 1988 Formats: txt pdf Status: PROPOSED STANDARD This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.
RFC 1091	Telnet terminal-type option
	Authors: J. VanBokkelen. Date: February 1989 Formats: txt pdf Obsoletes: RFC 0930 Status: PROPOSED STANDARD This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate
RFC 1096	Telnet X display location option
	Authors: G.A. Marcy. Date: March 1989 Formats: txt pdf Status: PROPOSED STANDARD This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.
RFC 1116	Telnet Linemode option
	Authors: D.A. Borman. Date: August 1989 Formats: txt pdf Obsoleted by: RFC 1184 Status: PROPOSED STANDARD Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]
RFC 1131	OSPF specification
	Authors: J. Moy. Date: October 1989 Formats: txt pdf ps Obsoleted by: RFC 1247 Status: PROPOSED STANDARD This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]
RFC 1134	Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links
	Authors: D. Perkins. Date: November 1989 Formats: txt pdf Obsoleted by: RFC 1171 Status: PROPOSED 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 1139	Echo function for ISO 8473
	Authors: R.A. Hagens. Date: January 1990 Formats: txt pdf Obsoleted by: RFC 1574, RFC 1575 Status: PROPOSED STANDARD This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard.
RFC 1144	Compressing TCP/IP Headers for Low-Speed Serial Links
	Authors: V. Jacobson. Date: February 1990 Formats: txt pdf ps Status: PROPOSED STANDARD This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS- TRACK]
RFC 1158	Management Information Base for network management of TCP/IP-based internets: MIB-II
	Authors: M.T. Rose. Date: May 1990 Formats: txt pdf Obsoleted by: RFC 1213 Status: PROPOSED STANDARD This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]
RFC 1172	Point-to-Point Protocol (PPP) initial configuration options
	Authors: D. Perkins, R. Hobby. Date: July 1990 Formats: txt pdf Obsoleted by: RFC 1331, RFC 1332 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of 1) a method for encapsulating datagrams over serial links,2) an extensible Link Control Protocol (LCP), and3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called theIP Control Protocol, IPCP) are defined in The Point-to-Point Protocol(PPP) [1]. This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme.
RFC 1195	Use of OSI IS-IS for routing in TCP/IP and dual environments
	Authors: R.W. Callon. Date: December 1990 Formats: txt pdf ps Updated by: RFC 1349, RFC 5302, RFC 5304 Status: PROPOSED STANDARD This RFC specifies an integrated routing protocol, based on the OSIIntra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering TaskForce. The OSI IS-IS protocol has reached a mature state, and is ready for implementation and operational use. The most recent version of theOSI IS-IS protocol is contained in ISO DP 10589 [1]. The proposed standard for using IS-IS for support of TCP/IP will therefore make use of this version (with a minor bug correction, as discussed inAnnex B). We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when available. Comments should be sent to "isis@merit.edu".
RFC 1220	Point-to-Point Protocol extensions for bridging
	Authors: F. Baker. Date: April 1991 Formats: txt pdf Obsoleted by: RFC 1638 Status: PROPOSED STANDARD This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]
RFC 1229	Extensions to the generic-interface MIB
	Authors: K. McCloghrie. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1573 Updated by: RFC 1239 Status: PROPOSED STANDARD This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK]
RFC 1231	IEEE 802.5 Token Ring MIB
	Authors: K. McCloghrie, R. Fox, E. Decker. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1743, RFC 1748 Updated by: RFC 1239 Status: PROPOSED STANDARD This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines 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 1232	Definitions of managed objects for the DS1 Interface type
	Authors: F. Baker, C.P. Kolb. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1406 Updated by: RFC 1239 Status: PROPOSED STANDARD
RFC 1233	Definitions of managed objects for the DS3 Interface type
	Authors: T.A. Cox, K. Tesink. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1407 Updated by: RFC 1239 Status: PROPOSED STANDARD This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]
RFC 1237	Guidelines for OSI NSAP Allocation in the Internet
	Authors: R. Colella, E. Gardner, R. Callon. Date: July 1991 Formats: txt pdf ps Obsoleted by: RFC 1629 Status: PROPOSED STANDARD This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]
RFC 1243	AppleTalk Management Information Base
	Authors: S. Waldbusser. Date: July 1991 Formats: txt pdf Obsoleted by: RFC 1742 Status: PROPOSED STANDARD This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]
RFC 1248	OSPF Version 2 Management Information Base
	Authors: F. Baker, R. Coltun. Date: July 1991 Formats: txt pdf Obsoleted by: RFC 1252 Updated by: RFC 1349 Status: PROPOSED STANDARD This memo defines an experimental 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 OSPF Version 2. [STANDARDS-TRACK]
RFC 1252	OSPF Version 2 Management Information Base
	Authors: F. Baker, R. Coltun. Date: August 1991 Formats: txt pdf Obsoletes: RFC 1248 Obsoleted by: RFC 1253 Also: RFC 1247, RFC 1245 Status: PROPOSED 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 OSPF Version 2. [STANDARDS- TRACK]
RFC 1253	OSPF Version 2 Management Information Base
	Authors: F. Baker, R. Coltun. Date: August 1991 Formats: txt pdf Obsoletes: RFC 1252 Obsoleted by: RFC 1850 Also: RFC 1247, RFC 1245, RFC 1246 Status: PROPOSED 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 OSPF Version 2. [STANDARDS- TRACK]
RFC 1256	ICMP Router Discovery Messages
	Authors: S. Deering, Ed.. Date: September 1991 Formats: txt pdf Also: RFC 0792 Status: PROPOSED STANDARD This document specifies an extension of the Internet Control MessageProtocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers.
RFC 1269	Definitions of Managed Objects for the Border Gateway Protocol: Version 3
	Authors: S. Willis, J.W. Burruss. Date: October 1991 Formats: txt pdf Obsoleted by: RFC 4273 Status: PROPOSED 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 Border Gateway Protocol. [STANDARDS-TRACK]
RFC 1271	Remote Network Monitoring Management Information Base
	Authors: S. Waldbusser. Date: November 1991 Formats: txt pdf Obsoleted by: RFC 1757 Updated by: RFC 1513 Status: PROPOSED 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. [STANDARDS-TRACK]
RFC 1274	The COSINE and Internet X.500 Schema
	Authors: P. Barker, S. Kille. Date: November 1991 Formats: txt pdf Obsoleted by: RFC 4524 Status: PROPOSED STANDARD This document suggests an X.500 Directory Schema, or NamingArchitecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema. This document also proposes a mechanism for allowing the schema to evolve in line with emerging requirements. Proformas to support this process are included. Corrections and additions to the schema should be sent to na- update@cs.ucl.ac.uk list, as described within.
RFC 1277	Encoding Network Addresses to Support Operation over Non-OSI Lower Layers
	Authors: S.E. Hardcastle-Kille. Date: November 1991 Formats: txt ps pdf Status: PROPOSED STANDARD The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSINetwork Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSINetwork Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a globalOSI Network Service. This document defines a new network address format, and rules for using some existing network address formats. The scope of this document is:
RFC 1284	Definitions of Managed Objects for the Ethernet-like Interface Types
	Authors: J. Cook, Ed.. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1398 Status: PROPOSED 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. [STANDARDS-TRACK]
RFC 1286	Definitions of Managed Objects for Bridges
	Authors: E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1493, RFC 1525 Status: PROPOSED 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 bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]
RFC 1289	DECnet Phase IV MIB Extensions
	Authors: J. Saperia. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1559 Status: PROPOSED STANDARD This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. When used in conjunction with the structure of management information (RFC 1155), the management information base for network management of TCP/IP-based internets(RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of combinedTCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the InternetEngineering Task Force (IETF).
RFC 1293	Inverse Address Resolution Protocol
	Authors: T. Bradley, C. Brown. Date: January 1992 Formats: txt pdf Obsoleted by: RFC 2390 Status: PROPOSED STANDARD 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 1294	Multiprotocol Interconnect over Frame Relay
	Authors: T. Bradley, C. Brown, A. Malis. Date: January 1992 Formats: txt pdf Obsoleted by: RFC 1490, RFC 2427 Status: PROPOSED 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. [STANDARDS-TRACK]
RFC 1304	Definitions of Managed Objects for the SIP Interface Type
	Authors: T. Cox, K. Tesink, Eds.. Date: February 1992 Formats: txt pdf Obsoleted by: RFC 1694 Status: PROPOSED 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 SIP (SMDS InterfaceProtocol) objects.
RFC 1315	Management Information Base for Frame Relay DTEs
	Authors: C. Brown, F. Baker, C. Carvalho. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 2115 Status: PROPOSED 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.
RFC 1316	Definitions of Managed Objects for Character Stream Devices
	Authors: B. Stewart. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 1658 Status: PROPOSED 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 the management of character stream devices. [STANDARDS-TRACK]
RFC 1317	Definitions of Managed Objects for RS-232-like Hardware Devices
	Authors: B. Stewart. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 1659 Status: PROPOSED 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 the management of RS-232-like devices. [STANDARDS-TRACK]
RFC 1318	Definitions of Managed Objects for Parallel-printer-like Hardware Devices
	Authors: B. Stewart. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 1660 Status: PROPOSED 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 the management of parallel-printer- like devices. [STANDARDS-TRACK]
RFC 1323	TCP Extensions for High Performance
	Authors: V. Jacobson, R. Braden, D. Borman. Date: May 1992 Formats: txt pdf Obsoletes: RFC 1072, RFC 1185 Status: PROPOSED STANDARD This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms:RTTM (Round Trip Time Measurement) and PAWS (Protect Against WrappedSequences). Selective acknowledgments are not included in this memo. This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs.
RFC 1327	Mapping between X.400(1988) / ISO 10021 and RFC 822
	Authors: S. Hardcastle-Kille. Date: May 1992 Formats: txt pdf Obsoletes: RFC 0987, RFC 1026, RFC 1138, RFC 1148 Obsoleted by: RFC 2156 Updates: RFC 0822 Updated by: RFC 1495 Status: PROPOSED STANDARD This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 1988)Recommendations on Message Handling Systems / ISO IEC 10021 MessageOriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and systems using the RFC 822 mail protocol [Crocker82a] or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings.The mappings should not require any changes to end systems. This document is a revision based on RFCs 987, 1026, 1138, and 1148[Kille86a,Kille87a] which it obsoletes. This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on theDARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected.
RFC 1331	The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links
	Authors: W. Simpson. Date: May 1992 Formats: txt pdf Obsoletes: RFC 1171, RFC 1172 Obsoleted by: RFC 1548 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating datagrams over serial links. 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 encapsulation scheme, together with thePPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1332	The PPP Internet Protocol Control Protocol (IPCP)
	Authors: G. McGregor. Date: May 1992 Formats: txt pdf Obsoletes: RFC 1172 Updated by: RFC 3241 Status: PROPOSED 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 configuring theInternet Protocol [2] over PPP, and a method to negotiate and use VanJacobson TCP/IP header compression [3] with PPP. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).
RFC 1333	PPP Link Quality Monitoring
	Authors: W. Simpson. Date: May 1992 Formats: txt pdf Obsoleted by: RFC 1989 Status: PROPOSED 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, 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. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1334	PPP Authentication Protocols
	Authors: B. Lloyd, W. Simpson. Date: October 1992 Formats: txt pdf Obsoleted by: RFC 1994 Status: PROPOSED 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, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines two protocols for Authentication: the PasswordAuthentication Protocol and the Challenge-Handshake AuthenticationProtocol. This memo is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1341	MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
	Authors: N. Borenstein, N. Freed. Date: June 1992 Formats: txt pdf ps Obsoleted by: RFC 1521 Status: PROPOSED STANDARD 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. [STANDARDS-TRACK]
RFC 1342	Representation of Non-ASCII Text in Internet Message Headers
	Authors: K. Moore. Date: June 1992 Formats: txt pdf Obsoleted by: RFC 1522 Status: PROPOSED STANDARD This memo describes an extension to the message format defined in [1](known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC822 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 1341.
RFC 1349	Type of Service in the Internet Protocol Suite
	Authors: P. Almquist. Date: July 1992 Formats: txt pdf Obsoleted by: RFC 2474 Updates: RFC 1248, RFC 1247, RFC 1195, RFC 1123, RFC 1122, RFC 1060, RFC 0791 Status: PROPOSED STANDARD This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]
RFC 1354	IP Forwarding Table MIB
	Authors: F. Baker. Date: July 1992 Formats: txt pdf Obsoleted by: RFC 2096 Status: PROPOSED 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 routes in the IPInternet. It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table. This adds the ability to set or display multi-path routes, and varying routes by network management policy.
RFC 1364	BGP OSPF Interaction
	Authors: K. Varadhan. Date: September 1992 Formats: txt pdf Obsoleted by: RFC 1403 Also: RFC 1247, RFC 1267 Status: PROPOSED STANDARD This memo defines the various criteria to be used when designingAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP.
RFC 1368	Definition of Managed Objects for IEEE 802.3 Repeater Devices
	Authors: D. McMaster, K. McCloghrie. Date: October 1992 Formats: txt pdf Obsoleted by: RFC 1516 Status: PROPOSED 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 IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs."
RFC 1372	Telnet Remote Flow Control Option
	Authors: C. Hedrick, D. Borman. Date: October 1992 Formats: txt pdf Obsoletes: RFC 1080 Status: PROPOSED STANDARD This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]
RFC 1374	IP and ARP on HIPPI
	Authors: J. Renwick, A. Nicholson. Date: October 1992 Formats: txt pdf Obsoleted by: RFC 2834 Status: PROPOSED STANDARD The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP onHIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks.
RFC 1376	The PPP DECnet Phase IV Control Protocol (DNCP)
	Authors: S. Senum. Date: November 1992 Formats: txt pdf Obsoleted by: RFC 1762 Status: PROPOSED 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 1377	The PPP OSI Network Layer Control Protocol (OSINLCP)
	Authors: D. Katz. Date: November 1992 Formats: txt pdf Status: PROPOSED 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 configuring OSINetwork Layer Protocols. This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1381	SNMP MIB Extension for X.25 LAPB
	Authors: D. Throop, F. Baker. Date: November 1992 Formats: txt pdf Status: PROPOSED 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 Link Layer ofX.25, LAPB. The objects defined here, along with the objects in the"SNMP MIB Extension for the Packet Layer of X.25" [9] and the"Definitions of Managed Objects for RS-232-like Hardware Devices"[8], combine to allow management of an X.25 protocol stack.
RFC 1382	SNMP MIB Extension for the X.25 Packet Layer
	Authors: D. Throop, Ed.. Date: November 1992 Formats: txt pdf Status: PROPOSED 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 Packet Layer ofX.25. The objects defined here, along with the objects in the "SNMPMIB Extension for LAPB" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8], combine to allow management of an X.25 protocol stack.
RFC 1388	RIP Version 2 Carrying Additional Information
	Authors: G. Malkin. Date: January 1993 Formats: txt pdf Obsoleted by: RFC 1723 Updates: RFC 1058 Status: PROPOSED STANDARD This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security.A companion document will define the SNMP MIB objects for RIP-2 [2].
RFC 1389	RIP Version 2 MIB Extensions
	Authors: G. Malkin, F. Baker. Date: January 1993 Formats: txt pdf Obsoleted by: RFC 1724 Status: PROPOSED 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 1406	Definitions of Managed Objects for the DS1 and E1 Interface Types
	Authors: F. Baker, J. Watt, Eds.. Date: January 1993 Formats: txt pdf Obsoletes: RFC 1232 Obsoleted by: RFC 2495 Status: PROPOSED 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 DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. This document entirely replaces RFC 1232, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1232 should not be implemented.
RFC 1407	Definitions of Managed Objects for the DS3/E3 Interface Type
	Authors: T. Cox, K. Tesink. Date: January 1993 Formats: txt pdf Obsoletes: RFC 1233 Obsoleted by: RFC 2496 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3Interfaces. This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type. This document entirely replaces RFC 1233, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1233 should not be implemented.
RFC 1413	Identification Protocol
	Authors: M. St. Johns. Date: February 1993 Formats: txt pdf Obsoletes: RFC 0931 Status: PROPOSED STANDARD The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]
RFC 1420	SNMP over IPX
	Authors: S. Bostock. Date: March 1993 Formats: txt pdf Obsoletes: RFC 1298 Status: PROPOSED STANDARD This document defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2].
RFC 1425	SMTP Service Extensions
	Authors: J. Klensin, WG Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. Date: February 1993 Formats: txt pdf Obsoleted by: RFC 1651 Status: PROPOSED 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 1426	SMTP Service Extension for 8bit-MIMEtransport
	Authors: J. Klensin, WG Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. Date: February 1993 Formats: txt pdf Obsoleted by: RFC 1652 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex
RFC 1427	SMTP Service Extension for Message Size Declaration
	Authors: J. Klensin, WG Chair, N. Freed, Ed., K. Moore. Date: February 1993 Formats: txt pdf Obsoleted by: RFC 1653 Status: PROPOSED 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. [STANDARDS-TRACK]
RFC 1442	Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1902 Status: PROPOSED STANDARD Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]
RFC 1443	Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1903 Status: PROPOSED STANDARD It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]
RFC 1444	Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1904 Status: PROPOSED 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 1448	Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1905 Status: PROPOSED 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 1449	Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1906 Status: PROPOSED STANDARD It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]
RFC 1450	Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1907 Status: PROPOSED STANDARD It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]
RFC 1452	Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1908 Status: PROPOSED STANDARD The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]
RFC 1471	The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol
	Authors: F. Kastenholz. Date: June 1993 Formats: txt pdf Status: PROPOSED 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 describes managed objects used for managing theLink Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10,11, & 12].
RFC 1472	The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol
	Authors: F. Kastenholz. Date: June 1993 Formats: txt pdf Status: PROPOSED 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 describes managed objects used for managing theSecurity Protocols on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12].
RFC 1473	The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol
	Authors: F. Kastenholz. Date: June 1993 Formats: txt pdf Status: PROPOSED 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 describes managed objects used for managing the IPNetwork Control Protocol on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12].
RFC 1483	Multiprotocol Encapsulation over ATM Adaptation Layer 5
	Authors: Juha Heinanen. Date: July 1993 Formats: txt pdf Obsoleted by: RFC 2684 Status: PROPOSED STANDARD This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit.
RFC 1488	The X.500 String Representation of Standard Attribute Syntaxes
	Authors: T. Howes, S. Kille, W. Yeong, C. Robbins. Date: July 1993 Formats: txt pdf Obsoleted by: RFC 1778 Status: PROPOSED STANDARD The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].
RFC 1495	Mapping between X.400 and RFC-822 Message Bodies
	Authors: H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. Date: August 1993 Formats: txt pdf Obsoleted by: RFC 2156 Updates: RFC 1327 Status: PROPOSED STANDARD Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]
RFC 1508	Generic Security Service Application Program Interface
	Authors: J. Linn. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 2078 Status: PROPOSED STANDARD This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
RFC 1509	Generic Security Service API : C-bindings
	Authors: J. Wray. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 2744 Status: PROPOSED STANDARD This document specifies C language bindings for the Generic SecurityService Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.
RFC 1510	The Kerberos Network Authentication Service (V5)
	Authors: J. Kohl, C. Neuman. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 4120 Status: PROPOSED STANDARD This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites.
RFC 1514	Host Resources MIB
	Authors: P. Grillo, S. Waldbusser. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 2790 Status: PROPOSED STANDARD 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 1515	Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
	Authors: D. McMaster, K. McCloghrie, S. Roberts. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 3636 Status: PROPOSED STANDARD 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 IEEE 802.3Medium Attachment Units (MAUs).
RFC 1519	Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
	Authors: V. Fuller, T. Li, J. Yu, K. Varadhan. Date: September 1993 Formats: txt pdf Obsoletes: RFC 1338 Obsoleted by: RFC 4632 Status: PROPOSED STANDARD This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers.
RFC 1531	Dynamic Host Configuration Protocol
	Authors: R. Droms. Date: October 1993 Formats: txt pdf Obsoleted by: RFC 1541 Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP 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, 23], and DHCP participants can interoperate with BOOTP participants [9].
RFC 1532	Clarifications and Extensions for the Bootstrap Protocol
	Authors: W. Wimer. Date: October 1993 Formats: txt pdf Obsoleted by: RFC 1542 Updates: RFC 0951 Status: PROPOSED STANDARD 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. In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these.
RFC 1533	DHCP Options and BOOTP Vendor Extensions
	Authors: S. Alexander, R. Droms. Date: October 1993 Formats: txt pdf Obsoletes: RFC 1497, RFC 1395, RFC 1084, RFC 1048 Obsoleted by: RFC 2132 Status: PROPOSED STANDARD 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. This document will be periodically updated as new options are defined.Each superseding document will include the entire current list of valid options. 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 1541	Dynamic Host Configuration Protocol
	Authors: R. Droms. Date: October 1993 Formats: txt pdf Obsoletes: RFC 1531 Obsoleted by: RFC 2131 Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP 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, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC1531 in the editorial process, this memo is reissued as RFC 1541.
RFC 1544	The Content-MD5 Header Field
	Authors: M. Rose. Date: November 1993 Formats: txt pdf Obsoleted by: RFC 1864 Status: PROPOSED STANDARD This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.
RFC 1565	Network Services Monitoring MIB
	Authors: S. Kille, N. Freed. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2248 Status: PROPOSED STANDARD This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]
RFC 1566	Mail Monitoring MIB
	Authors: S. Kille, N. Freed. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2249, RFC 2789 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]
RFC 1567	X.500 Directory Monitoring MIB
	Authors: G. Mansfield, S. Kille. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2605 Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB). It defines the MIB for monitoring Directory System Agents(DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs.
RFC 1570	PPP LCP Extensions
	Authors: W. Simpson, Ed.. Date: January 1994 Formats: txt pdf Updates: RFC 1548 Updated by: RFC 2484 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. 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 1572	Telnet Environment Option
	Authors: S. Alexander, Ed.. Date: January 1994 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. This document corrects some errors in [1].
RFC 1573	Evolution of the Interfaces Group of MIB-II
	Authors: K. McCloghrie, F. Kastenholz. Date: January 1994 Formats: txt pdf Obsoletes: RFC 1229 Obsoleted by: RFC 2233 Status: PROPOSED 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 Network Interfaces. [STANARDS-TRACK]
RFC 1577	Classical IP and ARP over ATM
	Authors: M. Laubach. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2225 Status: PROPOSED STANDARD This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connectingIP end-stations ("members") and routers operating in the "classical"LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature.Readers are encouraged to review the ATM Forum and ITU-TS (formerlyCCITT) references for more detailed information about ATM implementation agreements and standards.
RFC 1582	Extensions to RIP to Support Demand Circuits
	Authors: G. Meyer. Date: February 1994 Formats: txt pdf Status: PROPOSED STANDARD Running routing protocols on connection oriented Public DataNetworks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data. Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide AreaNetwork (WAN). This memo defines a generalized modification which can be applied toBellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above. The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links. Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface.When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces. Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN. An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received. The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN.
RFC 1587	The OSPF NSSA Option
	Authors: R. Coltun, V. Fuller. Date: March 1994 Formats: txt pdf Obsoleted by: RFC 3101 Status: PROPOSED STANDARD This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]
RFC 1595	Definitions of Managed Objects for the SONET/SDH Interface Type
	Authors: T. Brown, K. Tesink. Date: March 1994 Formats: txt pdf Obsoleted by: RFC 2558 Status: PROPOSED 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 Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407[13]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
RFC 1596	Definitions of Managed Objects for Frame Relay Service
	Authors: T. Brown, Ed.. Date: March 1994 Formats: txt pdf Obsoleted by: RFC 1604 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service.
RFC 1598	PPP in X.25
	Authors: W. Simpson. Date: March 1994 Formats: txt pdf Status: PROPOSED 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 X.25 for framing PPP encapsulated packets. 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@merit.edu mailing list.
RFC 1604	Definitions of Managed Objects for Frame Relay Service
	Authors: T. Brown, Ed.. Date: March 1994 Formats: txt pdf Obsoletes: RFC 1596 Obsoleted by: RFC 2954 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service.
RFC 1618	PPP over ISDN
	Authors: W. Simpson. Date: May 1994 Formats: txt pdf Status: PROPOSED 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 PPP over Integrated ServicesDigital Network (ISDN) switched circuits. 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@merit.edu mailing list.
RFC 1619	PPP over SONET/SDH
	Authors: W. Simpson. Date: May 1994 Formats: txt pdf Obsoleted by: RFC 2615 Status: PROPOSED 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 PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Heirarchy (SDH) circuits. 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@merit.edu mailing list.
RFC 1626	Default IP MTU for use over ATM AAL5
	Authors: R. Atkinson. Date: May 1994 Formats: txt pdf Obsoleted by: RFC 2225 Status: PROPOSED STANDARD There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]
RFC 1638	PPP Bridging Control Protocol (BCP)
	Authors: F. Baker, R. Bowen. Date: June 1994 Formats: txt pdf Obsoletes: RFC 1220 Obsoleted by: RFC 2878 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
RFC 1647	TN3270 Enhancements
	Authors: B. Kelly. Date: July 1994 Formats: txt pdf Obsoleted by: RFC 2355 Status: PROPOSED STANDARD This document describes a protocol that more fully supports 3270 devices than do the existing 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 would be negotiated and implemented under a new TelnetOption and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1].
RFC 1650	Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2
	Authors: F. Kastenholz. Date: August 1994 Formats: txt pdf Obsoleted by: RFC 2358 Status: PROPOSED 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 ethernet-like objects. [STANDARDS-TRACK]
RFC 1654	A Border Gateway Protocol 4 (BGP-4)
	Authors: Y. Rekhter, T. Li, Eds.. Date: July 1994 Formats: txt pdf Obsoleted by: RFC 1771 Status: PROPOSED STANDARD This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]
RFC 1655	Application of the Border Gateway Protocol in the Internet
	Authors: Y. Rekhter, P. Gross, Eds.. Date: July 1994 Formats: txt pdf Obsoletes: RFC 1268 Obsoleted by: RFC 1772 Status: PROPOSED 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 1663	PPP Reliable Transmission
	Authors: D. Rand. Date: July 1994 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. 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 1665	Definitions of Managed Objects for SNA NAUs using SMIv2
	Authors: Z. Kielczewski, D. Kostick, K. Shih, Eds.. Date: July 1994 Formats: txt pdf Obsoleted by: RFC 1666 Status: PROPOSED 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 the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]
RFC 1695	Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2
	Authors: M. Ahmed, K. Tesink, Eds.. Date: August 1994 Formats: txt pdf Obsoleted by: RFC 2515 Status: PROPOSED 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 objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]
RFC 1697	Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2
	Authors: D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith. Date: August 1994 Formats: txt pdf Status: PROPOSED 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 relational database (RDBMS) implementations. [STANDARDS-TRACK]
RFC 1717	The PPP Multilink Protocol (MP)
	Authors: K. Sklower, B. Lloyd, G. McGregor, D. Carr. Date: November 1994 Formats: txt pdf Obsoleted by: RFC 1990 Status: PROPOSED 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.
RFC 1730	Internet Message Access Protocol - Version 4
	Authors: M. Crispin. Date: December 1994 Formats: txt pdf Obsoleted by: RFC 2060, RFC 2061 Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.IMAP4 permits manipulation of remote message folders, called"mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers.These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous). IMAP4 supports a single server. A mechanism for supporting multipleIMAP4 servers is discussed in [IMSP]. IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.Compatibility issues are discussed in [IMAP-COMPAT].
RFC 1731	IMAP4 Authentication Mechanisms
	Authors: J. Myers. Date: December 1994 Formats: txt pdf Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]
RFC 1734	POP3 AUTHentication command
	Authors: J. Myers. Date: December 1994 Formats: txt pdf Obsoleted by: RFC 5034 Status: PROPOSED STANDARD This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]
RFC 1738	Uniform Resource Locators (URL)
	Authors: T. Berners-Lee, L. Masinter, M. McCahill. Date: December 1994 Formats: txt pdf Obsoleted by: RFC 4248, RFC 4266 Updated by: RFC 1808, RFC 2368, RFC 2396, RFC 3986, RFC 6196, RFC 6270 Status: PROPOSED STANDARD This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet.
RFC 1740	MIME Encapsulation of Macintosh Files - MacMIME
	Authors: P. Faltstrom, D. Crocker, E. Fair. Date: December 1994 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats.
RFC 1752	The Recommendation for the IP Next Generation Protocol
	Authors: S. Bradner, A. Mankin. Date: January 1995 Formats: txt pdf Status: PROPOSED STANDARD This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the InternetProtocol. This recommendation was accepted by the InternetEngineering Steering Group (IESG).
RFC 1755	ATM Signaling Support for IP over ATM
	Authors: M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis. Date: February 1995 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI)Specification Version 3.1 [ATMF94]. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities. This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNISpecification Version 3.1. Unless explicitly stated, no distinction is made between the Private and Public UNI. UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has been produced by the ATM Forum, largely for reasons of alignment withRecommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are several changes that make the two versions incompatible. A description of how to support IP over ATM using UNI 3.0 is found inAppendix B.
RFC 1759	Printer MIB
	Authors: R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 3805 Status: PROPOSED STANDARD A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]
RFC 1766	Tags for the Identification of Languages
	Authors: H. Alvestrand. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 3066, RFC 3282 Status: PROPOSED STANDARD This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822- like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header.
RFC 1767	MIME Encapsulation of EDI Objects
	Authors: D. Crocker. Date: March 1995 Formats: txt pdf Status: PROPOSED STANDARD Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]
RFC 1782	TFTP Option Extension
	Authors: G. Malkin, A. Harkin. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 2347 Updates: RFC 1350 Status: PROPOSED 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 1783	TFTP Blocksize Option
	Authors: G. Malkin, A. Harkin. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 2348 Updates: RFC 1350 Status: PROPOSED 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-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes 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 1784	TFTP Timeout Interval and Transfer Size Options
	Authors: G. Malkin, A. Harkin. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 2349 Updates: RFC 1350 Status: PROPOSED 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]. This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].
RFC 1793	Extending OSPF to Support Demand Circuits
	Authors: J. Moy. Date: April 1995 Formats: txt pdf Updated by: RFC 3883 Status: PROPOSED STANDARD This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic. Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open. While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio. The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- to-MultiPoint Interface). This memo provides functionality similar to that specified for RIP in[2], with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, becauseOSPF employs link-state routing technology as opposed to RIP'sDistance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different. Please send comments to ospf@gated.cornell.edu.
RFC 1808	Relative Uniform Resource Locators
	Authors: R. Fielding. Date: June 1995 Formats: txt pdf Obsoleted by: RFC 3986 Updates: RFC 1738 Updated by: RFC 2368, RFC 2396 Status: PROPOSED STANDARD A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet.When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path. In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative UniformResource Locators.
RFC 1812	Requirements for IP Version 4 Routers
	Authors: F. Baker, Ed.. Date: June 1995 Formats: txt pdf Obsoletes: RFC 1716, RFC 1009 Updated by: RFC 2644 Status: PROPOSED STANDARD This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]
RFC 1825	Security Architecture for the Internet Protocol
	Authors: R. Atkinson. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2401 Status: PROPOSED STANDARD This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK]
RFC 1826	IP Authentication Header
	Authors: R. Atkinson. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2402 Status: PROPOSED STANDARD This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]
RFC 1827	IP Encapsulating Security Payload (ESP)
	Authors: R. Atkinson. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2406 Status: PROPOSED STANDARD This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]
RFC 1829	The ESP DES-CBC Transform
	Authors: P. Karn, P. Metzger, W. Simpson. Date: August 1995 Formats: txt pdf Status: PROPOSED STANDARD This document describes the DES-CBC security transform for the IPEncapsulating Security Payload (ESP).
RFC 1831	RPC: Remote Procedure Call Protocol Specification Version 2
	Authors: R. Srinivasan. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 5531 Status: PROPOSED STANDARD This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]
RFC 1833	Binding Protocols for ONC RPC Version 2
	Authors: R. Srinivasan. Date: August 1995 Formats: txt pdf Updated by: RFC 5665 Status: PROPOSED STANDARD This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]
RFC 1847	Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
	Authors: J. Galvin, S. Murphy, S. Crocker, N. Freed. Date: October 1995 Formats: txt pdf Status: PROPOSED STANDARD This document defines a framework within which security services may be applied to MIME body parts. MIME, an acronym for "MultipurposeInternet Mail Extensions", defines the format of the contents ofInternet mail messages and provides for multi-part textual and non- textual message bodies. The new content types are subtypes of multipart: signed and encrypted. Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection. The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present.
RFC 1854	SMTP Service Extension for Command Pipelining
	Authors: N. Freed. Date: October 1995 Formats: txt pdf Obsoleted by: RFC 2197 Status: PROPOSED 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. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.
RFC 1883	Internet Protocol, Version 6 (IPv6) Specification
	Authors: S. Deering, R. Hinden. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 2460 Status: PROPOSED STANDARD This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.
RFC 1885	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Authors: A. Conta, S. Deering. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 2463 Status: PROPOSED STANDARD This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document.
RFC 1886	DNS Extensions to support IP version 6
	Authors: S. Thomson, C. Huitema. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 3596 Updated by: RFC 2874, RFC 3152 Status: PROPOSED STANDARD This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.
RFC 1889	RTP: A Transport Protocol for Real-Time Applications
	Authors: Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3550 Status: PROPOSED STANDARD This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
RFC 1890	RTP Profile for Audio and Video Conferences with Minimal Control
	Authors: Audio-Video Transport Working Group, H. Schulzrinne. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3551 Status: PROPOSED STANDARD This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
RFC 1891	SMTP Service Extension for Delivery Status Notifications
	Authors: K. Moore. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3461 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery 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. [STANDARDS-TRACK]
RFC 1892	The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
	Authors: G. Vaudreuil. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3462 Status: PROPOSED STANDARD The Multipart/Report 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. [STANDARDS-TRACK]
RFC 1893	Enhanced Mail System Status Codes
	Authors: G. Vaudreuil. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3463 Status: PROPOSED STANDARD There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]
RFC 1894	An Extensible Message Format for Delivery Status Notifications
	Authors: K. Moore, G. Vaudreuil. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3464 Updated by: RFC 2852 Status: PROPOSED STANDARD This memo defines a 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 inInternet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the 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. Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability. NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change.
RFC 1928	SOCKS Protocol Version 5
	Authors: M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. Date: March 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]
RFC 1929	Username/Password Authentication for SOCKS V5
	Authors: M. Leech. Date: March 1996 Formats: txt pdf Status: PROPOSED STANDARD The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]
RFC 1933	Transition Mechanisms for IPv6 Hosts and Routers
	Authors: R. Gilligan, E. Nordmark. Date: April 1996 Formats: txt pdf Obsoleted by: RFC 2893 Status: PROPOSED STANDARD This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6.
RFC 1938	A One-Time Password System
	Authors: N. Haller, C. Metz. Date: May 1996 Formats: txt pdf Obsoleted by: RFC 2289 Status: PROPOSED STANDARD This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]
RFC 1959	An LDAP URL Format
	Authors: T. Howes, M. Smith. Date: June 1996 Formats: txt pdf Obsoleted by: RFC 2255 Status: PROPOSED STANDARD This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]
RFC 1960	A String Representation of LDAP Search Filters
	Authors: T. Howes. Date: June 1996 Formats: txt pdf Obsoletes: RFC 1558 Obsoleted by: RFC 2254 Status: PROPOSED STANDARD The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]
RFC 1961	GSS-API Authentication Method for SOCKS Version 5
	Authors: P. McMahon. Date: June 1996 Formats: txt pdf Status: PROPOSED STANDARD This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]
RFC 1962	The PPP Compression Control Protocol (CCP)
	Authors: D. Rand. Date: June 1996 Formats: txt pdf Updated by: RFC 2153 Status: PROPOSED 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. This document defines a method for negotiating data compression overPPP links.
RFC 1964	The Kerberos Version 5 GSS-API Mechanism
	Authors: J. Linn. Date: June 1996 Formats: txt pdf Updated by: RFC 4121 Status: PROPOSED STANDARD This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK]
RFC 1968	The PPP Encryption Control Protocol (ECP)
	Authors: G. Meyer. Date: June 1996 Formats: txt pdf Status: PROPOSED 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. This document defines a method for negotiating data encryption overPPP links.
RFC 1970	Neighbor Discovery for IP Version 6 (IPv6)
	Authors: T. Narten, E. Nordmark, W. Simpson. Date: August 1996 Formats: txt pdf Obsoleted by: RFC 2461 Status: PROPOSED STANDARD 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 1971	IPv6 Stateless Address Autoconfiguration
	Authors: S. Thomson, T. Narten. Date: August 1996 Formats: txt pdf Obsoleted by: RFC 2462 Status: PROPOSED STANDARD 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 1972	A Method for the Transmission of IPv6 Packets over Ethernet Networks
	Authors: M. Crawford. Date: August 1996 Formats: txt pdf Obsoleted by: RFC 2464 Status: PROPOSED STANDARD This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]
RFC 1973	PPP in Frame Relay
	Authors: W. Simpson. Date: June 1996 Formats: txt pdf Status: PROPOSED 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 Frame Relay for framing PPP encapsulated packets.
RFC 1982	Serial Number Arithmetic
	Authors: R. Elz, R. Bush. Date: August 1996 Formats: txt pdf Updates: RFC 1034, RFC 1035 Status: PROPOSED STANDARD This memo defines serial number arithmetic, as used in the DomainName System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in anIETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035.
RFC 1985	SMTP Service Extension for Remote Message Queue Starting
	Authors: J. De Winter. Date: August 1996 Formats: txt pdf Status: PROPOSED 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 start the processing of its queues for messages to go to a given host. This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers.
RFC 1995	Incremental Zone Transfer in DNS
	Authors: M. Ohta. Date: August 1996 Formats: txt pdf Updates: RFC 1035 Status: PROPOSED STANDARD This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.
RFC 1996	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
	Authors: P. Vixie. Date: August 1996 Formats: txt pdf Updates: RFC 1035 Status: PROPOSED STANDARD This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.
RFC 1997	BGP Communities Attribute
	Authors: R. Chandra, P. Traina, T. Li. Date: August 1996 Formats: txt pdf Status: PROPOSED STANDARD Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.
RFC 2001	TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
	Authors: W. Stevens. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2581 Status: PROPOSED STANDARD Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [2] and [3] provide some details on these algorithms, [4] provides examples of the algorithms in action, and [5] provides the source code for the 4.4BSD implementation. RFC 1122 requires that a TCP must implement slow start and congestion avoidance (Section 4.2.2.15 of [1]), citing [2] as the reference, but fast retransmit and fast recovery were implemented after RFC 1122. The purpose of this document is to document these four algorithms for the Internet.
RFC 2002	IP Mobility Support
	Authors: C. Perkins, Ed.. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 3220 Updated by: RFC 2290 Status: PROPOSED STANDARD This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
RFC 2003	IP Encapsulation within IP
	Authors: C. Perkins. Date: October 1996 Formats: txt pdf Updated by: RFC 3168 Status: PROPOSED STANDARD This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram.Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IPDestination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP.
RFC 2004	Minimal Encapsulation within IP
	Authors: C. Perkins. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. Encapsulation may be serve a variety of purposes, such as delivery of a datagram to a mobile node usingMobile IP.
RFC 2005	Applicability Statement for IP Mobility Support
	Authors: J. Solomon. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD As required by [RFC 1264], this report discusses the applicability ofMobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied.
RFC 2006	The Definitions of Managed Objects for IP Mobility Support using SMIv2
	Authors: D. Cong, M. Hamlen, C. Perkins. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the MobileNode, Foreign Agent and Home Agent of the Mobile IP Protocol.
RFC 2011	SNMPv2 Management Information Base for the Internet Protocol using SMIv2
	Authors: K. McCloghrie, Ed.. Date: November 1996 Formats: txt pdf Obsoleted by: RFC 4293 Updates: RFC 1213 Status: PROPOSED STANDARD This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]
RFC 2012	SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2
	Authors: K. McCloghrie, Ed.. Date: November 1996 Formats: txt pdf Obsoleted by: RFC 4022 Updates: RFC 1213 Status: PROPOSED STANDARD This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]
RFC 2013	SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2
	Authors: K. McCloghrie, Ed.. Date: November 1996 Formats: txt pdf Obsoleted by: RFC 4113 Updates: RFC 1213 Status: PROPOSED STANDARD This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]
RFC 2015	MIME Security with Pretty Good Privacy (PGP)
	Authors: M. Elkins. Date: October 1996 Formats: txt pdf Updated by: RFC 3156 Status: PROPOSED STANDARD This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC1847.
RFC 2017	Definition of the URL MIME External-Body Access-Type
	Authors: N. Freed, K. Moore, A. Cargille. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]
RFC 2018	TCP Selective Acknowledgment Options
	Authors: M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. Date: October 1996 Formats: txt pdf Obsoletes: RFC 1072 Status: PROPOSED STANDARD TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received. A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments. This memo proposes an implementation of SACK and discusses its performance and related issues.
RFC 2019	Transmission of IPv6 Packets Over FDDI
	Authors: M. Crawford. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2467 Status: PROPOSED STANDARD This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]
RFC 2020	IEEE 802.12 Interface MIB
	Authors: J. Flick. Date: October 1996 Formats: txt pdf Status: PROPOSED 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 network interfaces based on IEEE 802.12. [STANDARDS-TRACK]
RFC 2021	Remote Network Monitoring Management Information Base Version 2 using SMIv2
	Authors: S. Waldbusser. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 4502 Status: PROPOSED 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 2022	Support for Multicast over UNI 3.0/3.1 based ATM Networks
	Authors: G. Armitage. Date: November 1996 Formats: txt pdf Status: PROPOSED STANDARD Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.This memo describes a mechanism to support the multicast needs ofLayer 3 protocols in general, and describes its application to IP multicasting in particular. ATM based IP hosts and routers use a Multicast Address ResolutionServer (MARS) to support RFC 1112 style Level 2 IP multicast over theATM Forum's UNI 3.0/3.1 point to multipoint connection service.Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group. The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice may be made on a per-group basis, and is transparent to the endpoints.
RFC 2023	IP Version 6 over PPP
	Authors: D. Haskin, E. Allen. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2472 Status: PROPOSED 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 method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.
RFC 2024	Definitions of Managed Objects for Data Link Switching using SMIv2
	Authors: D. Chen, Ed., P. Gayek, S. Nix. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw) [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3].
RFC 2025	The Simple Public-Key GSS-API Mechanism (SPKM)
	Authors: C. Adams. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism.
RFC 2029	RTP Payload Format of Sun's CellB Video Encoding
	Authors: M. Speer, D. Hoffman. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB.
RFC 2032	RTP Payload Format for H.261 Video Streams
	Authors: T. Turletti, C. Huitema. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 4587 Status: PROPOSED STANDARD This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]
RFC 2034	SMTP Service Extension for Returning Enhanced Error Codes
	Authors: N. Freed. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]
RFC 2035	RTP Payload Format for JPEG-compressed Video
	Authors: L. Berc, W. Fenner, R. Frederick, S. McCanne. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2435 Status: PROPOSED STANDARD This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s).
RFC 2037	Entity MIB using SMIv2
	Authors: K. McCloghrie, A. Bierman. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2737 Status: PROPOSED 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 multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]
RFC 2038	RTP Payload Format for MPEG1/MPEG2 Video
	Authors: D. Hoffman, G. Fernando, V. Goyal. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2250 Status: PROPOSED STANDARD This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.
RFC 2043	The PPP SNA Control Protocol (SNACP)
	Authors: A. Fuqua. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP.
RFC 2051	Definitions of Managed Objects for APPC using SMIv2
	Authors: M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore. Date: October 1996 Formats: txt pdf Status: PROPOSED 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 the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]
RFC 2056	Uniform Resource Locators for Z39.50
	Authors: R. Denenberg, J. Kunze, D. Lynch. Date: November 1996 Formats: txt pdf Status: PROPOSED STANDARD Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]
RFC 2058	Remote Authentication Dial In User Service (RADIUS)
	Authors: C. Rigney, A. Rubens, W. Simpson, S. Willens. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2138 Status: PROPOSED STANDARD 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 2060	Internet Message Access Protocol - Version 4rev1
	Authors: M. Crispin. Date: December 1996 Formats: txt pdf Obsoletes: RFC 1730 Obsoleted by: RFC 3501 Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP]. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution ofIMAP4rev1, some aspects in the earlier protocol have become obsolete.Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in [IMAP-OBSOLETE]. Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.
RFC 2065	Domain Name System Security Extensions
	Authors: D. Eastlake 3rd, C. Kaufman. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2535 Updates: RFC 1034, RFC 1035 Status: PROPOSED STANDARD The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions.
RFC 2068	Hypertext Transfer Protocol -- HTTP/1.1
	Authors: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2616 Status: PROPOSED STANDARD The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.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".
RFC 2069	An Extension to HTTP : Digest Access Authentication
	Authors: J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2617 Status: PROPOSED STANDARD The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". 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 2073	An IPv6 Provider-Based Unicast Address Format
	Authors: Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2374 Status: PROPOSED STANDARD This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]
RFC 2074	Remote Network Monitoring MIB Protocol Identifiers
	Authors: A. Bierman, R. Iddon. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2895 Status: PROPOSED STANDARD This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]
RFC 2077	The Model Primary Content Type for Multipurpose Internet Mail Extensions
	Authors: S. Nelson, C. Parks, Mitra. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS- TRACK]
RFC 2078	Generic Security Service Application Program Interface, Version 2
	Authors: J. Linn. Date: January 1997 Formats: txt pdf Obsoletes: RFC 1508 Obsoleted by: RFC 2743 Status: PROPOSED STANDARD The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.
RFC 2079	Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)
	Authors: M. Smith. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD Uniform Resource Locators (URLs) are being widely used to specify the location of Internet resources. There is an urgent need to be able to include URLs in directories that conform to the LDAP and X.500 information models, and a desire to include other types of UniformResource Identifiers (URIs) as they are defined. A number of independent groups are already experimenting with the inclusion ofURLs in LDAP and X.500 directories. This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way.
RFC 2080	RIPng for IPv6
	Authors: G. Malkin, R. Minnear. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in theIPv4 Internet. This specification represents the minimum change to the RoutingInformation Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723[2], necessary for operation over IPv6 [3].
RFC 2082	RIP-2 MD5 Authentication
	Authors: F. Baker, R. Atkinson. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 4822 Status: PROPOSED STANDARD Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]
RFC 2085	HMAC-MD5 IP Authentication with Replay Prevention
	Authors: M. Oehler, R. Glenn. Date: February 1997 Formats: txt pdf Status: PROPOSED STANDARD This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks.
RFC 2086	IMAP4 ACL extension
	Authors: J. Myers. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 4314 Status: PROPOSED STANDARD The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]
RFC 2087	IMAP4 QUOTA extension
	Authors: J. Myers. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]
RFC 2088	IMAP4 non-synchronizing literals
	Authors: J. Myers. Date: January 1997 Formats: txt pdf Updated by: RFC 4466 Status: PROPOSED STANDARD The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK]
RFC 2091	Triggered Extensions to RIP to Support Demand Circuits
	Authors: G. Meyer, S. Sherry. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD This document defines a modification which can be applied toBellman-Ford (distance vector) algorithm information broadcasting protocols - for example IP RIP, Netware RIP or Netware SAP - which makes it feasible to run them on connection oriented Public DataNetworks. This proposal has a number of efficiency advantages over the DemandRIP proposal (RFC 1582).
RFC 2095	IMAP/POP AUTHorize Extension for Simple Challenge/Response
	Authors: J. Klensin, R. Catoe, P. Krumviede. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2195 Status: PROPOSED STANDARD While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.
RFC 2096	IP Forwarding Table MIB
	Authors: F. Baker. Date: January 1997 Formats: txt pdf Obsoletes: RFC 1354 Obsoleted by: RFC 4292 Status: PROPOSED STANDARD This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]
RFC 2097	The PPP NetBIOS Frames Control Protocol (NBFCP)
	Authors: G. Pall. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms.
RFC 2108	Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2
	Authors: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. Date: February 1997 Formats: txt pdf Obsoletes: RFC 1516 Status: PROPOSED 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 10 and 100Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10& 100 Mb/s Management," October 26, 1995.
RFC 2110	MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
	Authors: J. Palme, A. Hopmann. Date: March 1997 Formats: txt pdf Obsoleted by: RFC 2557 Status: PROPOSED STANDARD Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base".
RFC 2111	Content-ID and Message-ID Uniform Resource Locators
	Authors: E. Levinson. Date: March 1997 Formats: txt pdf Obsoleted by: RFC 2392 Status: PROPOSED STANDARD The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.
RFC 2112	The MIME Multipart/Related Content-type
	Authors: E. Levinson. Date: March 1997 Formats: txt pdf Obsoletes: RFC 1872 Obsoleted by: RFC 2387 Status: PROPOSED STANDARD The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use.
RFC 2113	IP Router Alert Option
	Authors: D. Katz. Date: February 1997 Formats: txt pdf Updated by: RFC 5350, RFC 6398 Status: PROPOSED STANDARD This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.
RFC 2122	VEMMI URL Specification
	Authors: D. Mavrakis, H. Layec, K. Kartmann. Date: March 1997 Formats: txt pdf Status: PROPOSED STANDARD A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]
RFC 2125	The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)
	Authors: C. Richards, K. Smith. Date: March 1997 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol[2]. This is done by defining the Bandwidth Allocation Protocol(BAP), as well as its associated control protocol, the BandwidthAllocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co- ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection.
RFC 2126	ISO Transport Service on top of TCP (ITOT)
	Authors: Y. Pouffary, A. Young. Date: March 1997 Formats: txt pdf Updates: RFC 1006 Status: PROPOSED STANDARD This document is a revision to STD35, RFC1006 written by Marshall T.Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. The goal of this version is to minimise the number of changes toRFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users.
RFC 2127	ISDN Management Information Base using SMIv2
	Authors: G. Roeck, Ed.. Date: March 1997 Formats: txt pdf Status: PROPOSED 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 a minimal set of managed objects for SNMP- based management of ISDN terminal interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author. The current version of this document reflects changes made during the last call period and the IESG review.
RFC 2128	Dial Control Management Information Base using SMIv2
	Authors: G. Roeck, Ed.. Date: March 1997 Formats: txt pdf Status: PROPOSED 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 demand access circuits, including ISDN. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author.
RFC 2136	Dynamic Updates in the Domain Name System (DNS UPDATE)
	Authors: P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. Date: April 1997 Formats: txt pdf Updates: RFC 1035 Updated by: RFC 3007, RFC 4035, RFC 4033, RFC 4034 Status: PROPOSED STANDARD The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File. Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of anRRset, or the existence of a single RR. UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met.
RFC 2137	Secure Domain Name System Dynamic Update
	Authors: D. Eastlake 3rd. Date: April 1997 Formats: txt pdf Obsoleted by: RFC 3007 Updates: RFC 1035 Status: PROPOSED STANDARD Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys.
RFC 2138	Remote Authentication Dial In User Service (RADIUS)
	Authors: C. Rigney, A. Rubens, W. Simpson, S. Willens. Date: April 1997 Formats: txt pdf Obsoletes: RFC 2058 Obsoleted by: RFC 2865 Status: PROPOSED STANDARD 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 2141	URN Syntax
	Authors: R. Moats. Date: May 1997 Formats: txt pdf Status: PROPOSED STANDARD Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it.
RFC 2142	Mailbox Names for Common Services, Roles and Functions
	Authors: D. Crocker. Date: May 1997 Formats: txt pdf Status: PROPOSED STANDARD This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]
RFC 2147	TCP and UDP over IPv6 Jumbograms
	Authors: D. Borman. Date: May 1997 Formats: txt pdf Obsoleted by: RFC 2675 Status: PROPOSED STANDARD IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]
RFC 2155	Definitions of Managed Objects for APPN using SMIv2
	Authors: B. Clouston, B. Moore. Date: June 1997 Formats: txt pdf Obsoleted by: RFC 2455 Status: PROPOSED 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 monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK]
RFC 2156	MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
	Authors: S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 0987, RFC 1026, RFC 1138, RFC 1148, RFC 1327, RFC 1495 Updates: RFC 0822 Status: PROPOSED STANDARD This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]
RFC 2157	Mapping between X.400 and RFC-822/MIME Message Bodies
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]
RFC 2158	X.400 Image Body Parts
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]
RFC 2159	A MIME Body Part for FAX
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]
RFC 2160	Carrying PostScript in X.400 and MIME
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]
RFC 2163	Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)
	Authors: C. Allocchio. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1664 Updated by: RFC 3597 Status: PROPOSED STANDARD This memo is the complete technical specification to store in theInternet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their localDNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying theDNS instead of having fixed tables which need to be centrally updated and distributed. This memo obsoletes RFC1664. It includes the changes introduced byMIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too. RFC1664 was a joint effort of IETF X400 operation working group(x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group.
RFC 2164	Use of an X.500/LDAP directory to support MIXER address mapping
	Authors: S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1838 Status: PROPOSED STANDARD This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]
RFC 2165	Service Location Protocol
	Authors: J. Veizades, E. Guttman, C. Perkins, S. Kaplan. Date: June 1997 Formats: txt pdf Updated by: RFC 2608, RFC 2609 Status: PROPOSED STANDARD The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
RFC 2177	IMAP4 IDLE command
	Authors: B. Leiba. Date: June 1997 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]
RFC 2181	Clarifications to the DNS Specification
	Authors: R. Elz, R. Bush. Date: July 1997 Formats: txt pdf Updates: RFC 1034, RFC 1035, RFC 1123 Updated by: RFC 4035, RFC 2535, RFC 4343, RFC 4033, RFC 4034, RFC 5452 Status: PROPOSED STANDARD This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK]
RFC 2183	Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
	Authors: R. Troost, S. Dorner, K. Moore, Ed.. Date: August 1997 Formats: txt pdf Obsoletes: RFC 1806 Updated by: RFC 2184, RFC 2231 Status: PROPOSED STANDARD This memo provides a mechanism whereby messages conforming to theMIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC2049] can convey presentational information. It specifies the"Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values. This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and[RFC 822]. The information presented herein supplements but does not replace that found in those documents. This document is a revision to the Experimental protocol defined inRFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the FileTransfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values.
RFC 2184	MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
	Authors: N. Freed, K. Moore. Date: August 1997 Formats: txt pdf Obsoleted by: RFC 2231 Updates: RFC 2045, RFC 2047, RFC 2183 Status: PROPOSED STANDARD This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]
RFC 2192	IMAP URL Scheme
	Authors: C. Newman. Date: September 1997 Formats: txt pdf Obsoleted by: RFC 5092 Status: PROPOSED STANDARD IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores.This document defines a URL scheme for referencing objects on anIMAP server.
RFC 2193	IMAP4 Mailbox Referrals
	Authors: M. Gahrns. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]
RFC 2195	IMAP/POP AUTHorize Extension for Simple Challenge/Response
	Authors: J. Klensin, R. Catoe, P. Krumviede. Date: September 1997 Formats: txt pdf Obsoletes: RFC 2095 Status: PROPOSED STANDARD While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.
RFC 2198	RTP Payload for Redundant Audio Data
	Authors: C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. Date: September 1997 Formats: txt pdf Updated by: RFC 6354 Status: PROPOSED STANDARD This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications.
RFC 2203	RPCSEC_GSS Protocol Specification
	Authors: M. Eisler, A. Chiu, L. Ling. Date: September 1997 Formats: txt pdf Updated by: RFC 5403 Status: PROPOSED STANDARD This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services ApplicationProgramming Interface (referred to henceforth as GSS-API).
RFC 2205	Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
	Authors: R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. Date: September 1997 Formats: txt pdf Updated by: RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437 Status: PROPOSED STANDARD This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
RFC 2206	RSVP Management Information Base using SMIv2
	Authors: F. Baker, J. Krawczyk, A. Sastry. Date: September 1997 Formats: txt pdf Status: PROPOSED 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 ResourceReservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu.
RFC 2207	RSVP Extensions for IPSEC Data Flows
	Authors: L. Berger, T. O'Malley. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IPAuthentication Header (AH) or RFC 1827, IP Encapsulating SecurityPayload (ESP). RSVP Version 1 as currently specified can support theIPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with bothIPv4 and IPv6.
RFC 2210	The Use of RSVP with IETF Integrated Services
	Authors: J. Wroclawski. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. TheRSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here.
RFC 2211	Specification of the Controlled-Load Network Element Service
	Authors: J. Wroclawski. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies the network element behavior required to deliverControlled-Load service in the Internet. Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.
RFC 2212	Specification of Guaranteed Quality of Service
	Authors: S. Shenker, C. Partridge, R. Guerin. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in theInternet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in [1].
RFC 2213	Integrated Services Management Information Base using SMIv2
	Authors: F. Baker, J. Krawczyk, A. Sastry. Date: September 1997 Formats: txt pdf Status: PROPOSED 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 the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu.
RFC 2214	Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2
	Authors: F. Baker, J. Krawczyk, A. Sastry. Date: September 1997 Formats: txt pdf Status: PROPOSED 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 the interface attributes defined in the Guaranteed Service of the IntegratedServices Model. Comments should be made to the Integrated ServicesWorking Group, intserv@isi.edu.
RFC 2215	General Characterization Parameters for Integrated Service Network Elements
	Authors: S. Shenker, J. Wroclawski. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. General parameters are those with common, shared definitions across all QoS control services.
RFC 2218	A Common Schema for the Internet White Pages Service
	Authors: T. Genovese, B. Jennings. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD This work is the result of the IETF Integrated Directory Services(IDS) Working Group. The IDS Working Group proposes a standard specification for a simple Internet White Pages service by defining a common schema for use by the various White Pages servers. This schema is independent of specific implementations of the White Pages service. This document specifies the minimum set of core attributes of a WhitePages entry for an individual and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. Further, it does not address the search sort expectations within a particular service.
RFC 2221	IMAP4 Login Referrals
	Authors: M. Gahrns. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]
RFC 2222	Simple Authentication and Security Layer (SASL)
	Authors: J. Myers. Date: October 1997 Formats: txt pdf Obsoleted by: RFC 4422, RFC 4752 Updated by: RFC 2444 Status: PROPOSED STANDARD This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]
RFC 2225	Classical IP and ARP over ATM
	Authors: M. Laubach, J. Halpern. Date: April 1998 Formats: txt pdf Obsoletes: RFC 1626, RFC 1577 Updated by: RFC 5494 Status: PROPOSED STANDARD This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]
RFC 2226	IP Broadcast over ATM Networks
	Authors: T. Smith, G. Armitage. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group. An understanding of the services provided by RFC 2022 is assumed.
RFC 2227	Simple Hit-Metering and Usage-Limiting for HTTP
	Authors: J. Mogul, P. Leach. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]
RFC 2228	FTP Security Extensions
	Authors: M. Horowitz, S. Lunt. Date: October 1997 Formats: txt pdf Updates: RFC 0959 Status: PROPOSED STANDARD This document defines extensions to the FTP specification STD 9, RFC959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication/Security Mechanism),ADAT (Authentication/Security Data),PROT (Data Channel Protection Level),PBSZ (Protection Buffer Size),CCC (Clear Command Channel),MIC (Integrity Protected Command),CONF (Confidentiality Protected Command), andENC (Privacy Protected Command). A new class of reply types (6yz) is also introduced for protected replies. None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands. Note that this specification is compatible with STD 9, RFC 959.
RFC 2231	MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
	Authors: N. Freed, K. Moore. Date: November 1997 Formats: txt pdf Obsoletes: RFC 2184 Updates: RFC 2045, RFC 2047, RFC 2183 Status: PROPOSED STANDARD This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]
RFC 2232	Definitions of Managed Objects for DLUR using SMIv2
	Authors: B. Clouston, Ed., B. Moore, Ed.. Date: November 1997 Formats: txt pdf Status: PROPOSED 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 monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]
RFC 2233	The Interfaces Group MIB using SMIv2
	Authors: K. McCloghrie, F. Kastenholz. Date: November 1997 Formats: txt pdf Obsoletes: RFC 1573 Obsoleted by: RFC 2863 Status: PROPOSED 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 Network Interfaces. [STANDARDS-TRACK]
RFC 2234	Augmented BNF for Syntax Specifications: ABNF
	Authors: D. Crocker, Ed., P. Overell. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 4234 Status: PROPOSED STANDARD In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]
RFC 2236	Internet Group Management Protocol, Version 2
	Authors: W. Fenner. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 3376 Updates: RFC 1112 Status: PROPOSED STANDARD This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s).
RFC 2238	Definitions of Managed Objects for HPR using SMIv2
	Authors: B. Clouston, Ed., B. Moore, Ed.. Date: November 1997 Formats: txt pdf Status: PROPOSED 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 monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]
RFC 2239	Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2
	Authors: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 2668 Status: PROPOSED STANDARD This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing 10 and 100 Mb/secondMedium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30,"10 & 100 Mb/s Management," October 26, 1995.
RFC 2241	DHCP Options for Novell Directory Services
	Authors: D. Provan. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This document defines three new DHCP options for delivering configuration information to clients of the Novell DirectoryServices. The first option carries a list of NDS servers. The second option carries the name of the client's NDS tree. The third carries the initial NDS context. These three options provide an NDS client with enough information to connect to an NDS tree without manual configuration of the client.
RFC 2242	NetWare/IP Domain Name and Information
	Authors: R. Droms, K. Fong. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]
RFC 2243	OTP Extended Responses
	Authors: C. Metz. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This document provides a specification for a type of response to anOTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase.
RFC 2244	ACAP -- Application Configuration Access Protocol
	Authors: C. Newman, J. G. Myers. Date: November 1997 Formats: txt pdf Updated by: RFC 6075 Status: PROPOSED STANDARD The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.
RFC 2245	Anonymous SASL Mechanism
	Authors: C. Newman. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 4505 Status: PROPOSED STANDARD It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.
RFC 2246	The TLS Protocol Version 1.0
	Authors: T. Dierks, C. Allen. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 4346 Updated by: RFC 3546, RFC 5746, RFC 6176 Status: PROPOSED STANDARD This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
RFC 2247	Using Domains in LDAP/X.500 Distinguished Names
	Authors: S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. Date: January 1998 Formats: txt pdf Updated by: RFC 4519, RFC 4524 Status: PROPOSED STANDARD This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]
RFC 2248	Network Services Monitoring MIB
	Authors: N. Freed, S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1565 Obsoleted by: RFC 2788 Status: PROPOSED STANDARD This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]
RFC 2249	Mail Monitoring MIB
	Authors: N. Freed, S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1566 Obsoleted by: RFC 2789 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS- TRACK]
RFC 2250	RTP Payload Format for MPEG1/MPEG2 Video
	Authors: D. Hoffman, G. Fernando, V. Goyal, M. Civanlar. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2038 Status: PROPOSED STANDARD This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms inSection 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added.
RFC 2251	Lightweight Directory Access Protocol (v3)
	Authors: M. Wahl, T. Howes, S. Kille. Date: December 1997 Formats: txt pdf Obsoleted by: RFC 4510, RFC 4511, RFC 4513, RFC 4512 Updated by: RFC 3377, RFC 3771 Status: PROPOSED STANDARD The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]
RFC 2252	Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
	Authors: M. Wahl, A. Coulbeck, T. Howes, S. Kille. Date: December 1997 Formats: txt pdf Obsoleted by: RFC 4510, RFC 4517, RFC 4523, RFC 4512 Updated by: RFC 3377 Status: PROPOSED STANDARD This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]
RFC 2253	Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
	Authors: M. Wahl, S. Kille, T. Howes. Date: December 1997 Formats: txt pdf Obsoletes: RFC 1779 Obsoleted by: RFC 4510, RFC 4514 Updated by: RFC 3377 Status: PROPOSED STANDARD The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight DirectoryAccess Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.
RFC 2254	The String Representation of LDAP Search Filters
	Authors: T. Howes. Date: December 1997 Formats: txt pdf Obsoletes: RFC 1960 Obsoleted by: RFC 4510, RFC 4515 Updated by: RFC 3377 Status: PROPOSED STANDARD This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]
RFC 2255	The LDAP URL Format
	Authors: T. Howes, M. Smith. Date: December 1997 Formats: txt pdf Obsoletes: RFC 1959 Obsoleted by: RFC 4510, RFC 4516 Updated by: RFC 3377 Status: PROPOSED STANDARD This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]
RFC 2256	A Summary of the X.500(96) User Schema for use with LDAPv3
	Authors: M. Wahl. Date: December 1997 Formats: txt pdf Obsoleted by: RFC 4517, RFC 4519, RFC 4523, RFC 4512, RFC 4510 Updated by: RFC 3377 Status: PROPOSED STANDARD This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS- TRACK]
RFC 2257	Agent Extensibility (AgentX) Protocol Version 1
	Authors: M. Daniele, B. Wijnen, D. Francisco. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2741 Status: PROPOSED STANDARD 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 processes SNMP protocol messages. [STANDARDS-TRACK]
RFC 2261	An Architecture for Describing SNMP Management Frameworks
	Authors: D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2271 Status: PROPOSED STANDARD 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 2262	Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
	Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2272 Status: PROPOSED STANDARD This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2261]. 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 2263	SNMPv3 Applications
	Authors: D. Levi, P. Meyer, B. Stewart. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2273 Status: PROPOSED STANDARD This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. 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 2264	User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
	Authors: U. Blumenthal, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2274 Status: PROPOSED STANDARD This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. 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 2265	View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
	Authors: B. Wijnen, R. Presuhn, K. McCloghrie. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2275 Status: PROPOSED STANDARD This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. 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 2266	Definitions of Managed Objects for IEEE 802.12 Repeater Devices
	Authors: J. Flick. Date: January 1998 Formats: txt pdf Status: PROPOSED 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 network repeaters based on IEEE 802.12.
RFC 2271	An Architecture for Describing SNMP Management Frameworks
	Authors: D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2261 Obsoleted by: RFC 2571 Status: PROPOSED STANDARD 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 2272	Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
	Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2262 Obsoleted by: RFC 2572 Status: PROPOSED STANDARD This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2271]. 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 2273	SNMPv3 Applications
	Authors: D. Levi, P. Meyer, B. Stewart. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2263 Obsoleted by: RFC 2573 Status: PROPOSED STANDARD This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. 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 2274	User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
	Authors: U. Blumenthal, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2264 Obsoleted by: RFC 2574 Status: PROPOSED STANDARD This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. 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 2275	View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
	Authors: B. Wijnen, R. Presuhn, K. McCloghrie. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2265 Obsoleted by: RFC 2575 Status: PROPOSED STANDARD This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. 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 2280	Routing Policy Specification Language (RPSL)
	Authors: C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2622 Status: PROPOSED STANDARD This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]
RFC 2283	Multiprotocol Extensions for BGP-4
	Authors: T. Bates, R. Chandra, D. Katz, Y. Rekhter. Date: February 1998 Formats: txt pdf Obsoleted by: RFC 2858 Status: PROPOSED STANDARD This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]
RFC 2284	PPP Extensible Authentication Protocol (EAP)
	Authors: L. Blunk, J. Vollbrecht. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3748 Updated by: RFC 2484 Status: PROPOSED 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 the PPP Extensible Authentication Protocol.
RFC 2287	Definitions of System-Level Managed Objects for Applications
	Authors: C. Krupczak, J. Saperia. Date: February 1998 Formats: txt pdf Status: PROPOSED 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 a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]
RFC 2290	Mobile-IPv4 Configuration Option for PPP IPCP
	Authors: J. Solomon, S. Glass. Date: February 1998 Formats: txt pdf Updates: RFC 2002 Updated by: RFC 2794 Status: PROPOSED STANDARD Mobile IP [RFC 2002] defines media-independent procedures by which aMobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point- to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to theInternet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP[RFC 1332], and PPP [RFC 1661] is assumed.
RFC 2293	Representing Tables and Subtrees in the X.500 Directory
	Authors: S. Kille. Date: March 1998 Formats: txt pdf Obsoletes: RFC 1837 Status: PROPOSED STANDARD This document defines techniques for representing two types of information mapping in the OSI Directory [1]. 1. Mapping from a key to a value (or set of values), as might be done in a table lookup. 2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability.
RFC 2294	Representing the O/R Address hierarchy in the X.500 Directory Information Tree
	Authors: S. Kille. Date: March 1998 Formats: txt pdf Obsoletes: RFC 1836 Status: PROPOSED STANDARD This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: o Support for MHS Routing [4]. o Support for X.400/RFC 822 address mappings [2, 5]. Please send comments to the author or to the discussion group <mhs- ds@mercury.udev.cdc.com&rt;. Object Class Mandatory------------ --------- mHSCountry M aDMD M pRMD O mHSX121 O mHSNumericUserIdentifier O mHSOrganization O mHSOrganizationalUnit O mHSPerson O mHSNamedObject O mHSTerminalID O mHSDomainDefinedAttribute O Table 1: Order of O/R Address Directory Components
RFC 2298	An Extensible Message Format for Message Disposition Notifications
	Authors: R. Fajman. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3798 Status: PROPOSED STANDARD This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully 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 the privacy concerns that 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 2301	File Format for Internet Fax
	Authors: L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3949 Status: PROPOSED STANDARD This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed RasterContent modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-TRecommendations. Files formatted according to this specification use the image/tiff MIME Content Type.
RFC 2302	Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
	Authors: G. Parsons, J. Rafferty, S. Zilles. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3302 Status: PROPOSED STANDARD This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]
RFC 2303	Minimal PSTN address format in Internet Mail
	Authors: C. Allocchio. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3191 Status: PROPOSED STANDARD This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]
RFC 2304	Minimal FAX address format in Internet Mail
	Authors: C. Allocchio. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3192 Status: PROPOSED STANDARD This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK]
RFC 2305	A Simple Mode of Facsimile Using Internet Mail
	Authors: K. Toyoda, H. Ohno, J. Murai, D. Wing. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3965 Status: PROPOSED STANDARD This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]
RFC 2308	Negative Caching of DNS Queries (DNS NCACHE)
	Authors: M. Andrews. Date: March 1998 Formats: txt pdf Updates: RFC 1034, RFC 1035 Updated by: RFC 4035, RFC 4033, RFC 4034 Status: PROPOSED STANDARD [RFC1034] provided a description of how to cache negative responses.It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section4.3.4]. Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name. Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver.
RFC 2320	Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)
	Authors: M. Greene, J. Luciani, K. White, T. Kuo. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD The purpose of this memo is to define the Management Information Base(MIB) for supporting Classical IP and ARP over ATM as specified inClassical IP and ARP over ATM, refer to reference [3]. Support of anATM interface by an IP layer will require implementation of objects from several Management Information Bases (MIBs) as well as their enhancement in order to enable usage of ATM transports. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of theSimple Network Management Protocol Version (refer to RFC 1902, reference [1]).
RFC 2326	Real Time Streaming Protocol (RTSP)
	Authors: H. Schulzrinne, A. Rao, R. Lanphier. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889).
RFC 2327	SDP: Session Description Protocol
	Authors: M. Handley, V. Jacobson. Date: April 1998 Formats: txt pdf Obsoleted by: RFC 4566 Updated by: RFC 3266 Status: PROPOSED STANDARD This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors.
RFC 2331	ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update
	Authors: M. Maher. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 [SIG40] to support IP over ATM environments as described in RFC 2225 [LAUB98] and in RFC 2332 [LUC98]. Among the new features found in UNISignalling 4.0 are Available Bit Rate signalling and traffic parameter negotiation. This memo highlights the features of UNISignalling 4.0 that provide IP entities capabilities for requestingATM service in sites with SVC support, whether it is private ATM or publicly provisioned ATM, in which case the SVC support is probably configured inside PVPs. This document is only relevant to IP when used as the well known"best effort" connectionless service. In particular, this means that this document does not pertain to IP in the presence of implementedIP Integrated Services. The topic of IP with Integrated Services over ATM will be handled by a different specification or set of specifications being worked on in the ISSLL WG. This specification is a follow-on to RFC 1755, "ATM Signaling Support for IP over ATM", which is based on UNI 3.1 signalling [UNI95].Readers are assumed to be familiar with RFC 1755.
RFC 2332	NBMA Next Hop Resolution Protocol (NHRP)
	Authors: J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes the NBMA Next Hop Resolution Protocol (NHRP).NHRP can be used by a source station (host or router) connected to aNon-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the"NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks. Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study. This document is intended to be a functional superset of the NBMAAddress Resolution Protocol (NARP) documented in [1]. Operation of NHRP as a means of establishing a transit path across anNBMA subnetwork between two routers will be addressed in a separate document (see [13]).
RFC 2333	NHRP Protocol Applicability Statement
	Authors: D. Cansever. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol(NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access(NBMA) networks, such as ATM, SMDS and X.25.
RFC 2334	Server Cache Synchronization Protocol (SCSP)
&nb