Internet Documents

RFCs 2900 - 2999s

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

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 2900 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden, S. Ginoza.
Date:August 2001
Formats:txt json html
Obsoletes:RFC 2800
Obsoleted by:RFC 3000
Status:HISTORIC
DOI:10.17487/RFC 2900
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
 
RFC 2901 Guide to Administrative Procedures of the Internet Infrastructure
 
Authors:Z. Wenzel, J. Klensin, R. Bush, S. Huter.
Date:August 2000
Formats:txt json html
Also:FYI 0037
Status:INFORMATIONAL
DOI:10.17487/RFC 2901
This document describes the administrative procedures for networks seeking to connect to the global Internet. This includes the steps and operations necessary for address space allocation and registration, routing database registration, and domain name registration. The document also contains information about the required forms and how to obtain them.
 
RFC 2902 Overview of the 1998 IAB Routing Workshop
 
Authors:S. Deering, S. Hares, C. Perkins, R. Perlman.
Date:August 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2902
This document is an overview of a Routing workshop held by theInternet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion.
 
RFC 2903 Generic AAA Architecture
 
Authors:C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence.
Date:August 2000
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 2903
This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. A separation of AAA functions required in a multi-domain environment is then proposed using a layered protocol abstraction. The long term goal is to create a generic framework which allows complex authorizations to be realized through a network of interconnected AAA servers.
 
RFC 2904 AAA Authorization Framework
 
Authors:J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence.
Date:August 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2904
This memo serves as the base requirements for Authorization ofInternet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.
 
RFC 2905 AAA Authorization Application Examples
 
Authors:J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence.
Date:August 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2905
This memo describes several examples of applications requiring authorization. Each application is described in terms of a consistent framework, and specific authorization requirements of each application are given. This material was not contributed by the working groups responsible for the applications and should not be considered prescriptive for how the applications will meet their authorization needs. Rather the intent is to explore the fundamental needs of a variety of different applications with the view of compiling a set of requirements that an authorization protocol will need to meet in order to be generally useful.
 
RFC 2906 AAA Authorization Requirements
 
Authors:S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence.
Date:August 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2906
This document specifies the requirements that AuthenticationAuthorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others.
 
RFC 2907 MADCAP Multicast Scope Nesting State Option
 
Authors:R. Kermode.
Date:September 2000
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2907
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 2908 The Internet Multicast Address Allocation Architecture
 
Authors:D. Thaler, M. Handley, D. Estrin.
Date:September 2000
Formats:txt json html
Obsoleted by:RFC 6308
Status:HISTORIC
DOI:10.17487/RFC 2908
This document proposes a multicast address allocation architecture(MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server- server coordination mechanism, and an inter-domain mechanism.
 
RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
 
Authors:P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler.
Date:September 2000
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 2909
This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group- specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist.
 
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 json html
Obsoletes:RFC 2565
Obsoleted by:RFC 8010
Updated by:RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2910
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 json html
Obsoletes:RFC 2566
Obsoleted by:RFC 8011
Updated by:RFC 3380, RFC 3382, RFC 3996, RFC 3995, RFC 7472
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2911
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2912
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2913
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 2914 Congestion Control Principles
 
Authors:S. Floyd.
Date:September 2000
Formats:txt json html
Updated by:RFC 7141
Also:BCP 0041
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2914
The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols.
 
RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record
 
Authors:M. Mealling, R. Daniel.
Date:September 2000
Formats:txt json html
Obsoleted by:RFC 3401, RFC 3402, RFC 3403, RFC 3404
Updates:RFC 2168
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2915
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 html json
Obsoleted by:RFC 3761
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2916
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 2917 A Core MPLS IP VPN Architecture
 
Authors:K. Muthukrishnan, A. Malis.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2917
This memo presents an approach for building core Virtual PrivateNetwork (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications.
 
RFC 2918 Route Refresh Capability for BGP-4
 
Authors:E. Chen.
Date:September 2000
Formats:txt json html
Updated by:RFC 7313
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2918
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2919
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 2920 SMTP Service Extension for Command Pipelining
 
Authors:N. Freed.
Date:September 2000
Formats:txt json html
Obsoletes:RFC 2197
Also:STD 0060
Status:INTERNET STANDARD
DOI:10.17487/RFC 2920
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission ControlProtocol (TCP) send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.
 
RFC 2921 6BONE pTLA and pNLA Formats (pTLA)
 
Authors:B. Fink.
Date:September 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2921
This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation",[6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers(pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's).
 
RFC 2922 Physical Topology MIB
 
Authors:A. Bierman, K. Jones.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2922
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 physical topology identification and discovery.
 
RFC 2923 TCP Problems with Path MTU Discovery
 
Authors:K. Lahey.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2923
This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission UnitDiscovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between MaximumSegment Size (MSS) and segment size, and MSS advertisement based onPMTU.
 
RFC 2924 Accounting Attributes and Record Formats
 
Authors:N. Brownlee, A. Blount.
Date:September 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2924
This document summarises Internet Engineering Task Force (IETF) andInternational Telecommunication Union (ITU-T) documents related toAccounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats forAccounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This document discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described.
 
RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
 
Authors:K. White.
Date:September 2000
Formats:txt json html
Obsoleted by:RFC 4560
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2925
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 2926 Conversion of LDAP Schemas to and from SLP Templates
 
Authors:J. Kempf, R. Moats, P. St. Pierre.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2926
This document describes a procedure for mapping between ServiceLocation Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. The document covers two aspects of the mapping. One aspect is mapping between SLP service type templates and LDAP directory schema.Because the SLP service type template grammar is relatively simple, mapping from service type templates to LDAP types is straightforward.Mapping in the other direction is straightforward if the attributes are restricted to use just a few of the syntaxes defined in RFC 2252.If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible. The second aspect is representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers.The resulting system allows service advertisements to propagate easily between SLP and LDAP.
 
RFC 2927 MIME Directory Profile for LDAP Schema
 
Authors:M. Wahl.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2927
This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol(LDAP) schema. It is intended for communication with the Internet schema listing service.
 
RFC 2928 Initial IPv6 Sub-TLA ID Assignments
 
Authors:R. Hinden, S. Deering, R. Fink, T. Hain.
Date:September 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2928
This document defines initial assignments of IPv6 Sub-Top-LevelAggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned NumbersAuthority (IANA) from the Internet Engineering Task Force (IETF)Internet Protocol Next Generation (IPNG) and Next GenerationTransition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses.

This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The Internet Architecture Board (IAB) subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses.

 
RFC 2929 Domain Name System (DNS) IANA Considerations
 
Authors:D. Eastlake 3rd, E. Brunner-Williams, B. Manning.
Date:September 2000
Formats:txt json html
Obsoleted by:RFC 5395
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2929
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System(DNS) classes, Resource Record (RR) types, operation codes, error codes, etc.
 
RFC 2930 Secret Key Establishment for DNS (TKEY RR)
 
Authors:D. Eastlake 3rd.
Date:September 2000
Formats:txt json html
Updated by:RFC 6895
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2930
[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 json html
Updates:RFC 2535
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2931
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 html json
Obsoleted by:RFC 5132
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2932
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 html json
Obsoleted by:RFC 5519
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2933
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 2934 Protocol Independent Multicast MIB for IPv4
 
Authors:K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner.
Date:October 2000
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 2934
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 theProtocol Independent Multicast (PIM) protocol for IPv4.
 
RFC 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement
 
Authors:D. Eastlake 3rd, C. Smith.
Date:September 2000
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2935
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 2936 HTTP MIME Type Handler Detection
 
Authors:D. Eastlake 3rd, C. Smith, D. Soroka.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2936
Entities composing web pages to provide services over the HypertextTransfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. For example, whether an Internet OpenTrading Protocol (IOTP) or VRML or SET or some streaming media handler is available. In some cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on theInternet as of early 2000. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed.
 
RFC 2937 The Name Service Search Option for DHCP
 
Authors:C. Smith.
Date:September 2000
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2937
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 json html
Updates:RFC 2533
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2938
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 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
 
Authors:R. Droms.
Date:September 2000
Formats:txt json html
Obsoletes:RFC 2489
Also:BCP 0043
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2939
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TransmissionControl Protocol/Internet Protocol (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".

DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option.

New DHCP options and message types may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters or to accommodate new protocol semantics. This document describes the procedure for defining new DHCP options and message types.

 
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2940
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 html json
Obsoletes:RFC 1416
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2941
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2942
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2943
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2944
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2945
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2946
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2947
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2948
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2949
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 html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2950
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 2951 TELNET Authentication Using KEA and SKIPJACK
 
Authors:R. Housley, T. Horting, P. Yee.
Date:September 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2951
This document defines a method to authenticate TELNET using the KeyExchange Algorithm (KEA), and encryption of the TELNET stream usingSKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNETAuthentication Option.
 
RFC 2952 Telnet Encryption: DES 64 bit Cipher Feedback
 
Authors:T. Ts'o.
Date:September 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2952
This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option.
 
RFC 2953 Telnet Encryption: DES 64 bit Output Feedback
 
Authors:T. Ts'o.
Date:September 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2953
This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option.
 
RFC 2954 Definitions of Managed Objects for Frame Relay Service
 
Authors:K. Rehbehn, D. Fowler.
Date:October 2000
Formats:txt html json
Obsoletes:RFC 1604
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2954
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 html json
Updated by:RFC 9141
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2955
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 2956 Overview of 1999 IAB Network Layer Workshop
 
Authors:M. Kaat.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2956
This document is an overview of a workshop held by the InternetArchitecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet.Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering TaskForce (IETF) community.
 
RFC 2957 The application/whoispp-query Content-Type
 
Authors:L. Daigle, P. Faltstrom.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2957
This document defines the expression of Whois++ protocol (RFC 1835) queries within MIME (Multipurpose Internet Mail Extensions) (RFC2046) media types. The intention of this document, in conjunction with RFC 2958 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.
 
RFC 2958 The application/whoispp-response Content-type
 
Authors:L. Daigle, P. Faltstrom.
Date:October 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2958
This document defines the expression of Whois++ protocol (RFC1835) responses within MIME (Multipurpose Internet Mail Extensions)(RFC2046) media types. The intention of this document, in conjunction with RFC 2957 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.
 
RFC 2959 Real-Time Transport Protocol Management Information Base
 
Authors:M. Baugher, B. Strahm, I. Suconick.
Date:October 2000
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2959
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 html json
Obsoleted by:RFC 4960
Updated by:RFC 3309
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2960
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 html json
Updated by:RFC 5063
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2961
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 2962 An SNMP Application Level Gateway for Payload Address Translation
 
Authors:D. Raz, J. Schoenwaelder, B. Sugla.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2962
This document describes the ALG (Application Level Gateway) for theSNMP (Simple Network Management Protocol) by which IP (InternetProtocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15].

An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (NetworkAddress Translator) in order to manage several potentially overlapping addressing realms.

This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application LevelGateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms.

 
RFC 2963 A Rate Adaptive Shaper for Differentiated Services
 
Authors:O. Bonaventure, S. De Cnodder.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2963
This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 andRFC2698, respectively. These RAS improve the performance of TCP when a TCM is used at the ingress of a diffserv network by reducing the burstiness of the traffic. With TCP traffic, this reduction of the burstiness is accompanied by a reduction of the number of marked packets and by an improved TCP goodput. The proposed RAS can be used at the ingress of Diffserv networks providing the Assured ForwardingPer Hop Behavior (AF PHB). They are especially useful when a TCM is used to mark traffic composed of a small number of TCP connections.
 
RFC 2964 Use of HTTP State Management
 
Authors:K. Moore, N. Freed.
Date:October 2000
Formats:txt html json
Also:BCP 0044
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2964
The mechanisms described in "HTTP State Management Mechanism" (RFC-2965), and its predecessor (RFC-2109), can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses ofHypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification.
 
RFC 2965 HTTP State Management Mechanism
 
Authors:D. Kristol, L. Montulli.
Date:October 2000
Formats:txt html json
Obsoletes:RFC 2109
Obsoleted by:RFC 6265
Status:HISTORIC
DOI:10.17487/RFC 2965
This document specifies a way to create a stateful session withHypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)

This document reflects implementation experience with RFC 2109 and obsoletes it.

 
RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS
 
Authors:T. Li, T. Przygienda, H. Smit.
Date:October 2000
Formats:txt json html
Obsoleted by:RFC 5302
Status:INFORMATIONAL
DOI:10.17487/RFC 2966
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2].

This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.

 
RFC 2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
 
Authors:L. Daigle, R. Hedberg.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2967
The strength of the TISDAG (Technical Infrastructure for SwedishDirectory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access- point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.
 
RFC 2968 Mesh of Multiple DAG servers - Results from TISDAG
 
Authors:L. Daigle, T. Eklof.
Date:October 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2968
The Common Indexing Protocol ([CIP1]) is designed to facilitate the creation not only of query referral indexes, but also of meshes of(loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways) project ([TISDAG], [DAGEXP]) has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services.
 
RFC 2969 Wide Area Directory Deployment - Experiences from TISDAG
 
Authors:T. Eklof, L. Daigle.
Date:October 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2969
The TISDAG (Technical Infrastructure for Swedish Directory AccessGateway) project provided valuable insight into the current reality of deploying a wide-scale directory service. This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. A perspective on the project's relationship to other directory deployment projects is provided, along with some proposals for future extensions of the work(larger scale deployment, other application areas).

These are our own observations, based on work done and general project discussions. No doubt, other project participants have their own list of project experiences; we don't claim this document is exhaustive!

 
RFC 2970 Architecture for Integrated Directory Services - Result from TISDAG
 
Authors:L. Daigle, T. Eklof.
Date:October 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2970
A single, unified, global whitepages directory service remains elusive. Nonetheless, there is increasing call for participation of widely-dispersed directory servers (i.e., across multiple organizations) in large-scale directory services. These services range from national whitepages services, to multi-national indexes ofWWW resources, and beyond. Drawing from experiences with the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways)([TISDAG]) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use.
 
RFC 2971 IMAP4 ID extension
 
Authors:T. Showalter.
Date:October 2000
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2971
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 2972 Context and Goals for Common Name Resolution
 
Authors:N. Popp, M. Mealling, L. Masinter, K. Sollins.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2972
This document establishes the context and goals for a Common NameResolution Protocol. It defines the terminology used concerning a"Common Name" and how one might be "resolved", and establishes the distinction between "resolution" and more elaborate search mechanisms. It establishes some expected contexts for use of CommonName Resolution, and the criteria for evaluating a successful protocol. It also analyzes the various motivations that would cause services to provide Common Name resolution for both public, private and commercial use.

This document is intended as input to the formation of a Common NameResolution Protocol working group. Please send any comments to cnrp-ietf@lists.internic.net. To review the mail archives, see<http://lists.internic.net/archives/cnrp-ietf.html&rt;

 
RFC 2973 IS-IS Mesh Groups
 
Authors:R. Balay, D. Katz, J. Parker.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2973
This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System(IS-IS) Routing protocol, as described in ISO 10589. The described mechanism can be used to reduce the flooding of Link State PDUs(Protocol Data Units) (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This document serves to document the existing behavior in deployed implementations.

The document describes behaviors that are backwards compatible with implementations that do not support this feature.

 
RFC 2974 Session Announcement Protocol
 
Authors:M. Handley, C. Perkins, E. Whelan.
Date:October 2000
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 2974
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
 
RFC 2975 Introduction to Accounting Management
 
Authors:B. Aboba, J. Arkko, D. Harrington.
Date:October 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2975
The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.

Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application.This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.

 
RFC 2976 The SIP INFO Method
 
Authors:S. Donovan.
Date:October 2000
Formats:txt json html
Obsoleted by:RFC 6086
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2976
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 2977 Mobile IP Authentication, Authorization, and Accounting Requirements
 
Authors:S. Glass, T. Hiller, S. Jacobs, C. Perkins.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2977
The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements forAuthentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services.
 
RFC 2978 IANA Charset Registration Procedures
 
Authors:N. Freed, J. Postel.
Date:October 2000
Formats:txt html json
Obsoletes:RFC 2278
Also:BCP 0019
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 2978
Multipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046,RFC-2047, RFC-2184) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential.

Note: The charset 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.In particular, the general applicability and appropriateness of a given registered charset to a particular application is a protocol issue, not a registration issue, and is not dealt with by this registration procedure.

 
RFC 2979 Behavior of and Requirements for Internet Firewalls
 
Authors:N. Freed.
Date:October 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2979
This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices.
 
RFC 2980 Common NNTP Extensions
 
Authors:S. Barber.
Date:October 2000
Formats:txt html json
Updated by:RFC 3977, RFC 4643, RFC 4644, RFC 6048
Status:INFORMATIONAL
DOI:10.17487/RFC 2980
In this document, a number of popular extensions to the Network NewsTransfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of extensions.
 
RFC 2981 Event MIB
 
Authors:R. Kavasseri, Ed..
Date:October 2000
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2981
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2982
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 2983 Differentiated Services and Tunnels
 
Authors:D. Black.
Date:October 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2983
This document considers the interaction of Differentiated Services(diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms.The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers.This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.
 
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS
 
Authors:C. Adams.
Date:October 2000
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2984
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 2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0
 
Authors:M. Nystrom, B. Kaliski.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2985
This memo represents a republication of PKCS #9 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification.

This memo provides a selection of object classes and attribute types for use in conjunction with public-key cryptography and LightweightDirectory Access Protocol (LDAP) accessible directories. It also includes ASN.1 syntax for all constructs.

 
RFC 2986 PKCS #10: Certification Request Syntax Specification Version 1.7
 
Authors:M. Nystrom, B. Kaliski.
Date:November 2000
Formats:txt json html
Obsoletes:RFC 2314
Updated by:RFC 5967
Status:INFORMATIONAL
DOI:10.17487/RFC 2986
This memo represents a republication of PKCS #10 v1.7 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.

This memo describes a syntax for certification requests.

 
RFC 2987 Registration of Charset and Languages Media Features Tags
 
Authors:P. Hoffman.
Date:November 2000
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2987
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 html json
Obsoleted by:RFC 6298
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2988
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 2989 Criteria for Evaluating AAA Protocols for Network Access
 
Authors:B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2989
This document represents a summary of Authentication, Authorization,Accounting (AAA) protocol requirements for network access. In creating this document, inputs were taken from documents produced by the Network Access Server Requirements Next Generation (NASREQ),Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as from TIA 45.6.

This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.

 
RFC 2990 Next Steps for the IP QoS Architecture
 
Authors:G. Huston.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2990
While there has been significant progress in the definition ofQuality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.

This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.

 
RFC 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection
 
Authors:D. Thaler, C. Hopps.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2991
Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow "Equal-Cost Multipath" (ECMP) routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next- hop should be used for a given data packet.
 
RFC 2992 Analysis of an Equal-Cost Multi-Path Algorithm
 
Authors:C. Hopps.
Date:November 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2992
Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops.
 
RFC 2993 Architectural Implications of NAT
 
Authors:T. Hain.
Date:November 2000
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 2993
In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.
 
RFC 2994 A Description of the MISTY1 Encryption Algorithm
 
Authors:H. Ohta, M. Matsui.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2994
This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part.
 
RFC 2995 Pre-Spirits Implementations of PSTN-initiated Services
 
Authors:H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2995
This document contains information relevant to the work underway inThe Services in the PSTN/IN Requesting InTernet Services (SPIRITS)Working Group. It describes four existing implementations ofSPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.

Surveying the implementations, we can make the following observations: o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it. o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between thePSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.) o All implementations use IN-based solutions for the PSTN part.

It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS WorkingGroup to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services.

 
RFC 2996 Format of the RSVP DCLASS Object
 
Authors:Y. Bernet.
Date:November 2000
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2996
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 json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 2997
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 2998 A Framework for Integrated Services Operation over Diffserv Networks
 
Authors:Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine.
Date:November 2000
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2998
The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, theIntserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.
 
RFC 2999 Request for Comments Summary RFC Numbers 2900-2999
 
Authors:S. Ginoza.
Date:August 2001
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 2999