|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2901 |
 Guide to Administrative Procedures of the Internet Infrastructure
|
|
Summary Publication date: Aug 2000 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
|
|
Summary Publication date: Aug 2000 This document is an overview of a Routing workshop held by the Internet 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
|
|
Summary Publication date: Aug 2000 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
|
|
Summary Publication date: Aug 2000 This memo serves as the base requirements for Authorization of Internet 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
|
|
Summary Publication date: Aug 2000 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
|
|
Summary Publication date: Aug 2000 This document specifies the requirements that Authentication Authorization 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
|
|
Summary Publication date: Sep 2000 This document defines a new option to the Multicast Address Dynamic Client 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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 new Internet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext Transfer Protocol (HTTP) a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. |
| RFC 2911 |
Internet Printing Protocol/1.1: Model and Semantics
|
|
Summary Publication date: Sep 2000 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. |
| RFC 2912 |
Indicating Media Features for MIME Content
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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 Multipurpose Internet 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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 or Uniform 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 Discovery Systems 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 This memo presents an approach for building core Virtual Private Network (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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Mar 2001 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
|
|
Summary Publication date: Sep 2000 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 Control Protocol (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)
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. |
| RFC 2924 |
Accounting Attributes and Record Formats
|
|
Summary Publication date: Sep 2000 This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats for Accounting 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
|
|
Summary Publication date: Sep 2000 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 an IP 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
|
|
Summary Publication date: Sep 2000 This document describes a procedure for mapping between Service Location 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned Numbers Authority (IANA) from the Internet Engineering Task Force (IETF) Internet Protocol Next Generation (IPNG) and Next Generation Transition (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
|
|
Summary Publication date: Sep 2000 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)
|
|
Summary Publication date: Sep 2000 RFC 2845 provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the Transaction 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 )
|
|
Summary Publication date: Sep 2000 Extensions to the Domain Name System (DNS) are described in [RFC 2535] 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
|
|
Summary Publication date: Oct 2000 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 IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. |
| RFC 2933 |
Internet Group Management Protocol MIB
|
|
Summary Publication date: Oct 2000 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 Internet Group Management Protocol (IGMP). |
| RFC 2934 |
Protocol Independent Multicast MIB for IPv4
|
|
Summary Publication date: Oct 2000 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. |
| RFC 2935 |
Internet Open Trading Protocol (IOTP) HTTP Supplement
|
|
Summary Publication date: Sep 2000 Internet Open Trading Protocol (IOTP) messages will be carried as Extensible 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 Transport Protocol (HTTP), Versions 1.0 and 1.1. |
| RFC 2936 |
HTTP MIME Type Handler Detection
|
|
Summary Publication date: Sep 2000 Entities composing web pages to provide services over the Hypertext Transfer 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 Open Trading 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 the Internet 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a Transmission Control 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
|
|
Summary Publication date: Oct 2000 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 Common Open Policy Service (COPS) protocol. This memo includes a MIB module in a manner that is compliant to the SMIv2 [V2SMI]. |
| RFC 2941 |
Telnet Authentication Option
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA) [FIPS186]. It relies on the Telnet Authentication Option RFC 2941. |
| RFC 2944 |
Telnet Authentication: SRP
|
|
Summary Publication date: Sep 2000 This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in RFC 2945. |
| RFC 2945 |
The SRP Authentication and Key Exchange System
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNET Authentication Option. |
| RFC 2952 |
Telnet Encryption: DES 64 bit Cipher Feedback
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Sep 2000 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
|
|
Summary Publication date: Oct 2000 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control 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
|
|
Summary Publication date: Oct 2000 This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. |
| RFC 2956 |
Overview of 1999 IAB Network Layer Workshop
|
|
Summary Publication date: Oct 2000 This document is an overview of a workshop held by the Internet Architecture 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 Task Force (IETF) community. |
| RFC 2957 |
The application/whoispp-query Content-Type
|
|
Summary Publication date: Oct 2000 This document defines the expression of Whois++ protocol (RFC 1835) queries within MIME (Multipurpose Internet Mail Extensions) (RFC 2046) 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
|
|
Summary Publication date: Oct 2000 This document defines the expression of Whois++ protocol (RFC 1835) responses within MIME (Multipurpose Internet Mail Extensions) (RFC 2046) 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
|
|
Summary Publication date: Oct 2000 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 Transport Protocol (RTP) systems (RFC 1889). |
| RFC 2960 |
Stream Control Transmission Protocol
|
|
Summary Publication date: Oct 2000 This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP 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
|
|
Summary Publication date: Apr 2001 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
|
|
Summary Publication date: Oct 2000 This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) 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 (Network Address 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 Level Gateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms. |
| RFC 2963 |
A Rate Adaptive Shaper for Differentiated Services
|
|
Summary Publication date: Oct 2000 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 RFC 2697 and RFC 2698, 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 Forwarding Per 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
|
|
Summary Publication date: Oct 2000 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 of Hypertext 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
|
|
Summary Publication date: Oct 2000 This document specifies a way to create a stateful session with Hypertext 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
|
|
Summary Publication date: Oct 2000 This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, 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 Intermediate Systems (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
|
|
Summary Publication date: Oct 2000 The strength of the TISDAG (Technical Infrastructure for Swedish Directory 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
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 The TISDAG (Technical Infrastructure for Swedish Directory Access Gateway) 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
|
|
Summary Publication date: Oct 2000 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 of WWW 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
|
|
Summary Publication date: Oct 2000 The ID extension to the Internet Message Access Protocol - Version 4rev1 (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
|
|
Summary Publication date: Oct 2000 This document establishes the context and goals for a Common Name Resolution 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 Common Name 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 Name Resolution Protocol working group. |
| RFC 2973 |
IS-IS Mesh Groups
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 This document proposes an extension to the Session Initiation Protocol (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 and ISDN 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
|
|
Summary Publication date: Oct 2000 The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements for Authentication, 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
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 In this document, a number of popular extensions to the Network News Transfer 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
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 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 become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. |
| RFC 2983 |
Differentiated Services and Tunnels
|
|
Summary Publication date: Oct 2000 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
|
|
Summary Publication date: Oct 2000 This document specifies how to incorporate CAST-128 (RFC 2144) 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 (RFC 2630) for symmetric content and key encryption. |
| RFC 2985 |
PKCS #9: Selected Object Classes and Attribute Types Version 2.0
|
|
Summary Publication date: Nov 2000 This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' 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 Lightweight Directory 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
|
|
Summary Publication date: Nov 2000 This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' 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
|
|
Summary Publication date: Nov 2000 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
|
|
Summary Publication date: Nov 2000 This document defines the standard algorithm that Transmission Control 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
|
|
Summary Publication date: Nov 2000 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
|
|
Summary Publication date: Nov 2000 While there has been significant progress in the definition of Quality 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
|
|
Summary Publication date: Nov 2000 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
|
|
Summary Publication date: Nov 2000 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
|
|
Summary Publication date: Nov 2000 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
|
|
Summary Publication date: Nov 2000 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
|
|
Summary Publication date: Nov 2000 This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-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. |
| RFC 2996 |
Format of the RSVP DCLASS Object
|
|
Summary Publication date: Nov 2000 Resource Reservation Protocol (RSVP) signaling may be used to request Quality of Service (QoS) services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv or DS) network. When using RSVP with DS networks it is useful to be able to carry carry Differentiated Services Code Points (DSCPs) in RSVP 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
|
|
Summary Publication date: Nov 2000 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'. The Null Service allows applications to identify themselves to network Quality 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
|
|
Summary Publication date: Nov 2000 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, the Intserv 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
|
|
Summary Publication date: Aug 2001 This RFC is a slightly annotated list of the 100 RFCs from RFC 2900 through RFCs 2999. This is a status report on these RFCs. |
| RFC 3000 |
Internet Official Protocol Standards
|
|
Summary Publication date: Nov 2001 This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 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. |
