| |
| RFC 3300 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. |
| Date: | November 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 3000 |
| Obsoleted by: | RFC 3600 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3300 |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 24, 2002. 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 3301 | Layer Two Tunnelling Protocol (L2TP): ATM access network extensions |
| |
| Authors: | Y. T'Joens, P. Crivellari, B. Sales. |
| Date: | June 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3301 |
|
This document augments the procedures described in RFC 2661 to further support ATM SVC (Switched Virtual Circuits) or PVC (PermanentVirtual Circuits) based access networks. L2TP (Layer 2 TunnelingProtocol) specifies a protocol for tunnelling PPP packets over packet based networks and over IP networks in particular. L2TP supports remote access by ISDN and PSTN networks. The extensions defined within this document allow for asymmetric bi-directional call establishment and service selection in the ATM access network. |
|
| |
| RFC 3302 | Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration |
| |
| Authors: | G. Parsons, J. Rafferty. |
| Date: | September 2002 |
| Formats: | txt json html |
| Obsoletes: | RFC 2302 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 3302 |
|
This document describes the registration of the MIME sub-type image/tiff. This document refines an earlier sub-type registration in RFC 1528.
This document obsoletes RFC 2302. |
|
| |
| RFC 3303 | Middlebox communication architecture and framework |
| |
| Authors: | P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3303 |
|
A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group.
There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP andH.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic. |
|
| |
| RFC 3304 | Middlebox Communications (midcom) Protocol Requirements |
| |
| Authors: | R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3304 |
|
This document specifies the requirements that the MiddleboxCommunication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function.These requirements were developed with a specific focus on network address translation and firewall middleboxes. |
|
| |
| RFC 3305 | Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations |
| |
| Authors: | M. Mealling, Ed., R. Denenberg, Ed.. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3305 |
|
This document, a product of the W3C Uniform Resource Identifier (URI)Interest Group, addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject. |
|
| |
| RFC 3306 | Unicast-Prefix-based IPv6 Multicast Addresses |
| |
|
|
This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. |
|
| |
| RFC 3307 | Allocation Guidelines for IPv6 Multicast Addresses |
| |
| Authors: | B. Haberman. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3307 |
|
This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address. |
|
| |
| RFC 3308 | Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension |
| |
| Authors: | P. Calhoun, W. Luo, D. McPherson, K. Peirce. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3308 |
|
This document describes mechanisms which enable the Layer TwoTunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel.
L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supportingDifferentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination. |
|
| |
| RFC 3309 | Stream Control Transmission Protocol (SCTP) Checksum Change |
| |
|
|
Stream Control Transmission Protocol (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum. |
|
| |
| RFC 3310 | Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) |
| |
| Authors: | A. Niemi, J. Arkko, V. Torvinen. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3310 |
|
This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext TransferProtocol (HTTP) Digest access authentication. The HTTPAuthentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal MobileTelecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. |
|
| |
| RFC 3311 | The Session Initiation Protocol (SIP) UPDATE Method |
| |
| Authors: | J. Rosenberg. |
| Date: | October 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3311 |
|
This specification defines the new UPDATE method for the SessionInitiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs. |
|
| |
| RFC 3312 | Integration of Resource Management and Session Initiation Protocol (SIP) |
| |
|
|
This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session InitiationProtocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session. |
|
| |
| RFC 3313 | Private Session Initiation Protocol (SIP) Extensions for Media Authorization |
| |
| Authors: | W. Marshall, Ed.. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3313 |
|
This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains. |
|
| |
| RFC 3314 | Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards |
| |
| Authors: | M. Wasserman, Ed.. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3314 |
|
This document contains recommendations from the Internet EngineeringTask Force (IETF) IPv6 Working Group to the Third GenerationPartnership Project (3GPP) community regarding the use of IPv6 in the3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document. |
|
| |
| RFC 3315 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. |
| Date: | July 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8415 |
| Updated by: | RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3315 |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters. |
|
| |
| RFC 3316 | Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts |
| |
| Authors: | J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. |
| Date: | April 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7066 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3316 |
|
As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on howIPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or UniversalMobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. |
|
| |
| RFC 3317 | Differentiated Services Quality of Service Policy Information Base |
| |
| Authors: | K. Chan, R. Sahita, S. Hahn, K. McCloghrie. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3317 |
|
This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control over resources implementing the Differentiated Services Architecture.These provisioning classes can be used with other none DifferentiatedServices provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage. |
|
| |
| RFC 3318 | Framework Policy Information Base |
| |
| Authors: | R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3318 |
|
This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol forProvisioning.
Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well- defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).
One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.
As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules.However, some PRovisioning Classes are common to all subject- categories (client-types) and need to be present in each. |
|
| |
| RFC 3319 | Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers |
| |
| Authors: | H. Schulzrinne, B. Volz. |
| Date: | July 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3319 |
|
This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more Session InitiationProtocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. |
|
| |
| RFC 3320 | Signaling Compression (SigComp) |
| |
| Authors: | R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3320 |
|
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as theSession Initiation Protocol (SIP) (RFC 3261) and the Real TimeStreaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of theSigComp message.
Decompression functionality for SigComp is provided by a UniversalDecompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951). |
|
| |
| RFC 3321 | Signaling Compression (SigComp) - Extended Operations |
| |
| Authors: | H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3321 |
|
This document describes how to implement certain mechanisms inSignaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per- message compression.
SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC3320. |
|
| |
| RFC 3322 | Signaling Compression (SigComp) Requirements & Assumptions |
| |
| Authors: | H. Hannu. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3322 |
|
The purpose of this document is to outline requirements and motivations for the development of a scheme for compression and decompression of messages from signaling protocols. In wireless environments and especially in cellular systems, e.g., GSM (GlobalSystem for Mobile communications) and UMTS (Universal MobileTelecommunications System), there is a need to maximize the transport efficiency for data over the radio interface. With the introduction of SIP/SDP (Session Initiation Protocol/Session Description Protocol) to cellular devices, compression of the signaling messages should be considered in order to improve both service availability and quality, mainly by reducing the user idle time, e.g., at call setup. |
|
| |
| RFC 3323 | A Privacy Mechanism for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3323 |
|
This document defines new mechanisms for the Session InitiationProtocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. |
|
| |
| RFC 3324 | Short Term Requirements for Network Asserted Identity |
| |
| Authors: | M. Watson. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3324 |
|
A Network Asserted Identity is an identity initially derived by aSession Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks.
There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias. |
|
| |
| RFC 3325 | Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks |
| |
|
|
This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. |
|
| |
| RFC 3326 | The Reason Header Field for the Session Initiation Protocol (SIP) |
| |
|
|
For creating services, it is often useful to know why a SessionInitiation Protocol (SIP) request was issued. This document defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", orHERFP. |
|
| |
| RFC 3327 | Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts |
| |
| Authors: | D. Willis, B. Hoeneisen. |
| Date: | December 2002 |
| Formats: | txt json html |
| Updated by: | RFC 5626 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3327 |
|
The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of aUniform Resource Identifier (URI), such as Contact:<sip:alice@pc33.atlanta.com&rt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. |
|
| |
| RFC 3329 | Security Mechanism Agreement for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3329 |
|
This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities. |
|
| |
| RFC 3330 | Special-Use IPv4 Addresses |
| |
|
|
This document describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned NumbersAuthority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. |
|
| |
| RFC 3331 | Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer |
| |
| Authors: | K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3331 |
|
This document defines a protocol for the backhauling of SignalingSystem 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signalling Gateway (SG) and MediaGateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. The Signalling Gateway would act as a Signalling Link Terminal. |
|
| |
| RFC 3332 | Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) |
| |
| Authors: | G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. |
| Date: | September 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4666 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3332 |
|
This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between twoIP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. |
|
| |
| RFC 3334 | Policy-Based Accounting |
| |
| Authors: | T. Zseby, S. Zander, C. Carle. |
| Date: | October 2002 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3334 |
|
This document describes policy-based accounting which is an approach to provide flexibility to accounting architectures. Accounting policies describe the configuration of an accounting architecture in a standardized way. They are used to instrument the accounting architecture and can be exchanged between Authentication,Authorization and Accounting (AAA) entities in order to share configuration information.
This document describes building blocks and message sequences for policy-based accounting in the generic AAA architecture (RFC 2903).Examples are given for the usage of accounting policies in different scenarios. It is also shown how accounting components can be integrated into the AAA authorization framework (RFC 2904). This document does not propose a language for the description of accounting policies. Rather, it is assumed that a suitable policy language can be chosen from existing or upcoming standards. |
|
| |
| RFC 3335 | MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet |
| |
| Authors: | T. Harding, R. Drummond, C. Shih. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3335 |
|
This document describes how to exchange structured business data securely using SMTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, ElectronicData Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message. |
|
| |
| RFC 3336 | PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) |
| |
| Authors: | B. Thompson, T. Koren, B. Buffam. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3336 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets. |
|
| |
| RFC 3337 | Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 |
| |
| Authors: | B. Thompson, T. Koren, B. Buffam. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3337 |
|
The Point-to-Point Protocol (PPP) over Asynchronous Transfer Mode(ATM) Adaptation Layer 2 defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the ATMAdaptation Layer 2 (AAL2) adaptation layer. This document defines a set of class extensions to PPP over AAL2 that implement equivalent functionality to Multi Class Multi Link PPP over a single ATM virtual circuit. Instead of using Multi Link PPP as the basis for fragmentation functionality, this document uses the functionality of the Segmentation and Reassembly Service Specific Convergence Sublayer that is already required as the basic encapsulation format of PPP over AAL2. |
|
| |
| RFC 3338 | Dual Stack Hosts Using "Bump-in-the-API" (BIA) |
| |
| Authors: | S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. |
| Date: | October 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6535 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3338 |
|
This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications.The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation. |
|
| |
| RFC 3339 | Date and Time on the Internet: Timestamps |
| |
|
|
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. |
|
| |
| RFC 3340 | The Application Exchange Core |
| |
| Authors: | M. Rose, G. Klyne, D. Crocker. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3340 |
|
This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs. |
|
| |
| RFC 3341 | The Application Exchange (APEX) Access Service |
| |
| Authors: | M. Rose, G. Klyne, D. Crocker. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3341 |
|
This memo describes the Application Exchange (APEX) access service, addressed as the well-known endpoint "apex=access". The access service is used to control use of both the APEX "relaying mesh" and other APEX services. |
|
| |
| RFC 3342 | The Application Exchange (APEX) Option Party Pack, Part Deux! |
| |
| Authors: | E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz. |
| Date: | July 2002 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3342 |
|
Application Exchange (APEX), at its core, provides a best-effort application-layer datagram service. Options are used to alter the semantics of the core service. This memo defines various options to change the default behavior of APEX's "relaying mesh". |
|
| |
| RFC 3343 | The Application Exchange (APEX) Presence Service |
| |
| Authors: | M. Rose, G. Klyne, D. Crocker. |
| Date: | April 2003 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3343 |
|
This memo describes the Application Exchange (APEX) presence service, addressed as the well-known endpoint "apex=presence". The presence service is used to manage presence information for APEX endpoints. |
|
| |
| RFC 3344 | IP Mobility Support for IPv4 |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3345 | Border Gateway Protocol (BGP) Persistent Route Oscillation Condition |
| |
| Authors: | D. McPherson, V. Gill, D. Walton, A. Retana. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3345 |
|
In particular configurations, the BGP scaling mechanisms defined in"BGP Route Reflection - An Alternative to Full Mesh IBGP" and"Autonomous System Confederations for BGP" will introduce persistentBGP route oscillation. This document discusses the two types of persistent route oscillation that have been identified, describes when these conditions will occur, and provides some network design guidelines to avoid introducing such occurrences. |
|
| |
| RFC 3346 | Applicability Statement for Traffic Engineering with MPLS |
| |
| Authors: | J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3346 |
|
This document describes the applicability of Multiprotocol LabelSwitching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted. |
|
| |
| RFC 3347 | Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations |
| |
| Authors: | M. Krueger, R. Haagens. |
| Date: | July 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3347 |
|
This document specifies the requirements iSCSI and its related infrastructure should satisfy and the design considerations guiding the iSCSI protocol development efforts. In the interest of timely adoption of the iSCSI protocol, the IPS group has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer.Both these protocols are widely-deployed and well-understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment. |
|
| |
| RFC 3348 | The Internet Message Action Protocol (IMAP4) Child Mailbox Extension |
| |
| Authors: | M. Gahrns, R. Cheng. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3348 |
|
The Internet Message Action Protocol (IMAP4) CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST "" * or aLIST "" % for each mailbox. |
|
| |
| RFC 3349 | A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force |
| |
|
|
As a part of their deliverables, working groups of the IETF may develop BEEP profiles. During the development process, it is desirable to assign a transient identifier to each profile. If the profile is subsequently published as an RFC, then a permanent identifier is subsequently assigned by the IANA. |
|
| |
| RFC 3351 | User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals |
| |
| Authors: | N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3351 |
|
This document presents a set of Session Initiation Protocol(SIP) user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications.
A number of issues related to these user requirements are further raised in this document.
Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level. |
|
| |
| RFC 3352 | Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status |
| |
|
|
The Connection-less Lightweight Directory Access Protocol (CLDAP) technical specification, RFC 1798, was published in 1995 as aProposed Standard. This document discusses the reasons why the CLDAP technical specification has not been furthered on the Standard Track.This document recommends that RFC 1798 be moved to Historic status. |
|
| |
| RFC 3353 | Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment |
| |
| Authors: | D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3353 |
|
This document offers a framework for IP multicast deployment in anMPLS environment. Issues arising when MPLS techniques are applied toIP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. |
|
| |
| RFC 3354 | Internet Open Trading Protocol Version 2 Requirements |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3354 |
|
This document gives requirements for the Internet Open TradingProtocol (IOTP) Version 2 by describing design principles and scope and dividing features into those which will, may, or will not be included.
Version 2 of the IOTP will extend the interoperable framework forInternet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms. |
|
| |
| RFC 3355 | Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) |
| |
| Authors: | A. Singh, R. Turner, R. Tio, S. Nanji. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3355 |
|
The Layer Two Tunneling Protocol (L2TP) provides a standard method for transporting the link layer of the Point-to-Point Protocol (PPP) between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point-to-point connection. This document describes the use of an Asynchronous Transfer Mode (ATM) network for the underlying network connection. ATM User-NetworkInterface (UNI) Signaling Specification Version 4.0 or Version 3.1 with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to theATM network. |
|
| |
| RFC 3356 | Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines |
| |
|
|
This document provides guidance to aid in the understanding of collaboration on standards development between the InternationalTelecommunication Union -- Telecommunication Standardization Sector(ITU-T) and the Internet Society (ISOC) / Internet Engineering TaskForce (IETF). It is an update of and obsoletes RFC 2436. The updates reflect changes in the IETF and ITU-T since RFC 2436 was written. The bulk of this document is common text with ITU-TSupplement 3 to the ITU-T A-Series Recommendations.
Note: This was approved by ITU-T TSAG on 30 November 2001 as aSupplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3). |
|
| |
| RFC 3357 | One-way Loss Pattern Sample Metrics |
| |
| Authors: | R. Koodli, R. Ravikanth. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3357 |
|
Using the base loss metric defined in RFC 2680, this document defines two derived metrics "loss distance" and "loss period", and the associated statistics that together capture loss patterns experienced by packet streams on the Internet. The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. The loss pattern or loss distribution is a key parameter that determines the performance observed by the users for certain real-time applications such as packet voice and video. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance. |
|
| |
| RFC 3358 | Optional Checksums in Intermediate System to Intermediate System (ISIS) |
| |
| Authors: | T. Przygienda. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3358 |
|
This document describes an optional extension to the IntermediateSystem to Intermediate System (ISIS) protocol, used today by severalInternet Service Proviers (ISPs) for routing within their clouds.ISIS is an interior gateway routing protocol developed originally byOSI and used with IP extensions as Interior Gateway Protocol (IGP).ISIS originally does not provide Complete Sequence Numbers ProtocolData (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP) checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional Type, Length and Value (TLV) providing checksums. |
|
| |
| RFC 3359 | Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System |
| |
| Authors: | T. Przygienda. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3359 |
|
This document describes implementation codepoints within IntermediateSystem to Intermediate System (IS-IS) used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions asInterior Gateway Protocol (IGP). This document summarizes all Table,Length and Value (TLV) codepoints that are being used by the protocol and its pending extensions. |
|
| |
| RFC 3360 | Inappropriate TCP Resets Considered Harmful |
| |
|
|
This document is being written because there are a number of firewalls in the Internet that inappropriately reset a TCP connection upon receiving certain TCP SYN packets, in particular, packets with flags set in the Reserved field of the TCP header. In this document we argue that this practice is not conformant with TCP standards, and is an inappropriate overloading of the semantics of the TCP reset.We also consider the longer-term consequences of this and similar actions as obstacles to the evolution of the Internet infrastructure. |
|
| |
| RFC 3361 | Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers |
| |
| Authors: | H. Schulzrinne. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3361 |
|
This document defines a Dynamic Host Configuration Protocol(DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session InitiationProtocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. |
|
| |
| RFC 3362 | Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration |
| |
| Authors: | G. Parsons. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3362 |
|
This document describes the registration of the MIME sub-type image/t38. The encoding is defined by ITU Recommendation T.38 and is intended for use as an Session Description Protocol (SDP) media descriptor. |
|
| |
| RFC 3363 | Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) |
| |
|
|
This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status. |
|
| |
| RFC 3364 | Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) |
| |
|
|
The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. |
|
| |
| RFC 3365 | Strong Security Requirements for Internet Engineering Task Force Standard Protocols |
| |
|
|
It is the consensus of the IETF that IETF standard protocols MUST make use of appropriate strong security mechanisms. This document describes the history and rationale for this doctrine and establishes this doctrine as a best current practice. |
|
| |
| RFC 3366 | Advice to link designers on link Automatic Repeat reQuest (ARQ) |
| |
|
|
This document provides advice to the designers of digital communication equipment and link-layer protocols employing link-layerAutomatic Repeat reQuest (ARQ) techniques. This document presumes that the designers wish to support Internet protocols, but may be unfamiliar with the architecture of the Internet and with the implications of their design choices for the performance and efficiency of Internet traffic carried over their links.
ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of channel. This document also describes issues relevant to supporting IP traffic over physical-layer channels where performance varies, and where link ARQ is likely to be used. |
|
| |
| RFC 3367 | Common Name Resolution Protocol (CNRP) |
| |
| Authors: | N. Popp, M. Mealling, M. Moseley. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3367 |
|
People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs.Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable.For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource.
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is also intended to address issues of internationalization and localization. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added. |
|
| |
| RFC 3368 | The 'go' URI Scheme for the Common Name Resolution Protocol |
| |
| Authors: | M. Mealling. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3368 |
|
This document defines a URI scheme, 'go:' to be used with the CommonName Resolution Protocol. Specifically it lays out the syntactic components and how those components are used by URI Resolution to find the available transports for a CNRP service. Care should be taken with several of the URI components because, while they may look like components found in other URI schemes, they often do not act like them. The "go" scheme has more in common with the location independent "news" scheme than any other URI scheme. |
|
| |
| RFC 3369 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3370 | Cryptographic Message Syntax (CMS) Algorithms |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS).The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. |
|
| |
| RFC 3371 | Layer Two Tunneling Protocol "L2TP" Management Information Base |
| |
| Authors: | E. Caves, P. Calhoun, R. Wheeler. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3371 |
|
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 networks using Layer 2Tunneling Protocol (L2TP). |
|
| |
| RFC 3372 | Session Initiation Protocol for Telephones (SIP-T): Context and Architectures |
| |
| Authors: | A. Vemuri, J. Peterson. |
| Date: | September 2002 |
| Formats: | txt html json |
| Also: | BCP 0063 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3372 |
|
The popularity of gateways that interwork between the PSTN (PublicSwitched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This document taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying). |
|
| |
| RFC 3373 | Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies |
| |
|
|
The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. |
|
| |
| RFC 3374 | Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network |
| |
| Authors: | J. Kempf, Ed.. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3374 |
|
In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly.In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service(QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility. |
|
| |
| RFC 3375 | Generic Registry-Registrar Protocol Requirements |
| |
| Authors: | S. Hollenbeck. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3375 |
|
This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. |
|
| |
| RFC 3376 | Internet Group Management Protocol, Version 3 |
| |
| Authors: | B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. |
| Date: | October 2002 |
| Formats: | txt html json |
| Updates: | RFC 2236 |
| Updated by: | RFC 4604 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3376 |
|
This document specifies Version 3 of the Internet Group ManagementProtocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets*only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.
This document obsoletes RFC 2236. |
|
| |
| RFC 3377 | Lightweight Directory Access Protocol (v3): Technical Specification |
| |
|
|
This document specifies the set of RFCs comprising the LightweightDirectory Access Protocol Version 3 (LDAPv3), and addresses the "IESGNote" attached to RFCs 2251 through 2256. |
|
| |
| RFC 3378 | EtherIP: Tunneling Ethernet Frames in IP Datagrams |
| |
| Authors: | R. Housley, S. Hollenbeck. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3378 |
|
This document describes the EtherIP, an early tunneling protocol, to provide informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse anIP internet. The protocol is very lightweight, and it does not provide protection against infinite loops. |
|
| |
| RFC 3379 | Delegated Path Validation and Delegated Path Discovery Protocol Requirements |
| |
| Authors: | D. Pinkas, R. Housley. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3379 |
|
This document specifies the requirements for Delegated PathValidation (DPV) and Delegated Path Discovery (DPD) for Public KeyCertificates. It also specifies the requirements for DPV and DPD policy management. |
|
| |
| RFC 3380 | Internet Printing Protocol (IPP): Job and Printer Set Operations |
| |
|
|
This document is an OPTIONAL extension to the Internet PrintingProtocol (IPP/1.0 and IPP/1.1). This document specifies 3 additionalOPTIONAL operations for use with the Internet Printing Protocol/1.0(IPP) and IPP/1.1. The end user, operator, and administrator Set-Job-Attributes and Set-Printer-Attributes operations are used to modify IPP Job objects and Printer objects, respectively. The Get-Printer-Supported-Values administrative operation returns values that the IPP Printer will accept for setting its "xxx-supported" attributes. |
|
| |
| RFC 3381 | Internet Printing Protocol (IPP): Job Progress Attributes |
| |
|
|
This document defines four new Job Description attributes for monitoring job progress to be registered as OPTIONAL extensions to the Internet Printing Protocol (IPP/1.0 and IPP/1.1). These attributes are drawn from the PWG Job Monitoring MIB. This document also defines a new "sheet-collate" Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes. |
|
| |
| RFC 3382 | Internet Printing Protocol (IPP): The 'collection' attribute syntax |
| |
|
|
This document specifies an OPTIONAL attribute syntax called'collection' for use with the Internet Printing Protocol (IPP/1.0 andIPP/1.1). A 'collection' is a container holding one or more named values, which are called "member" attributes. A collection allows data to be grouped like a PostScript dictionary or a Java Map. This document also specifies the conformance requirements for a definition document that defines a collection attribute. Finally, this document gives some illustrative example collection attribute definitions that are not intended as actual attribute specifications. |
|
| |
| RFC 3383 | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | September 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4520 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3383 |
|
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). This document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned. |
|
| |
| RFC 3384 | Lightweight Directory Access Protocol (version 3) Replication Requirements |
| |
| Authors: | E. Stokes, R. Weiser, R. Moats, R. Huber. |
| Date: | October 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3384 |
|
This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol(version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. |
|
| |
| RFC 3385 | Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations |
| |
| Authors: | D. Sheinwald, J. Satran, P. Thaler, V. Cavanna. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3385 |
|
In this memo, we attempt to give some estimates for the probability of undetected errors to facilitate the selection of an error detection code for the Internet Protocol Small Computer SystemInterface (iSCSI).
We will also attempt to compare Cyclic Redundancy Checks (CRCs) with other checksum forms (e.g., Fletcher, Adler, weighted checksums), as permitted by available data. |
|
| |
| RFC 3386 | Network Hierarchy and Multilayer Survivability |
| |
| Authors: | W. Lai, Ed., D. McDysan, Ed.. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3386 |
|
This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments. |
|
| |
| RFC 3387 | Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network |
| |
| Authors: | M. Eder, H. Chaskar, S. Nag. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3387 |
|
The guiding principles in the design of IP network management were simplicity and no centralized control. The best effort service paradigm was a result of the original management principles and the other way around. New methods to distinguish the service given to one set of packets or flows relative to another are well underway.However, as IP networks evolve the management approach of the past may not apply to the Quality of Service (QoS)-capable network envisioned by some for the future. This document examines some of the areas of impact that QoS is likely to have on management and look at some questions that remain to be addressed. |
|
| |
| RFC 3388 | Grouping of Media Lines in the Session Description Protocol (SDP) |
| |
| Authors: | G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5888 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3388 |
|
This document defines two Session Description Protocol (SDP) attributes: "group" and "mid". They allow to group together several"m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces. |
|
| |
| RFC 3389 | Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) |
| |
| Authors: | R. Zopf. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3389 |
|
This document describes a Real-time Transport Protocol (RTP) payload format for transporting comfort noise (CN). The CN payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711,G.726, G.727, G.728, and G.722. |
|
| |
| RFC 3390 | Increasing TCP's Initial Window |
| |
|
|
This document specifies an optional standard for TCP to increase the permitted initial window from one or two segment(s) to roughly 4K bytes, replacing RFC 2414. It discusses the advantages and disadvantages of the higher initial window, and includes discussion of experiments and simulations showing that the higher initial window does not lead to congestion collapse. Finally, this document provides guidance on implementation issues. |
|
| |
| RFC 3391 | The MIME Application/Vnd.pwg-multiplexed Content-Type |
| |
| Authors: | R. Herriot. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3391 |
|
The Application/Vnd.pwg-multiplexed content-type, like theMultipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. AnApplication/Vnd.pwg-multiplexed entity contains a sequence of chunks.Each chunk contains a MIME message or a part of a MIME message. EachMIME message represents a component of the compound object, just as a body part of a Multipart/Related entity represents a component. With a Multipart/Related entity, a body part and its reference in some other body part may be separated by many octets. With anApplication/Vnd.pwg-multiplexed entity, a message and its reference in some other message can be made quite close by chunking the message containing the reference. For example, if a long message contains references to images and the producer does not know of the need for each image until it generates the reference, thenApplication/Vnd.pwg-multiplexed allows the consumer to process the reference to the image and the image before it consumes the entire long message. This ability is important in printing and scanning applications. This document defines the Application/Vnd.pwg- multiplexed content-type. It also provides examples of its use. |
|
| |
| RFC 3392 | Capabilities Advertisement with BGP-4 |
| |
|
|
This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
This document obsoletes RFC 2842. |
|
| |
| RFC 3393 | IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) |
| |
| Authors: | C. Demichelis, P. Chimento. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3393 |
|
This document refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in theOne-Way-Delay of selected packets. This difference in delay is called "IP Packet Delay Variation (ipdv)".
The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this document. |
|
| |
| RFC 3394 | Advanced Encryption Standard (AES) Key Wrap Algorithm |
| |
| Authors: | J. Schaad, R. Housley. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3394 |
|
The purpose of this document is to make the Advanced EncryptionStandard (AES) Key Wrap algorithm conveniently available to theInternet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES KeyWrap posted by NIST. |
|
| |
| RFC 3395 | Remote Network Monitoring MIB Protocol Identifier Reference Extensions |
| |
| Authors: | A. Bierman, C. Bucci, R. Dietz, A. Warth. |
| Date: | September 2002 |
| Formats: | txt json html |
| Updates: | RFC 2895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3395 |
|
This memo defines extensions to the Protocol Identifier Reference document for the identification of application verb information. It updates the Protocol Identifier Reference document but does not obsolete any portion of that document. In particular, it describes the algorithms required to identify protocol operations (verbs) within the protocol encapsulations managed with MIBs such as theRemote Network Monitoring MIB Version 2, RFC 2021. |
|
| |
| RFC 3396 | Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) |
| |
| Authors: | T. Lemon, S. Cheshire. |
| Date: | November 2002 |
| Formats: | txt html json |
| Updates: | RFC 2131 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3396 |
|
This document specifies the processing rules for Dynamic HostConfiguration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing. |
|
| |
| RFC 3397 | Dynamic Host Configuration Protocol (DHCP) Domain Search Option |
| |
| Authors: | B. Aboba, S. Cheshire. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3397 |
|
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 domain search list used when resolving hostnames usingDNS. |
|
| |
| RFC 3398 | Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping |
| |
| Authors: | G. Camarillo, A. B. Roach, J. Peterson, L. Ong. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3398 |
|
This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and theIntegrated Services Digital Network (ISDN) User Part (ISUP) ofSignaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). |
|
