| |
| RFC 2900 | Internet Official Protocol Standards |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
[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 ) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
|
|
|
