Internet Documents

RFCs

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs 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 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 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 ps pdf
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 ps pdf
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 ps pdf
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
Obsoleted by:RFC 7323
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 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, RFC 6633
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, RFC 6649
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, RFC 6864
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, RFC 6780
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
Updates:RFC 1112
Updated by:RFC 3376
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, RFC 6604
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)
 
Authors:J. Luciani, G. Armitage, J. Halpern, N. Doraswamy.
Date:April 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes the Server Cache Synchronization Protocol(SCSP) and is written in terms of SCSP's use within Non BroadcastMultiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. SCSP attempts to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. However, in this document, SCSP is couched in terms of the client/server paradigm in which distributed server entities, which are bound to a Server Group (SG) through some means, wish to synchronize the contents (or a portion thereof) of their caches which contain information about the state of clients being served.
 
RFC 2335 A Distributed NHRP Service Using SCSP
 
Authors:J. Luciani.
Date:April 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a method for distributing an NHRP service within a LIS [1]. This method uses the Server Cache SynchronizationProtocol (SCSP) [2] to synchronize the client information databases held by NHRP Servers (NHSs) within a LIS.
 
RFC 2338 Virtual Router Redundancy Protocol
 
Authors:S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem.
Date:April 1998
Formats:txt pdf
Obsoleted by:RFC 3768
Status:PROPOSED STANDARD
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.
 
RFC 2342 IMAP4 Namespace
 
Authors:M. Gahrns, C. Newman.
Date:May 1998
Formats:txt pdf
Updated by:RFC 4466
Status:PROPOSED STANDARD
This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS- TRACK]
 
RFC 2344 Reverse Tunneling for Mobile IP
 
Authors:G. Montenegro, Ed..
Date:May 1998
Formats:txt pdf
Obsoleted by:RFC 3024
Status:PROPOSED STANDARD
Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address.When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.

This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.

 
RFC 2358 Definitions of Managed Objects for the Ethernet-like Interface Types
 
Authors:J. Flick, J. Johnson.
Date:June 1998
Formats:txt pdf
Obsoletes:RFC 1650
Obsoleted by:RFC 2665
Status:PROPOSED STANDARD
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1650 "Definitions of Managed Objects for theEthernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces.

Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.

 
RFC 2359 IMAP4 UIDPLUS extension
 
Authors:J. Myers.
Date:June 1998
Formats:txt pdf
Obsoleted by:RFC 4315
Status:PROPOSED STANDARD
The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]
 
RFC 2363 PPP Over FUNI
 
Authors:G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens.
Date:July 1998
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 ATM Frame User Network Interface(FUNI) for framing PPP encapsulated packets.

 
RFC 2364 PPP Over AAL5
 
Authors:G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens.
Date:July 1998
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 ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets.

 
RFC 2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
 
Authors:C. Chung, M. Greene.
Date:July 1998
Formats:txt pdf
Obsoleted by:RFC 2417
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 for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1].

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.

This memo does not specify a standard for the Internet community.

 
RFC 2368 The mailto URL scheme
 
Authors:P. Hoffman, L. Masinter, J. Zawinski.
Date:July 1998
Formats:txt pdf
Obsoleted by:RFC 6068
Updates:RFC 1738, RFC 1808
Status:PROPOSED STANDARD
This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', andRFC 1808, 'Relative Uniform Resource Locators'. The syntax of'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 messages by allowing the URL to express additional header and body fields.
 
RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
 
Authors:G. Neufeld, J. Baer.
Date:July 1998
Formats:txt pdf
Status:PROPOSED STANDARD
The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. Each field typically contains a URL (usually mailto [RFC2368]) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe.

There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These areList-Post, List-Owner and List-Archive.

By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.

 
RFC 2370 The OSPF Opaque LSA Option
 
Authors:R. Coltun.
Date:July 1998
Formats:txt pdf
Obsoleted by:RFC 5250
Updated by:RFC 3630
Also:RFC 2328
Status:PROPOSED STANDARD
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]
 
RFC 2371 Transaction Internet Protocol Version 3.0
 
Authors:J. Lyon, K. Evans, J. Klein.
Date:July 1998
Formats:txt pdf
Status:PROPOSED STANDARD
In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end.
 
RFC 2373 IP Version 6 Addressing Architecture
 
Authors:R. Hinden, S. Deering.
Date:July 1998
Formats:txt pdf
Obsoletes:RFC 1884
Obsoleted by:RFC 3513
Status:PROPOSED STANDARD
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.
 
RFC 2380 RSVP over ATM Implementation Requirements
 
Authors:L. Berger.
Date:August 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This memo presents specific implementation requirements for runningRSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP overATM.
 
RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM
 
Authors:M. Garrett, M. Borden.
Date:August 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. The service mappings are useful for providing effective interoperation and end-to-end Quality of Service for IPIntegrated Services networks containing ATM subnetworks.

The discussion and specifications given here support the IP integrated services protocols for Guaranteed Service (GS),Controlled-Load Service (CLS) and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service over ATM is also included.

 
RFC 2384 POP URL Scheme
 
Authors:R. Gellens.
Date:August 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]
 
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
 
Authors:A. Heffernan.
Date:August 1998
Formats:txt pdf
Obsoleted by:RFC 5925
Updated by:RFC 6691
Status:PROPOSED STANDARD
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP.
 
RFC 2387 The MIME Multipart/Related Content-type
 
Authors:E. Levinson.
Date:August 1998
Formats:txt pdf
Obsoletes:RFC 2112
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 2388 Returning Values from Forms: multipart/form-data
 
Authors:L. Masinter.
Date:August 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]
 
RFC 2389 Feature negotiation mechanism for the File Transfer Protocol
 
Authors:P. Hethmon, R. Elz.
Date:August 1998
Formats:txt pdf
Also:RFC 0959
Status:PROPOSED STANDARD
The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms.This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server.
 
RFC 2392 Content-ID and Message-ID Uniform Resource Locators
 
Authors:E. Levinson.
Date:August 1998
Formats:txt pdf
Obsoletes:RFC 2111
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 2393 IP Payload Compression Protocol (IPComp)
 
Authors:A. Shacham, R. Monsour, R. Pereira, M. Thomas.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 3173
Status:PROPOSED STANDARD
This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.
 
RFC 2397 The "data" URL scheme
 
Authors:L. Masinter.
Date:August 1998
Formats:txt pdf
Status:PROPOSED STANDARD
A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]
 
RFC 2401 Security Architecture for the Internet Protocol
 
Authors:S. Kent, R. Atkinson.
Date:November 1998
Formats:txt pdf
Obsoletes:RFC 1825
Obsoleted by:RFC 4301
Updated by:RFC 3168
Status:PROPOSED STANDARD
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]
 
RFC 2402 IP Authentication Header
 
Authors:S. Kent, R. Atkinson.
Date:November 1998
Formats:txt pdf
Obsoletes:RFC 1826
Obsoleted by:RFC 4302, RFC 4305
Status:PROPOSED STANDARD
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]
 
RFC 2403 The Use of HMAC-MD5-96 within ESP and AH
 
Authors:C. Madson, R. Glenn.
Date:November 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload[ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection.

Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

 
RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH
 
Authors:C. Madson, R. Glenn.
Date:November 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with SHA-1 provides data origin authentication and integrity protection.

Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

 
RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
 
Authors:C. Madson, N. Doraswamy.
Date:November 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes the use of the DES Cipher algorithm in CipherBlock Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating SecurityPayload (ESP).
 
RFC 2406 IP Encapsulating Security Payload (ESP)
 
Authors:S. Kent, R. Atkinson.
Date:November 1998
Formats:txt pdf
Obsoletes:RFC 1827
Obsoleted by:RFC 4303, RFC 4305
Status:PROPOSED STANDARD
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]
 
RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP
 
Authors:D. Piper.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 4306
Status:PROPOSED STANDARD
This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]
 
RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)
 
Authors:D. Maughan, M. Schertler, M. Schneider, J. Turner.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 4306
Status:PROPOSED STANDARD
This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications(via IP Security Service or any other security protocol) in anInternet environment.
 
RFC 2409 The Internet Key Exchange (IKE)
 
Authors:D. Harkins, D. Carrel.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 4306
Updated by:RFC 4109
Status:PROPOSED STANDARD
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]
 
RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec
 
Authors:R. Glenn, S. Kent.
Date:November 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines the NULL encryption algorithm and its use with theIPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality.

Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD].

 
RFC 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
 
Authors:C. Chung, M. Greene.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 2366
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 for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1].

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 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis)
 
Authors:K. Sklower, G. Meyer.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 1969
Status:PROPOSED STANDARD
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.

This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.

 
RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE)
 
Authors:H. Kummert.
Date:September 1998
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.

The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.

This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets.

 
RFC 2421 Voice Profile for Internet Mail - version 2
 
Authors:G. Vaudreuil, G. Parsons.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 1911
Obsoleted by:RFC 3801
Status:PROPOSED STANDARD
This document profiles Internet mail for voice messaging. [STANDARDS- TRACK]
 
RFC 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
 
Authors:G. Vaudreuil, G. Parsons.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 1911
Obsoleted by:RFC 3802
Status:PROPOSED STANDARD
This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]
 
RFC 2423 VPIM Voice Message MIME Sub-type Registration
 
Authors:G. Vaudreuil, G. Parsons.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 1911
Obsoleted by:RFC 3801
Status:PROPOSED STANDARD
This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]
 
RFC 2424 Content Duration MIME Header Definition
 
Authors:G. Vaudreuil, G. Parsons.
Date:September 1998
Formats:txt pdf
Obsoleted by:RFC 3803
Status:PROPOSED STANDARD
This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]
 
RFC 2425 A MIME Content-Type for Directory Information
 
Authors:T. Howes, M. Smith, F. Dawson.
Date:September 1998
Formats:txt pdf
Obsoleted by:RFC 6350
Status:PROPOSED STANDARD
This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]
 
RFC 2426 vCard MIME Directory Profile
 
Authors:F. Dawson, T. Howes.
Date:September 1998
Formats:txt pdf
Obsoleted by:RFC 6350
Status:PROPOSED STANDARD
This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document.
 
RFC 2428 FTP Extensions for IPv6 and NATs
 
Authors:M. Allman, S. Ostermann, C. Metz.
Date:September 1998
Formats:txt pdf
Status:PROPOSED STANDARD
The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address(specifically IP version 4). With the deployment of version 6 of theInternet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.
 
RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec
 
Authors:H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu.
Date:October 1998
Formats:txt pdf
Obsoleted by:RFC 4629
Status:PROPOSED STANDARD
This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]
 
RFC 2431 RTP Payload Format for BT.656 Video Encoding
 
Authors:D. Tynan.
Date:October 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies the RTP payload format for encapsulating ITURecommendation BT.656-3 video streams in the Real-Time TransportProtocol (RTP). Each RTP packet contains all or a portion of one scan line as defined by ITU Recommendation BT.601-5, and includes fragmentation, decoding and positioning information.
 
RFC 2435 RTP Payload Format for JPEG-compressed Video
 
Authors:L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart.
Date:October 1998
Formats:txt pdf
Obsoletes:RFC 2035
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 2439 BGP Route Flap Damping
 
Authors:C. Villamizar, R. Chandra, R. Govindan.
Date:November 1998
Formats:txt pdf
Status:PROPOSED STANDARD
A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP.

The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes.

This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead

An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet.This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is"route flap". The techniques described here are now widely deployed and are commonly referred to as "route flap damping".

 
RFC 2440 OpenPGP Message Format
 
Authors:J. Callas, L. Donnerhacke, H. Finney, R. Thayer.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 4880
Status:PROPOSED STANDARD
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP.

 
RFC 2444 The One-Time-Password SASL Mechanism
 
Authors:C. Newman.
Date:October 1998
Formats:txt pdf
Updates:RFC 2222
Status:PROPOSED STANDARD
OTP [OTP] provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL [SASL] mechanism so it can be easily and formally integrated into many application protocols.
 
RFC 2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar)
 
Authors:F. Dawson, D. Stenerson.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 5545
Status:PROPOSED STANDARD
There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across theInternet.

This memo is formatted as a registration for a MIME media type per[RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type.

The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below.

This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities.

This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information.In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification.

This memo defines the format for specifying iCalendar object methods.An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendentInteroperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol.

 
RFC 2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
 
Authors:S. Silverberg, S. Mansour, F. Dawson, R. Hopson.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 5546
Status:PROPOSED STANDARD
This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems.Subsequent documents specify interoperable methods of communications between systems that use this protocol.

The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects.Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects.

This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol(iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols.

 
RFC 2447 iCalendar Message-Based Interoperability Protocol (iMIP)
 
Authors:F. Dawson, S. Mansour, S. Silverberg.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 6047
Status:PROPOSED STANDARD
This document, [iMIP], specifies a binding from the iCalendarTransport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendarObject Model [iCAL] are composed using constructs from [RFC-822],[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

This document is based on discussions within the Internet EngineeringTask Force (IETF) Calendaring and Scheduling (CALSCH) working group.More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents.

 
RFC 2449 POP3 Extension Mechanism
 
Authors:R. Gellens, C. Newman, L. Lundblade.
Date:November 1998
Formats:txt pdf
Updates:RFC 1939
Updated by:RFC 5034
Status:PROPOSED STANDARD
This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]
 
RFC 2451 The ESP CBC-Mode Cipher Algorithms
 
Authors:R. Pereira, R. Adams.
Date:November 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms.
 
RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol
 
Authors:M. Daniele.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4022
Status:PROPOSED STANDARD
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl Protocol (TCP) over IP Version 6 (IPv6).

This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of whichIP versions underlie TCP, and only the TCP connection information isIP version-specific.

This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets.

 
RFC 2455 Definitions of Managed Objects for APPN
 
Authors:B. Clouston, B. Moore.
Date:November 1998
Formats:txt pdf
Obsoletes:RFC 2155
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.
 
RFC 2456 Definitions of Managed Objects for APPN TRAPS
 
Authors:B. Clouston, B. Moore.
Date:November 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 defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR(Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture.
 
RFC 2457 Definitions of Managed Objects for Extended Border Node
 
Authors:B. Clouston, B. Moore.
Date:November 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 defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN(Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture.
 
RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile
 
Authors:R. Housley, W. Ford, W. Polk, D. Solo.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 3280
Status:PROPOSED STANDARD
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices.
 
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
 
Authors:M. Crawford.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1972
Updated by:RFC 6085
Status:PROPOSED STANDARD
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]
 
RFC 2465 Management Information Base for IP Version 6: Textual Conventions and General Group
 
Authors:D. Haskin, S. Onishi.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4293
Status:PROPOSED STANDARD
This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.

This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.

 
RFC 2466 Management Information Base for IP Version 6: ICMPv6 Group
 
Authors:D. Haskin, S. Onishi.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4293
Status:PROPOSED STANDARD
This document is one in the series of documents that define variousMIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.

This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.

 
RFC 2467 Transmission of IPv6 Packets over FDDI Networks
 
Authors:M. Crawford.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 2019
Status:PROPOSED STANDARD
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS- TRACK]
 
RFC 2470 Transmission of IPv6 Packets over Token Ring Networks
 
Authors:M. Crawford, T. Narten, S. Thomas.
Date:December 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]
 
RFC 2472 IP Version 6 over PPP
 
Authors:D. Haskin, E. Allen.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 2023
Obsoleted by:RFC 5072, RFC 5172
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 2473 Generic Packet Tunneling in IPv6 Specification
 
Authors:A. Conta, S. Deering.
Date:December 1998
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others.
 
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
 
Authors:K. Nichols, S. Blake, F. Baker, D. Black.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1455, RFC 1349
Updates:RFC 0791
Updated by:RFC 3168, RFC 3260
Status:PROPOSED STANDARD
Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of:

- setting bits in an IP header field at network boundaries(autonomous system boundaries, internal administrative boundaries, or hosts),- using those bits to determine how packets are forwarded by the nodes inside the network, and- conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.

The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity.

This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined.

For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].

 
RFC 2476 Message Submission
 
Authors:R. Gellens, J. Klensin.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4409
Status:PROPOSED STANDARD
This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]
 
RFC 2478 The Simple and Protected GSS-API Negotiation Mechanism
 
Authors:E. Baize, D. Pinkas.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4178
Status:PROPOSED STANDARD
This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK]
 
RFC 2480 Gateways and MIME Security Multiparts
 
Authors:N. Freed.
Date:January 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]
 
RFC 2484 PPP LCP Internationalization Configuration Option
 
Authors:G. Zorn.
Date:January 1999
Formats:txt pdf
Updates:RFC 2284, RFC 1994, RFC 1570
Status:PROPOSED STANDARD
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]
 
RFC 2485 DHCP Option for The Open Group's User Authentication Protocol
 
Authors:S. Drach.
Date:January 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines a DHCP [1] option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open GroupNetwork Computing Client Technical Standard [2].
 
RFC 2486 The Network Access Identifier
 
Authors:B. Aboba, M. Beadles.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 4282
Status:PROPOSED STANDARD
This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]
 
RFC 2487 SMTP Service Extension for Secure SMTP over TLS
 
Authors:P. Hoffman.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 3207
Status:PROPOSED STANDARD
This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]
 
RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks
 
Authors:G. Armitage, P. Schulter, M. Jork, G. Harter.
Date:January 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described.

Dynamic NBMA shortcuts are achieved through the use of IPv6 NeighborDiscovery protocol operation within Logical Links, and inter-routerNHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported.

 
RFC 2492 IPv6 over ATM Networks
 
Authors:G. Armitage, P. Schulter, M. Jork.
Date:January 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths(when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.
 
RFC 2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
 
Authors:K. Tesink, Ed..
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 3593
Status:PROPOSED STANDARD
This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals.
 
RFC 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type
 
Authors:D. Fowler, Ed..
Date:January 1999
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 objects used for managing DS0 and DS0Bundle interfaces. This document is a companion document withDefinitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 [17]),DS3/E3 (RFC 2496 [18]), and the work in progress, SONET/SDH InterfaceTypes.

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 2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types
 
Authors:D. Fowler, Ed..
Date:January 1999
Formats:txt pdf
Obsoletes:RFC 1406
Obsoleted by:RFC 3895
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 DS1, E1, DS2 and E2 interfaces. This document is a companion document withDefinitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3(RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types.

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 2496 Definitions of Managed Object for the DS3/E3 Interface Type
 
Authors:D. Fowler, Ed..
Date:January 1999
Formats:txt pdf
Obsoletes:RFC 1407
Obsoleted by:RFC 3896
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 DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [25]), DS1/E1/DS2/E2 (RFC2495 [17]), and the work in progress SONET/SDH Interface Types.

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 2497 Transmission of IPv6 Packets over ARCnet Networks
 
Authors:I. Souvatzis.
Date:January 1999
Formats:txt pdf
Also:RFC 1201
Status:PROPOSED STANDARD
This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]
 
RFC 2507 IP Header Compression
 
Authors:M. Degermark, B. Nordgren, S. Pink.
Date:February 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP andUDP headers, and encapsulated IPv6 and IPv4 headers.

Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links.

The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links.

 
RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
 
Authors:S. Casner, V. Jacobson.
Date:February 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a method for compressing the headers ofIP/UDP/RTP datagrams to reduce overhead on low-speed serial links.In many cases, all three headers can be compressed to 2-4 bytes.

Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s).

 
RFC 2509 IP Header Compression over PPP
 
Authors:M. Engan, S. Casner, C. Bormann.
Date:February 1999
Formats:txt pdf
Obsoleted by:RFC 3544
Status:PROPOSED STANDARD
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in [IPHC] and [CRTP].
 
RFC 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols
 
Authors:C. Adams, S. Farrell.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 4210
Status:PROPOSED STANDARD
This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management.Note that "certificate" in this document refers to an X.509v3Certificate as defined in [COR95, X509-AM].
 
RFC 2511 Internet X.509 Certificate Request Message Format
 
Authors:M. Myers, C. Adams, D. Solo, D. Kemp.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 4211
Status:PROPOSED STANDARD
This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]
 
RFC 2512 Accounting Information for ATM Networks
 
Authors:K. McCloghrie, J. Heinanen, W. Greene, A. Prasad.
Date:February 1999
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. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]
 
RFC 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
 
Authors:K. McCloghrie, J. Heinanen, W. Greene, A. Prasad.
Date:February 1999
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 controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]
 
RFC 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management
 
Authors:M. Noto, E. Spiegel, K. Tesink.
Date:February 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services.
 
RFC 2515 Definitions of Managed Objects for ATM Management
 
Authors:K. Tesink, Ed.
Date:February 1999
Formats:txt pdf
Obsoletes:RFC 1695
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 2518 HTTP Extensions for Distributed Authoring -- WEBDAV
 
Authors:Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen.
Date:February 1999
Formats:txt pdf
Obsoleted by:RFC 4918
Status:PROPOSED STANDARD
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).
 
RFC 2526 Reserved IPv6 Subnet Anycast Addresses
 
Authors:D. Johnson, S. Deering.
Date:March 1999
Formats:txt pdf
Status:PROPOSED STANDARD
The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces(typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.
 
RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
 
Authors:B. Carpenter, C. Jung.
Date:March 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, RouterAdvertisement, Neighbor Solicitation, and Neighbor Advertisement andRedirect messages, when those messages are transmitted on an IPv4 multicast network.

The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It usesIPv4 multicast as a "virtual Ethernet".

 
RFC 2530 Indicating Supported Media Features Using Extensions to DSN and MDN
 
Authors:D. Wing.
Date:March 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]
 
RFC 2531 Content Feature Schema for Internet Fax
 
Authors:G. Klyne, L. McIntyre.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 2879
Status:PROPOSED STANDARD
This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5].

This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values. It specifies a textual format to be used for describing Internet fax capability information.

 
RFC 2532 Extended Facsimile Using Internet Mail
 
Authors:L. Masinter, D. Wing.
Date:March 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes extensions to "Simple Mode of Facsimile UsingInternet Mail" [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing.

These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html&rt;.

 
RFC 2533 A Syntax for Describing Media Feature Sets
 
Authors:G. Klyne.
Date:March 1999
Formats:txt pdf
Updated by:RFC 2738, RFC 2938
Status:PROPOSED STANDARD
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1].A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3].

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.

An algorithm for feature set matching is also described here.

 
RFC 2534 Media Features for Display, Print, and Fax
 
Authors:L. Masinter, D. Wing, A. Mutz, K. Holtman.
Date:March 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications.These features are registered for use within the framework of [REG].
 
RFC 2535 Domain Name System Security Extensions
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 2065
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 2181, RFC 1035, RFC 1034
Updated by:RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Status:PROPOSED STANDARD
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases.

The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services 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 and requests.

This document incorporates feedback on RFC 2065 from early implementers and potential users.

 
RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Updated by:RFC 6944
Status:PROPOSED STANDARD
A standard method for storing US Government Digital SignatureAlgorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records.
 
RFC 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 3110
Status:PROPOSED STANDARD
A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNSKEY and SIG resource records.
 
RFC 2538 Storing Certificates in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd, O. Gudmundsson.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 4398
Status:PROPOSED STANDARD
Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).
 
RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Updated by:RFC 6944
Status:PROPOSED STANDARD
A standard method for storing Diffie-Hellman keys in the Domain NameSystem is described which utilizes DNS KEY resource records.
 
RFC 2543 SIP: Session Initiation Protocol
 
Authors:M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265
Status:PROPOSED STANDARD
The Session Initiation Protocol (SIP) is an application-layer control(signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.

SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types.SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.

 
RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
 
Authors:P. Marques, F. Dupont.
Date:March 1999
Formats:txt pdf
Status:PROPOSED STANDARD
BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information.This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information.
 
RFC 2554 SMTP Service Extension for Authentication
 
Authors:J. Myers.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 4954
Status:PROPOSED STANDARD
This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]
 
RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
 
Authors:J. Palme, A. Hopmann, N. Shelness.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 2110
Status:PROPOSED STANDARD
HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers(URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI.

In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by whichURIs in the text/html root can reference subsidiary resources within that composite message structure.

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header(Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure.

While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents.

Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.

 
RFC 2558 Definitions of Managed Objects for the SONET/SDH Interface Type
 
Authors:K. Tesink.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 1595
Obsoleted by:RFC 3592
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 Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]
 
RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
 
Authors:M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 6960
Updated by:RFC 6277
Status:PROPOSED STANDARD
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK]
 
RFC 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2
 
Authors:K. White, R. Moore.
Date:April 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices.

The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be.

A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA)System Services Control Point (SSCP) for the dependent SecondaryLogical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gatewayTN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods.

It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data.

 
RFC 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)
 
Authors:K. White, R. Moore.
Date:April 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines the protocol and the Management Information Base(MIB) for performing response time data collection on TN3270 andTN3270E sessions by a TN3270E server. The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring ofTN3270 and TN3270E Sessions. This MIB has as a prerequisite theTN3270E-MIB, reference [20].

TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices.

 
RFC 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
 
Authors:R. Troll.
Date:May 1999
Formats:txt pdf
Status:PROPOSED STANDARD
Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum.To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-localIP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own.
 
RFC 2564 Application Management MIB
 
Authors:C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia.
Date:May 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a standards track portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the SystemApplication MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed.
 
RFC 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
 
Authors:R. Frye, D. Levi, S. Routhier, B. Wijnen.
Date:March 2000
Formats:txt pdf
Obsoletes:RFC 1908, RFC 2089
Obsoleted by:RFC 3584
Status:PROPOSED STANDARD
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14].
 
RFC 2581 TCP Congestion Control
 
Authors:M. Allman, V. Paxson, W. Stevens.
Date:April 1999
Formats:txt pdf
Obsoletes:RFC 2001
Obsoleted by:RFC 5681
Updated by:RFC 3390
Status:PROPOSED STANDARD
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.
 
RFC 2584 Definitions of Managed Objects for APPN/HPR in IP Networks
 
Authors:B. Clouston, B. Moore.
Date:May 1999
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 HPR(High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications.
 
RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
 
Authors:R. Housley, P. Hoffman.
Date:May 1999
Formats:txt pdf
Status:PROPOSED STANDARD
The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public KeyInfrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext TransferProtocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressingPKIX operational requirements are specified in separate documents.
 
RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema
 
Authors:S. Boeyen, T. Howes, P. Richard.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 4523
Status:PROPOSED STANDARD
The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]
 
RFC 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
 
Authors:Y. Yaacovi, M. Wahl, T. Genovese.
Date:May 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]
 
RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification
 
Authors:A. Conta, A. Malis, M. Mueller.
Date:May 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
 
RFC 2591 Definitions of Managed Objects for Scheduling Management Operations
 
Authors:D. Levi, J. Schoenwaelder.
Date:May 1999
Formats:txt pdf
Obsoleted by:RFC 3231
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 set of managed objects that are used to schedule management operations periodically or at specified dates and times.
 
RFC 2592 Definitions of Managed Objects for the Delegation of Management Script
 
Authors:D. Levi, J. Schoenwaelder.
Date:May 1999
Formats:txt pdf
Obsoleted by:RFC 3165
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 set of managed objects that allow the delegation of management scripts to distributed managers.
 
RFC 2594 Definitions of Managed Objects for WWW Services
 
Authors:H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder.
Date:May 1999
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 set of objects for managing World WideWeb (WWW) services.
 
RFC 2595 Using TLS with IMAP, POP3 and ACAP
 
Authors:C. Newman.
Date:June 1999
Formats:txt pdf
Updated by:RFC 4616
Status:PROPOSED STANDARD
Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]
 
RFC 2596 Use of Language Codes in LDAP
 
Authors:M. Wahl, T. Howes.
Date:May 1999
Formats:txt pdf
Obsoleted by:RFC 3866
Status:PROPOSED STANDARD
This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]
 
RFC 2597 Assured Forwarding PHB Group
 
Authors:J. Heinanen, F. Baker, W. Weiss, J. Wroclawski.
Date:June 1999
Formats:txt pdf
Updated by:RFC 3260
Status:PROPOSED STANDARD
This document defines a general use Differentiated Services (DS)[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.
 
RFC 2598 An Expedited Forwarding PHB
 
Authors:V. Jacobson, K. Nichols, K. Poduri.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 3246
Status:PROPOSED STANDARD
The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given.

A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf

 
RFC 2601 ILMI-Based Server Discovery for ATMARP
 
Authors:M. Davison.
Date:June 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers.
 
RFC 2602 ILMI-Based Server Discovery for MARS
 
Authors:M. Davison.
Date:June 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers.
 
RFC 2603 ILMI-Based Server Discovery for NHRP
 
Authors:M. Davison.
Date:June 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers.
 
RFC 2605 Directory Server Monitoring MIB
 
Authors:G. Mansfield, S. Kille.
Date:June 1999
Formats:txt pdf
Obsoletes:RFC 1567
Status:PROPOSED STANDARD
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoringDirectory Servers.
 
RFC 2608 Service Location Protocol, Version 2
 
Authors:E. Guttman, C. Perkins, J. Veizades, M. Day.
Date:June 1999
Formats:txt pdf
Updates:RFC 2165
Updated by:RFC 3224
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 need little or no 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 2609 Service Templates and Service: Schemes
 
Authors:E. Guttman, C. Perkins, J. Kempf.
Date:June 1999
Formats:txt pdf
Updates:RFC 2165
Status:PROPOSED STANDARD
The "service:" URL scheme name is used to define URLs (called"service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users.

This document describes a formal procedure for defining and standardizing new service types and attributes for use with the"service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable.They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings.

 
RFC 2610 DHCP Options for Service Location Protocol
 
Authors:C. Perkins, E. Guttman.
Date:June 1999
Formats:txt pdf
Status:PROPOSED STANDARD
The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network.Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents.
 
RFC 2615 PPP over SONET/SDH
 
Authors:A. Malis, W. Simpson.
Date:June 1999
Formats:txt pdf
Obsoletes:RFC 1619
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 Hierarchy (SDH) circuits.

This document replaces and obsoletes RFC 1619. See section 7 for a summary of the changes from RFC 1619.

 
RFC 2618 RADIUS Authentication Client MIB
 
Authors:B. Aboba, G. Zorn.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 4668
Status:PROPOSED STANDARD
This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients.
 
RFC 2619 RADIUS Authentication Server MIB
 
Authors:G. Zorn, B. Aboba.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 4669
Status:PROPOSED STANDARD
This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers.
 
RFC 2622 Routing Policy Specification Language (RPSL)
 
Authors:C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra.
Date:June 1999
Formats:txt pdf
Obsoletes:RFC 2280
Updated by:RFC 4012
Status:PROPOSED STANDARD
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous 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.
 
RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
 
Authors:M. Eisler.
Date:June 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how theVersion 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations.
 
RFC 2625 IP and ARP over Fibre Channel
 
Authors:M. Rajagopal, R. Bhagwat, W. Rickard.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 4338
Status:PROPOSED STANDARD
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.
 
RFC 2630 Cryptographic Message Syntax
 
Authors:R. Housley.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 3369, RFC 3370
Status:PROPOSED STANDARD
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.

The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management.

 
RFC 2631 Diffie-Hellman Key Agreement Method
 
Authors:E. Rescorla.
Date:June 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.
 
RFC 2632 S/MIME Version 3 Certificate Handling
 
Authors:B. Ramsdell, Ed..
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 3850
Status:PROPOSED STANDARD
S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]
 
RFC 2633 S/MIME Version 3 Message Specification
 
Authors:B. Ramsdell, Ed..
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 3851
Status:PROPOSED STANDARD
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]
 
RFC 2634 Enhanced Security Services for S/MIME
 
Authors:P. Hoffman, Ed..
Date:June 1999
Formats:txt pdf
Updated by:RFC 5035
Status:PROPOSED STANDARD
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]
 
RFC 2640 Internationalization of the File Transfer Protocol
 
Authors:B. Curtin.
Date:July 1999
Formats:txt pdf
Updates:RFC 0959
Status:PROPOSED STANDARD
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII.

This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending theFTP specification and giving recommendations for proper internationalization support.

 
RFC 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
 
Authors:R. Gellens.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]
 
RFC 2646 The Text/Plain Format Parameter
 
Authors:R. Gellens, Ed..
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 3676
Updates:RFC 2046
Status:PROPOSED STANDARD
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]
 
RFC 2651 The Architecture of the Common Indexing Protocol (CIP)
 
Authors:J. Allen, M. Mealling.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices.
 
RFC 2652 MIME Object Definitions for the Common Indexing Protocol (CIP)
 
Authors:J. Allen, M. Mealling.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type.
 
RFC 2653 CIP Transport Protocols
 
Authors:J. Allen, P. Leach, R. Hedberg.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP.The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH].
 
RFC 2658 RTP Payload Format for PureVoice(tm) Audio
 
Authors:K. McKay.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]
 
RFC 2661 Layer Two Tunneling Protocol "L2TP"
 
Authors:W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes the Layer Two Tunneling Protocol (L2TP). STD51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.
 
RFC 2662 Definitions of Managed Objects for the ADSL Lines
 
Authors:G. Bathrick, F. Ly.
Date:August 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]
 
RFC 2665 Definitions of Managed Objects for the Ethernet-like Interface Types
 
Authors:J. Flick, J. Johnson.
Date:August 1999
Formats:txt pdf
Obsoletes:RFC 2358
Obsoleted by:RFC 3635
Status:PROPOSED STANDARD
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces.

Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.

 
RFC 2667 IP Tunnel MIB
 
Authors:D. Thaler.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 4087
Status:PROPOSED STANDARD
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]
 
RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
 
Authors:A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts.
Date:August 1999
Formats:txt pdf
Obsoletes:RFC 2239
Obsoleted by:RFC 3636
Status:PROPOSED STANDARD
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.

Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.

 
RFC 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems
 
Authors:M. St. Johns, Ed..
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 4639
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 basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems.

This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.

This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.

 
RFC 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces
 
Authors:M. St. Johns, Ed..
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 4546
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 basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces.

This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.

This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.

 
RFC 2671 Extension Mechanisms for DNS (EDNS0)
 
Authors:P. Vixie.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 6891
Status:PROPOSED STANDARD
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.
 
RFC 2672 Non-Terminal DNS Name Redirection
 
Authors:M. Crawford.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 6672
Updated by:RFC 4592, RFC 6604
Status:PROPOSED STANDARD
This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]
 
RFC 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions
 
Authors:E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 4363
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 two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.

Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI].

This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB].

 
RFC 2675 IPv6 Jumbograms
 
Authors:D. Borman, S. Deering, R. Hinden.
Date:August 1999
Formats:txt pdf
Obsoletes:RFC 2147
Status:PROPOSED STANDARD
A "jumbogram" is an IPv6 packet containing a payload longer than65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.

Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.

 
RFC 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
 
Authors:M. Greene, J. Cucchiara, J. Luciani.
Date:August 1999
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 for the Next HopResolution Protocol (NHRP) as defined in RFC 2332.
 
RFC 2678 IPPM Metrics for Measuring Connectivity
 
Authors:J. Mahdavi, V. Paxson.
Date:September 1999
Formats:txt pdf
Obsoletes:RFC 2498
Status:PROPOSED STANDARD
This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]
 
RFC 2679 A One-way Delay Metric for IPPM
 
Authors:G. Almes, S. Kalidindi, M. Zekauskas.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]
 
RFC 2680 A One-way Packet Loss Metric for IPPM
 
Authors:G. Almes, S. Kalidindi, M. Zekauskas.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]
 
RFC 2681 A Round-trip Delay Metric for IPPM
 
Authors:G. Almes, S. Kalidindi, M. Zekauskas.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]
 
RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5
 
Authors:D. Grossman, J. Heinanen.
Date:September 1999
Formats:txt pdf
Obsoletes:RFC 1483
Status:PROPOSED STANDARD
This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM.The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection.
 
RFC 2685 Virtual Private Networks Identifier
 
Authors:B. Fox, B. Gleeson.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
Virtual Private IP networks may span multiple Autonomous Systems orService Providers. There is a requirement for the use of a globally unique VPN identifier in order to be able to refer to a particularVPN (see section 6.1.1 of [1]). This document proposes a format for a globally unique VPN identifier.
 
RFC 2686 The Multi-Class Extension to Multi-Link PPP
 
Authors:C. Bormann.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.

This document proposes the fragment-oriented solution for the real- time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and provide a small number of extensions to add functionality and reduce the overhead.

 
RFC 2687 PPP in a Real-time Oriented HDLC-like Framing
 
Authors:C. Bormann.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.

This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.

 
RFC 2688 Integrated Services Mappings for Low Speed Networks
 
Authors:S. Jackowski, D. Putzolu, E. Crawley, B. Davie.
Date:September 1999
Formats:txt pdf
Status:PROPOSED STANDARD
A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.

This document defines the service mappings of the IETF IntegratedServices for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.

 
RFC 2710 Multicast Listener Discovery (MLD) for IPv6
 
Authors:S. Deering, W. Fenner, B. Haberman.
Date:October 1999
Formats:txt pdf
Updated by:RFC 3590, RFC 3810
Status:PROPOSED STANDARD
This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as MulticastListener Discovery or MLD. MLD is derived from version 2 of IPv4'sInternet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.
 
RFC 2711 IPv6 Router Alert Option
 
Authors:C. Partridge, A. Jackson.
Date:October 1999
Formats:txt pdf
Updated by:RFC 6398
Status:PROPOSED STANDARD
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
 
RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
 
Authors:A. Medvinsky, M. Hur.
Date:October 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS TRACK]
 
RFC 2720 Traffic Flow Measurement: Meter MIB
 
Authors:N. Brownlee.
Date:October 1999
Formats:txt pdf
Obsoletes:RFC 2064
Status:PROPOSED STANDARD
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'.

This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised.

 
RFC 2725 Routing Policy System Security
 
Authors:C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy.
Date:December 1999
Formats:txt pdf
Updated by:RFC 4012
Status:PROPOSED STANDARD
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
 
RFC 2726 PGP Authentication for RIPE Database Updates
 
Authors:J. Zsako.
Date:December 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force.
 
RFC 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal
 
Authors:R. Panabaker, S. Wegerif, D. Zigmond.
Date:November 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS TRACK]
 
RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP)
 
Authors:S. Hanna, B. Patel, M. Shah.
Date:December 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines a protocol, Multicast Address Dynamic ClientAllocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.
 
RFC 2732 Format for Literal IPv6 Addresses in URL's
 
Authors:R. Hinden, B. Carpenter, L. Masinter.
Date:December 1999
Formats:txt pdf
Obsoleted by:RFC 3986
Updates:RFC 2396
Status:PROPOSED STANDARD
This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol.

This document incudes an update to the generic syntax for UniformResource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose.

 
RFC 2733 An RTP Payload Format for Generic Forward Error Correction
 
Authors:J. Rosenberg, H. Schulzrinne.
Date:December 1999
Formats:txt pdf
Obsoleted by:RFC 5109
Status:PROPOSED STANDARD
This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions.
 
RFC 2734 IPv4 over IEEE 1394
 
Authors:P. Johansson.
Date:December 1999
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS TRACK]
 
RFC 2735 NHRP Support for Virtual Private Networks
 
Authors:B. Fox, B. Petri.
Date:December 1999
Formats:txt pdf
Status:PROPOSED STANDARD
The NBMA Next Hop Resolution Protocol (NHRP) is used to determine theNBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see [1]). This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network.
 
RFC 2737 Entity MIB (Version 2)
 
Authors:K. McCloghrie, A. Bierman.
Date:December 1999
Formats:txt pdf
Obsoletes:RFC 2037
Obsoleted by:RFC 4133
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.
 
RFC 2738 Corrections to "A Syntax for Describing Media Feature Sets"
 
Authors:G. Klyne.
Date:December 1999
Formats:txt pdf
Updates:RFC 2533
Status:PROPOSED STANDARD
In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.

This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates.

 
RFC 2739 Calendar Attributes for vCard and LDAP
 
Authors:T. Small, D. Hennessy, F. Dawson.
Date:January 2000
Formats:txt pdf
Updated by:RFC 6350
Status:PROPOSED STANDARD
When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event.

In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time.

This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include:

- Manual transfer of the information;

- Personal data exchange using the vCard format; and

- Directory lookup using the LDAP protocol.

 
RFC 2740 OSPF for IPv6
 
Authors:R. Coltun, D. Ferguson, J. Moy.
Date:December 1999
Formats:txt pdf
Obsoleted by:RFC 5340
Status:PROPOSED STANDARD
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.

Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header andEncapsulating Security Payload.

Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed.In addition, option handling has been made more flexible.

All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF(MOSPF) are also supported in OSPF for IPv6.

 
RFC 2743 Generic Security Service Application Program Interface Version 2, Update 1
 
Authors:J. Linn.
Date:January 2000
Formats:txt pdf
Obsoletes:RFC 2078
Updated by:RFC 5554
Status:PROPOSED STANDARD
The Generic Security Service Application Program Interface (GSS-API),Version 2, as defined in [RFC-2078], 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 defines GSS-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 obsoletes [RFC-2078], 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 2744 Generic Security Service API Version 2 : C-bindings
 
Authors:J. Wray.
Date:January 2000
Formats:txt pdf
Obsoletes:RFC 1509
Status:PROPOSED STANDARD
This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC-2743 [GSSAPI]. It obsoletes RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track.

The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of 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 2745 RSVP Diagnostic Messages
 
Authors:A. Terzis, B. Braden, S. Vincent, L. Zhang.
Date:January 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules.
 
RFC 2746 RSVP Operation Over IP Tunnels
 
Authors:A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang.
Date:January 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.
 
RFC 2747 RSVP Cryptographic Authentication
 
Authors:F. Baker, B. Lindell, M. Talwar.
Date:January 2000
Formats:txt pdf
Updated by:RFC 3097
Status:PROPOSED STANDARD
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.
 
RFC 2748 The COPS (Common Open Policy Service) Protocol
 
Authors:D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry.
Date:January 2000
Formats:txt pdf
Updated by:RFC 4261
Status:PROPOSED STANDARD
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
 
RFC 2749 COPS usage for RSVP
 
Authors:S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry.
Date:January 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes usage directives for supporting COPS policy services in RSVP environments.
 
RFC 2750 RSVP Extensions for Policy Control
 
Authors:S. Herzog.
Date:January 2000
Formats:txt pdf
Updates:RFC 2205
Status:PROPOSED STANDARD
This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP]

These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events.

This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP].

 
RFC 2751 Signaled Preemption Priority Policy Element
 
Authors:S. Herzog.
Date:January 2000
Formats:txt pdf
Obsoleted by:RFC 3181
Status:PROPOSED STANDARD
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and[COPS]).

Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow.

 
RFC 2752 Identity Representation for RSVP
 
Authors:S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog.
Date:January 2000
Formats:txt pdf
Obsoleted by:RFC 3182
Status:PROPOSED STANDARD
This document describes the representation of identity information inPOLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting.
 
RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT)
 
Authors:E. Nordmark.
Date:February 2000
Formats:txt pdf
Obsoleted by:RFC 6145
Status:PROPOSED STANDARD
This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts.
 
RFC 2769 Routing Policy System Replication
 
Authors:C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer.
Date:February 2000
Formats:txt pdf
Status:PROPOSED STANDARD
The RIPE database specifications and RPSL define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any use. The Routing Policy System Security RFC [3] addresses the need to assure integrity of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System SecurityRFC.
 
RFC 2782 A DNS RR for specifying the location of services (DNS SRV)
 
Authors:A. Gulbrandsen, P. Vixie, L. Esibov.
Date:February 2000
Formats:txt pdf
Obsoletes:RFC 2052
Updated by:RFC 6335
Status:PROPOSED STANDARD
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.
 
RFC 2784 Generic Routing Encapsulation (GRE)
 
Authors:D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina.
Date:March 2000
Formats:txt pdf
Updated by:RFC 2890
Status:PROPOSED STANDARD
This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
 
RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol
 
Authors:B. Jewell, D. Chuang.
Date:March 2000
Formats:txt pdf
Obsoleted by:RFC 6527
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 routers that employ the Virtual Router RedundancyProtocol (VRRP) [17].

This memo specifies a MIB module in a manner that is compliant withSMIv2 [5], and semantically identical to the SMIv1 definitions [2].

 
RFC 2788 Network Services Monitoring MIB
 
Authors:N. Freed, S. Kille.
Date:March 2000
Formats:txt pdf
Obsoletes:RFC 2248
Status:PROPOSED STANDARD
This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS TRACK]
 
RFC 2789 Mail Monitoring MIB
 
Authors:N. Freed, S. Kille.
Date:March 2000
Formats:txt pdf
Obsoletes:RFC 2249, RFC 1566
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 defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS TRACK]
 
RFC 2793 RTP Payload for Text Conversation
 
Authors:G. Hellstrom.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4103
Status:PROPOSED STANDARD
This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified inITU-T Recommendation T.140 [1].

Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services.

This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198.

 
RFC 2794 Mobile IP Network Access Identifier Extension for IPv4
 
Authors:P. Calhoun, C. Perkins.
Date:March 2000
Formats:txt pdf
Updates:RFC 2290
Status:PROPOSED STANDARD
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers.Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.
 
RFC 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP
 
Authors:T. Bates, R. Chandra, E. Chen.
Date:April 2000
Formats:txt pdf
Obsoleted by:RFC 4456
Updates:RFC 1966
Status:PROPOSED STANDARD
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within thatAS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].

This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP.

 
RFC 2797 Certificate Management Messages over CMS
 
Authors:M. Myers, X. Liu, J. Schaad, J. Weinstein.
Date:April 2000
Formats:txt pdf
Obsoleted by:RFC 5272
Status:PROPOSED STANDARD
This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community:

1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys.

A small number of additional services are defined to supplement the core certificate request service.

Throughout this specification the term CMS is used to refer to both[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification.

 
RFC 2806 URLs for Telephone Calls
 
Authors:A. Vaha-Sipila.
Date:April 2000
Formats:txt pdf
Obsoleted by:RFC 3966
Status:PROPOSED STANDARD
This document specifies URL (Uniform Resource Locator) schemes "tel","fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers.
 
RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
 
Authors:R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer.
Date:May 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a signaling method and protocol for RSVP- based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee.
 
RFC 2815 Integrated Service Mappings on IEEE 802 Networks
 
Authors:M. Seaman, A. Smith, E. Crawley, J. Wroclawski.
Date:May 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes mappings of IETF Integrated Services overLANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches.

These mappings are one component of the Integrated Services over IEEE802 LANs framework.

 
RFC 2817 Upgrading to TLS Within HTTP/1.1
 
Authors:R. Khare, S. Lawrence.
Date:May 2000
Formats:txt pdf
Updates:RFC 2616
Updated by:RFC 7230, RFC 7231
Status:PROPOSED STANDARD
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP +TLS server can disambiguate traffic intended for several hostnames at a single IP address.

Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to- end tunnels across HTTP proxies. Finally, this memo establishes newIANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.

This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace(http://example.org/ and https://example.org/ are not equivalent).

 
RFC 2821 Simple Mail Transfer Protocol
 
Authors:J. Klensin, Ed..
Date:April 2001
Formats:txt pdf
Obsoletes:RFC 0821, RFC 0974, RFC 1869
Obsoleted by:RFC 5321
Updated by:RFC 5336
Status:PROPOSED STANDARD
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:

- the original SMTP (Simple Mail Transfer Protocol) specification ofRFC 821 [30],

- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],

- the clarifications and applicability statements in RFC 1123 [2], and

- material drawn from the SMTP Extension mechanisms [19].

It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models.Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.

It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.

Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476[15].

Section 2.3 provides definitions of terms specific to this document.Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.

A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship.

 
RFC 2822 Internet Message Format
 
Authors:P. Resnick, Ed..
Date:April 2001
Formats:txt pdf
Obsoletes:RFC 0822
Obsoleted by:RFC 5322
Updated by:RFC 5335, RFC 5336
Status:PROPOSED STANDARD
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.
 
RFC 2829 Authentication Methods for LDAP
 
Authors:M. Wahl, H. Alvestrand, J. Hodges, R. Morgan.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4513, RFC 4510
Updated by:RFC 3377
Status:PROPOSED STANDARD
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations.
 
RFC 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
 
Authors:J. Hodges, R. Morgan, M. Wahl.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4511, RFC 4513, RFC 4510
Updated by:RFC 3377
Status:PROPOSED STANDARD
This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request.
 
RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
 
Authors:H. Schulzrinne, S. Petrack.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4733, RFC 4734
Status:PROPOSED STANDARD
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
 
RFC 2834 ARP and IP Broadcast over HIPPI-800
 
Authors:J.-M. Pittet.
Date:May 2000
Formats:txt pdf
Obsoletes:RFC 1374
Updated by:RFC 5494
Status:PROPOSED STANDARD
This document specifies a method for resolving IP addresses to ANSIHigh-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte SystemNetwork, GSN). This document (when combined with RFC-2067 "IP overHIPPI") obsoletes RFC-1374.
 
RFC 2835 IP and ARP over HIPPI-6400 (GSN)
 
Authors:J.-M. Pittet.
Date:May 2000
Formats:txt pdf
Updated by:RFC 5494
Status:PROPOSED STANDARD
The ANSI T11.1 task force has standardized HIPPI-6400 also known asGigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified inHIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3].

HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs[10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI-6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks.

 
RFC 2836 Per Hop Behavior Identification Codes
 
Authors:S. Brim, B. Carpenter, F. Le Faucheur.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 3140
Status:PROPOSED STANDARD
This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK]
 
RFC 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard
 
Authors:K. Teow.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 4044
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 the objects for managing the operations of the Fabric Element portion of the Fibre ChannelStandards.
 
RFC 2842 Capabilities Advertisement with BGP-4
 
Authors:R. Chandra, J. Scudder.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 3392
Status:PROPOSED STANDARD
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives anOPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP.

This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiring that BGP peering be terminated.

 
RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
 
Authors:P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington.
Date:May 2000
Formats:txt pdf
Updates:RFC 1035
Updated by:RFC 3645, RFC 4635, RFC 6895
Status:PROPOSED STANDARD
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.

No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available.

 
RFC 2846 GSTN Address Element Extensions in E-mail Services
 
Authors:C. Allocchio.
Date:June 2000
Formats:txt pdf
Updated by:RFC 3191, RFC 3192
Status:PROPOSED STANDARD
There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in[1].
 
RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
 
Authors:M. Eisler.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memorandum describes a method whereby one can use GSS-API[RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol[RFC2246].

The method leverages the existing Simple Public Key Mechanism (SPKM)[RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM.

 
RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
 
Authors:S. Petrack, L. Conroy.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document contains the specification of the PINT Service Protocol1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.
 
RFC 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification
 
Authors:G. Good.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a file format suitable for describing directory information or modifications made to directory information.The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information betweenLDAP-based directory servers, or to describe a set of changes which are to be applied to a directory.
 
RFC 2851 Textual Conventions for Internet Network Addresses
 
Authors:M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder.
Date:June 2000
Formats:txt pdf
Obsoleted by:RFC 3291
Status:PROPOSED STANDARD
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations.

This work is output from the Operations and Management Area "IPv6MIB" design team.

 
RFC 2852 Deliver By SMTP Service Extension
 
Authors:D. Newman.
Date:June 2000
Formats:txt pdf
Updates:RFC 1894
Status:PROPOSED STANDARD
This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued.

This extension should not be viewed as a vehicle for requesting"priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a DeliverBy request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period.

A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond

17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a"delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems.

 
RFC 2853 Generic Security Service API Version 2 : Java Bindings
 
Authors:J. Kabat, M. Upadhyay.
Date:June 2000
Formats:txt pdf
Obsoleted by:RFC 5653
Status:PROPOSED STANDARD
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].

The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are TheSimple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5GSS-API Mechanism [KERBV5].

 
RFC 2855 DHCP for IEEE 1394
 
Authors:K. Fujisawa.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages.
 
RFC 2856 Textual Conventions for Additional High Capacity Data Types
 
Authors:A. Bierman, K. McCloghrie, R. Presuhn.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future.
 
RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH
 
Authors:A. Keromytis, N. Provos.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection.

Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

 
RFC 2858 Multiprotocol Extensions for BGP-4
 
Authors:T. Bates, Y. Rekhter, R. Chandra, D. Katz.
Date:June 2000
Formats:txt pdf
Obsoletes:RFC 2283
Obsoleted by:RFC 4760
Status:PROPOSED STANDARD
Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. 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.

This document obsoletes RFC 2283.

 
RFC 2862 RTP Payload Format for Real-Time Pointers
 
Authors:M. Civanlar, G. Cash.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism.
 
RFC 2864 The Inverted Stack Table Extension to the Interfaces Group MIB
 
Authors:K. McCloghrie, G. Hanson.
Date:June 2000
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 which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS TRACK]
 
RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP
 
Authors:Y. Bernet, R. Pabbati.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used byRSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information.
 
RFC 2873 TCP Processing of the IPv4 Precedence Field
 
Authors:X. Xiao, A. Hannan, V. Paxson, E. Crabbe.
Date:June 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memo describes a conflict between TCP [RFC793] and DiffServ[RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.

Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet.

 
RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms
 
Authors:H. Prafullchandra, J. Schaad.
Date:July 2000
Formats:txt pdf
Obsoleted by:RFC 6955
Status:PROPOSED STANDARD
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing.
 
RFC 2878 PPP Bridging Control Protocol (BCP)
 
Authors:M. Higashiyama, F. Baker.
Date:July 2000
Formats:txt pdf
Obsoletes:RFC 1638
Obsoleted by:RFC 3518
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.

This document obsoletes RFC 1638, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1QVirtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs.

 
RFC 2879 Content Feature Schema for Internet Fax (V2)
 
Authors:G. Klyne, L. McIntyre.
Date:August 2000
Formats:txt pdf
Obsoletes:RFC 2531
Status:PROPOSED STANDARD
This document defines a content media feature schema for Internet fax.

It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extendedInternet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531.

 
RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP
 
Authors:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky.
Date:July 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This note defines an extension of the Selective Acknowledgement(SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of theSACK option for acknowledging out-of-sequence data not covered byTCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts.
 
RFC 2890 Key and Sequence Number Extensions to GRE
 
Authors:G. Dommety.
Date:September 2000
Formats:txt pdf
Updates:RFC 2784
Status:PROPOSED STANDARD
GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GREHeader [1].
 
RFC 2891 LDAP Control Extension for Server Side Sorting of Search Results
 
Authors:T. Howes, M. Wahl, A. Anantha.
Date:August 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted.Other permissible controls on search operations are not defined in this extension.

The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation.

The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].

 
RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers
 
Authors:R. Gilligan, E. Nordmark.
Date:August 2000
Formats:txt pdf
Obsoletes:RFC 1933
Obsoleted by:RFC 4213
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. This document obsoletes RFC 1933.
 
RFC 2894 Router Renumbering for IPv6
 
Authors:M. Crawford.
Date:August 2000
Formats:txt pdf
Status:PROPOSED STANDARD
IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes.

This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of NeighborDiscovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site.

 
RFC 2907 MADCAP Multicast Scope Nesting State Option
 
Authors:R. Kermode.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines a new option to the Multicast Address DynamicClient Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence it may be used for expanding scope searches or hierarchical multicast transport.
 
RFC 2910 Internet Printing Protocol/1.1: Encoding and Transport
 
Authors:R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn.
Date:September 2000
Formats:txt pdf
Obsoletes:RFC 2565
Updated by:RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995
Status:PROPOSED STANDARD
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext TransferProtocol (HTTP) a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics [RFC2911]Internet Printing Protocol/1.1: Encoding and Transport (this document)Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]

The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.1. A few OPTIONAL operator operations have been added to IPP/1.1.

The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.

The document, "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.

The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.

The document "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

 
RFC 2911 Internet Printing Protocol/1.1: Model and Semantics
 
Authors:T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell.
Date:September 2000
Formats:txt pdf
Obsoletes:RFC 2566
Updated by:RFC 3380, RFC 3382, RFC 3996, RFC 3995
Status:PROPOSED STANDARD
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues.

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.1: Model and Semantics (this document)Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]Mapping between LPD and IPP Protocols [RFC2569]

The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.

The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.

The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called"application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.

The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.

The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

 
RFC 2912 Indicating Media Features for MIME Content
 
Authors:G. Klyne.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.

This memo defines a Multipurpose Internet Mail Extensions (MIME)'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.

 
RFC 2913 MIME Content Types in Media Feature Expressions
 
Authors:G. Klyne.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.

This memo defines a media feature tag whose value is a MultipurposeInternet Mail Extensions (MIME) content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.

 
RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record
 
Authors:M. Mealling, R. Daniel.
Date:September 2000
Formats:txt pdf
Obsoleted by:RFC 3401, RFC 3402, RFC 3403, RFC 3404
Updates:RFC 2168
Status:PROPOSED STANDARD
This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label orUniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer(NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).

This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource DiscoverySystems to moving out-of-date services to new domains.

This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR.

 
RFC 2916 E.164 number and DNS
 
Authors:P. Faltstrom.
Date:September 2000
Formats:txt pdf
Obsoleted by:RFC 3761
Status:PROPOSED STANDARD
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number.Routing of the actual connection using the service selected using these methods is not discussed.
 
RFC 2918 Route Refresh Capability for BGP-4
 
Authors:E. Chen.
Date:September 2000
Formats:txt pdf
Updated by:RFC 7313
Status:PROPOSED STANDARD
This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non-disruptive routing policy changes.
 
RFC 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
 
Authors:R. Chandhok, G. Wenger.
Date:March 2001
Formats:txt pdf
Status:PROPOSED STANDARD
Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time.

The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use.

By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available.

 
RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
 
Authors:K. White.
Date:September 2000
Formats:txt pdf
Obsoleted by:RFC 4560
Status:PROPOSED STANDARD
This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to anIP address at a remote host.

Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.

 
RFC 2930 Secret Key Establishment for DNS (TKEY RR)
 
Authors:D. Eastlake 3rd.
Date:September 2000
Formats:txt pdf
Updated by:RFC 6895
Status:PROPOSED STANDARD
[RFC 2845] provides a means of authenticating Domain Name System(DNS) queries and responses using shared secret keys via theTransaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server.
 
RFC 2931 DNS Request and Transaction Signatures ( SIG(0)s)
 
Authors:D. Eastlake 3rd.
Date:September 2000
Formats:txt pdf
Updates:RFC 2535
Status:PROPOSED STANDARD
Extensions to the Domain Name System (DNS) are described in [RFC2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.

Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein.

 
RFC 2932 IPv4 Multicast Routing MIB
 
Authors:K. McCloghrie, D. Farinacci, D. Thaler.
Date:October 2000
Formats:txt pdf
Obsoleted by:RFC 5132
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 IPMulticast Routing for IPv4, independent of the specific multicast routing protocol in use.
 
RFC 2933 Internet Group Management Protocol MIB
 
Authors:K. McCloghrie, D. Farinacci, D. Thaler.
Date:October 2000
Formats:txt pdf
Obsoleted by:RFC 5519
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 the InternetGroup Management Protocol (IGMP).
 
RFC 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement
 
Authors:D. Eastlake 3rd, C. Smith.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
Internet Open Trading Protocol (IOTP) messages will be carried asExtensible Markup Language (XML) documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.

This document describes that mapping for the Hyper Text TransportProtocol (HTTP), Versions 1.0 and 1.1.

 
RFC 2937 The Name Service Search Option for DHCP
 
Authors:C. Smith.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information.
 
RFC 2938 Identifying Composite Media Features
 
Authors:G. Klyne, L. Masinter.
Date:September 2000
Formats:txt pdf
Updates:RFC 2533
Status:PROPOSED STANDARD
In RFC 2533, an expression format is presented for describing media feature capabilities as a combination of simple media feature tags.

This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite.

 
RFC 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients
 
Authors:A. Smith, D. Partain, J. Seligson.
Date:October 2000
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 a client of the CommonOpen Policy Service (COPS) protocol.

This memo includes a MIB module in a manner that is compliant to theSMIv2 [V2SMI].

 
RFC 2941 Telnet Authentication Option
 
Authors:T. Ts'o, Ed., J. Altman.
Date:September 2000
Formats:txt pdf
Obsoletes:RFC 1416
Status:PROPOSED STANDARD
This document describes the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type.

This document updates a previous specification of the telnet authentication option, RFC 1416 [2], so that it can be used to securely enable the telnet encryption option [3].

 
RFC 2942 Telnet Authentication: Kerberos Version 5
 
Authors:T. Ts'o.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes how Kerberos Version 5 [1] is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option [2]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the telnet encryption option [3].
 
RFC 2943 TELNET Authentication Using DSA
 
Authors:R. Housley, T. Horting, P. Yee.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines a telnet authentication mechanism using theDigital Signature Algorithm (DSA) [FIPS186]. It relies on the TelnetAuthentication Option [RFC2941].
 
RFC 2944 Telnet Authentication: SRP
 
Authors:T. Wu.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies an authentication scheme for the Telnet protocol under the framework described in [RFC2941], using the SecureRemote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945].
 
RFC 2945 The SRP Authentication and Key Exchange System
 
Authors:T. Wu.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords.This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge-response techniques, making it an ideal drop-in replacement where secure password authentication is needed.
 
RFC 2946 Telnet Data Encryption Option
 
Authors:T. Ts'o.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. While this document summarizes currently utilized encryption types and codes, it does not define a specific encryption algorithm.Separate documents are to be published defining implementations of this option for each encryption algorithm.
 
RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback
 
Authors:J. Altman.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option.
 
RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback
 
Authors:J. Altman.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option.
 
RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback
 
Authors:J. Altman.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit.
 
RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback
 
Authors:J. Altman.
Date:September 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit.
 
RFC 2954 Definitions of Managed Objects for Frame Relay Service
 
Authors:K. Rehbehn, D. Fowler.
Date:October 2000
Formats:txt pdf
Obsoletes:RFC 1604
Status:PROPOSED STANDARD
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TransmissionControl Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service.

This document obsoletes RFC 1604.

 
RFC 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function
 
Authors:K. Rehbehn, O. Nicklass, G. Mouradian.
Date:October 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) forPermanent Virtual Connections (PVC) between Frame Relay andAsynchronous Transfer Mode (ATM) technologies.
 
RFC 2959 Real-Time Transport Protocol Management Information Base
 
Authors:M. Baugher, B. Strahm, I. Suconick.
Date:October 2000
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 Real-Time TransportProtocol (RTP) systems (RFC1889).
 
RFC 2960 Stream Control Transmission Protocol
 
Authors:R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson.
Date:October 2000
Formats:txt pdf
Obsoleted by:RFC 4960
Updated by:RFC 3309
Status:PROPOSED STANDARD
This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi- homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.

 
RFC 2961 RSVP Refresh Overhead Reduction Extensions
 
Authors:L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini.
Date:April 2001
Formats:txt pdf
Updated by:RFC 5063
Status:PROPOSED STANDARD
This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP(Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages.The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues.
 
RFC 2971 IMAP4 ID extension
 
Authors:T. Showalter.
Date:October 2000
Formats:txt pdf
Status:PROPOSED STANDARD
The ID extension to the Internet Message Access Protocol - Version4rev1 (IMAP4rev1) protocol allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete.
 
RFC 2976 The SIP INFO Method
 
Authors:S. Donovan.
Date:October 2000
Formats:txt pdf
Obsoleted by:RFC 6086
Status:PROPOSED STANDARD
This document proposes an extension to the Session InitiationProtocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP andISDN signaling messages used to control telephony call services.

This and other example uses of the INFO method may be standardized in the future.

 
RFC 2981 Event MIB
 
Authors:R. Kavasseri, Ed..
Date:October 2000
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 that can be used to manage and monitor MIB objects and take action through events.

The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met.

 
RFC 2982 Distributed Management Expression MIB
 
Authors:R. Kavasseri, Ed..
Date:October 2000
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 expressions of MIB objects. The results of these expressions becomeMIB objects usable like any other MIB object, such as for the test condition for declaring an event.
 
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS
 
Authors:C. Adams.
Date:October 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document specifies how to incorporate CAST-128 (RFC2144) into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification (RFC2630) for symmetric content and key encryption.
 
RFC 2987 Registration of Charset and Languages Media Features Tags
 
Authors:P. Hoffman.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document contains the registration for two media feature tags:"charset" and "language". These media features allow specification of character sets and human languages that can be understood by devices and the devices' users. The templates in this document are derived from RFC 2506.
 
RFC 2988 Computing TCP's Retransmission Timer
 
Authors:V. Paxson, M. Allman.
Date:November 2000
Formats:txt pdf
Obsoleted by:RFC 6298
Status:PROPOSED STANDARD
This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.
 
RFC 2996 Format of the RSVP DCLASS Object
 
Authors:Y. Bernet.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
Resource Reservation Protocol (RSVP) signaling may be used to requestQuality of Service (QoS) services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv orDS) network. When using RSVP with DS networks it is useful to be able to carry carry Differentiated Services Code Points (DSCPs) inRSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router.

The DCLASS object is used to represent and carry DSCPs within RSVP messages. This document specifies the format of the DCLASS object and briefly discusses its use.

 
RFC 2997 Specification of the Null Service Type
 
Authors:Y. Bernet, A. Smith, B. Davie.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. TheNull Service allows applications to identify themselves to networkQuality of Service (QoS) policy agents, using RSVP signaling.However, it does not require them to specify resource requirements.QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.
 
RFC 3003 The audio/mpeg Media Type
 
Authors:M. Nilsson.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose InternetMail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents.
 
RFC 3004 The User Class Option for DHCP
 
Authors:G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user.
 
RFC 3006 Integrated Services in the Presence of Compressible Flows
 
Authors:B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
An Integrated Services (int-serv) router performs admission control and resource allocation based on the information contained in a TSpec(among other things). As currently defined, TSpecs convey information about the data rate (using a token bucket) and range of packet sizes of the flow in question. However, the TSpec may not be an accurate representation of the resources needed to support the reservation if the router is able to compress the data at the link level. This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. Routers which support appropriate compression take advantage of the hint in their admission control decisions and resource allocation procedures; other routers ignore the hint. An initial application of this approach is to notify routers performing real-time transport protocol(RTP) header compression that they may allocate fewer resources toRTP flows.
 
RFC 3007 Secure Domain Name System (DNS) Dynamic Update
 
Authors:B. Wellington.
Date:November 2000
Formats:txt pdf
Obsoletes:RFC 2137
Updates:RFC 2535, RFC 2136
Status:PROPOSED STANDARD
This document proposes a method for performing secure Domain NameSystem (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization.
 
RFC 3008 Domain Name System Security (DNSSEC) Signing Authority
 
Authors:B. Wellington.
Date:November 2000
Formats:txt pdf
Obsoleted by:RFC 4035, RFC 4033, RFC 4034
Updates:RFC 2535
Updated by:RFC 3658
Status:PROPOSED STANDARD
This document proposes a revised model of Domain Name System Security(DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records.
 
RFC 3009 Registration of parityfec MIME types
 
Authors:J. Rosenberg, H. Schulzrinne.
Date:November 2000
Formats:txt pdf
Obsoleted by:RFC 5109
Status:PROPOSED STANDARD
The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats.
 
RFC 3010 NFS version 4 Protocol
 
Authors:S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck.
Date:December 2000
Formats:txt pdf
Obsoleted by:RFC 3530
Status:PROPOSED STANDARD
NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
 
RFC 3011 The IPv4 Subnet Selection Option for DHCP
 
Authors:G. Waters.
Date:November 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address.This option would override a DHCP server's normal methods of selecting the subnet on which to allocate an address for a client.
 
RFC 3012 Mobile IPv4 Challenge/Response Extensions
 
Authors:C. Perkins, P. Calhoun.
Date:November 2000
Formats:txt pdf
Obsoleted by:RFC 4721
Status:PROPOSED STANDARD
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.
 
RFC 3014 Notification Log MIB
 
Authors:R. Kavasseri.
Date:November 2000
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 logging SimpleNetwork Management Protocol (SNMP) Notifications.
 
RFC 3015 Megaco Protocol Version 1.0
 
Authors:F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers.
Date:November 2000
Formats:txt pdf
Obsoletes:RFC 2885, RFC 2886
Obsoleted by:RFC 3525
Status:PROPOSED STANDARD
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and aMedia Gateway Controller. The document is common text with ITU-TRecommendation H.248 and is a result of applying the changes in RFC2886 to the text of RFC 2885.

The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.

 
RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
 
Authors:Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata.
Date:November 2000
Formats:txt pdf
Obsoleted by:RFC 6416
Status:PROPOSED STANDARD
This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications forMultipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP).
 
RFC 3017 XML DTD for Roaming Access Phone Book
 
Authors:M. Riegel, G. Zorn.
Date:December 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. It comprises the information necessary to select the most appropriate ISP and to configure the host to get access to the network of the provider. The specification consists of a small set of required information elements and a variety of possible extensions.All data is specified in XML [5] (Extensible Markup Language) syntax leading to a concise XML DTD (Document Type Declaration) for the phone book.
 
RFC 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol
 
Authors:B. Haberman, R. Worzella.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 5519
Status:PROPOSED STANDARD
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in Internet ProtocolVersion 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the MulticastListener Discovery Protocol [RFC2710].
 
RFC 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function
 
Authors:P. Pate, B. Lynch, K. Rehbehn.
Date:December 2000
Formats:txt pdf
Status:PROPOSED STANDARD
This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also includes conformance and notification information.
 
RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links
 
Authors:A. Retana, R. White, V. Fuller, D. McPherson.
Date:December 2000
Formats:txt pdf
Status:PROPOSED STANDARD
With ever-increasing pressure to conserve IP address space on theInternet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout theInternet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way.
 
RFC 3023 XML Media Types
 
Authors:M. Murata, S. St. Laurent, D. Kohn.
Date:January 2001
Formats:txt pdf
Obsoletes:RFC 2376
Obsoleted by:RFC 7303
Updates:RFC 2048
Updated by:RFC 6839
Status:PROPOSED STANDARD
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible MarkupLanguage (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet MailExtensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.

Major differences from RFC 2376 are (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of"utf-16le" and "utf-16be".

 
RFC 3024 Reverse Tunneling for Mobile IP, revised
 
Authors:G. Montenegro, Ed..
Date:January 2001
Formats:txt pdf
Obsoletes:RFC 2344
Status:PROPOSED STANDARD
Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.

This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.

This document obsoletes RFC 2344.

 
RFC 3025 Mobile IP Vendor/Organization-Specific Extensions
 
Authors:G. Dommety, K. Leung.
Date:February 2001
Formats:txt pdf
Obsoleted by:RFC 3115
Status:PROPOSED STANDARD
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.
 
RFC 3028 Sieve: A Mail Filtering Language
 
Authors:T. Showalter.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 5228, RFC 5429
Status:PROPOSED STANDARD
This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs.
 
RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
 
Authors:G. Vaudreuil.
Date:December 2000
Formats:txt pdf
Obsoletes:RFC 1830
Status:PROPOSED STANDARD
This memo defines two extensions to the SMTP (Simple Mail TransferProtocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (MultipurposeInternet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending ofMIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830.
 
RFC 3031 Multiprotocol Label Switching Architecture
 
Authors:E. Rosen, A. Viswanathan, R. Callon.
Date:January 2001
Formats:txt pdf
Updated by:RFC 6178, RFC 6790
Status:PROPOSED STANDARD
This document specifies the architecture for Multiprotocol LabelSwitching (MPLS).
 
RFC 3032 MPLS Label Stack Encoding
 
Authors:E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta.
Date:January 2001
Formats:txt pdf
Updated by:RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274
Status:PROPOSED STANDARD
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which supportMPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding.
 
RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
 
Authors:M. Suzuki.
Date:January 2001
Formats:txt pdf
Status:PROPOSED STANDARD
The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 GenericIdentifier and Q.2957 User-to-user Signaling for the Internet protocol.

The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM.

 
RFC 3034 Use of Label Switching on Frame Relay Networks Specification
 
Authors:A. Conta, P. Doolan, A. Malis.
Date:January 2001
Formats:txt pdf
Status:PROPOSED STANDARD
This document defines the model and generic mechanisms forMultiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol LabelSwitching Architecture described in [ARCH] and the Label DistributionProtocol (LDP) described in [LDP] relative to Frame Relay Networks.MPLS enables the use of Frame Relay Switches as Label SwitchingRouters (LSRs).
 
RFC 3035 MPLS using LDP and ATM VC Switching
 
Authors:B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan.
Date:January 2001
Formats:txt pdf
Status:PROPOSED STANDARD
The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used asLabel Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), IntermediateSystem to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. NoATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers).

This document extends and clarifies the relevant portions of [1] and[2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels representForwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms.

This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3].

 
RFC 3036 LDP Specification
 
Authors:L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 5036
Status:PROPOSED STANDARD
The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
 
RFC 3038 VCID Notification over ATM link for LDP
 
Authors:K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan.
Date:January 2001
Formats:txt pdf
Updated by:RFC 7274
Status:PROPOSED STANDARD
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of VirtualConnection Identifier (VCID) is introduced to solve this problem.VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.
 
RFC 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile
 
Authors:S. Santesson, W. Polk, P. Barzin, M. Nystrom.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 3739
Status:PROPOSED STANDARD
This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term QualifiedCertificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, QualifiedCertificates are issued exclusively to physical persons.

The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs.

It is important to note that the profile does not define any legal requirements for Qualified Certificates.

 
RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
Authors:T. Narten, R. Draves.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 4941
Status:PROPOSED STANDARD
Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host ConfigurationProtocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
 
RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit
 
Authors:M. Allman, H. Balakrishnan, S. Floyd.
Date:January 2001
Formats:txt pdf
Status:PROPOSED STANDARD
This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. The"Limited Transmit" algorithm calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. Transmitting these segments increases the probability that TCP can recover from a single lost segment using the fast retransmit algorithm, rather than using a costly retransmission timeout. Limited Transmit can be used both in conjunction with, and in the absence of, the TCP selective acknowledgment (SACK) mechanism.
 
RFC 3046 DHCP Relay Agent Information Option
 
Authors:M. Patrick.
Date:January 2001
Formats:txt pdf
Updated by:RFC 6607
Status:PROPOSED STANDARD
Newer high-speed public Internet access technologies call for a high-speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use theDynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.However, a number of security and scaling problems arise with such"public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132.

The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originatedDHCP packets to a DHCP server. Servers recognizing the Relay AgentInformation option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.

The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem.

 
RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1
 
Authors:P. Luthi.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 5577
Status:PROPOSED STANDARD
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use ofG.722.1 with MIME and SDP.
 
RFC 3049 TN3270E Service Location and Session Balancing
 
Authors:J. Naugle, K. Kasthurirangan, G. Ledford.
Date:January 2001
Formats:txt pdf
Status:PROPOSED STANDARD
This document discusses the implementation of Service LocationProtocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server.

Application program developer's can locate TN3270E services and load balance among those services (3270 host sessions), by using this SLP support.

 
RFC 3055 Management Information Base for the PINT Services Architecture
 
Authors:M. Krishnaswamy, D. Romascanu.
Date:February 2001