Internet Documents

RFCs 2200 - 2299s

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

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 2200 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:June 1997
Formats:txt json html
Obsoletes:RFC 1250, RFC 2000
Obsoleted by:RFC 2300
Status:HISTORIC
DOI:10.17487/RFC 2200
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]
 
RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture
 
Authors:A. Ballardie.
Date:September 1997
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 2201
CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender's subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms.

The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model[2].

CBT is progressing through the IDMR working group of the IETF. TheCBT protocol is described in an accompanying document [1]. For this, and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr

 
RFC 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1
 
Authors:P. Cheng, R. Glenn.
Date:September 1997
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2202
This document provides two sets of test cases for HMAC-MD5 and HMAC-SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and other protocols to authenticate messages.The test cases and results provided in this document are meant to be used as a conformance test for HMAC-MD5 and HMAC-SHA-1 implementations.
 
RFC 2203 RPCSEC_GSS Protocol Specification
 
Authors:M. Eisler, A. Chiu, L. Ling.
Date:September 1997
Formats:txt html json
Updated by:RFC 5403
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2203
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 2204 ODETTE File Transfer Protocol
 
Authors:D. Nash.
Date:September 1997
Formats:txt json html
Obsoleted by:RFC 5024
Status:INFORMATIONAL
DOI:10.17487/RFC 2204
This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.

The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community.

 
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 json html
Updated by:RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437, RFC 6780
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2205
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2206
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2207
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 2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment
 
Authors:A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang.
Date:September 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2208
This document describes the applicability of RSVP along with theIntegrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto theInternet standards track.
 
RFC 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules
 
Authors:R. Braden, L. Zhang.
Date:September 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2209
This memo contains an algorithmic description of the rules used by anRSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification.

This memo provides a generic description of the rules for the operation of Version 1 of RSVP [RFC 2205]. It is intended to outline a set of algorithms that will accomplish the needed function, omitting many details.

 
RFC 2210 The Use of RSVP with IETF Integrated Services
 
Authors:J. Wroclawski.
Date:September 1997
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2210
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2211
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2212
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2213
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2214
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2215
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 2216 Network Element Service Specification Template
 
Authors:S. Shenker, J. Wroclawski.
Date:September 1997
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2216
This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications).
 
RFC 2217 Telnet Com Port Control Option
 
Authors:G. Clark.
Date:October 1997
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 2217
This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2218 A Common Schema for the Internet White Pages Service
 
Authors:T. Genovese, B. Jennings.
Date:October 1997
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2218
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 2219 Use of DNS Aliases for Network Services
 
Authors:M. Hamilton, R. Wright.
Date:October 1997
Formats:txt json html
Also:BCP 0017
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2219
It has become a common practice to use symbolic names (usuallyCNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers,Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP[RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server.

Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols.

It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as theServer Location Resource Records (DNS SRV) [RFC-2052] work.

 
RFC 2220 The Application/MARC Content-type
 
Authors:R. Guenther.
Date:October 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2220
This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications.
 
RFC 2221 IMAP4 Login Referrals
 
Authors:M. Gahrns.
Date:October 1997
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2221
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 html json
Obsoleted by:RFC 4422, RFC 4752
Updated by:RFC 2444
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2222
This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]
 
RFC 2223 Instructions to RFC Authors
 
Authors:J. Postel, J. Reynolds.
Date:October 1997
Formats:txt html json
Obsoletes:RFC 1543, RFC 1111, RFC 0825
Obsoleted by:RFC 7322
Updated by:RFC 5741, RFC 6949
Status:INFORMATIONAL
DOI:10.17487/RFC 2223
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2224 NFS URL Scheme
 
Authors:B. Callaghan.
Date:October 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2224
A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined inRFC 1738, "Uniform Resource Locators (URL)".

This scheme uses the public filehandle and multi-component lookup[RFC2054, RFC2055] to access server data with a minimum of protocol overhead.

The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3[RFC1813], both built on ONC RPC [RFC1831] at its associated eXternalData Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].

 
RFC 2225 Classical IP and ARP over ATM
 
Authors:M. Laubach, J. Halpern.
Date:April 1998
Formats:txt json html
Obsoletes:RFC 1626, RFC 1577
Updated by:RFC 5494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2225
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2226
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2227
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 json html
Updates:RFC 0959
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2228
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 2229 A Dictionary Server Protocol
 
Authors:R. Faith, B. Martin.
Date:October 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2229
The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.
 
RFC 2230 Key Exchange Delegation Record for the DNS
 
Authors:R. Atkinson.
Date:November 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2230
This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
 
Authors:N. Freed, K. Moore.
Date:November 1997
Formats:txt json html
Obsoletes:RFC 2184
Updates:RFC 2045, RFC 2047, RFC 2183
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2231
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2232
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 html json
Obsoletes:RFC 1573
Obsoleted by:RFC 2863
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2233
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 json html
Obsoleted by:RFC 4234
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2234
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 2235 Hobbes' Internet Timeline
 
Authors:R. Zakon.
Date:November 1997
Formats:txt json html
Also:FYI 0032
Status:INFORMATIONAL
DOI:10.17487/RFC 2235
This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2236 Internet Group Management Protocol, Version 2
 
Authors:W. Fenner.
Date:November 1997
Formats:txt html json
Updates:RFC 1112
Updated by:RFC 3376
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2236
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 2237 Japanese Character Encoding for Internet Messages
 
Authors:K. Tamaru.
Date:November 1997
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2237
This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2238 Definitions of Managed Objects for HPR using SMIv2
 
Authors:B. Clouston, Ed., B. Moore, Ed..
Date:November 1997
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2238
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 json html
Obsoleted by:RFC 2668
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2239
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 2240 A Legal Basis for Domain Name Allocation
 
Authors:O. Vaughan.
Date:November 1997
Formats:txt html json
Obsoleted by:RFC 2352
Status:INFORMATIONAL
DOI:10.17487/RFC 2240
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2241 DHCP Options for Novell Directory Services
 
Authors:D. Provan.
Date:November 1997
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2241
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2242
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2243
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 html json
Updated by:RFC 6075
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2244
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 html json
Obsoleted by:RFC 4505
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2245
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 json html
Obsoleted by:RFC 4346
Updated by:RFC 3546, RFC 5746, RFC 6176, RFC 7465, RFC 7507, RFC 7919
Status:HISTORIC
DOI:10.17487/RFC 2246
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 json html
Updated by:RFC 4519, RFC 4524
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2247
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 html json
Obsoletes:RFC 1565
Obsoleted by:RFC 2788
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2248
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 html json
Obsoletes:RFC 1566
Obsoleted by:RFC 2789
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2249
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 html json
Obsoletes:RFC 2038
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2250
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 html json
Obsoleted by:RFC 4510, RFC 4511, RFC 4513, RFC 4512
Updated by:RFC 3377, RFC 3771
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2251
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 json html
Obsoleted by:RFC 4510, RFC 4517, RFC 4523, RFC 4512
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2252
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 json html
Obsoletes:RFC 1779
Obsoleted by:RFC 4510, RFC 4514
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2253
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 html json
Obsoletes:RFC 1960
Obsoleted by:RFC 4510, RFC 4515
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2254
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 html json
Obsoletes:RFC 1959
Obsoleted by:RFC 4510, RFC 4516
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2255
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 json html
Obsoleted by:RFC 4517, RFC 4519, RFC 4523, RFC 4512, RFC 4510
Updated by:RFC 3377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2256
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 json html
Obsoleted by:RFC 2741
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2257
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 2258 Internet Nomenclator Project
 
Authors:J. Ordille.
Date:January 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2258
The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world.Each CCSO server has a database schema that is tailored to the needs of the organization that owns it. The project is integrating the different database schema into one query service. The InternetNomenclator Project will provide fast cross-server searches for locating people on the Internet. It augments existing CCSO services by supplying schema integration, more extensive indexing, and two kinds of caching -- all this in a system that scales as the number ofCCSO servers grows. One of the best things about the system is that administrators can incorporate their CCSO servers into Nomenclator without changing the servers. All Nomenclator needs is basic information about the server.

This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet NomenclatorProject, and how to use the Nomenclator search engine to find people on the Internet.

 
RFC 2259 Simple Nomenclator Query Protocol (SNQP)
 
Authors:J. Elliott, J. Ordille.
Date:January 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2259
The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500.

SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere.

 
RFC 2260 Scalable Support for Multi-homed Multi-provider Connectivity
 
Authors:T. Bates, Y. Rekhter.
Date:January 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2260
This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2261 An Architecture for Describing SNMP Management Frameworks
 
Authors:D. Harrington, R. Presuhn, B. Wijnen.
Date:January 1998
Formats:txt html json
Obsoleted by:RFC 2271
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2261
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 json html
Obsoleted by:RFC 2272
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2262
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 json html
Obsoleted by:RFC 2273
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2263
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 html json
Obsoleted by:RFC 2274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2264
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 html json
Obsoleted by:RFC 2275
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2265
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2266
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 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
 
Authors:P. Ferguson, D. Senie.
Date:January 1998
Formats:txt json html
Obsoleted by:RFC 2827
Status:INFORMATIONAL
DOI:10.17487/RFC 2267
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.
 
RFC 2268 A Description of the RC2(r) Encryption Algorithm
 
Authors:R. Rivest.
Date:March 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2268
This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2269 Using the MARS Model in non-ATM NBMA Networks
 
Authors:G. Armitage.
Date:January 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2269
Initially developed for IP over ATM, the RFC 2022 (MARS) model is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. RFC 2022 is not required over NBMA networks that offer Ethernet-like group addressing functionality.
 
RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider
 
Authors:J. Stewart, T. Bates, R. Chandra, E. Chen.
Date:January 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2270
With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930.
 
RFC 2271 An Architecture for Describing SNMP Management Frameworks
 
Authors:D. Harrington, R. Presuhn, B. Wijnen.
Date:January 1998
Formats:txt html json
Obsoletes:RFC 2261
Obsoleted by:RFC 2571
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2271
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 json html
Obsoletes:RFC 2262
Obsoleted by:RFC 2572
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2272
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 json html
Obsoletes:RFC 2263
Obsoleted by:RFC 2573
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2273
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 html json
Obsoletes:RFC 2264
Obsoleted by:RFC 2574
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2274
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 html json
Obsoletes:RFC 2265
Obsoleted by:RFC 2575
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2275
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 2276 Architectural Principles of Uniform Resource Name Resolution
 
Authors:K. Sollins.
Date:January 1998
Formats:txt json html
Updated by:RFC 3401
Status:INFORMATIONAL
DOI:10.17487/RFC 2276
This document addresses the issues of the discovery of URN (UniformResource Name) resolver services that in turn will directly translateURNs into URLs (Uniform Resource Locators) and URCs (Uniform ResourceCharacteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately.
 
RFC 2277 IETF Policy on Character Sets and Languages
 
Authors:H. Alvestrand.
Date:January 1998
Formats:txt json html
Also:BCP 0018
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2277
This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
 
RFC 2278 IANA Charset Registration Procedures
 
Authors:N. Freed, J. Postel.
Date:January 1998
Formats:txt html json
Obsoleted by:RFC 2978
Status:INFORMATIONAL
DOI:10.17487/RFC 2278
MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
 
RFC 2279 UTF-8, a transformation format of ISO 10646
 
Authors:F. Yergeau.
Date:January 1998
Formats:txt html json
Obsoletes:RFC 2044
Obsoleted by:RFC 3629
Status:DRAFT STANDARD
DOI:10.17487/RFC 2279
ISO/IEC 10646-1 defines a multi-octet character set called theUniversal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards.
 
RFC 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 html json
Obsoleted by:RFC 2622
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2280
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 2281 Cisco Hot Standby Router Protocol (HSRP)
 
Authors:T. Li, B. Cole, P. Morton, D. Li.
Date:March 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2281
The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. Multiple routers participate in this protocol and in concert create the illusion of a single virtual router. The protocol insures that one and only one of the routers is forwarding packets on behalf of the virtual router. End hosts forward their packets to the virtual router.

The router forwarding packets is known as the active router. A standby router is selected to replace the active router should it fail. The protocol provides a mechanism for determining active and standby routers, using the IP addresses on the participating routers.If an active router fails a standby router can take over without a major interruption in the host's connectivity. This memo also discusses the ARP, MAC address, and security issues with this protocol.

 
RFC 2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
 
Authors:J. Galvin.
Date:February 1998
Formats:txt json html
Obsoletes:RFC 2027
Obsoleted by:RFC 2727
Status:INFORMATIONAL
DOI:10.17487/RFC 2282
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today.
 
RFC 2283 Multiprotocol Extensions for BGP-4
 
Authors:T. Bates, R. Chandra, D. Katz, Y. Rekhter.
Date:February 1998
Formats:txt json html
Obsoleted by:RFC 2858
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2283
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 html json
Obsoleted by:RFC 3748
Updated by:RFC 2484
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2284
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 2285 Benchmarking Terminology for LAN Switching Devices
 
Authors:R. Mandeville.
Date:February 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2285
This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
 
Authors:J. Kapp.
Date:February 1998
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2286
This document provides two sets of test cases for HMAC-RIPEMD160 andHMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are two constructs of the HMAC [HMAC] message authentication function using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128 implementations.
 
RFC 2287 Definitions of System-Level Managed Objects for Applications
 
Authors:C. Krupczak, J. Saperia.
Date:February 1998
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2287
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 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names
 
Authors:C. Lynch, C. Preston, R. Daniel.
Date:February 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2288
A system for Uniform Resource Names (URNs) must be capable of supporting identifiers from existing widely-used naming systems.This document discusses how three major bibliographic identifiers(the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs.
 
RFC 2289 A One-Time Password System
 
Authors:N. Haller, C. Metz, P. Nesser, M. Straw.
Date:February 1998
Formats:txt html json
Obsoletes:RFC 1938
Also:STD 0061
Status:INTERNET STANDARD
DOI:10.17487/RFC 2289
This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS- TRACK]
 
RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP
 
Authors:J. Solomon, S. Glass.
Date:February 1998
Formats:txt html json
Updates:RFC 2002
Updated by:RFC 2794
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2290
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 2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
 
Authors:J. Slein, F. Vitali, E. Whitehead, D. Durand.
Date:February 1998
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2291
Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW.
 
RFC 2292 Advanced Sockets API for IPv6
 
Authors:W. Stevens, M. Thomas.
Date:February 1998
Formats:txt json html
Obsoleted by:RFC 3542
Status:INFORMATIONAL
DOI:10.17487/RFC 2292
Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like.

But another class of applications exists that will also be run underIPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.

There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too.

 
RFC 2293 Representing Tables and Subtrees in the X.500 Directory
 
Authors:S. Kille.
Date:March 1998
Formats:txt json html
Obsoletes:RFC 1837
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2293
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 html json
Obsoletes:RFC 1836
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2294
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 2295 Transparent Content Negotiation in HTTP
 
Authors:K. Holtman, A. Mutz.
Date:March 1998
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 2295
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0
 
Authors:K. Holtman, A. Mutz.
Date:March 1998
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 2296
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2297 Ipsilon's General Switch Management Protocol Specification Version 2.0
 
Authors:P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.
Date:March 1998
Formats:txt json html
Updates:RFC 1987
Status:INFORMATIONAL
DOI:10.17487/RFC 2297
This memo specifies enhancements to the General Switch ManagementProtocol (GSMP) [RFC1987]. The major enhancement is the addition ofQuality of Service (QoS) messages. Other improvements have been made to the protocol resulting from operational experience. GSMP is a general purpose protocol to control an ATM switch. It allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; and request statistics.
 
RFC 2298 An Extensible Message Format for Message Disposition Notifications
 
Authors:R. Fajman.
Date:March 1998
Formats:txt html json
Obsoleted by:RFC 3798
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2298
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 2299 Request for Comments Summary
 
Authors:A. Ramos.
Date:January 1999
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2299