Internet Documents

RFCs 3300 - 3399s

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

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
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
 
Authors:B. Haberman, D. Thaler.
Date:August 2002
Formats:txt json html
Updated by:RFC 3956, RFC 4489, RFC 7371
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3306
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
 
Authors:J. Stone, R. Stewart, D. Otis.
Date:September 2002
Formats:txt html json
Obsoleted by:RFC 4960
Updates:RFC 2960
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3309
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)
 
Authors:G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg.
Date:October 2002
Formats:txt ps json pdf html
Updated by:RFC 4032, RFC 5027
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3312
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
 
Authors:C. Jennings, J. Peterson, M. Watson.
Date:November 2002
Formats:txt html json
Updated by:RFC 5876, RFC 8217
Status:INFORMATIONAL
DOI:10.17487/RFC 3325
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)
 
Authors:H. Schulzrinne, D. Oran, G. Camarillo.
Date:December 2002
Formats:txt json html
Updated by:RFC 8606, RFC 9366
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3326
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
 
Authors:IANA.
Date:September 2002
Formats:txt html json
Obsoleted by:RFC 5735
Status:INFORMATIONAL
DOI:10.17487/RFC 3330
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
 
Authors:G. Klyne, C. Newman.
Date:July 2002
Formats:txt html json
Updated by:RFC 9557
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3339
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
 
Authors:C. Perkins, Ed..
Date:August 2002
Formats:txt json html
Obsoletes:RFC 3220
Obsoleted by:RFC 5944
Updated by:RFC 4636, RFC 4721
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3344
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
 
Authors:M. Rose.
Date:July 2002
Formats:txt json html
Also:BCP 0059
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3349
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
 
Authors:K. Zeilenga.
Date:March 2003
Formats:txt html json
Obsoletes:RFC 1798
Status:INFORMATIONAL
DOI:10.17487/RFC 3352
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
 
Authors:G. Fishman, S. Bradner.
Date:August 2002
Formats:txt html json
Obsoletes:RFC 2436
Obsoleted by:RFC 6756
Status:INFORMATIONAL
DOI:10.17487/RFC 3356
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
 
Authors:S. Floyd.
Date:August 2002
Formats:txt json html
Also:BCP 0060
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3360
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)
 
Authors:R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain.
Date:August 2002
Formats:txt html json
Updates:RFC 2673, RFC 2874
Updated by:RFC 6672
Status:INFORMATIONAL
DOI:10.17487/RFC 3363
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)
 
Authors:R. Austein.
Date:August 2002
Formats:txt json html
Updates:RFC 2673, RFC 2874
Status:INFORMATIONAL
DOI:10.17487/RFC 3364
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
 
Authors:J. Schiller.
Date:August 2002
Formats:txt json html
Also:BCP 0061
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3365
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)
 
Authors:G. Fairhurst, L. Wood.
Date:August 2002
Formats:txt html json
Also:BCP 0062
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3366
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)
 
Authors:R. Housley.
Date:August 2002
Formats:txt json html
Obsoletes:RFC 2630, RFC 3211
Obsoleted by:RFC 3852
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3369
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
 
Authors:R. Housley.
Date:August 2002
Formats:txt json html
Obsoletes:RFC 2630, RFC 3211
Updated by:RFC 5754, RFC 8702
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3370
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
 
Authors:D. Katz, R. Saluja.
Date:September 2002
Formats:txt html json
Obsoleted by:RFC 5303
Status:INFORMATIONAL
DOI:10.17487/RFC 3373
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
 
Authors:J. Hodges, R. Morgan.
Date:September 2002
Formats:txt html json
Obsoleted by:RFC 4510
Updates:RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3377
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
 
Authors:T. Hastings, R. Herriot, C. Kugler, H. Lewis.
Date:September 2002
Formats:txt json html
Updates:RFC 2910, RFC 2911
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3380
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
 
Authors:T. Hastings, H. Lewis, R. Bergman.
Date:September 2002
Formats:txt json html
Obsoleted by:RFC 8011
Updates:RFC 2910
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3381
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
 
Authors:R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler.
Date:September 2002
Formats:txt html json
Obsoleted by:RFC 8010, RFC 8011
Updates:RFC 2910, RFC 2911
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3382
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
 
Authors:M. Allman, S. Floyd, C. Partridge.
Date:October 2002
Formats:txt json html
Obsoletes:RFC 2414
Updates:RFC 2581
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3390
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
 
Authors:R. Chandra, J. Scudder.
Date:November 2002
Formats:txt html json
Obsoletes:RFC 2842
Obsoleted by:RFC 5492
Status:DRAFT STANDARD
DOI:10.17487/RFC 3392
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).