From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3599.txt | 1907 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1907 insertions(+) create mode 100644 doc/rfc/rfc3599.txt (limited to 'doc/rfc/rfc3599.txt') diff --git a/doc/rfc/rfc3599.txt b/doc/rfc/rfc3599.txt new file mode 100644 index 0000000..b52c0b8 --- /dev/null +++ b/doc/rfc/rfc3599.txt @@ -0,0 +1,1907 @@ + + + + + + +Network Working Group S. Ginoza +Request for Comments: 3599 ISI +Category: Informational December 2003 + + + Request for Comments Summary + + RFC Numbers 3500-3599 + +Status of This Memo + + This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 + through RFC 3599. This is a status report on these RFCs. This memo + provides information for the Internet community. It does not specify + an Internet standard of any kind. Distribution of this memo is + unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Note + + Many RFCs, but not all, are Proposed Standards, Draft Standards, or + Standards. Since the status of these RFCs may change during the + standards processing, we note here only that they are on the + standards track. Please see the latest edition of "Internet Official + Protocol Standards" for the current state and status of these RFCs. + In the following, RFCs on the standards track are marked [STANDARDS + TRACK]. + +RFC Author Date Title +--- ------ ---- ----- + +3599 Ginoza Request for Comments Summary + +This memo. + + +3598 Murchison Sep 2003 Sieve Email Filtering -- + Subaddress Extension + +On email systems that allow for "subaddressing" or "detailed addressing" +(e.g., "ken+sieve@example.org"), it is sometimes desirable to make +comparisons against these sub-parts of addresses. This document defines +an extension to the Sieve mail filtering language that allows users to +compare against the user and detail parts of an address. [STANDARDS +TRACK] + + + +Ginoza Informational [Page 1] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3597 Gustafsson Sep 2003 Handling of Unknown DNS + Resource Record (RR) Types + +Extending the Domain Name System (DNS) with new Resource Record (RR) +types currently requires changes to name server software. This document +specifies the changes necessary to allow future DNS implementations to +handle new RR types transparently. [STANDARDS TRACK] + + +3596 Thomson Oct 2003 DNS Extensions to Support IP + Version 6 + +This document defines the changes that need to be made to the Domain +Name System (DNS) to support hosts running IP version 6 (IPv6). The +changes include a resource record type to store an IPv6 address, a +domain to support lookups based on an IPv6 address, and updated +definitions of existing query types that return Internet addresses as +part of additional section processing. The extensions are designed to +be compatible with existing applications and, in particular, DNS +implementations themselves. [STANDARDS TRACK] + + +3595 Wijnen Sep 2003 Textual Conventions for IPv6 + Flow Label + +This MIB module defines textual conventions to represent the commonly +used IPv6 Flow Label. The intent is that these textual conventions +(TCs) will be imported and used in MIB modules that would otherwise +define their own representations. [STANDARDS TRACK] + + +3594 Duffy Sep 2003 PacketCable Security Ticket + Control Sub-Option for the + DHCP CableLabs Client + Configuration (CCC) Option + +This document defines a new sub-option for the DHCP CableLabs Client +Configuration (CCC) Option. This new sub-option will be used to direct +CableLabs Client Devices (CCDs) to invalidate security tickets stored in +CCD non volatile memory (i.e., locally persisted security tickets). +[STANDARDS TRACK] + + + + + + + + + + +Ginoza Informational [Page 2] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3593 Tesink, Ed. Sep 2003 Textual Conventions for MIB + Modules Using Performance + History Based on 15 Minute + Intervals + +This document defines a set of Textual Conventions for MIB modules that +make use of performance history data based on 15 minute intervals. + +This memo replaces RFC 2493. Changes relative to RFC 2493 are +summarized in the MIB module's REVISION clause. [STANDARDS TRACK] + + +3592 Tesink Sep 2003 Definitions of Managed Objects + for the Synchronous Optical + Network/Synchronous Digital + Hierarchy (SONET/SDH) + Interface Type + +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 Synchronous Optical +Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This +document is a companion to the documents that define Managed Objects for +the DS1/E1/DS2/E2 and DS3/E3 Interface Types. + +This memo replaces RFC 2558. Changes relative to RFC 2558 are +summarized in the MIB module's REVISION clause. [STANDARDS TRACK] + + +3591 Lam Sep 2003 Definitions of Managed Objects + for the Optical Interface Type + +This memo defines a portion of the Management Information Base (MIB) for +use with Simple Network Management Protocol (SNMP) in TCP/IP-based +internets. In particular, it defines objects for managing Optical +Interfaces associated with WavelengthDivision Multiplexing systems or +characterized by the Optical Transport Network (OTN) in accordance with +the OTN architecture defined in ITU-T Recommendation G.872. + +The MIB module defined in this memo can be used for performance +monitoring and/or configuration of such optical interface. [STANDARDS +TRACK] + + + + + + + + + +Ginoza Informational [Page 3] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3590 Haberman Sep 2003 Source Address Selection for + the Multicast Listener + Discovery (MLD) Protocol + +It has come to light that there is an issue with the selection of a +suitable IPv6 source address for Multicast Listener Discovery (MLD) +messages when a node is performing stateless address autoconfiguration. +This document is intended to clarify the rules on selecting an IPv6 +address to use for MLD messages. [STANDARDS TRACK] + + +3589 Loughney Sep 2003 Diameter Command Codes for + Third Generation Partnership + Project (3GPP) Release 5 + +This document describes the IANA's allocation of a block of Diameter +Command Codes for the Third Generation Partnership Project (3GPP) +Release 5. This document does not pass judgment on the usage of these +command codes. Further more, these command codes are for use for +Release 5. For future releases, these codes cannot be reused, but must +be allocated according to the Diameter Base specification. This memo +provides information for the Internet community. + + +3588 Calhoun Sep 2003 Diameter Base Protocol + +The Diameter base protocol is intended to provide an Authentication, +Authorization and Accounting (AAA) framework for applications such as +network access or IP mobility. Diameter is also intended to work in +both local Authentication, Authorization & Accounting and roaming +situations. This document specifies the message format, transport, +error reporting, accounting and security services to be used by all +Diameter applications. The Diameter base application needs to be +supported by all Diameter implementations. [STANDARDS TRACK] + + +3587 Hinden Aug 2003 IPv6 Global Unicast Address + Format + +This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast +Address Format". It defined an IPv6 address allocation structure that +includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). +This document makes RFC 2374 and the TLA/NLA structure historic. This +memo provides information for the Internet community. + + + + + + + +Ginoza Informational [Page 4] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3586 Blaze Aug 2003 IP Security Policy (IPSP) + Requirements + +This document describes the problem space and solution requirements for +developing an IP Security Policy (IPSP) configuration and management +framework. The IPSP architecture provides a scalable, decentralized +framework for managing, discovering and negotiating the host and network +security policies that govern access, authorization, authentication, +confidentiality, data integrity, and other IP Security properties. This +document highlights such architectural components and presents their +functional requirements. [STANDARDS TRACK] + + +3585 Jason Aug 2003 IPsec Configuration Policy + Information Model + +This document presents an object-oriented information model of IP +Security (IPsec) policy designed to facilitate agreement about the +content and semantics of IPsec policy, and enable derivations of task- +specific representations of IPsec policy such as storage schema, +distribution representations, and policy specification languages used to +configure IPsec-enabled endpoints. The information model described in +this document models the configuration parameters defined by IPSec. The +information model also covers the parameters found by the Internet Key +Exchange protocol (IKE). Other key exchange protocols could easily be +added to the information model by a simple extension. Further +extensions can further be added easily due to the object-oriented nature +of the model. + +This information model is based upon the core policy classes as defined +in the Policy Core Information Model (PCIM) and in the Policy Core +Information Model Extensions (PCIMe). [STANDARDS TRACK] + + +3584 Frye Aug 2003 Coexistence between Version 1, + Version 2, and Version 3 of + the Internet-standard Network + Management Framework + +The purpose of this document is to describe coexistence between version +3 of the Internet-standard Network Management Framework, (SNMPv3), +version 2 of the Internet-standard Network Management Framework +(SNMPv2), and the original Internet-standard Network Management +Framework (SNMPv1). This document also describes how to convert MIB +modules from SMIv1 format to SMIv2 format. This document obsoletes RFC +2576. This document specifies an Internet Best Current Practices for +the Internet Community, and requests discussion and suggestions for +improvements. + + + +Ginoza Informational [Page 5] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3583 Chaskar, Ed. Sep 2003 Requirements of a Quality of + Service (QoS) Solution for + Mobile IP + +Mobile IP ensures correct routing of packets to a mobile node as the +mobile node changes its point of attachment to the Internet. However, +it is also required to provide proper Quality of Service (QoS) +forwarding treatment to the mobile node's packet stream at the +intermediate nodes in the network, so that QoS-sensitive IP services can +be supported over Mobile IP. This document describes requirements for +an IP QoS mechanism for its satisfactory operation with Mobile IP. This +memo provides information for the Internet community. + + +3582 Abley Aug 2003 Goals for IPv6 + Site-Multihoming Architectures + +This document outlines a set of goals for proposed new IPv6 site- +multihoming architectures. It is recognised that this set of goals is +ambitious and that some goals may conflict with others. The solution or +solutions adopted may only be able to satisfy some of the goals +presented here. This memo provides information for the Internet +community. + + +3581 Rosenberg Aug 2003 An Extension to the Session + Initiation Protocol (SIP) for + Symmetric Response Routing + +The Session Initiation Protocol (SIP) operates over UDP and TCP, among +others. When used with UDP, responses to requests are returned to the +source address the request came from, and to the port written into the +topmost Via header field value of the request. This behavior is not +desirable in many cases, most notably, when the client is behind a +Network Address Translator (NAT). This extension defines a new +parameter for the Via header field, called "rport", that allows a client +to request that the server send the response back to the source IP +address and port from which the request originated. [STANDARDS TRACK] + + + + + + + + + + + + + +Ginoza Informational [Page 6] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3580 Congdon Sep 2003 IEEE 802.1X Remote + Authentication Dial In User + Service (RADIUS) Usage + Guidelines + +This document provides suggestions on Remote Authentication Dial In User +Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in +this document is also included within a non-normative Appendix within +the IEEE 802.1X specification, and is being presented as an IETF RFC for +informational purposes. This memo provides information for the Internet +community. + + +3579 Aboba Sep 2003 RADIUS (Remote Authentication + Dial In User Service) + Support For Extensible + Authentication Protocol (EAP) + +This document defines Remote Authentication Dial In User Service +(RADIUS) support for the Extensible Authentication Protocol (EAP), an +authentication framework which supports multiple authentication +mechanisms. In the proposed scheme, the Network Access Server (NAS) +forwards EAP packets to and from the RADIUS server, encapsulated within +EAP-Message attributes. This has the advantage of allowing the NAS to +support any EAP authentication method, without the need for method- +specific code, which resides on the RADIUS server. While EAP was +originally developed for use with PPP, it is now also in use with IEEE +802. This memo provides information for the Internet community. + + +3578 Camarillo Aug 2003 Mapping of Integrated Services + Digital Network (ISDN) User + Part (ISUP) Overlap Signalling + to the Session Initiation + Protocol (SIP) + + +This document describes a way to map Integrated Services Digital Network +User Part (ISUP) overlap signalling to Session Initiation Protocol +(SIP). 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). [STANDARDS TRACK] + + + + + + + + + +Ginoza Informational [Page 7] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3577 Waldbusser Aug 2003 Introduction to the Remote + Monitoring (RMON) Family of + MIB Modules + +The Remote Monitoring (RMON) Framework consists of a number of +interrelated documents. This memo describes these documents and how +they relate to one another. This memo provides information for the +Internet community. + + +3576 Chiba Jul 2003 Dynamic Authorization + Extensions to Remote + Authentication Dial In User + Service (RADIUS) + +This document describes a currently deployed extension to the Remote +Authentication Dial In User Service (RADIUS) protocol, allowing dynamic +changes to a user session, as implemented by network access server +products. This includes support for disconnecting users and changing +authorizations applicable to a user session. This memo provides +information for the Internet community. + + +3575 Aboba Jul 2003 IANA Considerations for RADIUS + (Remote Authentication Dial In + User Service) + +This document describes the IANA considerations for the Remote +Authentication Dial In User Service (RADIUS). [STANDARDS TRACK] + + +3574 Soininen, Ed. Aug 2003 Transition Scenarios for 3GPP + Networks + +This document describes different scenarios in Third Generation +Partnership Project (3GPP) defined packet network, i.e., General Packet +Radio Service (GPRS) that would need IP version 6 and IP version 4 +transition. The focus of this document is on the scenarios where the +User Equipment (UE) connects to nodes in other networks, e.g., in the +Internet. GPRS network internal transition scenarios, i.e., between +different GPRS elements in the network, are out of scope. The purpose +of the document is to list the scenarios for further discussion and +study. This memo provides information for the Internet community. + + + + + + + + +Ginoza Informational [Page 8] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3573 Goyret Jul 2003 Signaling of Modem-On-Hold + status in Layer 2 Tunneling + Protocol (L2TP) + +The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling +Point-to-Point Protocol (PPP) sessions. It is common for these PPP +sessions to be established using modems connected over the public +switched telephone network. + +One of the standards governing modem operation defines procedures that +enable a client modem to put the call on hold and later, re-establish +the modem link with minimal delay and without having to redial. While +the modem call is on hold, the client phone line can be used to place or +receive other calls. + +The L2TP base protocol does not provide any means to signal these events +from the L2TP Access Controller (LAC), where the modem is physically +connected, to the L2TP Network Server (LNS), where the PPP session is +handled. + +This document describes a method to let the LNS know when a client modem +connected to a LAC has placed the call on hold. [STANDARDS TRACK] + + +3572 Ogura Jul 2003 Internet Protocol Version 6 + over MAPOS (Multiple Access + Protocol Over SONET/SDH) + +Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- +layer protocol that provides multiple access capability over a +Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). + +This document specifies the frame format for encapsulating an IPv6 +datagram in a MAPOS frame. It also specifies the method of forming IPv6 +interface identifiers, the method of detecting duplicate addresses, and +the format of the Source/Target Link-layer Addresses option field used +in IPv6 Neighbor Discovery messages. This memo provides information for +the Internet community. + + +3571 Rawlins Aug 2003 Framework Policy Information + Base for Usage Feedback + +This document describes a portion of the Policy Information Base (PIB) +to control policy usage collection and reporting in a device. + + + + + + +Ginoza Informational [Page 9] + +RFC 3599 Summary of 3500-3599 December 2003 + + +The provisioning classes specified here allow a Policy Decision Point +(PDP) to select which policy objects should collect usage information, +what information should be collected and when it should be reported. + +This PIB requires the presence of other PIBs (defined elsewhere) that +provide the policy objects from which usage information is collected. +This memo provides information for the Internet community. + + +3570 Rzewski Jul 2003 Content Internetworking (CDI) + Scenarios + +In describing content internetworking as a technology targeted for use +in production networks, it is useful to provide examples of the sequence +of events that may occur when two content networks decide to +interconnect. The scenarios presented here seek to provide some +concrete examples of what content internetworking is, and also to +provide a basis for evaluating content internetworking proposals. This +memo provides information for the Internet community. + + +3569 Bhattacharyya Jul 2003 An Overview of Source-Specific + Multicast (SSM) + +The purpose of this document is to provide an overview of +Source-Specific Multicast (SSM) and issues related to its deployment. +It discusses how the SSM service model addresses the challenges faced in +inter-domain multicast deployment, changes needed to routing protocols +and applications to deploy SSM and interoperability issues with current +multicast service models. This memo provides information for the +Internet community. + + +3568 Barbir Jul 2003 Known Content Network (CN) + Request-Routing Mechanisms + +This document presents a summary of Request-Routing techniques that are +used to direct client requests to surrogates based on various policies +and a possible set of metrics. The document covers techniques that were +commonly used in the industry on or before December 2000. In this memo, +the term Request-Routing represents techniques that is commonly called +content routing or content redirection. In principle, Request-Routing +techniques can be classified under: DNS Request-Routing, Transport-layer +Request-Routing, and Application-layer Request-Routing. This memo +provides information for the Internet community. + + + + + + +Ginoza Informational [Page 10] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3567 Li Jul 2003 Intermediate System to + Intermediate System (IS-IS) + Cryptographic Authentication + +This document describes the authentication of Intermediate System to +Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed +Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as +found in RFC 2104. IS-IS is specified in International Standards +Organization (ISO) 10589, with extensions to support Internet Protocol +version 4 (IPv4) described in RFC 1195. The base specification includes +an authentication mechanism that allows for multiple authentication +algorithms. The base specification only specifies the algorithm for +cleartext passwords. + +This document proposes an extension to that specification that allows +the use of the HMAC-MD5 authentication algorithm to be used in +conjunction with the existing authentication mechanisms. This memo +provides information for the Internet community. + + +3566 Frankel Sep 2003 The AES-XCBC-MAC-96 Algorithm + and Its Use With IPsec + +A Message Authentication Code (MAC) is a key-dependent one way hash +function. One popular way to construct a MAC algorithm is to use a +block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of +operation. The classic CBC-MAC algorithm, while secure for messages of +a pre-selected fixed length, has been shown to be insecure across +messages of varying lengths such as the type found in typical IP +datagrams. This memo specifies the use of AES in CBC mode with a set of +extensions to overcome this limitation. This new algorithm is named +AES-XCBC-MAC-96. [STANDARDS TRACK] + + +3565 Schaad Jul 2003 Use of the Advanced Encryption + Standard (AES) Encryption + Algorithm in Cryptographic + Message Syntax (CMS) + +This document specifies the conventions for using the Advanced +Encryption Standard (AES) algorithm for encryption with the +Cryptographic Message Syntax (CMS). [STANDARDS TRACK] + + + + + + + + + +Ginoza Informational [Page 11] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3564 Le Faucheur Jul 2003 Requirements for Support of + Differentiated Services-aware + MPLS Traffic Engineering + +This document presents Service Provider requirements for support of +Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- +TE). + +Its objective is to provide guidance for the definition, selection and +specification of a technical solution addressing these requirements. +Specification for this solution itself is outside the scope of this +document. + +A problem statement is first provided. Then, the document describes +example applications scenarios identified by Service Providers where +existing MPLS Traffic Engineering mechanisms fall short and +Diff-Serv-aware Traffic Engineering can address the needs. The detailed +requirements that need to be addressed by the technical solution are +also reviewed. Finally, the document identifies the evaluation criteria +that should be considered for selection and definition of the technical +solution. This memo provides information for the Internet community. + + +3563 Zinin Jul 2003 Cooperative Agreement Between + the ISOC/IETF and ISO/IEC + Joint Technical Committee + 1/Sub Committee 6 (JTC1/SC6) + on IS-IS Routing Protocol + Development + +This document contains the text of the agreement signed between +ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the +IS-IS routing protocol. The agreement includes definitions of the +related work scopes for the two organizations, request for creation and +maintenance of an IS-IS registry by IANA, as well as collaboration +guidelines. This memo provides information for the Internet community. + + +3562 Leech Jul 2003 Key Management Considerations + for the TCP MD5 Signature + Option + +The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has +seen significant deployment in critical areas of Internet +infrastructure. The security of this option relies heavily on the +quality of the keying material used to compute the MD5 signature. This +document addresses the security requirements of that keying material. +This memo provides information for the Internet community. + + + +Ginoza Informational [Page 12] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3561 Perkins Jul 2003 Ad hoc On-Demand Distance + Vector (AODV) Routing + +The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended +for use by mobile nodes in an ad hoc network. It offers quick +adaptation to dynamic link conditions, low processing and memory +overhead, low network utilization, and determines unicast routes to +destinations within the ad hoc network. It uses destination sequence +numbers to ensure loop freedom at all times (even in the face of +anomalous delivery of routing control messages), avoiding problems (such +as "counting to infinity") associated with classical distance vector +protocols. This memo defines an Experimental Protocol for the Internet +community. + + +3560 Housley Jul 2003 Use of the RSAES-OAEP Key + Transport Algorithm in + the Cryptographic Message + Syntax (CMS) + +This document describes the conventions for using the RSAES-OAEP key +transport algorithm with the Cryptographic Message Syntax (CMS). The +CMS specifies the enveloped-data content type, which consists of an +encrypted content and encrypted content-encryption keys for one or more +recipients. The RSAES-OAEP key transport algorithm can be used to +encrypt content-encryption keys for intended recipients. [STANDARDS +TRACK] + + +3559 Thaler Jun 2003 Multicast Address Allocation + MIB + +This memo defines a portion of the Management Information Base (MIB) for +use with network management protocols in the Internet community. In +particular, it describes managed objects used for managing multicast +address allocation. [STANDARDS TRACK] + + + + + + + + + + + + + + + +Ginoza Informational [Page 13] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3558 Li Jul 2003 RTP Payload Format for + Enhanced Variable Rate Codecs + (EVRC) and Selectable Mode + Vocoders (SMV) + +This document describes the RTP payload format for Enhanced Variable +Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two +sub-formats are specified for different application scenarios. A +bundled/interleaved format is included to reduce the effect of packet +loss on speech quality and amortize the overhead of the RTP header over +more than one speech frame. A non-bundled format is also supported for +conversational applications. [STANDARDS TRACK] + + +3557 Xie, Ed. Jul 2003 RTP Payload Format for + European Telecommunications + Standards Institute (ETSI) + European Standard ES 201 108 + Distributed Speech Recognition + Encoding + +This document specifies an RTP payload format for encapsulating European +Telecommunications Standards Institute (ETSI) European Standard (ES) 201 +108 front-end signal processing feature streams for distributed speech +recognition (DSR) systems. [STANDARDS TRACK] + + +3556 Casner Jul 2003 Session Description Protocol + (SDP) Bandwidth Modifiers + for RTP Control Protocol + (RTCP) Bandwidth + +This document defines an extension to the Session Description Protocol +(SDP) to specify two additional modifiers for the bandwidth attribute. +These modifiers may be used to specify the bandwidth allowed for RTP +Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) +session. [STANDARDS TRACK] + + + + + + + + + + + + + + +Ginoza Informational [Page 14] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3555 Casner Jul 2003 MIME Type Registration of RTP + Payload Formats + +This document defines the procedure to register RTP Payload Formats as +audio, video or other MIME subtype names. This is useful in a text- +based format or control protocol to identify the type of an RTP +transmission. This document also registers all the RTP payload formats +defined in the RTP Profile for Audio and Video Conferences as MIME +subtypes. Some of these may also be used for transfer modes other than +RTP. [STANDARDS TRACK] + + +3554 Bellovin Jul 2003 On the Use of Stream Control + Transmission Protocol (SCTP) + with IPsec + +This document describes functional requirements for IPsec (RFC 2401) and +Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in +securing SCTP (RFC 2960) traffic. [STANDARDS TRACK] + + +3553 Mealling Jun 2003 An IETF URN Sub-namespace for + Registered Protocol Parameters + +This document describes a new sub-delegation for the 'ietf' URN +namespace for registered protocol items. The 'ietf' URN namespace is +defined in RFC 2648 as a root for persistent URIs that refer to IETF- +defined resources. This document specifies an Internet Best Current +Practices for the Internet Community, and requests discussion and +suggestions for improvements. + + +3552 Rescorla Jul 2003 Guidelines for Writing RFC + Text on Security + Considerations + +All RFCs are required to have a Security Considerations section. +Historically, such sections have been relatively weak. This document +provides guidelines to RFC authors on how to write a good Security +Considerations section. This document specifies an Internet Best +Current Practices for the Internet Community, and requests discussion +and suggestions for improvements. + + + + + + + + + +Ginoza Informational [Page 15] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3551 Schulzrinne Jul 2003 RTP Profile for Audio and + Video Conferences with Minimal + Control + +This document describes a profile called "RTP/AVP" for the use of the +real-time transport protocol (RTP), version 2, and the associated +control protocol, RTCP, within audio and video multiparticipant +conferences with minimal control. It provides interpretations of +generic fields within the RTP specification suitable for audio and video +conferences. In particular, this document defines a set of default +mappings from payload type numbers to encodings. + +This document also describes how audio and video data may be carried +within RTP. It defines a set of standard encodings and their names when +used within RTP. The descriptions provide pointers to reference +implementations and the detailed standards. This document is meant as +an aid for implementors of audio, video and other real-time multimedia +applications. + +This memorandum obsoletes RFC 1890. It is mostly backwards-compatible +except for functions removed because two interoperable implementations +were not found. The additions to RFC 1890 codify existing practice in +the use of payload formats under this profile and include new payload +formats defined since RFC 1890 was published. [STANDARDS TRACK] + + +3550 Schulzrinne Jul 2003 RTP: A Transport Protocol for + Real-Time Applications + +This memorandum describes RTP, the real-time transport protocol. RTP +provides end-to-end network transport functions suitable for +applications transmitting real-time data, such as audio, video or +simulation data, over multicast or unicast network services. RTP does +not address resource reservation and does not guarantee quality-of- +service for real-time services. The data transport is augmented by a +control protocol (RTCP) to allow monitoring of the data delivery in a +manner scalable to large multicast networks, and to provide minimal +control and identification functionality. RTP and RTCP are designed to +be independent of the underlying transport and network layers. The +protocol supports the use of RTP-level translators and mixers. + +Most of the text in this memorandum is identical to RFC 1889 which it +obsoletes. There are no changes in the packet formats on the wire, only +changes to the rules and algorithms governing how the protocol is used. +The biggest change is an enhancement to the scalable timer algorithm for +calculating when to send RTCP packets in order to minimize transmission +in excess of the intended rate when many participants join a session +simultaneously. [STANDARDS TRACK] + + + +Ginoza Informational [Page 16] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3549 Salim Jul 2003 Linux Netlink as an IP + Services Protocol + +This document describes Linux Netlink, which is used in Linux both as an +intra-kernel messaging system as well as between kernel and user space. +The focus of this document is to describe Netlink's functionality as a +protocol between a Forwarding Engine Component (FEC) and a Control Plane +Component (CPC), the two components that define an IP service. As a +result of this focus, this document ignores other uses of Netlink, +including its use as a intra-kernel messaging system, as an inter- +process communication scheme (IPC), or as a configuration tool for other +non-networking or non-IP network services (such as decnet, etc.). + +This document is intended as informational in the context of prior art +for the ForCES IETF working group. This memo provides information for +the Internet community. + + +3548 Josefsson Jul 2003 The Base16, Base32, and Base64 + Data Encodings + +This document describes the commonly used base 64, base 32, and base 16 +encoding schemes. It also discusses the use of line-feeds in encoded +data, use of padding in encoded data, use of non-alphabet characters in +encoded data, and use of different encoding alphabets. This memo +provides information for the Internet community. + + +3547 Baugher Jul 2003 The Group Domain of + Interpretation + +This document presents an ISAMKP Domain of Interpretation (DOI) for +group key management to support secure group communications. The GDOI +manages group security associations, which are used by IPSEC and +potentially other data security protocols running at the IP or +application layers. These security associations protect one or more +key-encrypting keys, traffic-encrypting keys, or data shared by group +members. [STANDARDS TRACK] + + + + + + + + + + + + + +Ginoza Informational [Page 17] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3546 Blake-Wilson Jun 2003 Transport Layer Security (TLS) + Extensions + + +This document describes extensions that may be used to add functionality +to Transport Layer Security (TLS). It provides both generic extension +mechanisms for the TLS handshake client and server hellos, and specific +extensions using these generic mechanisms. + +The extensions may be used by TLS clients and servers. The extensions +are backwards compatible - communication is possible between TLS 1.0 +clients that support the extensions and TLS 1.0 servers that do not +support the extensions, and vice versa. [STANDARDS TRACK] + + +3545 Koren Jul 2003 Enhanced Compressed RTP (CRTP) + for Links with High Delay, + Packet Loss and Reordering + +This document describes a header compression scheme for point to point +links with packet loss and long delays. It is based on Compressed +Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression +described in RFC 2508. CRTP does not perform well on such links: packet +loss results in context corruption and due to the long delay, many more +packets are discarded before the context is repaired. To correct the +behavior of CRTP over such links, a few extensions to the protocol are +specified here. The extensions aim to reduce context corruption by +changing the way the compressor updates the context at the decompressor: +updates are repeated and include updates to full and differential +context parameters. With these extensions, CRTP performs well over +links with packet loss, packet reordering and long delays. [STANDARDS +TRACK] + + +3544 Koren Jul 2003 IP Header Compression over PPP + +This document describes an option for negotiating the use of header +compression on IP datagrams transmitted over the Point-to-Point Protocol +(RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 +and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to +IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport +protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS +TRACK] + + + + + + + + +Ginoza Informational [Page 18] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3543 Glass Aug 2003 Registration Revocation in + Mobile IPv4 + +This document defines a Mobile IPv4 Registration Revocation mechanism +whereby a mobility agent involved in providing Mobile IP services to a +mobile node can notify the other mobility agent providing Mobile IP +services to the same mobile node of the termination of this +registration. The mechanism is also usable by a home agent to notify a +co-located mobile node of the termination of its binding as well. +Moreover, the mechanism provides for this notification to be +acknowledged. A signaling mechanism already defined by the Mobile IPv4 +protocol is leveraged as a way to inform a mobile node of the revocation +of its binding. [STANDARDS TRACK] + + +3542 Stevens May 2003 Advanced Sockets Application + Program Interface (API) for + IPv6 + +This document provides sockets Application Program Interface (API) to +support "advanced" IPv6 applications, as a supplement to a separate +specification, RFC 3493. The expected applications include Ping, +Traceroute, routing daemons and the like, which typically use raw +sockets to access IPv6 or ICMPv6 header fields. This document proposes +some portable interfaces for applications that use raw sockets under +IPv6. There are other features of IPv6 that some applications will need +to access: interface identification (specifying the outgoing interface +and determining the incoming interface), IPv6 extension headers, and +path Maximum Transmission Unit (MTU) information. This document +provides API access to these features too. Additionally, some extended +interfaces to libraries for the "r" commands are defined. The extension +will provide better backward compatibility to existing implementations +that are not IPv6-capable. This memo provides information for the +Internet community. + + +3541 Walsh May 2003 A Uniform Resource Name (URN) + Namespace for the Web3D + Consortium (Web3D) + +This document describes a Uniform Resource Name (URN) namespace for the +Web3D Consortium (Web3D) for naming persistent resources such as +technical documents and specifications, Virtual Reality Modeling +Language (VRML) and Extensible 3D (X3D) files and resources, Extensible +Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, +namespaces, style sheets, media assets, and other resources produced or +managed by Web3D. This memo provides information for the Internet +community. + + + +Ginoza Informational [Page 19] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3540 Spring Jun 2003 Robust Explicit Congestion + Notification (ECN) + Signaling with Nonces + +This note describes the Explicit Congestion Notification (ECN)-nonce, an +optional addition to ECN that protects against accidental or malicious +concealment of marked packets from the TCP sender. It improves the +robustness of congestion control by preventing receivers from exploiting +ECN to gain an unfair share of network bandwidth. The ECN-nonce uses +the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP +header, and requires a flag in the TCP header. It is computationally +efficient for both routers and hosts. This memo defines an Experimental +Protocol for the Internet community. + + +3539 Aboba Jun 2003 Authentication, Authorization + and Accounting (AAA) Transport + Profile + +This document discusses transport issues that arise within protocols for +Authentication, Authorization and Accounting (AAA). It also provides +recommendations on the use of transport by AAA protocols. This includes +usage of standards-track RFCs as well as experimental proposals. +[STANDARDS TRACK] + + +3538 Kawatsura Jun 2003 Secure Electronic Transaction + (SET) Supplement for the v1.0 + Internet Open Trading Protocol + (IOTP) + +This document describes detailed Input/Output parameters for the +Internet Open Trading Protocol (IOTP) Payment Application Programming +Interface (API). It also describes procedures in the Payment Bridge for +the use of SET (SET Secure Electronic Transaction) as the payment +protocol within Version 1.0 of the IOTP. This memo provides information +for the Internet community. + + + + + + + + + + + + + + +Ginoza Informational [Page 20] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3537 Schaad May 2003 Wrapping a Hashed Message + Authentication Code (HMAC) key + with a Triple-Data Encryption + Standard (DES) Key or an + Advanced Encryption Standard + (AES) Key + +This document defines two methods for wrapping an HMAC (Hashed Message +Authentication Code) key. The first method defined uses a Triple DES +(Data Encryption Standard) key to encrypt the HMAC key. The second +method defined uses an AES (Advanced Encryption Standard) key to encrypt +the HMAC key. One place that such an algorithm is used is for the +Authenticated Data type in CMS (Cryptographic Message Syntax). +[PROPOSED STANDARD] + + +3536 Hoffman May 2003 Terminology Used in + Internationalization in the + IETF + +This document provides a glossary of terms used in the IETF when +discussing internationalization. The purpose is to help frame +discussions of internationalization in the various areas of the IETF and +to help introduce the main concepts to IETF participants. This memo +provides information for the Internet community. + + +3535 Schoenwaelder May 2003 Overview of the 2002 IAB + Network Management + Workshop + +This document provides an overview of a workshop held by the Internet +Architecture Board (IAB) on Network Management. The workshop was hosted +by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the +workshop was to continue the important dialog started between network +operators and protocol developers, and to guide the IETFs focus on +future work regarding network management. This report summarizes the +discussions and lists the conclusions and recommendations to the +Internet Engineering Task Force (IETF) community. This memo provides +information for the Internet community. + + + + + + + + + + + +Ginoza Informational [Page 21] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3534 Walleij May 2003 The application/ogg Media + Type + +The Ogg Bitstream Format aims at becoming a general, freely-available +standard for transporting multimedia content across computing platforms +and networks. The intention of this document is to define the MIME +media type application/ogg to refer to this kind of content when +transported across the Internet. It is the intention of the Ogg +Bitstream Format developers that it be usable without intellectual +property concerns. [STANDARDS TRACK] + + +3533 Pfeiffer May 2003 The Ogg Encapsulation + Format Version 0 +This document describes the Ogg bitstream format version 0, which is a +general, freely-available encapsulation format for media streams. It is +able to encapsulate any kind and number of video and audio encoding +formats as well as other data streams in a single bitstream. This memo +provides information for the Internet community. This memo provides +information for the Internet community. + + +3532 Anderson May 2003 Requirements for the Dynamic + Partitioning of Switching + Elements + +This document identifies a set of requirements for the mechanisms used +to dynamically reallocate the resources of a switching element (e.g., an +ATM switch) to its partitions. These requirements are particularly +critical in the case of an operator creating a switch partition and then +leasing control of that partition to a third party. This memo provides +information for the Internet community. + + + + + + + + + + + + + + + + + + + +Ginoza Informational [Page 22] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3531 Blanchet Apr 2003 A Flexible Method for Managing + the Assignment of Bits of an + IPv6 Address Block + +This document proposes a method to manage the assignment of bits of an +IPv6 address block or range. When an organisation needs to make an +address plan for its subnets or when an ISP needs to make an address +plan for its customers, this method enables the organisation to postpone +the final decision on the number of bits to partition in the address +space they have. It does it by keeping the bits around the borders of +the partition to be free as long as possible. This scheme is applicable +to any bits addressing scheme using bits with partitions in the space, +but its first intended use is for IPv6. It is a generalization of RFC +1219 and can be used for IPv6 assignments. This memo provides +information for the Internet community. + + +3530 Shepler Apr 2003 Network File System (NFS) + version 4 Protocol + +The Network File System (NFS) version 4 is a distributed filesystem +protocol which owes heritage to NFS protocol version 2, RFC 1094, and +version 3, RFC 1813. Unlike earlier versions, the NFS version 4 +protocol supports traditional file access while integrating support for +file locking and the mount protocol. In addition, support for strong +security (and its negotiation), compound operations, client caching, and +internationalization have been added. Of course, attention has been +applied to making NFS version 4 operate well in an Internet environment. + +This document replaces RFC 3010 as the definition of the NFS version 4 +protocol. [STANDARDS TRACK] + + +3529 Harold Apr 2003 XML-RPC is an Extensible + +Markup Language-Remote Procedure Calling protocol that works over the +Internet. It defines an XML format for messages that are transfered +between clients and servers using HTTP. An XML-RPC message encodes +either a procedure to be invoked by the server, along with the +parameters to use in the invocation, or the result of an invocation. +Procedure parameters and results can be scalars, numbers, strings, +dates, etc.; they can also be complex record and list structures. + +This document specifies a how to use the Blocks Extensible Exchange +Protocol (BEEP) to transfer messages encoded in the XML-RPC format +between clients and servers. This memo defines an Experimental Protocol +for the Internet community. + + + + +Ginoza Informational [Page 23] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3528 Zhao Apr 2003 Mesh-enhanced Service Location + Protocol (mSLP) + +This document describes the Mesh-enhanced Service Location Protocol +(mSLP). mSLP enhances the Service Location Protocol (SLP) with a +scope-based fully-meshed peering Directory Agent (DA) architecture. +Peer DAs exchange new service registrations in shared scopes via anti- +entropy and direct forwarding. mSLP improves the reliability and +consistency of SLP DA services, and simplifies Service Agent (SA) +registrations in systems with multiple DAs. mSLP is backward compatible +with SLPv2 and can be deployed incrementally. This memo defines an +Experimental Protocol for the Internet community. + + +3527 Kinnear Apr 2003 Link Selection sub-option + for the Relay Agent + Information Option for DHCPv4 + +This document describes the link selection sub-option of the relay- +agent-information option for the Dynamic Host Configuration Protocol +(DHCPv4). The giaddr specifies an IP address which determines both a +subnet, and thereby a link on which a Dynamic Host Configuration +Protocol (DHCP) client resides as well as an IP address that can be used +to communicate with the relay agent. The subnet-selection option allows +the functions of the giaddr to be split so that when one entity is +performing as a DHCP proxy, it can specify the subnet/link from which to +allocate an IP address, which is different from the IP address with +which it desires to communicate with the DHCP server. Analogous +situations exist where the relay agent needs to specify the subnet/link +on which a DHCP client resides, which is different from an IP address +that can be used to communicate with the relay agent. [STANDARDS TRACK] + + +3526 Kivinen May 2003 More Modular Exponential + (MODP) Diffie-Hellman groups + for Internet Key Exchange + (IKE) + +This document defines new Modular Exponential (MODP) Groups for the +Internet Key Exchange (IKE) protocol. It documents the well known and +used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and +8192 bit Diffie-Hellman groups numbered starting at 14. The selection +of the primes for theses groups follows the criteria established by +Richard Schroeppel. [STANDARDS TRACK] + + + + + + + +Ginoza Informational [Page 24] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3525 Groves Jun 2003 Gateway Control Protocol + Version 1 + +This document defines the protocol used between elements of a physically +decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway +Controller. The protocol presented in this document meets the +requirements for a media gateway control protocol as presented in RFC +2805. + +This document replaces RFC 3015. It is the result of continued +cooperation between the IETF Megaco Working Group and ITU-T Study Group +16. It incorporates the original text of RFC 3015, modified by +corrections and clarifications discussed on the Megaco +E-mail list and incorporated into the Study Group 16 Implementor's Guide +for Recommendation H.248. The present version of this document +underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because +of ITU-T renumbering, it was published by the ITU-T as Recommendation +H.248.1 (03/2002), Gateway Control Protocol Version 1. + +Users of this specification are advised to consult the H.248 Sub-series +Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for +additional corrections and clarifications. [STANDARDS TRACK] + + +3524 Camarillo Apr 2003 Mapping of Media Streams to + Resource Reservation Flows + +This document defines an extension to the Session Description Protocol +(SDP) grouping framework. It allows requesting a group of media streams +to be mapped into a single resource reservation flow. The SDP syntax +needed is defined, as well as a new "semantics" attribute called Single +Reservation Flow (SRF). [STANDARDS TRACK] + + +3523 Polk Apr 2003 Internet Emergency + Preparedness (IEPREP) + Telephony Topology Terminology + +This document defines the topology naming conventions that are to be +used in reference to Internet Emergency Preparedness (IEPREP) phone +calls. These naming conventions should be used to focus the IEPREP +Working Group during discussions and when writing requirements, gap +analysis and other solutions documents. This memo provides information +for the Internet community. + + + + + + + +Ginoza Informational [Page 25] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3522 Ludwig Apr 2003 The Eifel Detection Algorithm + for TCP + +The Eifel detection algorithm allows a TCP sender to detect a posteriori +whether it has entered loss recovery unnecessarily. It requires that +the TCP Timestamps option defined in RFC 1323 be enabled for a +connection. The Eifel detection algorithm makes use of the fact that +the TCP Timestamps option eliminates the retransmission ambiguity in +TCP. Based on the timestamp of the first acceptable ACK that arrives +during loss recovery, it decides whether loss recovery was entered +unnecessarily. The Eifel detection algorithm provides a basis for +future TCP enhancements. This includes response algorithms to back out +of loss recovery by restoring a TCP sender's congestion control state. +This memo defines an Experimental Protocol for the Internet community. + + +3521 Hamer Apr 2003 Framework for Session Set-up + with Media Authorization + +Establishing multimedia streams must take into account requirements for +end-to-end QoS, authorization of network resource usage and accurate +accounting for resources used. During session set up, policies may be +enforced to ensure that the media streams being requested lie within the +bounds of the service profile established for the requesting host. +Similarly, when a host requests resources to provide a certain QoS for a +packet flow, policies may be enforced to ensure that the required +resources lie within the bounds of the resource profile established for +the requesting host. + +To prevent fraud and to ensure accurate billing, this document describes +various scenarios and mechanisms that provide the linkage required to +verify that the resources being used to provide a requested QoS are in- +line with the media streams requested (and authorized) for the session. +This memo provides information for the Internet community. + + + + + + + + + + + + + + + + + +Ginoza Informational [Page 26] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3520 Hamer Apr 2003 Session Authorization Policy + Element + +This document describes the representation of a session authorization +policy element for supporting policy-based per-session authorization and +admission control. The goal of session authorization is to allow the +exchange of information between network elements in order to authorize +the use of resources for a service and to co-ordinate actions between +the signaling and transport planes. This document describes how a +process on a system authorizes the reservation of resources by a host +and then provides that host with a session authorization policy element +which can be inserted into a resource reservation protocol (e.g., the +Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper +and secure reservation of those resources within the network. We +describe the encoding of session authorization information as a policy +element conforming to the format of a Policy Data object (RFC 2750) and +provide details relating to operations, processing rules and error +scenarios. [STANDARDS TRACK] + + +3519 Levkowetz May 2003 Mobile IP Traversal of Network + Address Translation (NAT) + Devices + +Mobile IP's datagram tunnelling is incompatible with Network Address +Translation (NAT). This document presents extensions to the Mobile IP +protocol and a tunnelling method which permits mobile nodes using Mobile +IP to operate in private address networks which are separated from the +public internet by NAT devices. The NAT traversal is based on using the +Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS +TRACK] + + +3518 Higashiyama Apr 2003 Point-to-Point Protocol (PPP) + Bridging Control Protocol + (BCP) + + +The Point-to-Point Protocol (PPP) provides a standard method for +transporting multi-protocol datagrams over point-to-point links. PPP +defines an extensible Link Control Protocol (LCP) and proposes a family +of Network Control Protocols (NCP) for establishing and configuring +different network-layer protocols. + +This document defines the NCP for establishing and configuring Remote +Bridging for PPP links. + + + + + +Ginoza Informational [Page 27] + +RFC 3599 Summary of 3500-3599 December 2003 + + +This document obsoletes RFC 2878, which was based on the IEEE 802.1D- +1993 MAC Bridge. This document extends that specification by improving +support for bridge control packets. [STANDARDS TRACK] + + +3517 Blanton Apr 2003 A Conservative Selective + Acknowledgment (SACK)-based + Loss Recovery Algorithm for + TCP + +This document presents a conservative loss recovery algorithm for TCP +that is based on the use of the selective acknowledgment (SACK) TCP +option. The algorithm presented in this document conforms to the spirit +of the current congestion control specification (RFC 2581), but allows +TCP senders to recover more effectively when multiple segments are lost +from a single flight of data. [STANDARDS TRACK] + + +3516 Nerenberg Apr 2003 IMAP4 Binary Content Extension + +This memo defines the Binary extension to the Internet Message Access +Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers +to exchange message body data without using a MIME content-transfer- +encoding. [STANDARDS TRACK] + + +3515 Sparks Apr 2003 The Session Initiation + Protocol (SIP) Refer Method + +This document defines the REFER method. This Session Initiation +Protocol (SIP) extension requests that the recipient REFER to a resource +provided in the request. It provides a mechanism allowing the party +sending the REFER to be notified of the outcome of the referenced +request. This can be used to enable many applications, including call +transfer. + +In addition to the REFER method, this document defines the refer event +package and the Refer-To request header. [STANDARDS TRACK] + + +3514 Bellovin 1 Apr 2003 The Security Flag in the IPv4 + Header + +Firewalls, packet filters, intrusion detection systems, and the like +often have difficulty distinguishing between packets that have malicious +intent and those that are merely unusual. We define a security flag in +the IPv4 header as a means of distinguishing the two cases. This memo +provides information for the Internet community. + + + +Ginoza Informational [Page 28] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3513 Hinden Apr 2003 Internet Protocol Version 6 + (IPv6) Addressing Architecture + +This specification defines the addressing architecture of the IP Version +6 (IPv6) protocol. The document includes the IPv6 addressing model, +text representations of IPv6 addresses, definition of IPv6 unicast +addresses, anycast addresses, and multicast addresses, and an IPv6 +node's required addresses. [STANDARDS TRACK] + + +3512 MacFaden Apr 2003 Configuring Networks and + Devices with Simple Network + Management Protocol (SNMP) + +This document is written for readers interested in the Internet Standard +Management Framework and its protocol, the Simple Network Management +Protocol (SNMP). In particular, it offers guidance in the effective use +of SNMP for configuration management. This information is relevant to +vendors that build network elements, management application developers, +and those that acquire and deploy this technology in their networks. +This memo provides information for the Internet community. + + +3511 Hickman Apr 2003 Benchmarking Methodology for + Firewall Performance + +This document discusses and defines a number of tests that may be used +to describe the performance characteristics of firewalls. In addition +to defining the tests, this document also describes specific formats for +reporting the results of the tests. + +This document is a product of the Benchmarking Methodology Working Group +(BMWG) of the Internet Engineering Task Force (IETF). This memo +provides information for the Internet community. + + +3510 Herriot Apr 2003 Internet Printing + Protocol/1.1: + IPP URL Scheme + +This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This +memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding +and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL +is used to specify the network location of a print service that supports +the IPP Protocol (RFC 2910), or of a network resource (for example, a +print job) managed by such a print service. [STANDARDS TRACK] + + + + + +Ginoza Informational [Page 29] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3509 Zinin Apr 2003 Alternative Implementations of + OSPF Area Border Routers + +Open Shortest Path First (OSPF) is a link-state intra-domain routing +protocol used for routing in IP networks. Though the definition of the +Area Border Router (ABR) in the OSPF specification does not require a +router with multiple attached areas to have a backbone connection, it is +actually necessary to provide successful routing to the inter-area and +external destinations. If this requirement is not met, all traffic +destined for the areas not connected to such an ABR or out of the OSPF +domain, is dropped. This document describes alternative ABR behaviors +implemented in Cisco and IBM routers. This memo provides information +for the Internet community. + + +3508 Levin Apr 2003 H.323 Uniform Resource Locator + (URL) Scheme Registration + +ITU-T Recommendation H.323 version 4 introduced an H.323-specific +Uniform Resource Locator (URL). This document reproduces the H323-URL +definition found in H.323, and is published as an RFC for ease of access +and registration with the Internet Assigned Numbers Authority (IANA). +This memo provides information for the Internet community. + + +3507 Elson Apr 2003 Internet Content Adaptation + Protocol (ICAP) + +ICAP, the Internet Content Adaption Protocol, is a protocol aimed at +providing simple object-based content vectoring for HTTP services. ICAP +is, in essence, a lightweight protocol for executing a "remote procedure +call" on HTTP messages. It allows ICAP clients to pass HTTP messages to +ICAP servers for some sort of transformation or other processing +("adaptation"). The server executes its transformation service on +messages and sends back responses to the client, usually with modified +messages. Typically, the adapted messages are either HTTP requests or +HTTP responses. This memo provides information for the Internet +community. + + + + + + + + + + + + + +Ginoza Informational [Page 30] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3506 Fujimura Mar 2003 Requirements and Design for + Voucher Trading System (VTS) + + +Crediting loyalty points and collecting digital coupons or gift +certificates are common functions in purchasing and trading +transactions. These activities can be generalized using the concept of +a "voucher", which is a digital representation of the right to claim +goods or services. This document presents a Voucher Trading System +(VTS) that circulates vouchers securely and its terminology; it lists +design principles and requirements for VTS and the Generic Voucher +Language (GVL), with which diverse types of vouchers can be described. +This memo provides information for the Internet community. + + +3505 Eastlake Mar 2003 Electronic Commerce Modeling + Language (ECML): Version 2 + Requirements + +This document lists the design principles, scope, and requirements for +the Electronic Commerce Modeling Language (ECML) version 2 +specification. It includes requirements as they relate to Extensible +Markup Language (XML) syntax, data model, format, and payment +processing. This memo provides information for the Internet community. + + +3504 Eastlake Mar 2003 Internet Open Trading Protocol + (IOTP) Version 1, Errata + +Since the publication of the RFCs specifying Version 1.0 of the Internet +Open Trading Protocol (IOTP), some errors have been noted. This +informational document lists these errors and provides corrections for +them. This memo provides information for the Internet community. + + +3503 Melnikov Mar 2003 Message Disposition + Notification (MDN) profile for + Internet Message Access + Protocol (IMAP) + +The Message Disposition Notification (MDN) facility defined in RFC 2298 +provides a means by which a message can request that message processing +by the recipient be acknowledged as well as a format to be used for such +acknowledgements. However, it doesn't describe how multiple Mail User +Agents (MUAs) should handle the generation of MDNs in an Internet +Message Access Protocol (IMAP4) environment. + + + + + +Ginoza Informational [Page 31] + +RFC 3599 Summary of 3500-3599 December 2003 + + +This document describes how to handle MDNs in such an environment and +provides guidelines for implementers of IMAP4 that want to add MDN +support to their products. [STANDARDS TRACK] + + +3502 Crispin Mar 2003 Internet Message Access + Protocol (IMAP) - MULTIAPPEND + Extension + +This document describes the multiappending extension to the Internet +Message Access Protocol (IMAP) (RFC 3501). This extension provides +substantial performance improvements for IMAP clients which upload +multiple messages at a time to a mailbox on the server. + +A server which supports this extension indicates this with a capability +name of "MULTIAPPEND". [STANDARDS TRACK] + + +3501 Crispin Mar 2003 INTERNET MESSAGE ACCESS + PROTOCOL - VERSION 4rev1 + +The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a +client to access and manipulate electronic mail messages on a server. +IMAP4rev1 permits manipulation of mailboxes (remote message folders) in +a way that is functionally equivalent to local folders. IMAP4rev1 also +provides the capability for an offline client to resynchronize with the +server. + +IMAP4rev1 includes operations for creating, deleting, and renaming +mailboxes, checking for new messages, permanently removing messages, +setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, +and selective fetching of message attributes, texts, and portions +thereof. Messages in IMAP4rev1 are accessed by the use of numbers. +These numbers are either message sequence numbers or unique identifiers. + +IMAP4rev1 supports a single server. A mechanism for accessing +configuration information to support multiple IMAP4rev1 servers is +discussed in RFC 2244. + +IMAP4rev1 does not specify a means of posting mail; this function is +handled by a mail transfer protocol such as RFC 2821. [STANDARDS TRACK] + + + + + + + + + + +Ginoza Informational [Page 32] + +RFC 3599 Summary of 3500-3599 December 2003 + + +3500 Never Issued + +RFC 3500 was never issued. + + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Sandy Ginoza + University of Southern California + Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: (310) 822-1511 + EMail: ginoza@isi.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ginoza Informational [Page 33] + +RFC 3599 Summary of 3500-3599 December 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ginoza Informational [Page 34] + -- cgit v1.2.3