| |
| RFC 2800 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to theRFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 2801 | Internet Open Trading Protocol - IOTP Version 1.0 |
| |
| Authors: | D. Burdett. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2801 |
|
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure ChannelCredit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, thePayment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. |
|
| |
| RFC 2802 | Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) |
| |
| Authors: | K. Davidson, Y. Kawatsura. |
| Date: | April 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2802 |
|
A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of theInternet Open Trading Protocol (IOTP). |
|
| |
| RFC 2803 | Digest Values for DOM (DOMHASH) |
| |
| Authors: | H. Maruyama, K. Tamura, N. Uramoto. |
| Date: | April 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2803 |
|
This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects. |
|
| |
| RFC 2804 | IETF Policy on Wiretapping |
| |
| Authors: | IAB, IESG. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2804 |
|
The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping.
This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. |
|
| |
| RFC 2805 | Media Gateway Control Protocol Architecture and Requirements |
| |
| Authors: | N. Greene, M. Ramalho, B. Rosen. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2805 |
|
This document describes protocol requirements for the Media GatewayControl Protocol between a Media Gateway Controller and a MediaGateway. |
|
| |
| RFC 2806 | URLs for Telephone Calls |
| |
|
|
This document specifies URL (Uniform Resource Locator) schemes "tel","fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers. |
|
| |
| RFC 2807 | XML Signature Requirements |
| |
| Authors: | J. Reagle. |
| Date: | July 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2807 |
|
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. |
|
| |
| RFC 2808 | The SecurID(r) SASL Mechanism |
| |
| Authors: | M. Nystrom. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2808 |
|
SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL. |
|
| |
| RFC 2809 | Implementation of L2TP Compulsory Tunneling via RADIUS |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2809 |
|
This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using theL2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. |
|
| |
| RFC 2810 | Internet Relay Chat: Architecture |
| |
|
|
The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves.
First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. |
|
| |
| RFC 2811 | Internet Relay Chat: Channel Management |
| |
|
|
One of the most notable characteristics of the IRC (Internet RelayChat) protocol is to allow for users to be grouped in forums, called channels, providing a mean for multiple users to communicate together.
There was originally a unique type of channels, but with the years, new types appeared either as a response to a need, or for experimental purposes.
This document specifies how channels, their characteristics and properties are managed by IRC servers. |
|
| |
| RFC 2812 | Internet Relay Chat: Client Protocol |
| |
|
|
The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server.
This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH]. |
|
| |
| RFC 2813 | Internet Relay Chat: Server Protocol |
| |
|
|
While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.
This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.
First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification. |
|
| |
| RFC 2814 | SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks |
| |
| Authors: | R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2814 |
|
This document describes a signaling method and protocol for RSVP- based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee. |
|
| |
| RFC 2815 | Integrated Service Mappings on IEEE 802 Networks |
| |
| Authors: | M. Seaman, A. Smith, E. Crawley, J. Wroclawski. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2815 |
|
This document describes mappings of IETF Integrated Services overLANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches.
These mappings are one component of the Integrated Services over IEEE802 LANs framework. |
|
| |
| RFC 2816 | A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies |
| |
| Authors: | A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2816 |
|
This memo describes a framework for supporting IETF IntegratedServices on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches.It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol(RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13]. |
|
| |
| RFC 2817 | Upgrading to TLS Within HTTP/1.1 |
| |
|
|
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP +TLS server can disambiguate traffic intended for several hostnames at a single IP address.
Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to- end tunnels across HTTP proxies. Finally, this memo establishes newIANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.
This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace(http://example.org/ and https://example.org/ are not equivalent). |
|
| |
| RFC 2818 | HTTP Over TLS |
| |
|
|
This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP[RFC2817]. |
|
| |
| RFC 2819 | Remote Network Monitoring Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices.
This memo obsoletes RFC 1757. This memo extends that specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. |
|
| |
| RFC 2820 | Access Control Requirements for LDAP |
| |
| Authors: | E. Stokes, D. Byrne, B. Blakley, P. Behera. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2820 |
|
This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory ApplicationProtocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories.
The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97]. |
|
| |
| RFC 2821 | Simple Mail Transfer Protocol |
| |
|
|
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:
- the original SMTP (Simple Mail Transfer Protocol) specification ofRFC 821 [30],
- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123 [2], and
- material drawn from the SMTP Extension mechanisms [19].
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models.Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476[15].
Section 2.3 provides definitions of terms specific to this document.Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship. |
|
| |
| RFC 2822 | Internet Message Format |
| |
|
|
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
| |
| RFC 2823 | PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing |
| |
| Authors: | J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2823 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, andRFCs 1662 [2] and 2615 [3] provide a means to carry PPP overSynchronous Optical Network (SONET) [4] and Synchronous DigitalHierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL)[6]. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. |
|
| |
| RFC 2824 | Call Processing Language Framework and Requirements |
| |
| Authors: | J. Lennox, H. Schulzrinne. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2824 |
|
A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language. |
|
| |
| RFC 2825 | A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols |
| |
| Authors: | IAB, L. Daigle, Ed.. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2825 |
|
The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today'sURLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development.
There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users.
This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. |
|
| |
| RFC 2826 | IAB Technical Comment on the Unique DNS Root |
| |
| Authors: | Internet Architecture Board. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2826 |
|
This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community. |
|
| |
| RFC 2827 | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing |
| |
|
|
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. |
|
| |
| RFC 2828 | Internet Security Glossary |
| |
|
|
This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion,ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future. |
|
| |
| RFC 2829 | Authentication Methods for LDAP |
| |
|
|
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. |
|
| |
| RFC 2830 | Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
| |
|
|
This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request. |
|
| |
| RFC 2831 | Using Digest Authentication as a SASL Mechanism |
| |
|
|
This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5[RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. |
|
| |
| RFC 2832 | NSI Registry Registrar Protocol (RRP) Version 1.1.0 |
| |
| Authors: | S. Hollenbeck, M. Srivastava. |
| Date: | May 2000 |
| Formats: | txt json html |
| Updated by: | RFC 3632 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2832 |
|
This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top LevelDomains (ccTLDs). This protocol was developed by the NetworkSolutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry.
Internet domain name registration typically involves three entities: a registrant who wishes to register a domain name, a registrar who provides services to the registrant, and a registry that provides services to the registrar while serving as the authoritative repository of all functional information required to resolve names registered in the registry's TLDs. This document describes a protocol for registry-registrar communication only. The protocol does not provide any registrant services.
This document is being discussed on the "rrp" mailing list. To join the list, send a message to <majordomo@NSIRegistry.com&rt; with the words "subscribe rrp" in the body of the message. There is also a web site for the mailing list archives at<http://www.NSIRegistry.net/maillist/rrp&rt;. |
|
| |
| RFC 2833 | RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals |
| |
|
|
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. |
|
| |
| RFC 2834 | ARP and IP Broadcast over HIPPI-800 |
| |
|
|
This document specifies a method for resolving IP addresses to ANSIHigh-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte SystemNetwork, GSN). This document (when combined with RFC-2067 "IP overHIPPI") obsoletes RFC-1374. |
|
| |
| RFC 2835 | IP and ARP over HIPPI-6400 (GSN) |
| |
|
|
The ANSI T11.1 task force has standardized HIPPI-6400 also known asGigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified inHIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3].
HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs[10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI-6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. |
|
| |
| RFC 2836 | Per Hop Behavior Identification Codes |
| |
| Authors: | S. Brim, B. Carpenter, F. Le Faucheur. |
| Date: | May 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3140 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2836 |
|
This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK] |
|
| |
| RFC 2837 | Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre ChannelStandards. |
|
| |
| RFC 2838 | Uniform Resource Identifiers for Television Broadcasts |
| |
| Authors: | D. Zigmond, M. Vickers. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2838 |
|
This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community. |
|
| |
| RFC 2839 | Internet Kermit Service |
| |
| Authors: | F. da Cruz, J. Altman. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2839 |
|
This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community. |
|
| |
| RFC 2840 | TELNET KERMIT OPTION |
| |
| Authors: | J. Altman, F. da Cruz. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2840 |
|
This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community. |
|
| |
| RFC 2841 | IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) |
| |
|
|
This document describes the use of keyed SHA1 with the IPAuthentication Header. |
|
| |
| RFC 2842 | Capabilities Advertisement with BGP-4 |
| |
| Authors: | R. Chandra, J. Scudder. |
| Date: | May 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3392 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2842 |
|
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives anOPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiring that BGP peering be terminated. |
|
| |
| RFC 2843 | Proxy-PAR |
| |
| Authors: | P. Droz, T. Przygienda. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2843 |
|
Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment.
The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR primarily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI.In addition, Proxy-PAR-capable servers provide filtering based on VPNIDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients. |
|
| |
| RFC 2844 | OSPF over ATM and Proxy-PAR |
| |
| Authors: | T. Przygienda, P. Droz, R. Haas. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2844 |
|
This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost- effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks(more than one VC) or Point-to-MultiPoint networks (more than oneVC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it. |
|
| |
| RFC 2845 | Secret Key Transaction Authentication for DNS (TSIG) |
| |
|
|
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. |
|
| |
| RFC 2846 | GSTN Address Element Extensions in E-mail Services |
| |
|
|
There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in[1]. |
|
| |
| RFC 2847 | LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM |
| |
| Authors: | M. Eisler. |
| Date: | June 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2847 |
|
This memorandum describes a method whereby one can use GSS-API[RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol[RFC2246].
The method leverages the existing Simple Public Key Mechanism (SPKM)[RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM. |
|
| |
| RFC 2848 | The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services |
| |
| Authors: | S. Petrack, L. Conroy. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2848 |
|
This document contains the specification of the PINT Service Protocol1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols. |
|
| |
| RFC 2849 | The LDAP Data Interchange Format (LDIF) - Technical Specification |
| |
| Authors: | G. Good. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2849 |
|
This document describes a file format suitable for describing directory information or modifications made to directory information.The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information betweenLDAP-based directory servers, or to describe a set of changes which are to be applied to a directory. |
|
| |
| RFC 2850 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC1601. |
|
| |
| RFC 2851 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2851 |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations.
This work is output from the Operations and Management Area "IPv6MIB" design team. |
|
| |
| RFC 2852 | Deliver By SMTP Service Extension |
| |
|
|
This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued.
This extension should not be viewed as a vehicle for requesting"priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a DeliverBy request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period.
A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond
17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a"delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems. |
|
| |
| RFC 2853 | Generic Security Service API Version 2 : Java Bindings |
| |
| Authors: | J. Kabat, M. Upadhyay. |
| Date: | June 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2853 |
|
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].
The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are TheSimple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5GSS-API Mechanism [KERBV5]. |
|
| |
| RFC 2854 | The 'text/html' Media Type |
| |
|
|
This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations; it is intended to obsolete the previous IETF documents defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC1942 and RFC 2070, and to remove HTML from IETF Standards Track.
This document was prepared at the request of the W3C HTML working group. Please send comments to www-html@w3.org, a public mailing list with archive at <http://lists.w3.org/Archives/Public/www-html/&rt;. |
|
| |
| RFC 2855 | DHCP for IEEE 1394 |
| |
| Authors: | K. Fujisawa. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2855 |
|
IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages. |
|
| |
| RFC 2856 | Textual Conventions for Additional High Capacity Data Types |
| |
| Authors: | A. Bierman, K. McCloghrie, R. Presuhn. |
| Date: | June 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2856 |
|
This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future. |
|
| |
| RFC 2857 | The Use of HMAC-RIPEMD-160-96 within ESP and AH |
| |
| Authors: | A. Keromytis, N. Provos. |
| Date: | June 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2857 |
|
This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection.
Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. |
|
| |
| RFC 2858 | Multiprotocol Extensions for BGP-4 |
| |
| Authors: | T. Bates, Y. Rekhter, R. Chandra, D. Katz. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2283 |
| Obsoleted by: | RFC 4760 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2858 |
|
Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
This document obsoletes RFC 2283. |
|
| |
| RFC 2859 | A Time Sliding Window Three Colour Marker (TSWTCM) |
| |
| Authors: | W. Fang, N. Seddigh, B. Nandy. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2859 |
|
This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner[RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB)[AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate(CTR) and Peak Target Rate (PTR). |
|
| |
| RFC 2860 | Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority |
| |
| Authors: | B. Carpenter, F. Baker, M. Roberts. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2860 |
|
This document places on record the text of the Memorandum ofUnderstanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. |
|
| |
| RFC 2861 | TCP Congestion Window Validation |
| |
| Authors: | M. Handley, J. Padhye, S. Floyd. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7661 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2861 |
|
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD. |
|
| |
| RFC 2862 | RTP Payload Format for Real-Time Pointers |
| |
| Authors: | M. Civanlar, G. Cash. |
| Date: | June 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2862 |
|
This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism. |
|
| |
| RFC 2863 | The Interfaces Group MIB |
| |
|
|
This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS TRACK] |
|
| |
| RFC 2864 | The Inverted Stack Table Extension to the Interfaces Group MIB |
| |
| Authors: | K. McCloghrie, G. Hanson. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2864 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS TRACK] |
|
| |
| RFC 2865 | Remote Authentication Dial In User Service (RADIUS) |
| |
|
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2866 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2867 | RADIUS Accounting Modifications for Tunnel Protocol Support |
| |
|
|
This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks. |
|
| |
| RFC 2868 | RADIUS Attributes for Tunnel Protocol Support |
| |
| Authors: | G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. |
| Date: | June 2000 |
| Formats: | txt json html |
| Updates: | RFC 2865 |
| Updated by: | RFC 3575 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2868 |
|
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. |
|
| |
| RFC 2869 | RADIUS Extensions |
| |
|
|
This document describes additional attributes for carrying authentication, authorization and accounting information between aNetwork Access Server (NAS) and a shared Accounting Server using theRemote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2]. |
|
| |
| RFC 2870 | Root Name Server Operational Requirements |
| |
| Authors: | R. Bush, D. Karrenberg, M. Kosters, R. Plzak. |
| Date: | June 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2010 |
| Obsoleted by: | RFC 7720 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2870 |
|
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details. |
|
| |
| RFC 2871 | A Framework for Telephony Routing over IP |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2871 |
|
This document serves as a framework for Telephony Routing over IP(TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. |
|
| |
| RFC 2872 | Application and Sub Application Identity Policy Element for Use with RSVP |
| |
| Authors: | Y. Bernet, R. Pabbati. |
| Date: | June 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2872 |
|
RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used byRSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. |
|
| |
| RFC 2873 | TCP Processing of the IPv4 Precedence Field |
| |
| Authors: | X. Xiao, A. Hannan, V. Paxson, E. Crabbe. |
| Date: | June 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9293 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2873 |
|
This memo describes a conflict between TCP [RFC793] and DiffServ[RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.
Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet. |
|
| |
| RFC 2874 | DNS Extensions to Support IPv6 Address Aggregation and Renumbering |
| |
|
|
This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing.
For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. |
|
| |
| RFC 2875 | Diffie-Hellman Proof-of-Possession Algorithms |
| |
| Authors: | H. Prafullchandra, J. Schaad. |
| Date: | July 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2875 |
|
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing. |
|
| |
| RFC 2876 | Use of the KEA and SKIPJACK Algorithms in CMS |
| |
| Authors: | J. Pawling. |
| Date: | July 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2876 |
|
This document describes the conventions for using the Key ExchangeAlgorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. |
|
| |
| RFC 2877 | 5250 Telnet Enhancements |
| |
|
|
This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described.
By allowing a Telnet client to select the device name, the 5250Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing,2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange.
Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description.Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates.
This memo describes how the IBM 5250 Telnet server supports WorkStation Function (WSF) printers using 5250 Display Station Pass-Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. |
|
| |
| RFC 2878 | PPP Bridging Control Protocol (BCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
This document obsoletes RFC 1638, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1QVirtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs. |
|
| |
| RFC 2879 | Content Feature Schema for Internet Fax (V2) |
| |
| Authors: | G. Klyne, L. McIntyre. |
| Date: | August 2000 |
| Formats: | txt json html |
| Obsoletes: | RFC 2531 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2879 |
|
This document defines a content media feature schema for Internet fax.
It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extendedInternet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531. |
|
| |
| RFC 2880 | Internet Fax T.30 Feature Mapping |
| |
| Authors: | L. McIntyre, G. Klyne. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2880 |
|
This document describes how to map Group 3 fax capability identification bits, described in ITU T.30 [6], into the Internet fax feature schema described in "Content feature schema for Internet fax"[4].
This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms[1,2,3], for use in performing capability identification between extended Internet fax systems [5]. |
|
| |
| RFC 2881 | Network Access Server Requirements Next Generation (NASREQNG) NAS Model |
| |
| Authors: | D. Mitton, M. Beadles. |
| Date: | July 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2881 |
|
This document describes the terminology and gives a model of typicalNetwork Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFCs 2865, 2866) [1], [2] and follow-on efforts like AAA Working Group, and the Diameter protocol [3]. These are protocols for carrying user service information for authentication, authorization, accounting, and auditing, between aNetwork Access Server which desires to authenticate its incoming calls and a shared authentication server. |
|
| |
| RFC 2882 | Network Access Servers Requirements: Extended RADIUS Practices |
| |
| Authors: | D. Mitton. |
| Date: | July 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2882 |
|
This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered.
These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. |
|
| |
| RFC 2883 | An Extension to the Selective Acknowledgement (SACK) Option for TCP |
| |
| Authors: | S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. |
| Date: | July 2000 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2883 |
|
This note defines an extension of the Selective Acknowledgement(SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of theSACK option for acknowledging out-of-sequence data not covered byTCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts. |
|
| |
| RFC 2884 | Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks |
| |
| Authors: | J. Hadi Salim, U. Ahmed. |
| Date: | July 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2884 |
|
This memo presents a performance study of the Explicit CongestionNotification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated intoRFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno,SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers.
A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf
This memo in its current revision is missing a lot of the visual representations and experimental results found in the pdf version. |
|
| |
| RFC 2885 | Megaco Protocol version 0.8 |
| |
| Authors: | F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers. |
| Date: | August 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3015 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2885 |
|
This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
|
| |
| RFC 2886 | Megaco Errata |
| |
|
|
This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS TRACK] |
|
| |
| RFC 2887 | The Reliable Multicast Design Space for Bulk Data Transfer |
| |
| Authors: | M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2887 |
|
The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions. |
|
| |
| RFC 2888 | Secure Remote Access with L2TP |
| |
| Authors: | P. Srisuresh. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2888 |
|
L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server(LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to controlAuthentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access andIPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote AccessServer (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach. |
|
| |
| RFC 2889 | Benchmarking Methodology for LAN Switching Devices |
| |
| Authors: | R. Mandeville, J. Perser. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2889 |
|
This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community. |
|
| |
| RFC 2890 | Key and Sequence Number Extensions to GRE |
| |
|
|
GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GREHeader [1]. |
|
| |
| RFC 2891 | LDAP Control Extension for Server Side Sorting of Search Results |
| |
| Authors: | T. Howes, M. Wahl, A. Anantha. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2891 |
|
This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted.Other permissible controls on search operations are not defined in this extension.
The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation.
The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97]. |
|
| |
| RFC 2892 | The Cisco SRP MAC Layer Protocol |
| |
| Authors: | D. Tsiang, G. Suwala. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2892 |
|
This document specifies the MAC layer protocol, "Spatial ReuseProtocol" (SRP) for use with ring based media. This is a second version of the protocol (V2).
The primary requirements for SRP are as follows:
- Efficient use of bandwidth using: spatial reuse of bandwidth local reuse of bandwidth minimal protocol overhead- Support for priority traffic- Scalability across a large number of nodes or stations attached to a ring- "Plug and play" design without a software based station management transfer (SMT) protocol or ring master negotiation as seen in other ring based MAC protocols [1][2]- Fairness among nodes using the ring- Support for ring based redundancy (error detection, ring wrap, etc.) similar to that found in SONET BLSR specifications.- Independence of physical layer (layer 1) media type.
This document defines the terminology used with SRP, packet formats, the protocol format, protocol operation and associated protocol finite state machines. |
|
| |
| RFC 2893 | Transition Mechanisms for IPv6 Hosts and Routers |
| |
|
|
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933. |
|
| |
| RFC 2894 | Router Renumbering for IPv6 |
| |
| Authors: | M. Crawford. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2894 |
|
IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes.
This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of NeighborDiscovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. |
|
| |
| RFC 2895 | Remote Network Monitoring MIB Protocol Identifier Reference |
| |
|
|
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network MonitoringManagement Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON ProtocolIdentifier Macros document [RFC2896] now contains the non-normative portion of that specification.
This document obsoletes RFC 2074. |
|
| |
| RFC 2896 | Remote Network Monitoring MIB Protocol Identifier Macros |
| |
| Authors: | A. Bierman, C. Bucci, R. Iddon. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2896 |
|
This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895].
This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard.It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document.
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RFC2895], and an "RMON Protocol Identifier Macros", document (this document) which contains the non-normative portion of that specification. |
|
| |
| RFC 2897 | Proposal for an MGCP Advanced Audio Package |
| |
| Authors: | D. Cromwell. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2897 |
|
This document is a proposal to add a new event/signal package to theMGCP (Media Gateway Control Protocol) protocol to control an ARF(Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server.
This event package provides support for the standard IVR (InteractiveVoice Response) operations of PlayAnnouncement, PlayCollect, andPlayRecord. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides audio variables, control of audio interruptibility, digit buffer control, special key sequences, and support for reprompting during data collection. It also provides an arbitrary number of user defined qualifiers to be used in resolving complex audio structures. For example, the user could define qualifiers for any or all of the following: language, accent, audio file format, gender, speaker, or customer. |
|
| |
| RFC 2898 | PKCS #5: Password-Based Cryptography Specification Version 2.0 |
| |
|
|
This memo represents a republication of PKCS #5 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 document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques.
The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS#8 [25]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints.
Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols[4][5][26] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope. |
|
| |
| RFC 2899 | Request for Comments Summary RFC Numbers 2800-2899 |
| |
| Authors: | S. Ginoza. |
| Date: | May 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2899 |
|
|
|
