Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. The Internet and the Millennium Problem (2000) ---------------------------------------------- "The Internet and the Millenium Problem (Year 2000)", Philip Nesser II, 11/16/1998, The Year 2000 Working Group(WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of 'period' problems were discovered, where a time field would 'roll over' as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. Application Configuration Access Protocol (acap) ------------------------------------------------ "ACAP TYPE Extension", R. Earhart, 03/13/1998, The Application Configuration Access Protocol [ACAP] defines rough typing information in the form of an attribute naming convention. This extension to ACAP allows a MIME content-type/subtype with parameters to be associated with a given piece of data, providing knowledgeable clients with useful information in a way which maintains compatability with innocent clients and servers. "ACAP Authorization Identifier Datasets Classes", S. Hole, 03/12/1998, Most distributed (client/server) applications require an authentication process between the client and the server before the server will grant access to its managed resources. Many applications provide varying levels of access to server resources based on a combination of authentication credentials and access control rules. The collection of information used to control access to resources is called ''authorization information''. "ACAP Personal Addressbook Dataset Class", Steven Hubert, Chris Newman, 03/05/1998, IMAP [IMAP4] allows nomadic users to access their mail store from any client, but it does not support storage of personal addressbooks. Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of personal addressbooks. While ACAP permits the definition of vendor specific solutions to this problem, having a standard addressbook dataset class permits clients from different vendors to interoperably share the same personal addressbooks. This specification defines a standard dataset class for personal addressbooks. "ACAP Application Options Dataset Class", S. Hole, 03/05/1998, The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of application option, configuration and preference information. The generalized form of this runtime configuration is called ''options''. Options consist of any type of structured or unstructured data that an application requires to operate in a user specific manner. "ACAP Media Type Dataset Class", Chris Newman, 03/05/1998, With the definition of standardized media types in MIME [MIME-IMT] it has become necessary to keep mapping tables which translate between the standard media type names, commonly used file name extensions, any platform specific typing mechanism, and helper applications to view, compose, edit or print media types. Supplying a set of site defaults is useful so that users won't have to configure well-known types. The mailcap mechanism [MAILCAP] provides some of this functionality in a homogeneous environment with a shared file system, and both the Macintosh program ''Internet Config'' and the Windows Registry have had some success in consolidating these tables for multiple applications on a single machine. But neither of these addresses the problems of multi- platform users or a heterogeneous environment. ACAP provides precisely the right facilities for this need. ACAP's dataset structure is extensible and ACAP's inheritance feature is ideal for enterprise default settings with per-user customization. "ACAP personal dictionary dataset class", Cyrus Daboo, 03/12/1998, The Application Configuration Access Protocol [ACAP] is designed to support remote storage and access of common application option, configuration and preference information. Its main benefits are in providing a way for users to gain access to personal information from any computer at a location supporting an internet connection, by keeping this information stored centrally on a server. Additionally, it allows 'kiosk' style use of computers so that users do not need to store data locally on a shared or public workstation or network computer. This specification defines a standard dataset class for personal dictionaries that would allow users to keep one or more 'user dictionaries' stored on an ACAP server for access by any ACAP-aware application that requires such information, for example any application that uses a spell checker. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for the ADSL Lines", F. Ly, Greg Bathrick, 11/17/1998, This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model [9]. The ADSL standard describes ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both ATU-C and ATU-R agent's perspectives. Each instance defined in the MIB represents a single ADSL line. It should be noted that much of the content for the first version (v00) of this document came from work completed by the ADSL Forum's Network Management working group and documented in ADSL Forum TR-006 'SNMP-based ADSL Line MIB'[9]. See Acknowledgement Section for a list of individuals involved with this effort. Authenticated Firewall Traversal (aft) -------------------------------------- "Challenge-Handshake Authentication Protocol for SOCKS V5", M. VanHeyningen, 01/07/1998, This document specifies the integration of authentication based on Challenge-Handshake Authenticaton Protocol into SOCKS Version 5. The primary algorithm to be used is HMAC-MD5, although the framework is general enough to permit use of MD5 or other keyed hash algorithms. This document describes the message formats and protocol details of incorporating CHAP into the SOCKS V5 authentication ''subnegotiation.'' Support is included for authentication of server to client as well as client to server. "SOCKS Protocol Version 5", Marc VanHeyningen, 06/26/1998, The use of network firewalls, systems that effectively isolate an organizations internal network structure from an exterior network, such as the INTERNET is becoming increasingly popular. "SOCKS V5 UDP and Multicast Extensions to Facilitate Multicast Firewall Traversal", D. Chouinard, 11/18/1997, This proposal creates a mechanism for managing the ingress or egress of IP multicast through a firewall. It does this by defining extensions to the existing SOCKS V5 protocol [RFC-1928], which provides a framework for doing user-level, authenticated firewall traversal of unicast TCP and UDP traffic. However, because the current UDP support in SOCKS V5 has scalability problems as well as other deficiencies -- and these need to be addressed before multicast support can be achieved -- the extensions are defined in two parts: Base-level UDP extensions, and Multicast UDP extensions. Using the SOCKS framework for managing multicast flows in/out of an organization, offers numerous security advantages over what is possible with a conventional firewall approach. These are spelled out in the draft. "SOCKS V5 Protocol extension for Multiple Firewalls Traversal", Makoto Kayashima, Tsukasa Ogino, Masato Terada, Yoichi Fujiyama, 11/26/1997, This document provides the extended specification of SOCKS Version 5 which enable to use multiple firewalls traversal. In this protocol, client does subnegotiation with all servers on the communication path, and each server relays the connection after subnegotiation. "EAP Authentication for SOCKS Version 5", Glen Zorn, Pat Calhoun, Jeff Haag, 03/06/1998, This document defines how EAP [5] (Extensible Authentication Protocol) can be used with the SOCKS V5 protocol. EAP was defined to allow any authentication mechanism to be used without any modification to the authentication protocol (i.e. CHAP, OTP). "Multi-Authentication Framework Method for SOCKS V5", J. Michener, Dan Fritch, 03/13/1998, SOCKS V5 [RFC 1928] provides a means to select one from among a number of authentication methods, but does not provide any means for utilizing multiple authentication methods to obtain desired authentication properties. This document specifies the Multi- Authentication Framework Method (MAF) which is a method extension to SOCKS Version 5 to support the efficient management of composite authentication protocols composed of more than one authentication methods. MAF is a client-initiated but server managed framework. MAF relies upon a trusted Authentication Management Server (AMS) to select the authentication methods to be invoked, order them as appropriate, and assign integrity grades to the final authentication after all methods invoked have been completed. "GSS-API Authentication Method for SOCKS Version 5",, 11/23/1998, The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial SOCKS connection setup. This document provides the specification for the SOCKS V5 GSS-API authentication protocol, the use of the Simple and Protected GSS-API Negotiation (SPNEGO) mechanism, and defines a GSS-API-based encapsulation for provision of integrity and optional confidentiality. SNMP Agent Extensibility (agentx) --------------------------------- "Definitions of Managed Objects for Extensible SNMP Agents", Maria Greene, S. Gudur, 04/15/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. Application MIB (applmib) ------------------------- "Application Management MIB", Jonathan Saperia, Cheryl Krupczak, Randy Presuhn, C. Kalbfleisch, 11/18/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the System Application MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed. "Definitions of Managed Objects for WWW Services", C. Kalbfleisch, H. Hazewinkel, J. Schoenwaelder, 10/28/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. Access, Searching and Indexing of Directories (asid) ---------------------------------------------------- "Definition of the inetOrgPerson Object Class", Mark Smith, 11/18/1998, While the X.500 standards [X500] define many useful attribute types and object classes, they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. AToM MIB (atommib) ------------------ "Definitions of Supplemental Managed Objects for ATM Management", Kaj Tesink, Andrew Smith, E. Spiegel, F. Ly, M. Noto, 09/04/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", Kaj Tesink, E. Spiegel, M. Noto, 11/09/1998, This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. "Definitions of Tests for ATM Management", Kaj Tesink, M. Noto, 09/14/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services in addition to those defined in the ATM MIB [16], to provide support for the management of ATM Loopback Tests. "Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks", Keith McCloghrie, Juha Heinanen, A. Prasad, W. Greene, 10/05/1998, 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 controlling the collection and storage of accounting information for connection-oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. For information on data which can be collected for ATM networks, see [19]. "Definitions of Managed Objects for ATM Management", Kaj Tesink, 11/09/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. This memo replaces RFC1695[24].Changes relative to RFC1695 are summarized in the MIB module's REVISION clause. Textual Conventions used in this MIB are defined in [6] and [19]. "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Kaj Tesink, 11/17/1998, This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. "Definitions of Managed Objects for the SONET/SDH Interface Type", Kaj Tesink, 11/16/1998, 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 [24][25]. Textual Conventions used in this MIB are defined in [6] and [36]. This memo replaces RFC1595 [30]. Changes relative to RFC1595 are summarized in the MIB module's REVISION clause. "Accounting Information for ATM Networks", Keith McCloghrie, Juha Heinanen, A. Prasad, W. Greene, 10/05/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A separate memo [16] defines managed objects, in a manner independent of the type of network, for controlling the selection, collection and storage of accounting information into files for later retrieval via a file transfer protocol. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. "Managed Objects for Recording ATM Performance History Data Based on 15 Minute Intervals", G. Mouradian, 05/13/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to record and retrieve ATM performance history data recorded in 15 minute interval. The functionality defined in this document is intended to satisfy the requirements defined by the ATM Forum in [9]. Audio/Video Transport (avt) --------------------------- "RTP Payload Format for H.263 Video Streams", C. Zhu, 09/11/1997, This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries. "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", V. Jacobson, Stephen Casner, 07/29/1998, This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). "Real-Time Transport Protocol Management Information Base", I. Suconick, M. Baugher, B. Strahm, 11/23/1998, This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group at rem-conf@es.net. This memo does not specify a standard for the Internet community. "RTP Profile for Audio and Video Conferences with Minimal Control", H. Schulzrinne, 11/23/1998, This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. The revision process is not yet complete; some changes which have been discussed and tentatively accepted in meetings of the Audio/Video Transport working group have not yet been incorporated into this draft. 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. However, the encoding definitions are independent of the particular transport mechanism used. 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. "RTP Payload for DTMF Digits", H. Schulzrinne, 11/23/1998, This memo describes how to carry dual-tone multifrequency (DTMF) signaling and other tone signals in RTP packets. "An RTP Payload Format for Generic Forward Error Correction", Jonathan Rosenberg, H. Schulzrinne, 11/10/1998, This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. "New Results in RTP Scalability", Jonathan Rosenberg, H. Schulzrinne, 12/03/1997, Recently, a number of problems related to RTP scalability to large multicast groups have been identified. The main problem, congestion of RTCP packets due to near-simultaneous joins, has been resolved in previous work. In this document, we present some additional problems and describe the solutions. In particular, we discuss the problem of BYE floods and premature timeouts. To resolve the BYE flood problem, we propose a BYE reconsideration mechanism. To help alleviate prema- ture timeouts, we propose a reverse timer reconsideration algorithm. Both algorithms are simple, and require minimal state and computa- tion. "Guidelines for Writers of RTP Payload Format Specifications", Mark Handley, 11/16/1998, This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifica- tions in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. "RTP: A Transport Protocol for Real-Time Applications", V. Jacobson, Stephen Casner, R. Frederick, H. Schulzrinne, 11/23/1998, This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. 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. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "RTP Payload Format for X Protocol Media Streams", Lassaad Gannoun, 03/11/1998, This document specifies the payload format for encapsulating X-protocol streams in the Realtime Transport Protocol (RTP). This specification is intended for X-protocol media streams that are not already handled by other RTP payload specifications. This specification gives details of the payload format of X-protocol data requests that are carried over RTP/UDP/IP in a shared window session. Multiple X protocol requests can be carried over an RTP packet as well as one X protocol request can be carried over multiple RTP packets. a shared window header is defined within the RTP payload to carry X protocol media requests. An RTCP join and RTP reply packets are specified to allow a latecomer to join an on-going session. This specification is intended for streaming stored X Window protocol data as well as live X protocol data requests. "RTP payload format for MPEG-4 Elementary Streams", H. Schulzrinne, D. Hoffman, M. Speer, R. Civanlar, Andrea Basso, Vahe Balabanian, Carsten Herpel, 03/13/1998, This memorandum describes a scheme to encapsulate MPEG-4 Elementary Streams into RTP packets. Two approaches are described. The first allows to map one MPEG-4 Elementary Stream to one RTP session, for maximum compatibility to the design principles of RTP. The second responds to the observation that MPEG-4 applications may well consist of such a large number of streams that the encapsulation of a bundle of Elementary Streams in one RTP session is required. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "The Role of DMIF in Support of RTP MPEG-4 Payloads", Vahe Balabanian, 03/13/1998, This memorandum describes how RTP carrying MPEG-4 payloads interacts with the MPEG-4 Access Unit layer through the MPEG (Delivery Multimedia Integration Framework) DMIF. DMIF is used to pass information essential for the packing and unpacking of MPEG-4 streams into RTP as well as for adjusting the MPEG-4 AL-PDU lengths to be within the path MTU. DMIF interprets the RTCP reports by comparing its statistics to the requested MPEG-4 media based QoS. If the statistics fail to meet the requested QoS then action is taken to either continue with the impaired perforamce, upgrade the network service class, scale down the stream or delete the stream. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "An RTP Payload Format for User Multiplexing", Jonathan Rosenberg, H. Schulzrinne, 05/19/1998, This memo describes an RTP payload format for multiplexing data from multiple users into a single RTP packet. Such multiplexing is especially useful for transporting voice data between Internet telephony gateways. It causes signif- icant reductions in header overheads and improves scalabil- ity. "RTP Payload for Redundant Audio Data", Mark Handley, C Perkins, I Kouvelas, Colin Perkins, Jean-Chrysostome Bolot, Andres Vega-Garcia, Sacha Fosse-Parisis, V Hardman, 08/10/1998, This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. "Sampling of the Group Membership in RTP", Jonathan Rosenberg, H. Schulzrinne, 11/10/1998, In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. "User Multiplexing in RTP payload between IP Telephony Gateways", Senthil Sengodan, Barani Subbiah, 08/31/1998, This draft proposes a method to multiplex a number of low bit rate audio streams (upto 256) into a single RTP/UDP/IP connection between IP telephony gateways. Audio samples from different users are assem- bled into an RTP payload thus reducing the overhead of RTP/UDP/IP headers. To identify users sharing a single RTP/UDP/IP connection, a 2 byte MINI-Header is proposed. A channel negotiation procedure to assign and release channels on a single UDP connection between gateways is described. "Issues and Options for RTP Multiplexing", Jonathan Rosenberg, H. Schulzrinne, 10/02/1998, This memorandum discusses the issues and options involved in the design of a new transport protocol for multiplexed voice within a single packet. The intended application is the interconnection of devices which provide trunking or long distance telephone service over the Internet. Such devices have many voice connections simultaneously between them. Multiplexing them into the same connection improves on the efficiency, enables the use of low bitrate voice codecs, and improves scalability. Options and issues con- cerning timestamping, payload type identification, length indication, and channel identification are discussed. Sev- eral possible header formats are identified, and their efficiencies are compared. "An RTP Payload Format for Reed Solomon Codes", Jonathan Rosenberg, H. Schulzrinne, 11/10/1998, This document specifies a payload format for forward error correction of media encapsulated in RTP using Reed Solomon codes. The payload format allows end systems to transmit using arbitrary block lengths and codes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. "GeRM: Generic RTP Multiplexing", Mark Handley, 11/12/1998, This document describes GeRM, an RTP payload format for generic multiplexing of multiple RTP streams. This document is a product of the Audio/Video Transport (AVT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author. "RTP Payload format for Interleaved Media", Colin Perkins, 11/18/1998, This memo defines an interleaving scheme for RTP streams. This scheme is derived from the RTP payload format for redundant audio data [3] and hence is targetted primarily at streamed audio, although it may be of use in other scenarios. "RTP Payloads for Telephone Signal Events", Scott Petrack, 11/23/1998, This note describes two RTP payload formats for in-band telephony signal events (TSE) such as DTMF, dial-tone, ring-tone, off-hook, SIT, etc. One payload is designed to carry a named signal, and the other is designed carry a compact representation of actual audio waveform cadence to be played. The two formats are independent, but they can be used together very usefully within redundant audio payloads; this enables highly efficient and robust transport of telephony network signal events along with a representation of the actual audio media associated to the signal events. Acknowledgements: This internet draft is an extension of H. Schulzrinne's draft ietf-avt-dtmf-00.txt and borrows heavily from it (including copying actual text). The main extensions appearing in this draft are as follows: a) many other telephony call progress tones and signal events have been added to the original DTMF and flash-hook of ietf-avt-dtmf-00.txt (an attempt has been made to align this with [MGCP] and [E.180 supp2] b) a second payload is defined which carries a highly compact frequency representation of the audio waveform of the signal; c) a few clarifications about reliability and redundancy, including how the two payloads will work together. Acknowledgement is also due to [MGCP]; part of this draft is an attempt to use RTP to provide the signal transport required by MGCP, in a way which can be reused by a large class of applications. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Cell/Call Benchmarking", Cynthia Martin, Jeff Dunn, 11/02/1998, This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of cell- based and call-based switching devices. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 1944 and 2285. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). "Benchmarking Terminology for Firewall Performance", David Newman, 07/27/1998, This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches and adds terminology specific to firewalls. The primary metrics used in this document are bit forwarding rate and connections. "Benchmarking Methodology for LAN Switching Devices", John Keene, B. Mandeville, 08/10/1998, This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. It extends the methodology already defined for benchmarking network interconnecting devices in RFC 1944 to switching devices. This RFC primarily deals with devices which switch frames at the Medium Access Control (MAC) layer. It provides a methodology for benchmarking switching devices, forwarding performance, congestion control, latency, address handling and filtering. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. Bridge MIB (bridge) ------------------- "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", Keith McCloghrie, P. Langille, A. Rijsinghani, Andrew Smith, Les Bell, 11/23/1998, 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 MAC bridges based on the IEEE 802.1D-1998 MAC Bridges and IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SNMPv2 SMI [5]. Calendaring and Scheduling (calsch) ----------------------------------- "Calendar attributes for vCard and LDAP", D. Hennessy, Frank Dawson Jr., Tony Small, 09/23/1998, When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current 'busy time' provides an a priori indication of whether the attendee will be free to participate in the event. In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time. This draft defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include: - Manual transfer of the information; - Personal data exchange using the vCard format; and - Directory lookup using the LDAP protocol. "Internet Calendar Model Specification", John Noerenberg, 11/17/1997, Internet Calendaring and Scheduling protocols require the definition of objects to encapsulate an event to be scheduled, a calendar on which the event will be stored, and means for exchanging these objects across the Internet between calendars on behalf of people for whom the calendars are meaningful. This document gives an abstract model of the objects and the protocols necessary to accomplish this kind of information exchange. It will establish the context in which other Calendaring and Scheduling RFCs can be interpreted. Included are brief introductions to the other components of Internet calendar protocols and definitions of nomenclature common to all documents defining these protocols. Reading this document will enable implementors and users of Internet Calendaring and Scheduling protocols to understand the goals and constraints chosen for related protocols. "CAP Requirements", P. O'Leary, Andre Courtemanche, S. Mansour, Frank Dawson Jr., Doug Royer, Tony Small, 11/23/1998, The Calendar Access Protocol (CAP) is an Internet protocol for accessing an [ICAL] based calendar store (CS) from a calendar user agent (CUA). The purpose of this document is to set forth a list of requirements that CAP MUST address in order to meet the needs of the calendaring and scheduling community. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Distribution of this document is unlimited. Comments and suggestions for improvement should be sent to the authors. Copyright (C) The Internet Society 1998. All Rights Reserved. "ICalendar Real-time Interoperability Protocol (IRIP)", P. O'Leary, Andre Courtemanche, S. Mansour, 11/20/1998, This document specifies a binding from the iCalendar Transport-independent Interoperability Protocol [ITIP] to a real-time transport. Calendaring entries defined by the iCalendar Object Model [ICAL] are composed using constructs from [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. This document is based on the calendaring and scheduling model defined by [ICMS]. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC website at http://www.imc.org, the IETF website at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Distribution of this document is unlimited. Comments and suggestions for improvement should be sent to the authors. "iCalendar v2.0 Formal Public Identifier",, 09/23/1998, The IETF has defined a standard format for exchanging calendaring and scheduling data, called iCalendar. This format is useful for exchange of personal calendar data across the Internet, as well as in non- Internet environments. In a number of environments where the iCalendar will be used, the format type and version needs to be identified. For example, when registering the iCalendar as a format for memory-based 'clipboard' or 'drag/drop' user interface interactions. For these cases, a definitive formal public identifier (FPI) for the iCalendar will be required. This memo defined the FPI to be used when referring to the version 2.0 (the value in the 'VERSION' property) of the iCalendar format. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY' and 'OPTIONAL' in this document are to be interpreted as described in [RFC 2119]. Common Authentication Technology (cat) -------------------------------------- "Integrating Single-use Authentication Mechanisms with Kerberos", Clifford Neuman, Glen Zorn, J. Trostle, Ken Hornstein, 11/24/1998, This document defines extensions to the Kerberos protocol specifi- cation [RFC1510] which provide a method by which a variety of single-use authentication mechanisms may be supported within the protocol. The method defined specifies a standard fashion in which the preauthentication data and error data fields in Kerberos mes- sages may be used to support single-use authentication mechanisms. "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)", C. Adams, 05/01/1998, The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated 'receivers' of the data unit. Thus, it is suitable for applications such as secure electronic mail where data needs to be protected without any on-line connection with the intended recipient(s) of that data. The protection offered by IDUP includes services such as data origin authentication with data integrity, data confidentiality with data integrity, and support for non-repudiation services. Subsequent to being protected, the data unit can be transferred to the recipient(s) - or to an archive - perhaps to be processed ('unprotected') only days or years later. Throughout the remainder of this document, the 'unit' of data described in the above paragraph will be referred to as an IDU (Independent Data Unit). The IDU can be of any size (the application may, if it wishes, split the IDU into pieces and have the protection computed a piece at a time, but the resulting protection token applies to the entire IDU). However, the primary characteristic of an IDU is that it represents a stand-alone unit of data whose protection is entirely independent of any other unit of data. If an application protects several IDUs and sends them all to a single receiver, the IDUs may be unprotected by that receiver in any order over any time span; no logical connection of any kind is implied by the protection process itself. As with RFC-2078, this IDUP-GSS-API definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source- level portability of applications to different environments. This specification "Public Key Cryptography for Initial Authentication in Kerberos", Clifford Neuman, John Wray, Brian Tung, J. Trostle, M. Hur, A. Medvinsky, Sasha Medvinsky, 11/13/1998, This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. "Generic Security Service API Version 2 : C-bindings", John Wray, 11/11/1998, This draft document specifies C language bindings for Version 2 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other drafts [GSSAPI]. It revises RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track. The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms. Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. "The Simple and Protected GSS-API Negotiation Mechanism", B. Pinkas, E. Baize, 04/14/1998, This draft document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms. This allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms. Once the common security mechanism is identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. This will be inside the mechanism tokens, and invisible to the SPNEGO protocol. "Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions", B. Pinkas, T. Parker, 11/09/1998, The Generic Security Service Application Program Interface (GSS- API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. It defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment. The GSSAPI allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. The primitives of the GSS-API do not currently allow support of security attributes other than a single identity and do not allow fine control of delegation. The additional primitives described in this document provide support for: * the exchange of a variety of security attributes, and the construction of authorization functions using these attributes, including delegated ones, (attribute handling support functions), * fine control over delegation by allowing specification of the delegation method, the acceptor(s) of a security context, their type and the restrictions that may apply (acceptor control and support functions). "Public Key Cryptography for Cross-Realm Authentication in Kerberos", G. Tsudik, Clifford Neuman, B. Sommerfeld, Brian Tung, M. Hur, T. Ryutov, A. Medvinsky, 11/13/1998, This document defines extensions to the Kerberos protocol specification (RFC 1510, 'The Kerberos Network Authentication Service (V5)', September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. "Public Key Utilizing Tickets for Application Servers (PKTAPP)", Clifford Neuman, M. Hur, A. Medvinsky, Alexander Medvinsky, 03/17/1998, Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. "Kerberos Change Password Protocol", M. Horowitz, 08/11/1998, The Kerberos V5 protocol [RFC1510] does not describe any mechanism for users to change their own passwords. In order to promote interoperability between workstations, personal computers, terminal servers, routers, and KDC's from multiple vendors, a common password changing protocol is required. "The Kerberos Network Authentication Service (V5)", Theodore Ts''o, Clifford Neuman, George Kohl, 11/23/1998, This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. This document is not intended to describe Kerberos to the end user, system administrator, or application developer. Higher level papers describing Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], are available elsewhere. "FTP Authentication Using DSA", P. Yee, Russ Housley, W. Nace, 03/05/1998, This document defines a method to secure file transfers using the FTP specification RFC 959, ''FILE TRANSFER PROTOCOL (FTP)'' (October 1985) and RFC 2228 ''FTP Security Extensions'' (October 1997) [1]. This method will use the extensions proposed in the ''FTP Security Extensions'' along with a public/private digital signature. "Generic Security Service Application Program Interface Version 2, Update 1", John Linn, 09/04/1998, The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This Internet-Draft revises [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. "Kerberos vs firewalls", Assar Westerlund, Johan Danielsson, 12/04/1997, Kerberos[RFC1510] is a protocol for authenticating parties communicating over insecure networks. Firewalling is a technique for achieving an illusion of security by putting restrictions on what kinds of packets and how these are sent between the internal (so called ''secure'') network and the global (or ''insecure'') Internet. "Public Key Cryptography for KDC Recovery in Kerberos V5", J. Trostle, 11/24/1998, This document defines extensions to the Kerberos protocol specification (RFC 1510, 'The Kerberos Network Authentication Service (V5)', September 1993) to enable the recovery of a compromised Kerberos V5 KDC using public key cryptography. The document specifies the recovery protocol which uses preauthentication data fields and error data fields in Kerberos messages to transport recovery data. "Extension to Kerberos V5 For Additional Initial Encryption", J. Trostle, Michael Swift, 06/29/1998, This document defines an extension to the Kerberos protocol specification (RFC 1510) [1] to enable a preauthentication field in the AS_REQ message to carry a ticket granting ticket. The session key from this ticket granting ticket will be used to cryptographically strengthen the initial exchange in either the conventional Kerberos V5 case or in the case the user stores their encrypted private key on the KDC [2]. "Generic Security Service API Version 2 : Java bindings", Jack Kabat, 08/11/1998, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2078 [GSSAPIv2]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are The Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5]. "Access Control Framework for Distributed Applications", Clifford Neuman, T. Ryutov, 11/20/1998, This document describes a unified model to support authorization in a wide range of applications, including metacomputing, remote printing, video conference, and any other application which will require interactions between entities across autonomous security domains. The document proposes requirements for the support of: - flexible and expressive mechanism for representing and evaluating security policies - uniform authorization service interface for facilitating access control decisions for applications and requesting access control information about a particular resource. This specification defines structures and their uses at a level independent of underlying mechanism and programming language environment. This document is accompanied by a second one describing the details of proposed structures and services along with bindings for C language environments. This document is to be found in draft-ietf-cat-gaa-cbind-01.txt. "Generic Authorization and Access control Application Program Interface C-bindings", Clifford Neuman, T. Ryutov, 11/20/1998, The Generic Authorization and Access control Application Programming Interface (GAA API) provides access control services to calling applications. It facilitates access control decisions for applications and allows applications to discover access control policies associated with a targeted resource. The GAA API is usable by multiple applications supporting different kinds of protected objects. The GAA API design supports: - a variety of security mechanisms based on public or secret key cryptosystems - different authorization models - heterogeneous security policies - various access rights This document specifies C language bindings for the GAA API, which is described at a language-independent conceptual level in draft-ietf-cat-acc-cntrl-frmw-01.txt "The Kerberos Version 5 GSSAPI Mechanism, Version 2", Tom Yu, 11/23/1998, This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFC 2078) when using Kerberos Version 5 technology (as specified in RFC 1510). This obsoletes RFC 1964. Content Negotiation (conneg) ---------------------------- "Media Feature Tag Registration Procedure", E. Hardie, K. Holtman, A. Mutz, 07/28/1998, Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. "Media Features for Display, Print, and Fax", Larry Masinter, K. Holtman, A. Mutz, Dan Wing, 09/09/1998, This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. These features are registered for use within the framework of [REG]. "Requirements for protocol-independent content negotiation", G. Klyne, 12/29/1997, A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1, 2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. The case for a cross-protocol negotiation framework is set out in [4]. This draft sets out terminology, an abstract framework and requirements for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The requirements set out the desired properties of a content negotiation mechanism. "An algebra for describing media feature sets", G. Klyne, 08/07/1998, A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra and syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. This document also outlines an algorithm for feature set matching. "A syntax for describing media feature sets", G. Klyne, 11/16/1998, A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3]. "W3C Composite Capability/Preference Profiles", G. Klyne, 10/21/1998, This document suggests some possible areas for extending the IETF 'conneg' working group's capability description framework, described in [2,3,4]. The suggested areas for extension have been motivated by WWW Consortium (W3C) work on Composite Capability/Preference Profiles (CCPP) [5] that parallels some aspects of IETF 'conneg' work. It is presented as a discussion document, with a view to maybe integrating some of these ideas into ongoing 'conneg' work. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", C Perkins, Jim Bound, 07/07/1998, The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for passing configuration information, via extensions, to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol should be considered a stateful counterpart to the IPv6 Stateless Address Autoconfiguration protocol specification, and can be used separately or together with the latter to obtain configuration information. "Procedure for Defining New DHCP Options", Ralph Droms, 11/10/1998, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called 'options.' New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. "Interaction between DHCP and DNS", Y Rekhter, 03/05/1998, DHCP provides a powerful mechanism for IP host autoconfiguration. However, the autoconfiguration provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained by DNS. This document specifies how DHCP clients and servers should use the Dynamic DNS Updates mechanism to update the DNS name to address and address to name mapping, so that the mappings for DHCP clients would be consistent with the IP addresses that the clients acquire via DHCP. "Authentication for DHCP Messages", Ralph Droms, William Arbaugh, 11/18/1998, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. "Extensions for the Dynamic Host Configuration Protocol for IPv6", C Perkins, 07/08/1998, This document specifies the current set of DHCPv6 extensions. This document will be periodically updated as new extensions are defined. Each superseding document will include the entire current list of valid extensions. The method for specifying new extensions is also included in this document. "DHCP Options for Service Location Protocol", C Perkins, Erik Guttman, 11/23/1998, The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. "The User Class Option for DHCP", Ralph Droms, G. Stump, 11/20/1998, This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that represents the user class of which the client is a member. "DHCP Relay Agent Information Option", M. Patrick, 11/16/1998, Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The 'Relay Agent Information' option is organized as a single DHCP option that contains one or more 'sub-options' that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a 'circuit ID' for the incoming circuit, a 'remote ID' which provides a trusted identifier for the remote high-speed modem, and the 'subnet mask' of the logical IP subnet from which the relay agent received the client DHCP packet. "Multicast Address Allocation Configuration Options", Steve Hanna, B. Patel, M. Shah, 08/10/1998, This document describes DHCP options that may be used to provide access to Multicast Address Allocation servers, such as MDHCP servers. "The Server Selection Option for DHCP", Ralph Droms, G. Stump, P. Gupta, 11/20/1998, This option is provided by DHCP servers to DHCP clients so that clients may optionally select from among multiple offers received from DHCP servers in the network offer from a DHCP. The information contained in this option is an hex value that represents an integer value indicating the priority of the offer in which this option is contained. "The Domain Search Option for DHCP", P. Gupta, 11/18/1998, This document defines a new DHCP option which is passed form the DHCP Server to the DHCP Client to configure the domain search list which is used by the clients to resolve hostnames in the Domain Name System[3]. "DHCP Failover Protocol", Ralph Droms, Bernard Volz, K. Kinnear, Arun Kapur, Mark Stapp, Greg Rabil, Mike Dooley, Steve Gonczi, 11/23/1998, DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide this synchronization between two servers. One server is designated the 'Primary' server, the other is the 'Secondary' server. Additionally, this document describes a protocol for the automatic transfer of control from the primary to the secondary in the case of failure (failover), as well as a network partition. This document further develops the concepts presented in draft-ietf- dhc-failover-02.txt. "DHCP Continuation Option Code", Angelos Keromytis, William Arbaugh, 11/24/1997, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Currently options are limited to an information size of 256 bytes because of the one-octet size of the length field. This document defines a new option that permits the continuation of the previous option information. "The Autonomous System Option for DHCP", W.D Lazear, 02/10/1998, This document describes a configuration option that may be used by hosts acting as IP forwarders. The option contains information about the autonomous system in which the host resides and may be required by routing protocols. "The Server Range Option for DHCP", W.D Lazear, 02/25/1998, This document describes a configuration option that may be used by hosts acting as IP forwarders. The option contains information about the networks adjacent to the host and may be required by routing protocols. "DHCP Safe Failover Protocol", K. Kinnear, 03/12/1998, The DHCP protocol [RFC 2131] [1] allows multiple DHCP servers. A recent draft, the DHCP Failover Protocol [3], has been distributed which is designed to provide a redundant DHCP solution. While clearly a work in progress, it is equally clear that it can be made to work and meet the goals that the authors have set for it. One of the goals of the Failover protocol is that it should avoid duplicate IP address allocations, except under some rare circumstances. While this approach may be quite reasonable in a wide variety of environ- ments, some environments require a DHCP redundancy solution which can (optionally) ensure that no possibility of duplicate IP address allo- cation exists. The Safe Failover protocol is designed to build on top of the Failover protocol, and add to it certain protocol exchanges, prac- tices and algorithms which will create a DHCP redundancy solution which avoids duplicate IP address allocation. "Security Requirements for the DHCP protocol", Ralph Droms, O. Gudmundsson, 03/13/1998, This document addresses the general security requirements of both DHCPv4 and DHCPv6. This document lists security requirements and the the reasons for each requirement. This document does not address how to implement the security requirements. "Dynamic Host Configuration Protocol (DHCP) Server MIB", G. Waters, Richard Barr Hibbs, 05/01/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) servers. "DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients", Ryan Troll, 10/19/1998, Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automaticly choosing an IP address which will allow them to communicate with other hosts running the same OS. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This draft describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not auto-configure it's own. "DHCP Option for User Authentication Protocol", Steve Drach, 11/12/1998, This document defines a DHCP [1] option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard [2]. "Automaticly Choosing an IP Address in an Ad-Hoc IPv4 Network", Ryan Troll, 10/19/1998, With operating systems appearing in more and more devices, as well as computers appearing in more and more aspects of everyday life, communication between networked devices is increasingly important. The communication mechanism between these devices must be able to not only support the office LAN environment, but must also scale to larger WANS and the internet. This draft describes a method by which a host may automaticly give itself a link-local IPv4 address, so that it will be able to use IP applications in the absence of an IP address management mechanism, such as DHCP. This mechanism is in use today by a few operating systems, and additional information on those implementations is also provided. "DHCP Use of the User Class Option for Address Assignment", Ye Gu, Burcak Beser, Ramesh Vyaghrapuri, 11/03/1998, This document proposes a mechanism that DHCP clients can use optionally to obtain their IP addresses from different address pools configured on a DHCP server. A DHCP client can specify a class to which it belongs. Based on the class, a DHCP server selects the appropriate address pool to assign an address to the client. Differentiated Services (diffserv) ---------------------------------- "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", Fred Baker, Kathleen Nichols, S. Blake, David Black, 10/09/1998, Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. "An Architecture for Differentiated Services", Mark Carlson, Walter Weiss, S. Blake, Z. Wang, David Black, Elwyn Davies, 10/09/1998, This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks. "A Framework for Differentiated Services", Srinivasan Keshav, Dinesh Verma, Mark Carlson, Borje Ohlman, S. Blake, Y. Bernet, James Binder, Z. Wang, Walter Weiss, Elwyn Davies, 10/20/1998, This document provides a general description of issues related to the definition, configuration and management of services enabled by the differentiated services architecture [DSARCH]. This document should be read along with its companion documents, the differentiated services architecture [DSARCH] and the definition of the DS field [DSHEAD]. A glossary of specialist terms used may be found in [DSARCH]. "A Framework for Use of RSVP with Diff-serv Networks", Lixia Zhang, R. Yavatkar, Fred Baker, Peter Ford, Kathleen Nichols, M. Speer, Y. Bernet, 11/20/1998, In the past several years, work on QoS enabled networks led to the development of the Integrated Services (Intserv) architecture [12] and the RSVP signaling protocol [1]. RSVP, as specified, enables applica- tions to signal per-flow requirements to the network. Intserv parame- ters are used to quantify these requirements for the purpose of admis- sion control. However, as work on RSVP and Intserv has proceeded, we have recognized the following basic limitations, which impede deploy- ment of these mechanisms in the Internet at large: 1) The reliance of RSVP on per-flow state and per-flow processing raises scalability concerns in large networks. 2) Today, only a small number of hosts generate RSVP signaling. While this number is expected to grow dramatically, many applications may never generate RSVP signaling. 3) Many applications require a form of QoS, but are unable to express these requirements using the intserv model. At present, the market is pushing for immediate deployment of a QoS solution that addresses the needs of the Internet as well as enter- prise networks. This push has led to the development of Differentiated services (diff-serv). In contrast to RSVP's per-flow orientation, diff-serv networks classify packets to one of a small number of aggre- gated flows, based on the setting of bits in the TOS field of each packet's IP header. Thus, in addition to eliminating the reliance on per-flow state, diff-serv QoS can initially be deployed using top-down provisioning, with no requirement for end-to-end signaling. At the same time however, it is important to assure that the diff-serv mechanisms deployed, interoperate effectively with hosts and networks that provide per-flow QoS in response to end-to-end signaling. This is important, as we believe that in the coming years, there will be a proliferation of applications that depend on QoS and of hosts which will sign "Requirements of Diff-serv Boundary Routers", Francis Reichmeyer, Y. Bernet, David Durham, 11/23/1998, This draft discusses requirements of routers that serve as ingress/egress points to/from differentiated services (diff-serv) networks. We discuss the traffic conditioning components required and associated configuration mechanisms and protocols. We also discuss admission control to diff-serv networks in support of signaled QoS. "Assured Forwarding PHB Group", Fred Baker, Juha Heinanen, John Wroclawski, Walter Weiss, 11/18/1998, This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class. "Management of PHBs", M. Borden, Christopher White, 08/05/1998, The DiffServ Working Group will produce PHBs (Per Hop Behaviors) used to provide differentiated services. Some of these are to be standardized, others may have widespread use and still others may remain experimental. The encoding of the PHB into a codepoint of the DS Field will not be standardized, except for the legacy, precedence PHBs. Therefore a method is needed to coordinate the use of PHBs and codepoints, even if only for the purpose of discussing them. This draft addresses this coordination issue. "An Expedited Forwarding PHB", V. Jacobson, Kathleen Nichols, Kedernath Poduri, 11/16/1998, The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given. A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf Distributed Management (disman) ------------------------------- "Definitions of Managed Objects for the Delegation of Management Scripts", D. Levi, J. Schoenwaelder, 11/23/1998, 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 a set of managed objects that allow the delegation of management scripts to distributed managers. "Distributed Management Framework", Steven Waldbusser, Bob Stewart, Andy Bierman, Maria Greene, 08/31/1998, This memo defines a distributed management architecture for use with the SNMP network management architecture. This memo does not specify a standard for the Internet community. "Expression MIB", Bob Stewart, 11/05/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. "Notification Log MIB", Bob Stewart, 10/13/1998, This memo defines an experimental 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 logging SNMP Notifications. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. "Event MIB", Bob Stewart, 10/07/1998, This memo defines an experimental 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 monitoring of MIB objects and taking action through events. "Definitions of Managed Objects for Scheduling Management Operations", D. Levi, J. Schoenwaelder, 11/23/1998, 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. "Definitions of Managed Objects for Remote Operations Using SMIv2", K. White, 09/04/1998, This memo defines a Management Information Base (MIB) for performing remote operations (ping, traceroute and DNS Lookup) at a remote host. When managing a network it is useful to be able to retrieve the results of either a ping or traceroute operation when performed at a remote host. A DNS Lookup capability is defined to determine the DNS of an address at a remote host. Currently, there exists several enterprise defined MIBs for performing both a remote ping or traceroute operation. The purpose of this memo is to defined a standards-based solution to enable interoperibility. DNS IXFR, Notification, and Dynamic Update (dnsind) --------------------------------------------------- "Secret Key Transaction Signatures for DNS (TSIG)", O. Gudmundsson, P. Vixie, Don Eastlake, B. Wellington, 11/23/1998, This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. "Reserved Top Level DNS Names", D. Eastlake, Aliza Panitz, 11/20/1998, To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. "Local Domain (DNS) Names", Don Eastlake, 11/20/1998, A set of second level domain names are defined under a new top level domain name such that local private DNS zones can be maintained similar to the private IP addresses reserved in [RFC 1918]. These zone locally appear to be part of the global DNS name tree. Additional second level domain names are assigned under this TLD for loopback addresses and IPv6 link and site local addresses. "A New Scheme for the Compression of Domain Names", Peter Koch, 11/18/1998, The compression of domain names in DNS messages was introduced in [RFC1035]. Although some remarks were made about applicability to future defined resource record types, no method has been deployed yet to support interoperable DNS compression for RR types specified since then. This document summarizes current problems and proposes a new compression scheme to be applied to future RR types which supports interoperability. Also, suggestions are made how to deal with RR types defined so far. "Binary Labels in the Domain Name System", M. Crawford, 09/01/1998, This document defines a ``Bit-String Label'' which may appear within domain names. This new label type compactly represents a sequence of ``One-Bit Labels'' and enables resource records to be stored at any bit-boundary in a binary-named section of the domain name tree. "Non-Terminal DNS Name Redirection", M. Crawford, 09/04/1998, This document defines a new DNS Resource Record called ``DNAME'', which provides the capability to map an entire subtree of the DNS name space to another domain. It differs from the CNAME record which maps a single node of the name space. "Extensions to DNS (EDNS1)", P. Vixie, 11/16/1998, This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. "Extension mechanisms for DNS (EDNS0)", P. Vixie, 09/01/1998, The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted, and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. "A DNS RR for specifying the location of services (DNS SRV)", P. Vixie, A. Gulbrandsen, 11/16/1998, This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). "A DNS RR Type for Lists of IP Address Prefixes (APL RR)", Peter Koch, 11/23/1998, The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe networks or address ranges. This document proposes a new DNS RR type 'APL' for address prefix lists. Domain Name System Security (dnssec) ------------------------------------ "Mapping Autonomous Systems Number into the Domain Name System", Don Eastlake, 08/02/1997, One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Additions have developed to the Domain Name System to enable it to be used for authenticated public key distribution [RFC 2065]. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS security can be used to distribute their public keys. [Changes from previous version are to accommodate AS numbers larger than 16 bits and to delegate on decimal boundaries rather than binary boundaries.] "Detached Domain Name System (DNS) Information", Don Eastlake, 10/14/1998, A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. "Zone KEY RRSet Signing Procedure", O. Gudmundsson, J Gilmore, 11/19/1997, Under the security extensions to DNS, as defined in RFC 2065 and RFC 2137, a secured zone will have a KEY RRSet associated with the domain name at the apex of the zone. This document covers the manner in which this RRSet is generated, signed, and inserted into the name servers. "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", Don Eastlake, 11/24/1998, A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. "Domain Name System Security Extensions", Don Eastlake, 11/24/1998, Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users. "DSA KEYs and SIGs in the Domain Name System (DNS)", Don Eastlake, 10/14/1998, A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. "Storing Certificates in the Domain Name System (DNS)", O. Gudmundsson, D. Eastlake, 11/24/1998, Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). "Indirect KEY RRs in the Domain Name System", D. Eastlake, 11/14/1997, RFC 2065 defines a means for storing cryptogrpahic public keys in the Domain Name System. An additional code point is defined for the KEY resource record (RR) algorithm field to indicate that the key itself is not stored in the KEY RR but is pointed to by the KEY RR. Encodings to indicate different types of key and pointer formats are specified. "DNSsec Authentication Referral Record (AR)", Robert Watson, 11/26/1997, Authentication Referrals allow DNS to refer to authentication mechanisms that supplement or replace the KEY RRs of DNSsec. Five Authentication Service types are defined: DNSsec, Kerberos IV, Kerberos V, Network Information Service (NIS+), and Radius. "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", Don Eastlake, 10/14/1998, A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. "Secret Key Establishment for DNS (TKEY RR)", Don Eastlake, 09/21/1998, [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and securing Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [changes from last draft: add IANA considerations section, make time fields module 2**32, minor edits, update author info, ...] "DNS Operational Security Considerations", Don Eastlake, 11/24/1998, Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. "Secure Domain Name System (DNS) Dynamic Update", Don Eastlake, 08/06/1998, Revised Domain Name System (DNS) protocol extensions to authenticate the data in DNS and provide key distribution services have been defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the original DNS security protocol definition in RFC 2065. In addition, symetric key DNS transaction signatures have been defined in draft- ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were also been defined [RFC 2137] in connection RFC 2065. This document updates secure dynamic update in light of draft-ietf-dnssec-secext2- *.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. "Intermediate Security Failures in DNSSEC", O. Gudmundsson, B. Wellington, 08/06/1998, This document identifies the situations where a signature verification fails in a recursive security aware DNS server, and how DNS servers should handle these cases, and the errors that should be reported to DNS resolvers. This document proposes a new error to be returned by DNSSEC capable servers. A DNSSEC server acting as a recursive server MUST validate the signatures on RRsets in a response it passes on; this draft addresses the case when the data it receives fails signature verification. The end resolver must be notified of this occurence in such a way that it will not confuse it with another error. "Domain Name System (DNS) Security Key Rollover", Don Eastlake, M. Andrews, 10/13/1998, Practical deployment of Domain Name System (DNS) security with good cryptologic practice will involve large volumes of key rollover traffic. A standard format and protocol for such messages is specified. "Simple Secure Domain Name System (DNS) Dynamic Update", B. Wellington, 11/12/1998, This draft proposes an alternative method for performing secure Domain Name System (DNS) dynamic updates. The method described here is both simple and flexible enough to represent any policy decisions. Secure communication based on request/transaction signatures [TSIG] is used to provide authentication and authorization. Detailed Revision/Update of Message Standards (drums) ----------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 08/05/1998, This document is a self-contained specification of the basic protocol for the Internet electronic mail transport, consolidating and updating: - the original SMTP specification of RFC 821 [RFC-821], - domain name system requirements and implications for mail transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - the clarifications and applicability statements in RFC 1123 [RFC-1123], and - material drawn from the SMTP Extension mechanisms [SMTPEXT]. It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123. However, RFC 821 specifies some features that are not in significant use in the Internet of the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821. It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have turned up as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and IMAP [RFC-IMAP4]. Section 2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively. A companion document discusses message headers, message bodies and formats and structures for them, and their relationship - [MSGFMT]. "Mail and Netnews Header Registration Procedure", J. Palme, 01/13/1998, Various IETF standards and http, e-mail and netnews software products use various http, e-mail and netnews header fields. This document specifies a procedure for the registration of http, e-mail and netnews header field names, to reduce the risk that two different products use the same header field name in different ways (homonyms) or that several different header field names are used with identical meaning (synonyms). "Internet Message Format Standard", P. Resnick, 11/23/1998, This standard specifies a syntax for text messages that are sent between computer users, within the framework of 'electronic mail' messages. This standard supersedes the one specified in Request For Comments 822, 'Standard for the Format of ARPA Internet Text Messages' [RFC-822], updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs [STD-3]. This standard specifies a syntax only for text messages. In particular, it makes no provision for the transmission of images, audio, or other sorts of structured data in electronic mail messages. There are several extensions published, such as the MIME document series [RFC-2045, RFC- 2046, RFC-2049], which describe mechanisms for the transmission of such data through electronic mail, either by extending the syntax provided here or by structuring such messages to conform to this syntax. Those mechanisms are outside of the scope of this standard. In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [SMTP] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. This standard applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope. However, some message systems may use information from the contents to create the envelope. It is intended that this standard facilitate the acquisition of such information by programs. "Use of Reply-To in Internet E-Mail messages", Robert Elz, 10/30/1997, This draft forms part of a discussion on the appropriate use of the Reply-To header in e-mail messages. This draft argues for one particular proposed definition of the Reply-To header. It is not intended that this document ever become anything more than an Internet-Draft. If adopted, the text here, or a modified version of some parts of it, would be merged into the proposed replacement for RFC822. "The ''Message-ID'' header", J. Palme, 12/03/1997, This is a proposal of a text to include msgfmt in order to clarify the relation between changes in the ''Message-ID'' header and other parts of a message. This information is important, because many mailers use the ''Message-ID'' to eliminate duplicates of the same message, and information may be lost if this is not done the right way. Temporary note This document does not at this time (21 November 1997) represent any consensus opinion in the drums working group. "Reply-To-Meaning Proposal", Chris Newman, 12/03/1997, This is a candidate proposal for one way which the problems with the reply-to header in email could be resolved. Under no circumstances should this be implemented as it is only a candidate for a solution and no decision has yet been made. This proposal distinguishes the different incompatible uses of the Reply-To header with a new Reply-To-Meaning header. This has the advantage of being relatively simple, not invalidating most current practices and allowing mail user agents to present more predictable user interfaces. "Reply-To Personal Proposal", Eric Raymond, 12/04/1997, This proposal describes proposed language for the 822bis draft, draft-ietf-drums-msg-fmt-03.txt, that clarifies the semantics of the Reply-To header. The intention is to clarify the rather vague language in 822bis in a way which preserves compatibility with the largest possible subset of existing mail user agents. This document should be read in conjunction with Jacob Palme's Mail-Followup-To proposal (draft-ietf-drums-mail-followup-to-00.txt), which the working group chair, Jacob Palme and the author regard as a natural complement of this proposal. "The ''Mail-Followup-To'' header", J. Palme, 12/04/1997, This proposal contains a proposed new e-mail header ''Mail-Followup-To'', which is intended to be used instead of the ''Reply-To'' header for suggesting where replies to the group who participates in a discussion should be sent. "Augmented BNF for Syntax Specifications: ABNF", P. Overell, Dave Crocker, 11/20/1998, Internet technical specifications often need to define a format syntax and are free to employ whatever notation their authors deem useful. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity, with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. Appendix A (Core) supplies rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. It is provided as a convenience and is otherwise separate from the meta language defined in the body of this document, and separate from its formal status. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "Requirements for Inter-operable Internet EDI", Rik Drummond, M. Jansson, C. Shih, 04/27/1998, This document is a functional specification, discussing the requirements for inter-operable EDI, with sufficient background material to give an explanation for the EDI community of the Internet and security related issues. "MIME-based Secure EDI", Rik Drummond, M. Jansson, C. Shih, 06/26/1998, This document describes how to securely exchange EDI documents using MIME and public key cryptography. "HTTP Transport for Secure EDI", Rik Drummond, C. Shih, Dale Moberg, 11/18/1997, This document describes how to exchange EDI documents securely using http transport for EDI data that is packaged in MIME messages that use public key security body parts. "Secure HL7 Transactions using Internet Mail", Gunther Schadow, Mark Tucker, Wes Rishel, 07/27/1998, This memo describes the applicability of the Internet standardization efforts on secure electronic data interchange (EDI) transactions for Health Level-7 (HL7), an EDI standard for healthcare used worldwide. This memo heavily relies on the work in progress by the IETF EDIINT working group. It is in most parts a restatement of the EDIINTs requirements document and application statement 1 (AS#1) tailored to the needs of the HL7 audience. We tried to make this document as self consistent as possible. The goal is to give to the reader who is not a security or Internet standards expert enough foundational and detail information to enable him to build communication software that complies to the Internet standards. Even though we rely on and promote the respective Internet standards and drafts, we did not withstand from commenting on and criticising this work where we see upcoming problems in use with HL7 or other EDI protocols that have not been in the initial focus of the EDIINT working group. We make suggestions to add parameters to the specification of the MIME type for EDI messages [RFC 1767] in order to enhance functionality. We give use cases for a larger subset of disposition types and modifiers of message disposition notifications. One key issue where this memo goes beyond the current EDIINT drafts is the concept of non-repudiation of commitment to an EDI transaction. Secure EDI transactions should be regarded as ``distributed contracts,'' i.e. not only the sending and receiving of single messages should be non-refutable but also the connection between messages interchanges. In anticipation of this requirement HL7 usually requires a response message to be sent to acknowledge every transaction. We therefore have the requirement to securely couple an EDI response message to its request message. Given the current shape of RFC 1767 this is generally possible only if a response message is coupled with an MDN receipt and the combi Entity MIB (entmib) ------------------- "Entity MIB Extensions", Keith McCloghrie, Andy Bierman, 03/12/1998, This memo defines an experimental 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 multiple logical and physical entities managed by a single SNMP agent. "Entity MIB using SMIv2 (Version 2)", Keith McCloghrie, Andy Bierman, 11/06/1998, This memo defines an experimental 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 multiple logical and physical entities managed by a single SNMP agent. Internet Fax (fax) ------------------ "SMTP Service Extension for Immediate Delivery", Larry Masinter, N. Joffe, Dan Wing, 08/07/1998, This memo defines an extension to SMTP which provides a mechanism for requesting immediate message delivery over SMTP instead of normal store-and-forward delivery. It also provides a mechanism for querying the SMTP server if immediate delivery was successful, is still in progress, or was simply queued as a normal store-and-forward message. "GSTN address element extensions in e-mail services", C. Allocchio, 09/17/1998, The possible elements composing a 'Global Switched Telephone Network (GSTN) address in e-mail' (formerly known also as Public Switched Telephone Network - PSTN) can vary from a minimum number up to a really large and complex collection: the minimal format and general address syntax are defined in [1], together with the syntax to define additional address elements. "Terminology and Goals for Internet Fax", Larry Masinter, 09/24/1998, This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including 'real-time', 'session', and 'store and forward'. Different levels of desirability are indicated throughout the document. "Using Message Disposition Notifications to Indicate Supported Features", Larry Masinter, Dan Wing, 03/10/1998, This document describes how Message Disposition Notifications [MDN] are used to indicate the supported features of a user's Mail User Agent (MUA). Knowing the supported features of a recipient or the recipient's MUA allows a sender to generate messages which take advantage of those features. Features indicate the MIME content-types are supported by the Mail User Agent, or finer gradations of features such as resolution, maximum image size, or software version number. The representation of features is still under discussion in the CONNEG working group. Features are registered using the framework described in [FEATURES]. "Extended Facsimile Using Internet Mail", Larry Masinter, Dan Wing, 11/12/1998, This document describes extensions to 'Simple Mode of Facsimile Using Internet Mail' [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users. NOTE: The authors of this document have recently been made aware of several intellectual property claims that relate to the technology described in this document, including US patents 5812278 and 5805298. This disclosure is being made according to the rules laid out in RFC 2026 and 2028, where contributors are required to disclose the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. These intellectual property claims may interfere with this specification moving forward along standards track. "Scenarios for Internet fax message confirmation", G. Klyne, 04/06/1998, The simple mode for Internet fax described in [1] does not provide positive confirmation of message delivery or disposition. There is a widespread view that an important benefit of traditional fax [2] is the fact that it provides a delivery confirmation which is trusted by fax system users. This memo describes some of the options for message confirmation in Internet fax, taking account of the particular nature and goals of the application [3], with a view to informing the debate over what mechanisms should be used for this purpose. "Extended MDN for Internet Fax Full Mode", Toru Maeda, 09/11/1998, This memo defines an additional MIME content-type defined in Message Disposition Notifications (MDN) that may be used by a mail user agent (UA) which is capable of Internet Fax Full Mode with Capabilities exchange and Confirmation of receipt. This content-type is intended to be machine-processable. Additional message headers are also defined to permit that the sender (of the message) requires Message Disposition Notifications (MDNs). MDN is 'An Extensible Message Format for Message Disposition Notification' in RFC2298. "Scenarios for Internet fax capability exchange", G. Klyne, 05/05/1998, The simple mode for Internet fax described in [1] relies on transmission of documents using a minimum feature set to achieve interoperability between sender and receiver. Proposals for extended Internet fax [2,3] aim to provide for transmission of enhanced documents (e.g. higher resolutions, colour) by employing mechanisms to identify recipient capabilities to the sender, in the same fashion as traditional Group 3 fax [4]. This memo describes some of the scenarios for capability exchange in Internet fax, taking account of the particular nature and goals of the application [5], with a view to informing the debate over what mechanisms should be used for this purpose. "Facsimile Applications for Internet Fax Full Mode", Toru Maeda, 07/28/1998, This memo explains Internet Fax Full Mode facsimile applications which can be implemented using the method of capability exchange in Internet Fax Full Mode. These applications are the same as implemented in G3FAX using T.30 protocol. These applications will be implemented under the Internet Draft 'Extended MDN for Internet Fax Full Mode' or other capability exchange mechanism. "Extensions to Message Disposition Notifications for Reporting on Multipart/Alternative Messages", Dan Wing, 08/04/1998, This document describes how a Message Disposition Notification can be returned which indicates which part(s) of a multipart/ alternative message the recipient processed. "Indicating Supported Media Features Using Extensions to DSN and MDN", Dan Wing, 10/26/1998, A device, unlike a workstation, is not generally extensible by installing a new reader, plugin, or other software. There is a need in Internet mail for a recipient to indicate the media features it supports so that messages can be generated by senders without exceeding the recipient's abilities. This memo describes a format for generating Message Disposition Notifications [RFC2298] and Delivery Status Notifications [RFC1894] which contain such information. This information can be used by senders to avoid exceeding the recipient's capabilities when sending subsequent messages. "Expressing Fax Capabilities in Internet Protocols", Dan Wing, 08/10/1998, This document describes how the DIS Standard Capabilities and Non-Standard Capabilities (NSF) of [T.30] can be expressed using the format described by the IETF Content Negotiation Working Group [MEDIA-FEATURES, FEATURE-ALGEBRA, FEATURE-REG]. The format described in this document, and the format described in [FEATURE-ALGEBRA] is intended to be usable in many Internet protocols and by a variety of methods. The specific methods are not described by this document. "MIME content-type for Internet Fax Full Mode", Toru Maeda, 10/20/1998, This memo defines a mechanism and formats for the Internet FAX Full Mode using a MIME content-type and an extended Message Disposition Notifications (MDN). Both of the MIME content-type and the extended MDN should be used by a mail user agent (UA) which is capable of Internet Fax Full Mode with capabilities exchange and confirmation of receipt. The MIME content-type that is used by Internet Fax Full Mode capable agent (UA) or electronic mail gateway to request, to response, and to receive the capabilities of recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit capabilities exchange in the Internet Fax Full Mode. The extended Message Disposition Notifications (MDN) that is used by a mail user agent (UA) which is capable of Internet Fax Full Mode for processing confirmation. This content-type is intended to be machine-processable. Additional message headers are also defined to permit that the sender (of the message) requires Message Disposition Notifications (MDNs). MDN is 'An Extensible Message Format for Message Disposition Notification' in RFC2298. "Content feature schema for Internet fax", G. Klyne, L. McIntyre, 11/19/1998, This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5]. "Internet fax T.30 Feature Mapping", G. Klyne, L. McIntyre, 09/29/1998, This document describes how to map Group 3 fax capability identification bits, described in ITU-T.30 [6], into the Internet fax feature schema described in 'Content feature schema for Internet fax' [4]. This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms [1,2,3], for use in performing capability identification between extended Internet fax systems [5]. Common Indexing Protocol (find) ------------------------------- "A Tagged Index Object for use in the Common Indexing Protocol", Roland Hedberg, R. Moats, M. Wahl, B. Greenblatt, 04/27/1998, This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as a the appropriate meanings for the headers that are defined in the Common Indexing Proto- col. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CCSO servers and many others. "CIP Index Object Format for SOIF Objects", Mike Schwartz, D. Hardy, M. Bowman, E. Hardie, Duane Wessels, 10/31/1997, The Common Indexing Protocol (CIP) allows servers to form a referral mesh for query handling by defining a mechanism by which cooperating servers exchange hints about the searchable indices they maintain. The structure and transport of CIP are described in (Ref. 1), as are general rules for the definition of index object types. This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. SOIF is a machine-readable syntax for transmitting structured summary objects, currently used primarily in the context of the World Wide Web. Query referral has often been dismissed as an ineffective strategy for handling searches of Web resources, and Web resources certainly present challenges not present in structured directory services like Rwhois. In situations where a keyword-based free text search is desired, query referral is not likely to be effective because the query will probably be routed to every server participating in the referral mesh. Where a search can be limited by reference to a specific resource attribute, however, query referral is an effective tool. SOIF can be used to create such a known-attribute query mesh because it provides a method for associating attributes with net-addressable resources. Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each contributed to the creation of the SOIF format and to the descriptions from which this draft is drawn; errors in this description of their work are the responsibility of Edward Hardie and corrections should be directed accordingly. "Registration Procedures for SOIF Template Types", E. Hardie, 05/27/1997, The Summary Object Interchange Format [Ref. 1] was first defined by the Harvest Project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF Working Group (IAFA) templates [Ref 3.] and the BibTeX bibliography format [Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates. SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases. This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see [Ref. 1]. "CIP Transport Protocols", P. Leach, J. Allen, 06/10/1997, This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH]. "MIME Object Definitions for the Common Indexing Protocol (CIP)", Michael Mealling, J. Allen, 11/23/1998, The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. "The Architecture of the Common Indexing Protocol (CIP)", Michael Mealling, J. Allen, 11/23/1998, The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. "LDAPv2 client Vs the Index Mesh", Roland Hedberg, 01/16/1998, Since LDAP v2 clients implemented according to RFC 1777 [1] has no notion on referral. The integration between such a client and a Index mesh, as defined by the current Common Indexing Protocol draft [2], who heavily depends on referrals has to be handled in a somewhat special way. This document defines one possible way of doing this. Frame Relay Service MIB (frnetmib) ---------------------------------- "Frame Relay Switched PVC MIB", B. Coutts, 11/17/1998, 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 Frame Relay Switched Permanent Virtual Circuits (SPVCs). This memo does not specify a standard for the Internet community. Extensions to FTP (ftpext) -------------------------- "Extended Directory Listing, TVFS, and Restart Mechanism for FTP", Robert Elz, Paul Hethmon, 03/09/1998, In order to overcome the problems caused by the undefined format of the current FTP LIST command output, a new command is needed to transfer standardized listing information from Server-FTP to Client- FTP. Commands to enable this are defined in this document. In order to allow consenting clients and servers to interact more freely, a quite basic, and optional, virtual file store structure is defined. This proposal also extends the FTP protocol to allow character sets other than US-ASCII[1] by allowing the transmission of 8-bit characters and the recommended use of UTF-8[2] encoding. Much implemented, but long undocumented, mechanisms to permit restarts of interrupted data transfers in STREAM mode, are also included here. This version contains editorial, grammar, spelling, and punctuation corrections. The Trivial Virtual File Store first appears in this version. It gives some semantics to path names, and modifies the specification of the ''cdir'' file type listing to make use of TVFS semantics when available, and be undefined otherwise. The ''Open Questions'' section has not been altered. All previously open questions remain open. There are still no examples (other than one for TVFS). This paragraph will be deleted from the final version of this document. "Internationalization of the File Transfer Protocol", B. Curtin, 05/27/1998, The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII. This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. "FTP Security Considerations", S. Ostermann, Mark Allman, 10/21/1998, The specification for the File Transfer Protocol contains a number of mechanisms that can be used to compromise network security. The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force 'password guessing' attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. G and R for Security Incident Processing (grip) ----------------------------------------------- "Security Expectations for Internet Service Providers", Tom Killalea, 03/12/1998, The purpose of this document is to express the general Internet community's expectations of Internet Service Providers (ISPs) with respect to security. It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers. HyperText Transfer Protocol (http) ---------------------------------- "PEP - an Extension Mechanism for HTTP", D. Connolly, H. Nielsen, R. Khare, Eric Prud''hommeaux, 12/04/1997, HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI[2], and use a few new RFC 822[1] derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1[7]. PEP is intended to be compatible with HTTP/1.0[5] inasmuch as HTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7). It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications. "HTTP State Management Mechanism", D. Kristol, L. Montulli, 07/29/1998, This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with TTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.) This document reflects implementation experience with RFC 2109 [RFC2109] and obsoletes it. "HTTP Trust Mechanism for State Management", D. Jaye, 03/06/1998, This document specifies an addition to the state management protocol specified in draft-ietf-http-state-man-mec-08[Kristol]. The intent is to provide a mechanism that allows user agents to determine the privacy practices of a server and to accept or reject cookies based on those practices. Allowing the user to establish preferences for how to handle cookies based on the server's practices provides a practical mechanism to provide users control over the privacy implications of cookies. To provide verification of server privacy practices, we assume the existence of one or more independent Trust Authorities. The authority establishes PICS ratings representing server privacy practices. It then issues trust-labels, in the form of digitally signed PICS labels, to organizations for specific domains and paths based on the server privacy practices. The Trust Authority must be able to audit domains to verify their adherence to a given level. Passing these trust-labels along with cookies allows the user agent to support cookie handling preferences based on trusted privacy practices. This document describes how PICS-headers are used in conjunction with Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels to communicate the privacy practices of servers regarding cookies. "Format and Example of HTTP/1.1 Requirements Summary", J Mogul, 09/15/1997, RFC1122 [1] introduced a ``Requirements Summary'' format, to help implementors understand what aspects of a lengthy specification were mandatory, recommended, or optional. The HTTP/1.1 specification is similarly lengthy and complicated; many implementors have asked for guidance in understanding what they need to do. The latest draft revision of the HTTP/1.1 specification [2] has a placeholder section for a ``Requirements Summary'', but there has been relatively little discussion of the format and content of this summary in the HTTP working group. This document proposes a specific format for the summary, and gives an example summary for one section of the document. "The Alternates Header Field", E. Hardie, K. Holtman, A. Mutz, 11/13/1997, This document proposes a header, Alternates, which is intended to provide a common method for Internet-based application protocols to indicate that a particular resource exists in multiple forms. The Alternates header provides a machine-readable indication of the bases on which the different forms vary and how the the recipient of the header can select among them. "Hypertext Transfer Protocol -- HTTP/1.1", J Mogul, Tim Berners-Lee, Larry Masinter, P. Leach, R. Fielding, H. Nielsen, Jim Gettys, 11/24/1998, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for^M many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is^M the typing and negotiation of data representation, allowing systems^M to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as 'HTTP/1.1', and is an update to RFC 2068 [33]. "HTTP Authentication: Basic and Digest Access Authentication", J. Franks, A. Luotonen, P. Leach, J. Hostetler, P. Hallam-Baker, L. Stewart, Scott Lawrence, 09/11/1998, 'HTTP/1.0' includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext. This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as 'Digest Access Authentication'. It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added -for compatibility, those new elements have been made optional, but are strongly recommended. Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Definitions of Managed Objects for the Ethernet-like Interface Types", Jeff Johnson, J. Flick, 06/04/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 ''Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2.'' This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2", Keith McCloghrie, Donna McMaster, Dan Romascanu, S. Roberts, Andrew Smith, J. Flick, K. De Graaf, 11/06/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 2239, ''Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2''. This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. "Definitions of Managed Objects for the Ethernet-like Interface Types", Jeff Johnson, J. Flick, 11/18/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 2358 ''Definitions of Managed Objects for the Ethernet-like Interface Types''. This memo extends that specification by including management information useful for the management of 1000 Mb/s and full-duplex Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. Internet Architecture Board (iab) --------------------------------- "The Case for IPv6", Bob Fink, Dimitry Haskin, C Perkins, Ruth Fax, Wenken Ling, Thomas Meehan, Steve King, 11/18/1998, This document outlines the business and technical case for IPv6. It is intended to acquaint both the existing IPv4 community with IPv6, to encourage its support for change, and to attract potential future users of Internet technology. "Architectural Implications of NAT", Tony Hain, 11/04/1998, In light of the growing interest in, and deployment of network address translation (NAT) [RFC-1631], this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in [RFC-1631]. "Report on the 1998 IAB Routing Workshop", R. Perlman, Susan Hares, C Perkins, Steve Deering, 11/18/1998, This document is an overview of a Routing workshop held by the Internet Architecture Board during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion. The full body of the report will be provided in a separate document. "Security Mechanisms for the Internet", Steve Bellovin, 11/20/1998, Many different mechanisms can be used to provide security for protocols. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each. Inter-Domain Multicast Routing (idmr) ------------------------------------- "Protocol Independent Multicast-Sparse Mode (PIM-SM): Motivation and Architecture", Deborah Estrin, V. Jacobson, D. Farinacci, L. Wei, Steve Deering, Mark Handley, David Thaler, Ching-Gung Liu, Puneet Sharma, A. Helmy, 08/05/1998, Traditional multicast routing mechanisms (e.g. DVMRP and MOSPF [1][2]) were intended for use within regions where groups are widely represented or bandwidth is universally plentiful. When group members, and senders to those group members, are distributed sparsely across a wide area, these schemes are not efficient; data packets or membership report information are periodically sent over many links that do not lead to receivers or senders, respectively. This characteristic lead the Internet community to investigate multicast routing architectures that efficiently establish distribution trees across wide-area internets, where many groups are sparsely represented and where bandwidth is not uniformly plentiful due to the distances and multiple administrations traversed. Efficiency is evaluated in terms of the state, control message processing, and data packet processing required across the entire network in order to deliver data packets to the members of the group. "Internet Group Management Protocol MIB", Keith McCloghrie, D. Farinacci, David Thaler, 07/30/1998, This memo defines an experimental 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 the Internet Group Management Protocol (IGMP). All of this MIB module is applicable to IP multicast routers [17,18,19,20,21]; a subset is applicable to hosts implementing IGMPv1 [16] or IGMPv2 [22]. "IP Multicast Routing MIB", Keith McCloghrie, D. Farinacci, David Thaler, 07/24/1998, This memo defines an experimental 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 IP Multicast Routing [16], independent of the specific multicast routing protocol [17-21] in use. Managed objects specific to particular multicast routing protocols are specified elsewhere. "Protocol Independent Multicast MIB", Keith McCloghrie, D. Farinacci, David Thaler, 07/30/1998, This memo defines an experimental 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 the Protocol Independent Multicast (PIM) protocol [16,17,18,19]. This MIB module is applicable to IP multicast routers which implement PIM. "A ''traceroute'' facility for IP Multicast.", Stephen Casner, Bill Fenner, 08/07/1998, This draft describes the IGMP multicast traceroute facility. As the deployment of IP multicast has spread, it has become clear that a method for tracing the route that a multicast IP packet takes from a source to a particular receiver is absolutely required. Unlike unicast traceroute, multicast traceroute requires a special packet type and implementation on the part of routers. This speci- fication describes the required functionality. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). "Distance Vector Multicast Routing Protocol", T. Pusateri, 08/11/1998, DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88]. "Core Based Tree (CBT) Multicast Border Router Specification", Tony Ballardie, B. Cain, Z. Zhang, 03/12/1998, This draft specifies the behaviour of a CBT multicast border router (BR). This specification assumes the use of CBTv3 - the latest CBT protocol version [3]. CBTv3 has capabilities which make CBT equally well suited for use in stub- or transit- domains; this draft describes mechanisms which enable a CBT distribution tree to span only those routers and links leading to interested receivers or receiver-domains. "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Deborah Estrin, David Meyer, David Thaler, 11/20/1998, This document describes BGMP, a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and allows receiver domains to build source-specific, inter-domain, distribution branches where needed. Building upon concepts from CBT and PIM-SM, BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). BGMP assumes that at any point in time, different ranges of the class D space are associated (e.g., with MASC [MASC]) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby "Domain Wide Multicast Group Membership Reports", Bill Fenner, 08/07/1998, When running a multi-level multicast routing protocol, upper levels need to know about group memberships in lower levels in a protocol-independent fashion. Domain Wide Multicast Group Membership Reports allow this information to be learned in a fashion similar to IGMP[Fenn97] at the domain level. This document is a product of the IDMR working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author. "Internet Group Management Protocol, Version 3", Steve Deering, B. Cain, A. Thyagarajan, 12/03/1997, ZZThis document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IP 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 is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). "PIM Version 2 DR Election Priority Option", L. Wei, 03/05/1998, This draft specifies the DR Election Priority Option in PIM version 2 Hello messages. "Core Based Trees (CBT version 3) Multicast Routing -- Protocol Specification --", Tony Ballardie, B. Cain, Z. Zhang, 07/31/1998, This document describes the Core Based Tree (CBT version 3) network layer multicast routing protocol. CBT builds a shared multicast dis- tribution tree per group, and is suited to inter- and intra-domain multicast routing. CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1]. This specification supercedes and obsoletes RFC 2189. Changes from RFC 2189 include support for source specific joining and pruning to provide better CBT transit domain capability, new packet formats, and new robustness features. Section 1 documents the primary changes to RFC 2189. This document is progressing through the IDMR working group of the IETF. CBT related documents include [1, 2, 3, 5, 8]. For all IDMR- related documents, see http://www.cs.ucl.ac.uk/ietf/idmr. "IGMP Multicast Router Discovery", B. Cain, Shantam Biswas, 03/12/1998, Companies have been proposing ''IGMP snooping'' type schemes for layer-2 bridging devices. A method for discovery multicast capable routers is necessary for these schemes. An IGMP query message is inadequate for discoverying multicast routers as one querier is elected. In order to ''discover'' multicast routers, we introduce two new types of IGMP messages: Multicast Router Advertisement and Multicast Router Solicitation. These two messages can be used by any device which listens to IGMP to discovery multicast routers. "DVMRPv1 Applicability Statement for Historic Status", Rob Coltun, T. Pusateri, Steve Deering, Ravi Shekhar, 08/05/1998, DVMRP version 1 (DVMRPv1) [RFC-1075] has been declared a historic document. This applicability statement provides the supporting motivation for that declaration. Inter-Domain Routing (idr) -------------------------- "A Border Gateway Protocol 4 (BGP-4)", Tony Li, Y Rekhter, 08/06/1998, The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", J. Burruss, Jodi Ito, Jeff Johnson, S. Willis, J. Chu, 03/15/1996, This memo is an extension to the SNMP MIB. It specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. The origin of this memo is from RFC 1269 'Definitions of Managed Objects for the Board Gateway Protocol (Version 3)' written by the first two authors of this memo, which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB was converted to use the SNMPv2 SMI, as well as updates references to the Draft Standard SNMPv2 SMI documents. Distribution of this memo is unlimited. Please forward comments to bgp@ans.net. "A Framework for Inter-Domain Route Aggregation", J. Stewart, E. Chen, 08/07/1998, This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implement' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. "Route Aggregation Tutorial", E. Chen, John Stewart III, 03/13/1998, Route aggregation is critical to the long-term viability of the Internet. This document presents practical information that network managers can use to both understand the concepts of aggregation as well as put those concepts into use in order to do their part to make the Internet stable and allow its continued growth. The intended audience for this document is anyone responsible for configuring a network which has its own Autonomous System Number (ASN) and exchanges routing information with its Internet Service Provider(s) (ISP(s)) using the Border Gateway Protocol (BGP). This document does not cover multi-homing, though multi-homed sites can still benefit from understanding this material. "Capabilities Negotiation with BGP-4", J. Scudder, R. Chandra, 08/11/1998, Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability negotiation without requiring that BGP peering be terminated. "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", F. Dupont, Pedro Marques, 02/09/1998, BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. "Multiprotocol Extensions for BGP-4", D Katz, Y Rekhter, T. Bates, R. Chandra, 08/11/1998, Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. IETF Steering Group (iesg) -------------------------- "(DRAFT) Checklist for RFC Authors", Keith Moore, 04/24/1998, This is a list of things that often delay processing of RFCs by IESG and/or the RFC Editor, and which are often preventable by RFC authors. The purpose of this document is to list in one place the most frequent causes of unnecessary delay, and thereby help RFC authors mini- mize such delays when possible. This document is emphatically NOT an expression of IESG policy, nor that of the RFC Editor, and is provided merely for informational pur- poses. When appropriate, this document attempts to provide references to other documents, some of which are expressions of IESG, IETF, and/or RFC Editor policy and others which are merely informational. Readers are advised to check the official status of each reference. The RFC Editor's instructions to RFC Authors are in [rfc-instruc- tions]. "On the use of HTTP as a Substrate for Other Protocols", Keith Moore, Patrik Faltstrom, 08/06/1998, Recently there has been widespread interest in using Hypertext Transport Protocol (HTTP) as a substrate for other applications-level protocols. This document relates current IESG and IAB thinking on technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This thinking is subject to change as discussion continues and more experience is gained with such use. "Applicability Statement for HTTP State Management", Keith Moore, 11/23/1998, The mechanisms described in 'HTTP State Management Mechanism' [RFC- XXXX] and its predecessor [RFC-2109], can be used for many different purposes. Even though this protocol has been approved for the Internet standards track, some current and potential uses of the protocol are not within the scope of the standard approved by IESG. This memo identifies specific uses of HTTP State Management protocol which are either (a) nonstandard and thus not recommended by IETF, or (b) nonstandard, believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. Interfaces MIB (ifmib) ---------------------- "IP Tunnel MIB", David Thaler, 03/13/1998, This memo defines an experimental 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 tunnels of any type in IP networks, including GRE [16,17], IP- in-IP [18], Minimal Encapsulation [19], L2TP [20], L2F [25], and PPTP [21] tunnels. Extension MIBs (e.g., [22]) may be designed for managing protocol-specific objects. "The Inverted Stack Table Extension to the Interfaces Group MIB", Keith McCloghrie, Gary Hanson, 07/17/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. "The Interfaces Group MIB",, 07/22/1998, 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 Network Interfaces. This memo discusses the 'interfaces' group of MIB-II [17], especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. This memo obsoletes RFC 2233, the previous version of the Interfaces Group MIB. The key words 'MUST' and 'MUST NOT' in this document are to be interpreted as described in RFC 2119 [16]. Integrated Services (intserv) ----------------------------- "Integrated Services Management Information Base",, 10/13/1997, 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 the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internetworking Over NBMA (ion) ------------------------------- "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", G. Armitage, M. Jork, P. Schulter, G. Harter, 10/21/1998, This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described. Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor Discovery protocol operation within Logical Links, and inter-router NHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported. "Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)", Maria Greene, Joan Cucchiara, J. Luciani, 11/20/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. This memo does not specify a standard for the Internet community. "Inverse Address Resolution Protocol", C. Brown, Andy Malis, T. Bradley, 07/27/1998, This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. Specifically, this applies to Frame Relay stations that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a hardware address, associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address of the station on the other side of this connection. It will also apply to other networks with similar circumstances. This memo replaces RFC 1293. The changes from RFC 1293 are minor changes to formalize the language, the additions of a packet diagram and an example in section 7.2, and a new security section. "A Distributed ATMARP Service Using SCSP", Joel Halpern, J. Luciani, B. Fox, 11/18/1998, This document describes a method for distributing an ATMARP service within a LIS[1]. This method uses the Server Cache Synchronization Protocol (SCSP)[2] to synchronize the ATMARP server databases within a LIS. When SCSP is used to synchronize the caches of ATMARP servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). "ILMI-Based Server Discovery for ATMARP", Michael Davison, 10/21/1998, This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM address of servers, shall be used to locate ATMARP servers. "ILMI-Based Server Discovery for MARS", Michael Davison, 10/21/1998, This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM address of servers, shall be used to locate MARS servers. "ILMI-Based Server Discovery for NHRP", Michael Davison, 10/21/1998, This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM address of servers, shall be used to locate NHRP servers. "IPv6 over ATM Networks", G. Armitage, M. Jork, P. Schulter, 10/21/1998, This document is a companion to the ION working group's architecture document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'. It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. "Transmission of IPv6 Packets over Frame Relay Networks Specification", Andy Malis, A. Conta, Martin Mueller, 11/21/1997, This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. "Proxy PAR", Antoni Przygienda, Patrick Droz, 11/21/1997, Proxy PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy PAR is designed as a client/server interaction where the client side is much simpler than the server side to allow fast implementation and deployment. The purpose of Proxy PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR addresses mainly protocols available in IPv4. But it also disposes of a generic interface to access the flooding of PAR. In addition, Proxy PAR capable servers provide filtering based on VPN IDs, IP protocols and address prefixes. This enables for instance routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients. "Definitions of Managed Objects for Server Cache Synchronization Protocol Using SMIv2", J. Luciani, Colin Verrilli, Cliff Wang, 10/09/1998, This document defines the Management Information Base (MIB) for supporting Server Cache Synchronization Protocol (SCSP)[1], [2], [3], [4]. SCSP is used to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. In a client/server paradigm, SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group. The MIB module specified in this document follows the Structure of Management Information (SMI) for the Simple Network Management Protocol (SNMP) Version 2. "NHRP with Mobile NHCs", D. Horton, Naganand Doraswamy, J. Luciani, H. Suzuki, 04/10/1998, This document describes an extension for Mobile NHCs to use when they register with their home LIS but initially connect to a non-serving NHS to do so. "NHRP Flow Extension", Lou Berger, Rob Enns, 07/01/1998, This document presents an extension to NHRP [RFC2332] that enables resolution of NBMA next hop addresses based on destination flow information. This extension also enables NHSs to relay simple forwarding policy to source stations (NHCs). "Definitions of Managed Objects for ATMARP dependent Server Cache Synchronization Protocol Using SMIv2", J. Luciani, Colin Verrilli, Cliff Wang, 10/09/1998, This document defines the ATMARP[2], [3] protocol dependent part Management Information Base (MIB) for supporting Server Cache Synchronization Protocol (SCSP)[1]. SCSP is used to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. In a client/server paradigm, SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group. The MIB module specified in this document follows the Structure of Management Information (SMI) for the Simple Network Management Protocol (SNMP) Version 2. "Multiprotocol Encapsulation over ATM Adaptation Layer 5", Juha Heinanen, Daniel Grossman, 10/28/1998, This memo describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection. IP Over IEEE 1394 (ip1394) -------------------------- "IPv4 over IEEE 1394", Peter Johansson, 09/15/1998, This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary methods, data structures and codes for that purpose and additionally defines a method for Address Resolution Protocol (ARP). "Multicast Channel Allocation Protocol (MCAP) for IEEE 1394", Peter Johansson, 04/23/1998, This docuent specifies how IP-capable Serial Bus devices may allocate IEEE 1394 channel nuber(s) for use in the multicast transmission of IP datagras. It defines the necessary methods, data structures and codes for that purpose. See also the ost recent revision of draft-ietf-ip1394-ipv4 for a specification of the transport of IPv4 datagras over IEEE 1394. CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe parts reflect rough consensus achieved at the 41st IETF eeting in Los Angeles, other parts reflect the editor's distillation of coments on the reflector since then and still other parts are new contributions to the evolution of MCAP. Until subsequent revisions of this docuent are posted that ore clearly identify agreed areas, the reader should consider this a work in progress very uch subject to revision. This docuent is not yet adopted by the IP/1394 working group. "DHCP on IEEE 1394", Kenji Fujisawa, 11/11/1998, IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages. IP over Cable Data Network (ipcdn) ---------------------------------- "Cable Device Management Information Base for MCNS compliant Cable Modems and Cable Modem Termination Systems", G. Roeck, 10/21/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS compliant Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", G. Roeck, 10/26/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. "Logical IP Subnetworks over IEEE 802.14 Services", Mark Laubach, 03/13/1998, This memo defines an initial application of classical IP and ARP in an IEEE 802.14 Community Access Television (CATV) Residential Access Network environment. IEEE 802.14 services provide two independent link layer service interfaces which are available to support IP residential access networking services: traditional Ethernet bridging (via IEEE 802.1D layer services) and residential ATM networking services. In this memo, the term Logical IP Subnetwork (LIS) is defined to apply to Classical IP over ATM LIS's operating over IEEE 802.14 services as well as traditional IP over Ethernet operating over IEEE 802.14 services. The recommendations in this draft rely on existing IETF standards for the family of Classical IP and ARP over ATM (IPOA) services and for IP and ARP over Broadcast Ethernet networks. The tree-based hierarchic nature of the IEEE 802.14 MAC subnetwork permits convenient extensions to Classical IPOA model for broadcast and multicast in the downstream direction of the CATV plant. "Baseline Privacy Interface Management Information Base for MCNS Compliant Cable Modems and Cable Modem Termination Systems", R. Woundy, 07/22/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of the Baseline Privacy Interface for MCNS compliant cable modems and cable modem termination systems. This MIB is defined as an extension to the MCNS Radio Frequency Interface MIB [5]. This memo specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo does not specify a standard for the Internet community. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. "Telephony-Return Interface (TRI) Management Information Base for DOCSIS-compliant Telephony-Return Cable Modems and Cable Modem Termination Systems", Jack Fijolek, Srinivyasa Murthy Adiraju, 08/04/1998, This memo defines an experimental portion of the Management^M Information Base (MIB) for use with network management protocols in^M the Internet community. In particular, it defines a basic set of^M managed objects for SNMP-based management of MCNS compliant Cable^M Modems and Cable Modem Termination Systems. This memo specifies a^M MIB module in a manner that is compliant to the SNMPv2 SMI. The set^M of objects is consistent with the SNMP framework and existing SNMP^M standards. This memo does not specify a standard for the Internet^M community. This memo is a product of the IPCDN working group within^M the Internet Engineering Task Force. Comments are solicited and^M should be addressed to the working group's mailing list at^M ipcdn@terayon.com and/or the author.^M "Data Over Cable System Quality of Service Management Information Base (DOCSIS-QOS MIB)", M. Patrick, 08/12/1998, This document describes the control of the QOS features for the Cable Modem Termination System (CMTS) and Cable Modem (CM) entities of the Data Over Cable System Interface Specification (DOCSIS). The DOCSIS QOS framework can be found in [DOCSIS-QOS]. "Cable Device IGMP Proxy MIB for DOCSIS compliant Cable Modems", Jonathan Fellows, 08/12/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of conditional access to IP multicast groups by DOCSIS compliant cable modems. This memo specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo does not specify a standard for the Internet community. IP Over Fibre Channel (ipfc) ---------------------------- "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", K. Teow, 11/03/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "IP and ARP over Fibre Channel", Raj Bhagwat, Murali Rajagopal, Wayne Rickard, 10/26/1998, Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards [3] do not adequately specify how IP packets may be transported over FC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. "Fibre Channel Interconnect MIB", Kim Banker, 08/06/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the operations of any Fibre Channel Interconnection device, or set of devices. An example of a Fibre Channel Interconnection would be a FC-AL repeater (or hub) or a FC Fabric Switch. IPNG (ipngwg) ------------- "Generic Packet Tunneling in IPv6 Specification", A. Conta, Steve Deering, 02/06/1998, This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. "IP Header Compression", S. Pink, M. Degermark, B. Nordgren, 07/07/1998, This document describes how to compress multiple IP headers and TCP and UDP headers per-hop over point-to-point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. "IPv6 Router Alert Option", C. Partridge, D Katz, A. Jackson, 04/17/1998, This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. "A Method for the Transmission of IPv6 Packets over ARCnet Networks.", I. Souvatzis, 09/28/1998, This memo specifies a frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in [DISC], when those messages are transmitted on an ARCnet. "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", Brian Carpenter, C. Jung, 10/28/1998, This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a 'virtual Ethernet.' "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6", Lixia Zhang, Allison Mankin, J. Stewart, Thomas Narten, M. Crawford, 11/20/1998, On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a node internal to a site with only the local routing and end-point identification portions of the address, thus hiding the full address from the node. When such a node generates a packet, only the low-order bytes of the source address are specified; the high-order bytes of the address are filled in by a border router when the packet leaves the site. There is a long history of a vague assertion in certain circles that IPv4 'got it wrong' by treating its addresses simultaneously as locators and identifiers. Despite these claims, however, there was never a complete proposal for a scaleable network protocol which separated the functions. As a result, it wasn't possible to do a serious analysis comparing and contrasting a 'separated' architecture and an 'overloaded' architecture. The GSE proposal serves as a vehicle for just such an analysis, and that is the purpose of this paper. We conclude that an architecture that clearly separates locators and identifiers in addresses introduces new issues and problems that do not have an easy or clear solution. Indeed, the alleged disadvantages of overloading addresses turn out to provide some significant benefits over the non-overloaded approach. "Router Renumbering for IPv6", M. Crawford, 11/10/1998, IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. "IPv6 Name Lookups Through ICMP", M. Crawford, 03/10/1998, IPv4 addresses are translated to fully-qualified domain names (FQDNs) using the DNS. Experience shows that the IN-ADDR.ARPA zones used for this translation tend to be poorly maintained in some cases. In a larger internet with more frequent site renumbering, the maintenance of such zones will be even more difficult. This document describes an experimental protocol for simply asking an IPv6 node to supply its FQDN when needed. The DNS style of authority delegation is thus eliminated for IPv6 address-to-name translations and the routing infrastructure plays that role. "Site prefixes in Neighbor Discovery", Erik Nordmark, 08/31/1998, This document specifies extensions to IPv6 Neighbor Discovery to carry site prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. This protocol requires that all IPv6 implementations, even those that do not implement this protocol, ignore all site-local addresses that they retrieve from the DNS. "DNS Extensions to support IP version 6", Christian Huitema, Susan Thomson, 02/09/1998, This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new 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. "Basic Socket Interface Extensions for IPv6", Robert Gilligan, W. Stevens, Jim Bound, Susan Thomson, 11/12/1998, The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. "Reverse Address lookup in DNS for IPng.", O. Gudmundsson, 12/03/1997, This document proposes a new mechanism to represent inverse address mapping in the Domain Name System (DNS) for IP version 6 (IPv6). Documented in here are the changes needed for securing the binding and delegation of address ranges, to facilitate queries for the binding of address to host name. This document also defines a mechanism for dumb resolvers to query directly for the binding. The changes include a new resource record to delegate the address space in segments based on arbitrary bit boundaries. This proposal provides a mechanism that is self checking and can be traversed from both top and bottom. Additional processing requirements on IPv6 aware resolvers and servers are defined. "Forcing Fragmentation to Network MTU", M. Andrews, 01/27/1998, There exists a class of applications which cannot accept Path MTU discovery [RFC-1981]. This is recommended to be turned on by default for IPv6 [IPV6-SPEC-V2, 4.5, 5]. This document describes an extension to the BSD API [RFC-2133] to inform the kernel when it should be fragmenting at the network MTU rather than trying to discover the path MTU. Path MTU discovery works well when there is a stream of data. However for distributed servers sending small answers larger than the network MTU to many clients the lack of fragmentation in intermediate nodes is anathema. RFC-1981 Section 5.6 recommends that a system utility be provided to: - Specify that Path MTU Discovery not be done on a given path. - Change the PMTU value associated with a given path. This documents specifies how to do the same at the application level to a individual socket. "Multicast Listener Discovery (MLD) for IPv6", Steve Deering, Bill Fenner, Brian Haberman, 03/06/1998, This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol [IGMPv2]. One important difference to note is that MLD uses ICMPv6 [ICMPv6] (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. This document is a product of the IP Next Generation working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipng@sunroof.Eng.Sun.COM and/or the author(s). "DNS Extensions to Support IP Version 6", Christian Huitema, Susan Thomson, M. Crawford, 09/15/1998, This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering, and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new domain to hold the top-level delegation information and a zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. "The IPv6 Jumbo Payload Option", Bob Hinden, Steve Deering, 08/07/1998, This document describes the Jumbo Payload option for IPv6, which is used to send IPv6 packets with payloads longer than 65,535 octets. This option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. "Reserved IPv6 Subnet Anycast Addresses", Steve Deering, D. Johnson, 10/19/1998, The IP Version 6 addressing architecture defines an 'anycast' address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. "Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6)", Brian Haberman, 09/22/1998, This document outlines a mechanism for generating routing tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward scoped unicast and multicast addresses regardless of the routing protocol. It should be noted that these rules will apply to all scoped addresses. "A method for flexible IPv6 address assignments", Marc Blanchet, 10/22/1998, This draft presents a method for assigning IP address prefixes that enables the IP assigning autority - the organisation that assigns IP address prefixes to other organisations, like a registry to an internet service provider or an internet service provider to a client organisation connected to its network -to postpone the final decision of prefix length by keeping space between assigned bits of the different parts of the IP address. This enables the assigning autority to change the different part lengths of the prefix (TLA (top level aggregator), subTLA, NLA(next-level aggregator) SLA (site-level aggregator), ...) even after allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the address space is larger and more flexible. It is a generalization of RFC1219 and can be used for IPv6 assignments based on RFC2373 and RFC2374. "Initial IPv6 Sub-TLA ID Assignments", Bob Fink, Bob Hinden, Steve Deering, Tony Hain, 11/17/1998, This document proposes initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups as an aid in starting the process of allocating IPv6 addresses. It is not intended for any official IETF status. Internet Printing Protocol (ipp) -------------------------------- "Design Goals for an Internet Printing Protocol", F. Wright, 11/19/1998, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. "Internet Printing Protocol/1.0: Model and Semantics", P. Powell, T. Hastings, R. Herriot, S. Isaacson, R. deBry, 11/19/1998, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. This document also addresses security, internationalization, and directory issues. "Mapping between LPD and IPP Protocols", J. Martin, T. Hastings, R. Herriot, N. Jacobs, 11/20/1998, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified in RFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. WARNING: RFC 1179 was not on the IETF standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementers. "Internet Printing Protocol/1.0: Encoding and Transport", R. Turner, R. Herriot, Sylvan Butler, Paul Moore, 11/20/1998, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called 'application/ipp'. This document also defines the rules for transporting over HTTP a message body whose Content-Type is 'application/ipp'. "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", Steve Zilles, 11/19/1998, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. "Requirements for IPP Notifications", R. deBry, 03/11/1998, This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). "DHCP Option for Internet Printing Protocol Services", R. Turner, 03/10/1998, This document defines a new DHCP option for automatic configuration of Internet Printing Protocol (IPP)[1] services to potential clients. Services. This new option provides an IPP client with enough configuration information to initiate a session with an IPP server without manual configuration of the client, and without existing directory services. "Internet Printing Protocol/NV: IPP URL Scheme", R. Herriot, Carl-Uno Manros, 11/20/1998, Internet Printing Protocol/NV (IPP/NV) is the next version of IPP, which is an application level protocol for distributed printing on the Internet. This document describes a new 'ipp' scheme, which is intended to identify URLs that reference an IPP printing service. "Internet Printing Protocol/1.0: Implementer's Guide", T. Hastings, Carl-Uno Manros, 11/19/1998, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [IPP-MOD] and the IPP Transport and Encoding [IPP-PRO] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. IP Performance Metrics (ippm) ----------------------------- "A One-way Delay Metric for IPPM", Guy Almes, S. Kalidindi, Matthew Zekauskas, 11/03/1998, This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1]; the reader is assumed to be familiar with that document. This memo is intended to be parallel in structure to a companion document for Packet Loss ('A Packet Loss Metric for IPPM' ) [2]. "A One-way Packet Loss Metric for IPPM", Guy Almes, S. Kalidindi, Matthew Zekauskas, 11/03/1998, This memo defines a metric for one-way packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1]; the reader is assumed to be familiar with that document. This memo is intended to be parallel in structure to a companion document for One-way Delay (currently 'A One-way Delay Metric for IPPM' ) [2]; the reader is assumed to be familiar with that document. "IPPM Metrics for Measuring Connectivity", J. Mahdavi, Vern Paxson, 11/23/1998, Connectivity is the basic stuff from which the Internet is made. Therefore, metrics determining whether pairs of hosts (IP addresses) can reach each other must form the base of a measurement suite. We define several such metrics, some of which serve mainly as building blocks for the others. This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. The reader is assumed to be familiar with that document. "Instantaneous Packet Delay Variation Metric for IPPM", Carlo Demichelis, 11/02/1998, This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on statistics of the difference in One-Way-Delay of consecutive packets. This particular definition of variation is called 'Instantaneous 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. In the second case it allows an evaluation of the reciprocal skew. Measurements performed on both directions (Two-ways measurements) allow a better estimation of clock differences. The precision that can be obtained is evaluated. "A Round-trip Delay Metric for IPPM", Guy Almes, S. Kalidindi, Matthew Zekauskas, 11/23/1998, This memo defines a metric for round-trip delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1], and follows closely the corresponding metric for One-way Delay ('A One-way Delay Metric for IPPM' ) [2]; the reader is assumed to be familiar with those documents. The memo was largely written by copying material from the One-way Delay metric. The intention is that, where the two metrics are similar, they will be described with similar or identical text, and that where the two metrics differ, new or modified text will be used. This memo is intended to be parallel in structure to a future companion document for Packet Loss. "Empirical Bulk Transfer Capacity",, 11/23/1998, Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. However, there are many congestion control algorithms (and hence transport implementations) permitted by IETF standards. This diversity in transport algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric. This document defines a framework for standardizing multiple BTC metrics that parallel the permitted transport diversity. Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF protocol. Pseudo-code or reference implementations are expected to be the norm. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC. IP Security Protocol (ipsec) ---------------------------- "The ESP Triple DES Transform", P. Karn, W. Simpson, Naganand Doraswamy, Perry Metzger, 07/03/1997, This document describes the 'Triple' DES-EDE3-CBC block cipher transform interface used with the IP Encapsulating Security Payload (ESP). It provides compatible migration from RFC-1851. "ESP with Cipher Block Chaining (CBC)", W. Simpson, 07/03/1997, This document describes the Cipher Block Chaining (CBC) mode, used by a number of IP Encapsulating Security Payload (ESP) transforms. "The ESP DES-XEX3-CBC Transform", W. Simpson, R. Baldwin, 07/23/1998, This document describes the 'DESX' DES-XEX3-CBC block cipher trans- form interface used with the IP Encapsulating Security Payload (ESP). "The ISAKMP Configuration Method", B. Patel, R. Pereira, S. Anand, 05/21/1998, This document describes a new ISAKMP method that allows configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms. "The Use of HMAC-RIPEMD-160-96 within ESP and AH", Angelos Keromytis, Niels Provos, 07/24/1998, This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. "A GSS-API Authentication Mode for ISAKMP/Oakley", D. Piper, 12/23/1997, This document describes an alternate authentication method for ISAKMP/Oakley which makes use of GSS-API to authenticate the Diffie- Hellman exchange. The mechanism described here extends the authentication modes defined in [Harkins97] without introducing any modifications to the ISAKMP/Oakley key exchange protocol. This constraint however, necessarily restricts the number of GSS-API exchanges and may limit the broader applicability of this method. Additional work is needed to provide a fully generalized solution. Such a solution will require ISAKMP/Oakley protocol modifications. For a list of changes since the previous version of this document, please see Section 5. "Dynamic remote host configuration over IPSEC using DHCP", B. Patel, 12/04/1997, IPSEC is a protocol suite defined by IETF working group on IP security to secure communication at the network layer between communicating peers. This protocol is comprised of three primary elements: 1) ISAKMP/Oakley[2], 2) IPSEC AH [4]and 3) IPSEC ESP [5]. ISAKMP/Oakley is the key management protocol while AH and ESP are used to protect IP traffic. Both AH and ESP can be used in tunnel or transport mode. Among many applications enabled by IPSEC tunnel and transport modes, an interesting and useful application is connect a remote host (e.g., roaming user) to the intranet through firewall (or secure network gateway) using IPSEC tunnels. "Revised SA negotiation mode for ISAKMP/Oakley", B. Patel, Michael Jeronimo, 12/04/1997, ISAKMP/OAKLEY [2][3] is the key management protocol defined by IPSEC working to be a framework for authentication, security association negotiation and key management. The protocol defines two phases whereby, in the phase 1, the peers are authenticates, the security association (SA) for ISAKMP/Oakley, and keying material is agreed upon by the peers to secure ISAKMP messages. The phase 2 is used to negotiate security association for security applications (e.g., IPSEC AH and ESP). When perfect forward secrecy is required, phase 2 is also used to exchange keying material for the application. However, when perfect forward secrecy is not a requirement, the keying material from the phase 1 is used to generate session keys for the secure communication applications. The proposal in this document is based on the observation that when perfect forward secrecy is not a requirement, if application specific SA was negotiated during phase 1, the application can start immediately after phase 1. The phase 2 can be used subsequently for key refresh on per need bases in the future. Therefore, this proposal reduces startup time for communication and improves the efficiency of the protocol. Remark: This document is NOT self-contained, it is intended as an addendum to [2][3]. Thus, it is best read in conjunction with [2][3]. "Extended Authentication Within ISAKMP/Oakley", R. Pereira, 11/09/1998, This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. "IPSec Policy Data Model", P. Bhattacharya, R. Pereira, 02/25/1998, This document presents a data model for IPSec policy based on ISAKMP. "The Pre-Shared Key for the Internet Protocol", D. Piper, D. Harkins, 04/06/1998, Recent efforts from the IPsec Working Group of the IETF in securing the Internet ([AH], [ARCH], [ESP], [ESPBLOW], [ESPCAST], [ESPCBC], [ESPNULL], [ESP3D], [DES], [DESMAC], [HMACMD5], [HMACSHA], [IKE], [DOI], [IPCOMP], [ISAKMP], and [OAKLEY]) imply the continued use of pre-shared keys. This document defines the Pre-Shared Key for the Internet. "A DH-less encryption mode for IKE", H. Krawczyk, P. Cheng, R. Canetti, 07/06/1998, This draft describes a ``DH-less'' version of the (revised) public-key encryption mode of [HC98]. This saves the DH exponentiation, which may be significant (especially on low-end machines and busy servers). The proposed mode is VERY similar to the existing modes and requires only minimal modifications. In particular, it is straightforward to implement as an addition to the existing modes. "A Framework for Group Key Management for Multicast Security", Naganand Doraswamy, B. Cain, Thomas Hardjono, 08/05/1998, This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). These regions are defined to have unique group keys and are open to differing (inter-region or intra-region) group key management protocols. The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. "PKI Requirements for IP Security", Rodney Thayer, 09/15/1998, The IP Security (IPSec) protocol set now being defined in the IETF uses public key cryptography for authentication in its key management protocol. This document defines the requirements that IPSec has for Public Key Infrastructure (PKI) protocols, formats, and services. "IPSec Monitoring MIB", Tim Jenkins, 11/11/1998, This document defines monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. Further, it does not provide policy information. Those MIBs may be defined in later versions of this document or in other documents. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. The IPSec MIB definitions use a virtual tunnel model, of which there can be configured permanent tunnels or transient tunnels. The virtual tunnel model is used to allow the use of IPSec from a virtual private networking (VPN) point of view. This allows users of IPSec based products to get similar monitoring and statistical information from an IPSec based VPN as they would from a VPN based on other technologies, such as Frame Relay. Finally, the objects defined perhaps represent a somewhat simplified view of security associations. This is done for the purposes of expediency and for simplification of presentation. Also, some information about SAs has been intentionally left out to reduce the security risk if SNMP traffic becomes compromised. "IPv4 ICMP messages and IPsec security gateways", M. Richardson, 09/28/1998, This document enumerates the list of ICMP messages that a security gate- way may receive and provides an analysis of if and how a gateway should handle them. Three options types of behaviour are enumerated: discard, MAY be forwarded, and MUST be forwarded. "Options for handling ICMP messages that must be forwarded", M. Richardson, 09/28/1998, This document discusses three options for securely communicating ICMP messages from one IPsec security gateway to another. This document expands upon section 6 of the IPsec architecture draft. "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)", R. Rajan, P. Bhattacharya, R. Adams, R. Pereira, William Dixon, 10/09/1998, This document describes the structure of an LDAP directory schema that enables policy based configuration and administration of IPSec based Virtual private networks within and among Internet domains, intranets, and extranets. The schema extends the base IPSec Policy data model in [9] to include end hosts and security gateways. The schema closely follows and expands on the DEN specification [7]. "Secure Configuration of IPsec-Enabled Network Devices", Mike St. Johns, Scott Kelly, 10/14/1998, Remote configuration of network devices which implement IPsec- related services is desirable as a matter of convenience and of scale. In some cases, these devices are installed on a network with no prior configuration. In such cases, secure mechanisms for bootstrap configuration are required. In this document the associated issues are examined, and a multi-tiered approach is proposed from which a specific method may be selected based upon the security requirements of the environment in which the security device exists. While the primary devices considered here are security gateways and bump-in-the-wire encryptors, many of the resulting conclusions may extend to other devices, including host IPsec implementations. "Security Policy Specification Language", Charles Lynn, John Zao, Matt Condell, 10/19/1998, This document describes the Security Policy Specification Language (SPSL), a language designed to express security policies, security domains, and the entities that manage the policies and domains. The syntax and semantics of the language are presented here. SPSL currently supports policies for packet filtering, IP Security (IPSec), and ISAKMP exchanges, however, it may easily be extended to express other types of policies. "Intra-Domain Group Key Management Protocol", B. Cain, Indermohan Monga, Thomas Hardjono, 11/10/1998, This document describes a protocol for intra-domain group key management for IP multicast security, based on the framework of [HCD98]. In order to support multicast groups, the domain is divided into a number of administratively-scoped 'areas'. A host-member of a multicast group is defined to reside within one (and only one) of these areas. The purpose of placing host-members in areas is to achieve flexible and efficient key management, particularly in the face of the problem of changes (joining, leaving, ejections) in the membership of a multicast group. A separate administratively-scoped area control-group is defined for each (data) multicast group, for the express purpose of key management and other control-message delivery. IP Telephony (iptel) -------------------- "A Framework for a Gateway Location Protocol", Jonathan Rosenberg, H. Schulzrinne, 10/29/1998, This document serves as a framework for a protocol for locating an IP telephony gateway. It defines terminology, specifies the various architectural elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. "Call Processing Language Requirements", H. Schulzrinne, Jonathan Lennox, 08/06/1998, A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architecture for such a method, which we call a call processing language. It also outlines requirements for such a language. "A Framework for a Peer Gatekeeper Routing Protocol", Ronald Davis, 11/16/1998, Within the ITU H.323 recommendation, the gatekeeper is a central point of communication for H.323 elements within a zone. All elements within the zone establish a communication channel with the gatekeeper over a registration, admission, and status (RAS) channel. Elements within a zone register with the gatekeeper and are subsequently able to communicate with other elements in the zone, or outside of the zone. What is needed in addition to the normal registration and connection admission procedures of H.323 is a means of acquiring information about elements in other zones. This document describes the framework for a peer gatekeeper routing protocol (pgrp) which allows gatekeepers to exchange information with other gatekeepers about elements in their respective zones. PGRP is a protocol supports the exchange of information among gatekeepers which may be used to make call routing decisions in a network. PGRP attempts to extend reliability concepts from telecommunications by incorporating maintenance state information exchange. This allows call routing decisions to be based upon the operational state of elements in the network. This feature is particularly useful in the H.323 gatekeeper mediated call model where a call may be completed to a pool of connection endpoints. An example of such a scenario is in the use of an H.323 to connect telecom end offices which connect to multiple H.323 gateways. In this context, pgrp is also able to support call distribution to balance the call load among the connection gateways serving an end office. IP over VBI (ipvbi) ------------------- "THE TRANSMISSION OF IP OVER THE VERTICAL BLANKING INTERVAL OF A TELEVISION SIGNAL", Dan Zigmond, R. Panabaker, Simon Wegerif, 10/22/1998, This is an Internet-Draft, which describes a method for broadcasting multicast IP data using the vertical blanking interval of television signals. It includes a description for compressing multicast IP headers on unidirectional networks, a framing protocol identical to SLIP, a forward error correction scheme, and the NABTS byte structures. Keywords: VBI, broadcast, push, FEC, television, NABTS, IP, multicast. IS-IS for IP Internets (isis) ----------------------------- "Optional Checksums in ISIS", Antoni Przygienda, 11/24/1998, This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], 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 as IGP. IS-IS originally doesn't provide CSNP adn 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 TLV providing checksums. "Maintaining more than 255 adjacencies in IS-IS", Antoni Przygienda, 11/24/1998, This draft describes an optional implementation technique within IS-IS [ISO90, Cal90a, Cal90b] 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 as IGP. This draft describes how to effectively bypass the problem of 255 circuits that IS-IS allows to maintain with minor violations of the specification that however does not prevent interoperability with existing implementations. Integrated Services over Specific Link Layers (issll) ----------------------------------------------------- "Providing integrated services over low-bitrate links", C. Bormann, 08/06/1998, This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B- channels, and sub-T1 links. It covers only the lower parts of the Internet Multimedia Conferencing Architecture [1]; additional components required for application services such as Internet Telephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real- time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. "SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks", R. Yavatkar, Fred Baker, D. Hoffman, M. Speer, Y. Bernet, 11/20/1998, This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee. "The Multi-Class Extension to Multi-Link PPP", C. Bormann, 08/06/1998, A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. This document proposes the fragment-oriented solution for the real- time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol [2] and provide a small number of extensions to add functionality and reduce the overhead. "A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies", M. Seaman, Andrew Smith, Vijay Srinivasan, W. Pace, A. Ghanwani, 11/24/1998, This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queueing support in LAN switches. It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol (RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13]. "PPP in a real-time oriented HDLC-like framing", C. Bormann, 08/06/1998, A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol [2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible. "Network Element Service Specification for Low Speed Networks", S. Jackowski, David Putzolu, 11/20/1998, This document defines the service mappings for controlled load and guaranteed services over low-bitrate networks. These low-bitrate networks typically include components such as analog phone lines, ISDN connections and sub-T1 rate links. The document specifies the per- network element packet handling behavior, parameters required, traffic specification, policing requirements, and traffic ordering relationships which are required to provide both Guaranteed and Controlled Load service capabilities. It also includes evaluation criteria for elements providing the service. This document is a product of the IETF ISSL working group and is based on [1] and [2] which describe modifications to the PPP protocol to enable these services. "Integrated Service Mappings on IEEE 802 Networks", M. Seaman, Andrew Smith, John Wroclawski, Eric Crawley, 11/23/1998, This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1 MAC Bridges (switches) [1][2]. It describes parameter mappings for supporting Controlled Load [6] and Guaranteed Service [7] using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches [2]. These mappings are one component of the Integrated Services over IEEE 802 LANs framework described in [5]. LDAP Extension (ldapext) ------------------------ "Use of Language Codes in LDAP", Tim Howes, M. Wahl, 07/17/1998, The Lightweight Directory Access Protocol [1] provides a means for clients to interrogate and modify information stored in a distributed directory system. The information in the directory is maintained as attributes [2] of entries. Most of these attributes have syntaxes which are human-readable strings, and it is desirable to be able to indicate the natural language associated with attribute values. This document describes how language codes [3] are carried in LDAP and are to be interpreted by LDAP servers. All implementations MUST be prepared to accept language codes in the LDAP protocols. Servers may or may not be capable of storing attributes with language codes in the directory. This document does not specify how to determine whether particular attributes can or cannot have language codes. "LDAP Control Extension for Simple Paged Results Manipulation", Chris Weider, Tim Howes, A. Herron, Anoop Anantha, 08/07/1998, This document describes an LDAPv3 control extension for simple paging of search results. This control extension allows a client to control the rate at which an LDAP server returns the results of an LDAP search operation. This control may be useful when the LDAP client has limited resources and may not be able to process the entire result set from a given LDAP query, or when the LDAP client is connected over a low-bandwidth connection. Other operations on the result set are not defined in this extension. This extension is not designed to provide more sophisticated result set management. The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to be interpreted as described in [bradner97]. "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", B. Morgan, J. Hodges, M. Wahl, 11/24/1998, This document defines the 'Start Transport Layer Security (TLS) Opera- tion' for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- ment in an LDAP association and is defined in terms of an LDAP extended request. "Access Control Requirements for LDAP", B. Blakley, E. Stokes, Debbie Byrne, Prasanta Behera, 08/07/1998, This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. The RFC 2119 terminology is used in this document. "Authentication Methods for LDAP", B. Morgan, Harald Alvestrand, J. Hodges, M. Wahl, 11/17/1998, This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. "The Java LDAP Application Program Interface", Tim Howes, Mark Smith, R. Weltman, Christine Ho, 07/14/1998, The LDAP class library is designed to provide powerful, yet simple, access to a LDAP directory services. It defines a synchronous interface to LDAP, with support for partial results on searching, to suit a wide variety of applications. This document gives a brief overview of the LDAP model, then an overview of the constituents of the class library. The public class methods are described in detail, followed by an appendix that provides some example code demonstrating the use of the classes, and an appendix listing changes from earlier drafts. "LDAP Extensions for Scrolling View Browsing of Search Results", Chris Weider, David Boreham, Jim Sermersheim, 11/23/1998, This document describes a Virtual List View control extension for the LDAP Search operation. This control is designed to allow the 'virtual list box' feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. The control allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value. "Persistent Search: A Simple LDAP Change Notification Mechanism", Tim Howes, Mark Smith, G. Good, R. Weltman, 08/07/1998, This document defines two controls that extend the LDAPv3 [LDAP] search operation to provide a simple mechanism by which an LDAP client can receive notification of changes that occur in an LDAP server. The mechanism is designed to be very flexible yet easy for clients and servers to implement. "LDAPv3 Triggered Search Control", M. Wahl, 08/11/1998, This document defines a LDAPv3 [2] control to be used on the Search Request to allow a client to retrieve information on changes which are made to the directory information tree held by that server. "LDAP Control Extension for Server Side Sorting of Search Results", Chris Weider, Tim Howes, M. Wahl, A. Herron, Anoop Anantha, 08/07/1998, This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted. Other permissible controls on search operations are not defined in this extension. The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation. The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to be interpreted as described in [bradner97]. "Referrals and Knowledge References in LDAP Directories",, 03/13/1998, This document defines a ''ref'' attribute and associated ''referral'' object class for representing generic knowledge information in LDAP directories [RFC2251]. The attribute uses URIs [RFC1738] to represent knowledge, enabling LDAP and non-LDAP services alike to be referenced. The object class can be used to construct entries in an LDAP directory containing references to other directories or services. This document also defines procedures directory servers should follow when supporting these schema elements. "LDAP C API Extensions for Scrolling View Browsing of Search Results", Mark Smith, 04/01/1998, This document defines extensions to the LDAP C API to support the LDAP Extensions for Scrolling View Browsing of Search Results. More specifi- cally, this document defines functions to create Virtual List View Request controls and to parse Virtual List View Response controls. "LDAP C API Extensions for Persistent Search", Mark Smith, 03/16/1998, This document defines extensions to the LDAP C API to support the LDAP Persistent Search Simple Change Notification Mechanism. More specifi- cally, this document defines functions to create Persistent Search con- trols and to parse Entry Change Notification controls. "The C LDAP Application Program Interface", Chris Weider, Tim Howes, Mark Smith, M. Wahl, A. Herron, Anoop Anantha, 08/10/1998, This document defines a C language application program interface (API) to the Lightweight Directory Access Protocol (LDAP). This document replaces the previous definition of this API, defined in RFC 1823, updating it to include support for features found in version 3 of the LDAP protocol. New extended operation functions were added to support LDAPv3 features such as controls. In addition, other LDAP API changes were made to support information hiding and thread safety. The C LDAP API is designed to be powerful, yet simple to use. It defines compatible synchronous and asynchronous interfaces to LDAP to suit a wide variety of applications. This document gives a brief overview of the LDAP model, then an overview of how the API is used by an applica- tion program to obtain LDAP information. The API calls are described in detail, followed by an appendix that provides some example code demon- strating the use of the API. "Access Control Model for LDAP", B. Blakley, E. Stokes, Debbie Byrne, 11/23/1998, This document describes the access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. A separate document defines the corresponding application programming interfaces (APIs). RFC2219 [Bradner97] terminology is used. "Signed Directory Operations Using S/MIME", B. Greenblatt, P. Richard, 10/08/1998, In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are 'journal entries' is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information. "X.509 Authentication SASL Mechanism", Steve Kille, 07/01/1998, This document defines a SASL [1] authentication mechanism based on X.509 strong authentication [3], providing two way authentication. This mechanism is only for authentication, and has no effect on the protocol encodings and is not designed to provide integrity or confidentiality services. "LDAP Control for a Duplicate Entry Representation of Search Results", Jim Sermersheim, 11/24/1998, This document describes a Duplicate Entry Representation control extension for the LDAP Search operation. By using the control with an LDAP search, a client requests that the server return separate entries for each value held in the specified attributes. For instance, if a specified attribute of an entry holds multiple values, the search operation will return multiple instances of that entry, each instance holding a separate single value in that attribute. Large Scale Multicast Applications (lsma) ----------------------------------------- "Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment", Mark Pullen, Michael Myjak, C. Bouwens, 11/12/1998, The Large-Scale Multicast Applications (LSMA) working group was chartered to produce Internet-Drafts aimed at a consensus-based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This draft defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. "Taxonomy of Communication Requirements for Large-scale Multicast Applications", P Bagnall, B Briscoe, Alan Poppitt, 05/20/1998, The intention of this draft is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimise the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardising the way that applications define their requirements is a necessary step towards this. Classification is a first step towards standardisation. Mail and Directory Management (madman) -------------------------------------- "Directory Server Monitoring MIB", Steve Kille, Glenn Mansfield, 11/06/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1567 'X.500 Directory Monitoring MIB'. This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoring Directory Servers. "Network Services Monitoring MIB", Steve Kille, Ned Freed, 11/16/1998, A networked application is a realization of some well defined service on one or more host computers that is accessible via some network, uses some network for its internal operations, or both. Multicast-Address Allocation (malloc) ------------------------------------- "The Multicast Address Set Claim (MASC) Protocol", Deborah Estrin, Mark Handley, R. Govindan, David Thaler, Pavlin Radoslavov, Satish Kumar, 08/11/1998, This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist. "Multicast address allocation based on the Dynamic Host Configuration Protocol", Steve Hanna, B. Patel, M. Shah, 11/10/1998, This document defines a protocol, MDHCP, that allows hosts to request multicast addresses from multicast address allocation servers. MDHCP is similar to DHCP, but not dependent on it. Mobile Ad-hoc Networks (manet) ------------------------------ "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", Joseph Macker, Scott Corson, 10/16/1998, This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. "Mobile Ad Hoc Networking Terminology", C Perkins, 11/18/1998, This document presents conventional definitions for many terms to be used during the discussion of various algorithms for enabling ad hoc networks of mobile computers, particularly over wireless media. "The Zone Routing Protocol (ZRP) for Ad Hoc Networks", Zygmunt Haas, Marc Pearlman, 09/08/1998, This document describes the Zone Routing Protocol (ZRP), a hybrid routing protocol suitable for a wide variety of mobile ad-hoc networks, especially those with large network spans and diverse mobility patterns. Each node proactively maintains routes within a local region (referred to as the routing zone). Knowledge of the routing zone topology is leveraged by the ZRP to improve the efficiency of a reactive route query/reply mechanism. The proactive maintenance of routing zones also helps improve the quality of discovered routes, by making them more robust to changes in network topology. The ZRP can be configured for a particular network by proper selection of a single parameter, the routing zone radius. This version of the ZRP internet draft describes a number of features which have been added to the protocol. The distance-vector based IARP algorithm has been enchanced to prevent the 'counting to infinity problem'. Route caching is now supported by the IERP route discovery process. By allowing discovered route information to be distributed in caches, route accumulation in the IERP query/ reply packets can be avoided, thereby reducing the amount of route discovery traffic, and improving the query response time. Two additional (optional) stages have also been added to the route discovery process, to support the acquisition and optimization of source routes. "Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification", Scott Corson, Vincent Park, 08/11/1998, This document provides a detailed specification of Version 1 of the Temporally-Ordered Routing Algorithm (TORA)--a distributed routing protocol for mobile, multihop, wireless networks. Its intended use is for routing of Internet Protocol (IP) datagrams within an autonmous system. The basic, underlying algorithm is neither a distance-vector nor a link-state; it is one of a family of algorithms referred to as ``link reversal'' algorithms. The protocol's reaction is structured as a temporally-ordered sequence of diffusing computations, each computation consisting of a sequence of directed link reversals. The protocol is highly adaptive, efficient and scalable; and is well- suited for use in large, dense, mobile networks. In these networks, the protocol's reaction to link failures typically involves only a localized ``single pass'' of the distributed algorithm. This desirable behavior is achieved through the use of a physical or logical clock to establish the ``temporal order'' of topological change events. The established temporal ordering is subsequently used to structure (or order) the algorithm's reaction to topological changes. "An Internet MANET Encapsulation Protocol (IMEP) Specification", Scott Corson, Vincent Park, Philip Papadopoulos, Spyro Papademetriou, Amir Qayyum, 08/11/1998, This memo describes a multipurpose network-layer protocol---named the Internet MANET Encapsulation Protocol (IMEP)---designed to support the operation of many routing algorithms, network control protocols or other Upper Layer Protocols (ULP) (where ``upper "Ad Hoc On Demand Distance Vector (AODV) Routing", C Perkins, Elizabeth Royer, 11/20/1998, The Ad Hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network characterized by frequent changes in link connectivity to each other caused by relative movement. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and establishment of both unicast and multicast routes between sources and destinations which are loop free at all times. It makes use of destination sequence numbers, which are a novel means of ensuring loop freedom even in the face of anomalous delivery of routing control messages, and solving classical problems associated with distance vector protocols, including the problem of ``counting to infinity''. "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks", D. Johnson, Dave Maltz, Josh Broch, 03/16/1998, Dynamic Source Routing (DSR) is a routing protocol designed specifically for use in mobile ad hoc networks. The protocol allows nodes to dynamically discover a source route across multiple network hops to any destination in the ad hoc network. When using source routing, each packet to be routed carries in its header the complete, ordered list of nodes through which the packet must pass. A key advantage of source routing is that intermediate hops do not need to maintain routing information in order to route the packets they receive, since the packets themselves already contain all of the necessary routing information. This, coupled with the dynamic, on-demand nature of Route Discovery, completely eliminates the need for periodic router advertisements and link status packets, reducing the overhead of DSR, especially during periods when the network topology is stable and these packets serve only as keep-alives. "Cluster Based Routing Protocol(CBRP) Functional Specification", Mingliang Jiang, Jinyang Li, Yong Chiang Tay, 08/03/1998, Cluster Based Routing Protocol (CBRP) is a routing protocol designed for use in mobile ad hoc networks. The protocol divides the nodes of the ad hoc network into a number of overlapping or disjoint clusters in a distributed manner. A cluster head is elected for each cluster to maintain cluster membership information. Inter-cluster routes are discovered dynamically using the cluster membership information kept at each cluster head. By clustering nodes into groups, the protocol efficiently minimizes the flooding traffic during route discovery and speeds up this process as well. Furthermore, the protocol takes into consideration of the existence of uni-directional links and uses these links for both intra-cluster and inter-cluster routing. "AMRoute: Adhoc Multicast Routing Protocol", Anthony McAuley, Ming-Kang Liu, R. Talpade, Ethendranath Bommaiah, 08/06/1998, The Adhoc Multicast Routing Protocol (AMRoute) allows for robust IP Multicast in mobile adhoc networks by exploiting user-multicast trees and dynamic cores. It creates a bidirectional shared-tree for data distribution using only the group senders and receivers as tree nodes. Unicast tunnels are used as the tree links to connect neighbors on the 'user-multicast tree.' Thus, AMRoute does not need to be supported by network nodes that are not interested/capable of multicast, and cost is incurred only by group senders and receivers. AMRoute makes certain nodes 'core nodes' to initiate the signaling component of AMRoute, such as detection of group members and tree setup. Core nodes differ significantly from those in CBT and PIM-SM, since they are not a central point for data distribution and can move dynamically among member nodes. Since AMRoute is not dependent on any specific unicast routing protocol, it can operate seamlessly over separate domains with different unicast protocols. "Core Extraction Distributed Ad hoc Routing (CEDAR) Specification", Raghupathy Sivakumar, Prasun Sinha, Vaduvur Bharghavan, 10/05/1998, This draft presents CEDAR, a Core-Extraction Distributed Ad hoc Routing algorithm for QoS routing in ad hoc network environments. CEDAR has three key components: (a) the establishment and maintenance of a self-organizing routing infrastructure, called the 'core', for performing route computations, (b) the propagation of the link-state of stable high-bandwidth links in the core through 'increase/decrease' waves, and (c) a QoS route computation algorithm that is executed at the core nodes using only locally available state. "MANET Routing Protocol Applicability Statement", Scott Corson, 11/02/1998, This memo puts forth a set of questions regarding Mobile Ad hoc Network (MANET) routing protocol functionality and applicability. Authors of MANET routing protocol draft submissions are requested to include these questions (and corresponding answers) in a section in their submissions. The intent of this 'Applicability Section' is to aid readers unfamiliar with the details of each protocol's design in understanding the protocol's basic characteristics, functioning and mechanisms, as well as to provide a general description of the networking context for which the protocol was designed, and in which it is expected to perform well. "Optimized Link State Routing Protocol", Amir Qayyum, Philippe Jacquet, Paul Muhlethaler, 11/19/1998, This document describes a routing protocol for mobile ad hoc networks. The protocol is based on the link state algorithm. It uses the multi-point relays to calculate the route towards any destination in the network. The protocol is particularly suitable to the large dense networks with high nodal mobility and topological changes. MBONE Deployment (mboned) ------------------------- "Multicast Debugging Handbook", B Aboba, David Thaler, 10/15/1998, This document serves as a handbook for the debugging of multicast con- nectivity problems. In addition to reviewing commonly encountered problems, the draft summarizes publicly distributable multicast diag- nostic tools, and provides examples of their use, along with pointers to source and binary distributions. "Multicast-Scope Zone Announcement Protocol (MZAP)", Mark Handley, David Thaler, 10/26/1998, This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby two common misconfigurations of administrative scope zones can be discovered. "IP Multicast and Firewalls", Ross Finlayson, 11/24/1998, Many organizations use a firewall computer that acts as a security gateway between the public Internet and their private, internal 'intranet'. In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. MIME Encapsulation of Aggregate HTML Documents (mhtml) ------------------------------------------------------ "Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", J. Palme, 06/17/1998, The memo 'MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)' (draft-ietf-mhtml-rev-05.txt) specifies how to send packaged aggregate HTML objects in MIME format. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", Nick Shelness, Alex Hopmann, J. Palme, 09/08/1998, HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies one MIME content-headers (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12. "The MIME Multipart/Related Content-type", Ed Levinson, 10/06/1998, The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SIP: Session Initiation Protocol", Jonathan Rosenberg, Eve Schooler, H. Schulzrinne, Mark Handley, 11/13/1998, The Session Initiation Protocol (SIP) is an application- layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. This document is a product of the Multi-party Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "SAP Security Using Public Key Algorithms", Peter Kirstein, G. Montasser-Kohsari, E. Whelan, 03/12/1998, The Session Announcement Protocol (SAP) has been specified in such a way that authentication and privacy can be assured. However the algorithms and mechanisms to achieve such security are not prescribed in the current draft. This document extends the SAP protocol, by describing specific algorithms and formats of authentication and encryption formats based on PGP and PKCS#7 standards. It is a companion document to draft-ietf-mmusic-sap. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "SIP Call Control Services", Jonathan Rosenberg, H. Schulzrinne, 03/16/1998, This document describes the org.ietf.sip.call extensions to the Session Initiation Protocol (SIP). The document also describes how standard telephony services can be implemented in SIP. "SIP Security Using Public Key Algorithms", Peter Kirstein, G. Montasser-Kohsari, E. Whelan, 03/18/1998, The Session Initiation Protocol (SIP) is a simple protocol designed to enable the invitation of users to multimedia sessions. This document is a companion draft to draft-ietf-mmusic-sip-04.txt, which defines SIP but doesn't specify any security mechanisms other than possible protection by lower-level security mechanisms such as SSL. This leaves SIP transactions vulnerable to attack and this document aims to extend the SIP protocol to address such security considerations. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "A Message Bus for Conferencing Systems", Joerg Ott, Colin Perkins, Dirk Kutscher, 08/11/1998, In a variety of scenarios, a local communication channel is desirable for conference-related information exchange between co-located but otherwise independent application entities, for example those taking part in application sessions that belong to the same conference. Such a mechanism allows for coordination of applications entities to e.g. implement synchronization between media streams or realize tightly coupled conferences. The local conference Message Bus (Mbus) provides a means to achieve the necessary amount of coordination between co-located conferencing applications for virtually any type of conference. The Message Bus comprises two logically distinct parts: a message transport and addressing infrastructure and a set of common as well as media tool specific messages. This documents deals with message addressing, transport, and security issues and defines the message syntax for the Mbus. It does not define application oriented semantics and procedures for using the message bus. The common procedures for Mbus operation as well as the common set of application/media specific messages are introduced in a companion Internet draft[9]. This document is intended for discussion in the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "Session Announcement Protocol: Version 2", Colin Perkins, Maryann Maher, 11/17/1998, This document describes modifications and enhancements to SAP, the session directory announcement protocol, for support of IPv6 conferencing environments. Along with support for IPv6, a couple new features are also introduced. This document compliments [SAP], which fully describes SAP in the context of IPv4. Readers are assumed to be familiar with [SAP]. Note: At this time, this document presents an initial set of ideas aimed solely at starting discussion within the working group. We await the RFC publication of [SAP] before finalizing any protocol specifications. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the author. "Reliability of Provisional Responses in SIP", Jonathan Rosenberg, H. Schulzrinne, 11/19/1998, This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. IP Routing for Wireless/Mobile Hosts (mobileip) ----------------------------------------------- "Route Optimization in Mobile IP", C Perkins, D. Johnson, 12/02/1997, This document defines extensions to the base Mobile IP protocol to allow for optimization of datagram routing from a correspondent node to a mobile node. Without Route Optimization, all datagrams destined to a mobile node are routed through that mobile node's home agent, which then tunnels each datagram to the mobile node's current location. The protocol extensions described here provide a means for correspondent nodes to cache the binding of a mobile node and to then tunnel their own datagrams for the mobile node directly to that location, bypassing the route for each datagram through the mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. "Mobility Support in IPv6", C Perkins, D. Johnson, 11/23/1998, This document specifies the operation of mobile computers using IPv6. 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 the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. "Firewall Support for Mobile IP", G. Montenegro, V. Gupta, 01/28/1998, The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space. "IP Mobility Support version 2", C Perkins, 11/14/1997, 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. "Registration Keys for Route Optimization", C Perkins, D. Johnson, 12/02/1997, Route optimization [6] defines extensions to Mobile IP [7] registration requests that allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. These extensions for smooth handoff require a registration key to be established between the mobile node and foreign agent. This document defines additional extensions to the registration requests to allow for the establishment of single-use registration keys between a mobile node and foreign agent. "Special Tunnels for Mobile IP", C Perkins, D. Johnson, 12/03/1997, This document defines actions taken by Mobile IP home agents and foreign agents to try to avoid loss of datagrams sent to an incorrect care-of address, even if a foreign agent has no binding for the mobile node. "Tunnel Establishment Protocol", C Perkins, G. Montenegro, Pat Calhoun, 03/18/1998, A general tunnel establishment protocol (TEP) is defined to handle multi-protocol tunneling as well as multilevel domains guarded by tunnel agents which may be thought of as security gateways, or alternatively as modified foreign agents defined by with Mobile IP. Mobile IP provides the model for TEP; the registration messages in RFC 2002 establish a tunnel between the home agent and the foreign agent. "Rapid Authentication for Mobile IP", Gregory Troxel, Luis Sanchez, 12/02/1997, This document describes a mechanism that provides Mobile IP nodes and agents with the necessary keys and information needed to establish mobility security associations within a foreign network. This mechanism aims at reducing the latency and computational burden introduced by public-key based key management protocols in network topologies where visiting mobile nodes register with their respective home agents several times through different foreign agents requiring Mobile-Foreign Authentication. This mechanism employs a key distribution center capable of generating the security contexts needed to authenticate Mobile IP control messages. This mechanism, designed as an extension to the Mobile IP protocol, preservs backward compatibility and interoperability with RFC2002 compliant implementations of Mobile IP. "Use of IPSec in Mobile IP", John Zao, Matt Condell, 01/08/1998, The use of IPSec ESP protocol in the Mobile IP packet redirection tunnels will protect the redirected packets against both passive and active attacks launched and aid these packets to traverse the firewalls surrounding both the home and the foreign subnets visited by the mobile nodes. This document proposes a scheme to negotiate the use of IPSec ESP on selected Mobile IP tunnels and a procedure to establish these tunnels with the aid of automatic key and security association management protocol such as ISAKMP. "Support for Mobile IP in Roaming", B Aboba, 03/13/1998, This document describes the issues involved in supporting Mobile IP in roaming. "Mobile IP Dynamic Home Address Allocation Extensions", C Perkins, Pat Calhoun, 11/18/1998, RFC2002 defines a method for a Mobile Node to be assigned a Home Agent dynamically through the use of a limited broadcast message. However, most corporate networks do not allow such packets to traverse through their firewall, which renders this feature difficult to use. This draft introduces new entity named the Home Domain Allocation Agency (HDAA) that can dynamically assign a Home Address to the Mobile Node. This draft also proposes a method for the HDAA to assign a dynamic Home Agent to the Mobile Node. "Mobile IP Regionalized Tunnel Management", C Perkins, G. Montenegro, Pat Calhoun, 11/20/1998, RFC2002 defines a method for a Mobile Node to be assigned a Home Agent dynamically through the use of a limited broadcast message. However, most corporate networks do not allow such packets to traverse through their firewall, which renders this feature difficult to use. This draft introduces new entity named the Home Domain Allocation Agency (HDAA) that can dynamically assign a Home Address to the Mobile Node. This draft also proposes a method for the HDAA to assign a dynamic Home Agent to the Mobile Node. "Mobile IP Foreign Agent Challenge/Response Extension", C Perkins, Pat Calhoun, 11/20/1998, RFC2002, which defines the base Mobile IP protocol, assumes that a shared secret exists with all mobility agents and the Mobile Node. However, in larger networks, this assumption can lead to scalability problems, especially in situations where the Mobility Agents are owned by different administrative domains. This document specifies the Router Advertisement and Mobile IP extensions necessary to integrate Mobile IP with Key Distribution Centers (KDC). Multiprotocol Label Switching (mpls) ------------------------------------ "A Framework for Multiprotocol Label Switching", Ross Callon, George Swallow, N. Feldman, A. Viswanathan, P. Doolan, A. Fredette, 11/26/1997, This document discusses technical issues and requirements for the Multiprotocol Label Switching working group. This is an initial draft document, which will evolve and expand over time. It is the intent of this document to produce a coherent description of all significant approaches which were and are being considered by the working group. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. Note that this document is at an early stage, and that most of the detailed technical discussion is only in a rough form. Additional text will be provided over time from a number of sources. A small amount of the text in this document may be redundant with the proposed protocol architecture for MPLS. This redundancy will be reduced over time, with the overall discussion of issues moved to be in this document, and the selection of specific approaches and specification of the protocol contained in the protocol architecture and other related documents. "Use of Label Switching With RSVP", Bruce Davie, Y Rekhter, A. Viswanathan, S. Blake, Vijay Srinivasan, E. Rosen, 03/12/1998, Multiprotocol Label Switching (MPLS) allows labels to be bound to various granularities of forwarding information, including application flows. In this document we present a specification for allocating and binding labels to RSVP flows, and to distributing the appropriate binding information using RSVP messages. "Multiprotocol Label Switching Architecture", Ross Callon, A. Viswanathan, E. Rosen, 07/13/1998, This internet draft specifies the architecture for multiprotocol label switching (MPLS). The architecture is based on other label switching approaches [2-11] as well as on the MPLS Framework document [1]. "MPLS Label Stack Encoding", D. Farinacci, Tony Li, A. Conta, Y Rekhter, Dan Tappan, E. Rosen, G. Fedorkow, 09/25/1998, 'Multi-Protocol Label Switching (MPLS)' [1,2] requires a set of procedures for augmenting network layer packets with 'label stacks', thereby turning them into 'labeled packets'. Routers which support MPLS are known as 'Label Switching Routers', or 'LSRs'. In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding. "The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol", M. Suzuki, 06/29/1998, The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM. "Use of Label Switching on Frame Relay Networks Specification", Andy Malis, A. Conta, P. Doolan, 11/20/1998, This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs). "VCID Notification over ATM link", Noritoshi Demizu, Hiroshi Esaki, K. Nagami, P. Doolan, 08/04/1998, The ATM Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC may change on each VC of that VC, it is not possible to use them to identify a VC in label binding messages. The concept of Virtual Connection Identifier (VCID) is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. "Carrying Label Information in BGP-4", Y Rekhter, E. Rosen, 08/05/1998, When a pair of Label Switch Routers (LSRs) that maintain BGP peering with each other exchange routes, the LSRs also need to exchange label mapping information for these routes. The exchange is accomplished by piggybacking the label mapping information for a route in the same BGP Update message that is used to exchange the route. This document specifies the way in which this is done. "Requirements for Traffic Engineering Over MPLS", Michael O'Dell, Joseph Malcolm, Johnson Agogbua, Daniel Awduche, Jim McManus, 08/28/1998, This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources, and enhance traffic oriented performance characteristics. "LDP Specification", Bob Thomas, N. Feldman, P. Doolan, Loa Andersson, A. Fredette, 11/17/1998, An overview of Multi Protocol Label Switching (MPLS) is provided in [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using the Label Distribution Protocol (LDP) referenced in [ARCH]. This document defines the LDP protocol. "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", Joan Cucchiara, J. Luciani, Hans Sjostrand, 08/31/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) as defined in [17]. This memo does not specify a standard for the Internet community. "MPLS using ATM VC Switching", Keith McCloghrie, Bruce Davie, George Swallow, Y Rekhter, E. Rosen, P. Doolan, Jeremy Lawrence, 11/18/1998, The MPLS Architecture [1] discusses a way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs. "Extensions to RSVP for LSP Tunnels", Der-Hwa Gan, Tony Li, George Swallow, Lou Berger, Vijay Srinivasan, Daniel Awduche, 11/19/1998, This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. Finally, we propose a number of mechanisms to reduce the refresh overhead of RSVP. The extensions can be used to reduce processing requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP message is lost and, when desired, eliminate the generation of refresh messages. An extension to support detection of when an RSVP neighbor resets its state is also presented. These extension present no backwards compatibility issues. Network Address Translators (nat) --------------------------------- "IP Network Address Translator (NAT) Terminology and Considerations", Pyda Srisuresh, Matt Holdrege, 10/23/1998, Network Address Translation is a method by which IP addresses are mapped from one realm to another, providing transparent routing to hosts. Traditionally, NATs are used to connect an isolated routing realm with private unregistered addresses to an external routing realm with globally unique registered addresses. This document attempts to describe the operation of NATs in general and to define the terminology used to identify various flavors of NAT. "DNS extensions to Network Address Translators (DNS_ALG)", Pyda Srisuresh, A. Heffernan, Praveen Akkiraju, George Tsirtsis, 10/23/1998, Domain Name Service(DNS) provides name to address mapping within a routing class (ex: IP). Network Address Translators (NATs) provide transparent routing between hosts in disparate routing realms of the same routing class. Typically, NATs exist at the border of a stub domain, hiding private addresses from external addresses. This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. DNS_ALG modifies payload transparently to alter address mapping of hosts as DNS packets cross one routing realm into another. The document also illustrates the operation of DNS_ALG with specific examples. "Traditional IP Network Address Translator (Traditional NAT)", Pyda Srisuresh, Kjeld Egevang, 11/02/1998, Basic Network Address Translation or Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a routing realm with private addresses to the external routing network with globally unique registered addresses. "Implications of NATs on the TCP/IP architecture", Y Rekhter, 08/07/1998, In light of the growing interest in, and deployment of network address translation (NAT - RFC 1631), this document will present some highlights of the architectural implications. A reader is assumed to be well familiar with the principles of NAT operations [RFC1631]. "IP Network Address Translator (NAT) Protocol Issues.", Pyda Srisuresh, Matt Holdrege, 11/18/1998, Many common internet applications can be adversely affected when the end-to-end significance of an IP packet is disrupted. Network Address Translation (NAT) can cause such disruptions both at the protocol level and with application data. While there are ready solutions for NATing each protocol listed, this document is only concerned with defining the native limitations. Future versions of this document may discuss workarounds. *NOTE* the authors wish to make it clear that this work is editorial in nature and that input from the Internet society is requested in order to better cover the range of applications that can be affected by NAT. This is a work in progress. "IP Network Address Translator Application Programming Interface", Pyda Srisuresh, 11/09/1998, NAT provides routing transparency for hosts in disparate routing realms to communicate with each other. However, external agents such as Application Level Gateways (ALGs), Host-NAT-clients and Management applications need to interact with NAT and influence its operations. The document identifies the resources and other elements controlled by a NAT device, with specific focus on areas subject to influence from external agents. An Application Programming Interface (API) framework by which external agents could interact with NAT is presented. The intent of this document is to leverage the API specification as a base to identify requirements for the development of one or more protocols by which external agents could interact with NAT. "Security for IP Network Address Translator (NAT) Domains", Pyda Srisuresh, 11/12/1998, There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Host-NAT-clients are allowed to pursue end-to-end IPsec secure sessions. However, all flavors of NAT can offer tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel mode IPsec security can be recognized on NAT devices. In addition, a section is devoted to describing how Secure policies may be communicated to IKE for automated KEY exchange and setup of Security Associations for an IPsec secure NAT gateway. "NAT Friendly Application Design Guidelines", D. Senie, 11/17/1998, While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. This document discusses those things which application designers might wish to consider when designing new protocols. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT. "IP Host Network Address (and Port) Translation", K. Taniguchi, Jeffrey Lo, 11/23/1998, Network Address Translation has become a popular technique that allows private addresses unregistered with Internet Assigned Number Authority (IANA) to be used by organizations within a private routing realm. These private addresses must not be advertised in the public Internet. Hence network address translator (NAT) are placed at the private routing realm border to translate private addresses to globally unique addresses and vice versa before packets are exchanged between the disparate routing realms. These modifications of the packet header by the NAT cause problems with the use of end-to-end security protocols such as IPSec and DNSSEC because network address translation does exactly what the security protocols are trying to prevent. Host Network Address Translation (HNAT) and Host Network Address Port Translation (NAPT), on the other hand, enable end hosts to carry out address (and port) translations before applying security algorithms. To make dynamic HNAT and HNAPT possible, three conditions are essential. First, there must exist a way for end hosts to discover the IP address of Host-NA(P)T-Server. Second, there must be a way for externally destined packets to be routed in the private domain between the Host -NA(P)T-Client and Host-NA(P)T-Server. Lastly, Host-NA(P)T-Client must be able to obtain an address (and port) binding from the Host-NA(P)T -Server dynamically. This draft aims to address these issues to a considerable extent. Methods suggested are by no means exhaustive in coverage and implementation specifics may vary from vendor to vendor. Network File System Version 4 (nfsv4) ------------------------------------- "NFS version 4 Strawman", Spencer Shepler, 08/06/1998, NFS version 4 is meant to be a further revision of the NFS protocol defined already by versions 2 and 3. It retains the essential characteristics of previous versions: stateless design for easy recovery, independent of transport protocols, operating systems and filesystems, simplicity, and good performance. This strawman is being offered as a starting point for future discussions and work on NFS version 4. The document contains ideas presented and discussed via email at nfsv4-wg@sunroof.eng.sun.com. Additional content has been added in areas with the intent of offering more suggestions for future discussion. Goals for NFS version 4 include: strong security, access and good performance via the Internet, cross-platform interoperability, and protocol extensibility. "NFS Version 4 Requirements", Spencer Shepler, 11/16/1998, With the creation of the NFS version 4 working group, a set of requirements for the next version of NFS must be codified to create a reasonable context for the new protocol discussions and aide in the upcoming decisions. This Internet Draft has the purpose of presenting the requirements for NFS version 4 and will be used as the leading document for NFSv4 working group. Next Generation Transition (ngtrans) ------------------------------------ "Stateless IP/ICMP Translator (SIIT)", Erik Nordmark, 11/10/1998, This document specifies a transition mechanism in addition to those already specified in RFC 1933. The new mechanism can be used as part of a solution that allows IPv6 hosts that do not have a permanently assigned IPv4 address to communication with IPv4-only hosts. "Transition Mechanisms for IPv6 Hosts and Routers", Robert Gilligan, Erik Nordmark, 08/11/1998, This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include pro- viding complete implementations of both versions of the Internet Pro- tocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual tran- sition of the entire Internet to IPv6. "6Bone Routing Practice", A. Durand, Bertrand Buclin, 05/27/1998, The 6Bone is an environment supporting experimentation with the IPv6 protocols and products implementing it. As the network grows, the need for common operation rules emerged. In particular, operation of the 6Bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites. This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC 2283]). "Network Address Translation - Protocol Translation (NAT-PT]", Pyda Srisuresh, George Tsirtsis, 11/09/1998, This document specifies a transition mechanism in addition to those already specified in [TRANS]. The new mechanism provides an end-to-end solution to allow IPv6-only hosts to communicate with IPv4-only hosts and vice versa using Network Address Translation and Protocol Translation. The scheme described does not require du- al-stack hosts; nor does it mandate any routing related changes on the hosts. The scheme is based on a combination of address transla- tion theme as described in [NAT] and V6/V4 protocol translation theme as described in [SIIT]. "Multihomed routing domain issues for IPv6 aggregatable scheme", F. Dupont, 02/03/1998, This document exposes some issues for multihomed routing domains using the aggregatable addressing and routing scheme. A routing domain is multihomed when it uses two or more providers of the upper level. Most of these issues are not specific to IPv6 but are consequences of the addressing and routing scheme. "Categorizing Translators between IPv4 and IPv6", K. Yamamoto, Munechika Sumikawa, 11/16/1998, This memo categorizes translators between IPv4 and IPv6. The two components, address interpretation and address mapping, are discussed. This draft is based on a paper appeared in the proceedings of INET98. The intention of this memo is circulation of such knowledge. "Dual Stack Hosts using the 'Bump-in-the-Stack' Technique", Yoshifumi Atarashi, Kazuaki Tsuchiya, Hidemitsu Higuchi, 11/16/1998, Especially in the early stage of the migration from IPv4 to IPv6, it is hard to prepare IPv6 applications completely. This memo pro- poses a mechanism of dual stack hosts using the technique called 'Bump-in-the-Stack' in the IP security area. The mechanism enables the hosts to communicate with other IPv6 hosts using IPv4 legacy applications. NNTP Extensions (nntpext) ------------------------- "Network News Transport Protocol", Stan Barber, 11/02/1998, The Network News Transport Protocol has been in use in the Internet for a decade and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977 and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality and provides a specific mechanism to add standardized extensions to NNTP. "Common NNTP Extensions", Stan Barber, 08/07/1998, In this document, a number of popular extensions to the NNTP protocol defined in RFC977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of exten- sions. "NNTP Full-text Search Extension",, 01/16/1998, This document describes a set of enhancements to the Network News Transport Protocol [NNTP-977] that allows full-text searching of news articles in multiple newsgroups. The proposed SEARCH command supports functionality similar to the [IMAP4] SEARCH command, minus user specific search keys (i.e., ANSWERED, DRAFT, FLAGGED, KEYWORD, NEW, OLD, RECENT, SEEN) and minus search keys based on headers that do not exist in news (i.e., CC, BCC, TO). The availability of the extensions described here will be advertised by the server using the extension negotiation-mechanism described in the new NNTP protocol specification currently being developed [NNTP-NEW]. "An NNTP Extension for Dynamic Feed Adjustment", Brian Court, 11/16/1998, This document describes an extension to the Network News Transport Protocol[RFC977] that allows NNTP peers to dynamically adjust their criteria for sending network news articles to one another. This extension provides only for the addition of 'negative' criteria, i.e., criteria for articles that are not to be sent. It is believed that a more comprehensive scheme allowing for 'positive' criteria, while desirable, would not receive wide deployment in the Internet because of concerns about security and intellectual property. The extension described in this document does not present these concerns and allows for gains in network efficiency. Individual Submissions (none) ----------------------------- "Photuris: Session Key Management Protocol", P. Karn, W. Simpson, 02/27/1998, Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms. "The Auto-Submitted, Supersedes and Expires Headers in E-mail and Netnews", J. Palme, 11/02/1998, This memo introduces three new e-mail headers, Auto-Submitted, Supersedes, and Expires. "Distance-Vector Multicast Routing Protocol MIB", David Thaler, 05/05/1998, This memo defines an experimental 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 the Distance-Vector Multicast Routing Protocol (DVMRP) protocol [5,6]. This MIB module is applicable to IP multicast routers which implement DVMRP. "SMTP Service Extension for Authentication", John Myers, 11/20/1998, This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL]. "Tunneling TCP based protocols through Web proxy servers", A. Luotonen, 08/27/1998, This document specifies a generic tunneling mechanism for TCP based protocols through Web proxy servers. This tunneling mechanism was initially introduced for the SSL protocol [SSL] to allow secure Web traffic to pass through firewalls, but its utility is not limited to SSL. Earlier drafts of this specification were titled 'Tunneling SSL through Web Proxy Servers' . Implementations of this tunneling feature are commonly referred to as 'SSL tunneling', although, again, it can be used for tunneling any TCP based protocol. A wide variety of existing client and proxy server implementations conform to this specification. The purpose of this specification is to describe the current practice, to propose some good practices for implementing this specification, and to document the security considerations that are involved with this protocol. "Fixing Backbone Partition with Dynamic Virtual Links", Z. Zhang, 11/26/1997, This document proposes a Dynamic Virtual Link (DVL) algorithm to dynamically detect and fix OSPF backbone area partition. In the DVL algorithm, each ABR periodically checks if it can reach via backbone area all other ABRs that it can reach via its transit areas. If not, it knows that a backbone partition has occurred and a spanning tree of Dynamic Virtual Links are created. When the DVLs are not needed, they are automatically deleted. "Guidelines for IETF Meeting Sites", E. Love, Dave Crocker, Bill Manning, Mark Prior, S. Coppins, 03/05/1998, The IETF is an international group that conducts most of its business using electronic mail however three times a year it conducts an open meeting for one week. For the most part the actual mechanics of the meeting are organised by the IETF secretariat but there are some requirements placed on the organisation hosting the meeting. This document attempts to provide some guidelines for organisations that wish to volunteer to act as host for one of these open meetings. As the IETF growth pattern mirrors the Internet itself this document expresses sizes as a percentage of the expected attendance rather than use fixed numbers as we expect these numbers to change for each meeting. At the last meeting, in Washington DC there were just over 1900 attendees. "SONAR - A Network Proximity Service Version 1", Keith Moore, 08/05/1998, SONAR is a service which, when presented with a list of Internet Protocol addresses, attempts to order that list according to the proximity from the SONAR server to each address. Given multiple locations for a network accessible resource, SONAR is designed to help networked applications make a reasonable choice between those alternatives. This memo describes the SONAR protocol as well as an experimental implementation of the SONAR service. While the name 'SONAR' is intended as a pun on the 'ping' utility that uses ICMP echo requests to verify network connectivity, the SONAR service does not specify use of any particular means of estimating network proximity. To the contrary, the design of SONAR assumes that the best means of estimating network proximity will change over time and perhaps from one network location to another. The SONAR protocol is intended to provide a stable interface for applications that need to measure network proximity, thus allowing proximity measurement algorithms to evolve separately from those applications. "Some Thoughts on the Importance of Modesty and Decorum and the Need for an IETF Code of Conduct", Michael O'Dell, 03/24/1998, Because of the importance of the work done in the IETF, and because of the increasing cultural diversity of the participants, some of whom find our most-unrestrained 'style' hard to accommodate, I believe the time has come for the IETF to adopt a Code of Conduct to govern our interactions. "ICMP Security Failures Messages", P. Karn, W. Simpson, 04/30/1996, This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). "WHOIS++ URL Specification", M. Hamilton, 03/13/1998, This document defines a new Uniform Resource Locator (URL) scheme ''whois++'', which provides a convention within the URL framework for referring to WHOIS++ servers and the data held within them. "The ESP Stream Transform", G. Caronni, M. Waldvogel, 07/17/1998, This document describes a security transform providing privacy and optional replay protection through Encapsulating Secure Payload (ESP). The transform defines how to use ESP in conjunction with byte-oriented stream ciphers, such as RC4 or SEAL. These stream ciphers offer strong encryption with comparatively low computational demands, and are thus favorable for multimedia bulk data or environments where the computing power needed per packet should be low. "Photuris: Extended Schemes and Attributes", P. Karn, W. Simpson, 03/06/1998, Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. Additional authentication attributes are included for use with the IP Authentication Header (AH). "Internet Security Transform Enhancements", W. Simpson, D. Wagner, 04/30/1997, This document describes several generic security transform enhancements for the IP Security Protocols (AH and ESP). "IP Authentication using Keyed SHA1 with Data Padding", W. Simpson, Perry Metzger, 05/01/1996, This document describes the use of keyed SHA1 with the IP Authentication Header. "Distributed Component Object Model Protocol -- DCOM/1.0", N. Brown, C. Kindel, 03/11/1998, The Distributed Component Object Model protocol is an application-level protocol for object-oriented remote procedure calls useful for distributed, component-based systems of all types. It is a generic protocol layered on the distributed computing environment (DCE) RPC specification and facilitates the construction of task-specific communication protocols through features such as: a platform neutral argument/parameter marshaling format (NDR), the ability for objects to support multiple interfaces with a safe, interface- level versioning scheme suited to independent evolution by multiple parties, the ability to make authenticated connections and to choose levels of channel security, and a transport-neutral data representation for references (including by-value) to objects. "Message Submission", John Klensin, R Gellens, 11/02/1998, SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA]. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. The process which accepts message submissions from MUAs is termed a Message Submission Agent (MSA). "A Common Internet File System (CIFS/1.0) Protocol Preliminary Draft", P. Leach, D. Naik, 01/02/1998, This document describes the CIFS file sharing protocol, version 1.0. Client systems use this protocol to request file access services from server systems over a network. It is based on the Server Message Block protocol widely in use by personal computers and workstations running a wide variety of operating systems. "Quality of Service Extensions to OSPF or Quality Of Service Path First Routing (QOSPF)", W. Salkewicz, Eric Crawley, Z. Zhang, C. Sanchez, 09/10/1997, This document describes a series of extensions for OSPF[1] and MOSPF[2] that can be used to provide Quality of Service (QoS) routing in conjunction with a resource reservation protocol such as RSVP[4] or other mechanisms that can notify routing of the QoS needs of a data flow. Advertisements indicating the resources available and the resources used are advertised to the OSPF routing domain and paths are computed based on topology information, link resource information, and the resource requirements of a particular data flow. "Requirements for IETF Mailing Lists", Keith Moore, 09/26/1997, This document describes requirements for all IETF official mailing lists, including (but not limited to) mailing lists used for working group discussion. "Internet Calendar Access Protocol (ICAP)", P. O'Leary, 06/12/1998, This Internet Calendar Access Protocol (ICAP) allows a client to access, manipulate and store Calendar information on a server. ICAP employs the iCalendar format [ICAL] for interchange of calendaring information. ICAP includes operations for creating Calendar stores on a server, opening them and retrieving information about them. When a Calendar Store has been opened, it can be bounded by start and end times so that the client can act on a smaller subset of Calendar information for more efficient operation. ICAP allows users to store new Calendar Objects into their own Calendar store and Calendar stores owned by other users with a single operation. ICAP supports searching iCalendar objects within a Calendar Store. Searches can be based on any iCalendar property and filtered by iCalendar Component type. "Dedicated Token Ring Interface MIB", K. Lee, T. Warwick, 12/31/1997, This document contains an extract from the approved text of IEEE standard 802.5R ''Dedicated Token Ring''. The extract comprises the Interface MIB for the Dedicated Token Ring interface, in SNMPv2 format. There are no changes to the MIB from the Draft 7 version. 802.5R is a standard that encompasses the existing 802.5 token- passing method of operation, and also defines a new duplex method of operation for use only on dedicated point to point links, that does not use tokens for data transmission. "S/Ident: Security Extensions for the Ident Protocol", B. Morgan, 03/13/1998, The Ident protocol [RFC-1413], specifies a method for a host to request from a remote host an assertion of an identifier associated with a TCP connection between the two hosts. This memo specifies extensions to Ident to support strong (i.e., cryptographic) authentication methods. The extensions are based on the Simple Authentication and Security Layer [RFC-2222]. "Dedicated Token Ring Concentrator MIB", K. Lee, T. Warwick, 12/31/1997, This document contains an extract from the approved text of IEEE standard 802.5R ''Dedicated Token Ring''. The extract comprises the MIB for the Dedicated Token Ring Concentrator, in SNMPv2 format. The changes from the previous version of this draft are small but important, and are in the area of CRF creation, where a RowStatus mechanism replaces the previous way of creating CRFs. 802.5R is a standard that encompasses the existing 802.5 token- passing method of operation, and also defines a new duplex method of operation for use only on dedicated point to point links, that does not use tokens for data transmission. The architecture of a DTR Concentrator is defined in the 802.5R standard. It is a MAC layer bridging device, which uses a new set of forwarding rules that ease interoperability between source routing and transparent bridging in an 802.5 LAN. The DTR Concentrator MIB is derived from the Source Routing and Transparent Bridge MIBs (RFCs 1525 and 1493). "The TACACS+ Protocol Version 1.78", David Carrel, L. Grant, 01/06/1998, TACACS+ provides access control for routers, network access servers and other networked computing devices via one or more centralized servers. TACACS+ provides separate authentication, authorization and accounting services. This document describes the protocol that is used by TACACS+. "Network Data Management Protocol", D. Hitz, R. Stager, 09/10/1997, The Network Data Management Protocol (NDMP) is an open protocol for enterprise-wide network based backup. The NDMP architecture allows network attached storage vendors to ship NDMP compliant file servers which can be used by any NDMP-compliant backup administration application. This same architecture is also used for network-attached backup devices, such as tape drives and tape libraries. "Interoperability Rules for Multicast Routing Protocols", David Thaler, 08/03/1998, The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them. "POP3 AUTHentication command", John Myers, 08/06/1998, This document defines the optional AUTH command to POP3 [POP3], for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Session Layer [SASL]. "Enhanced Communications Transport Service Definition", D. Kim, 07/06/1998, This memo is the final Committee Draft of the Enhanced Transport Service Definition under development within ISO/IEC JTC1/SC6/WG7 since last several years in order to provide to the upper-layer applications enhanced transport services over the current OSI transport service; major enhancements include multicast services and enhanced QoS. This memo is distributed to possibly interested grops within IETF, especially to experts in Transport Area, to make noticed the efforts being made within SC6 to come up with a new transport service definition meeting the wide range of requirements of the both current and future multimedia multicast applications. It is to be noted that a protocol maned ECTP(Enhanced Communications Transport Protocol) supporting this ECTS is also under development within SC6 and will be made public in the near future. Experts interested in this topic might compare the services defined by ECTS with those provided by more known protocols including RTP, MTP, RMP, and RAMP. The ultimate apparent objective of ECTS is the multimedia multicast transport service with varying degrees of reliability and multicast QoS. "The Weak Authentication and Tracing Option", Don Eastlake, 02/25/1998, The packet switched nature of the Internet Protocol (IP) provides no inherent method to assure that a packet has been issued with a source address authorized for the sender and no inherent method to trace the actual source of a packet. These characteristics make it difficult to take effective action concerning injurious packets which may have originated, by accident or maliciously, virtually anywhere in the Internet. A lightweight IP level option is proposed that provides (1) some assurance that packet's source addresses are authorized for their sender, and (2) limited statistical tracing information such that, if many bad packets are logged, the path to their source will be revealed. These features, even if not implemented throughout the Internet, would provide significantly improved protection against packet level abuse. "RMFP: A Reliable Multicast Framing Protocol", Jon Crowcroft, Henry Fuchs, T. Turletti, A Ghosh, C Diot, Z. Wang, Lorenzo Vicisano, 03/16/1998, There has been considerable interest in reliable multicast, and a number of reliable multicast transport applications and systems have been built in the past years, e.g. [PGM], [RMDP], [RMTP], [SRM]. A survey of most of current reliable multicast protocols is available in [Diot97]. "WHOIS++ templates", J. Knight, Patrik Faltstrom, M. Hamilton, Leslie Daigle, 03/16/1998, WHOIS++ is a simple Internet search and retrieval protocol, specified in [1], which allows clients and servers to exchange structured data objects known as templates. In the interests of interoperability it is desirable to have a common base schema for these templates. This document suggests a schema drawn from implementation and deployment experience to date with WHOIS++. "The LDAP Data Interchange Format (LDIF) - Technical Specification", G. Good, 11/02/1998, This document describes a file format suitable for describing directory information or modifications made to directory information. The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory. "MTP/SO: Self-Organizing Multicast", Joerg Ott, C. Bormann, N. Seifert, 12/04/1997, Multiparty cooperative applications have recently received much attention, as has the multicasting of datagrams in the internet. The internet datagram multicasting mechanism is not reliable, often requiring a higher level protocol to achieve the level of reliability required for an application. Much of the extensive work on reliable multicast protocols has assumed relatively stable groups that need to ensure that all messages are received by all members of this well-defined group. Recently, work on loosely coupled teleconferencing has directed attention to a class of multicast applications that scale up to an extent where this assumption is no longer practical. An interesting multicast transport protocol is defined in RFC 1301. MTP provides globally ordered, receiver reliable, rate controlled and atomic transfer of messages to multiple recipients. A revised, more practical version of MTP, the Multicast Transport Protocol MTP-2 has been in use for some time. Self-Organizing Multicast, MTP/SO, uses MTP-2 as a basis and adds spontaneous self-organization of the members of the group into local regions. Scalability is increased by providing passive group joining and local retransmission of lost packets. This version of the document is not yet complete but contains most of the vital parts. "A Simulation Model for IP Multicast with RSVP", Mark Pullen, L. Lavu, R. Malghan, Gang Duan, Jiemei Ma, Hoon Nah, 10/02/1998, This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting. "Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson, Martin Carpenter, 09/01/1998, This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by the IETF TLS working group and the extensions to the FTP protocol defined by the IETF CAT working group. It describes the subset of the extensions that are required and the parameters to be used; discusses some of the policy issues that clients and servers will need to take; considers some of the implications of those policies and discusses some expected behaviours of implementations to allow interoperation. TLS is not the only mechanism for securing file transfer, however it does offer some of the following positive attributes:- - Flexible security levels. TLS can support privacy, integrity, authentication or some combination of all of these. This allows clients and servers to dynamically, during a session, decide on the level of security required for a particular data transfer, - Formalised public key management. By use of X.509 public certificates during the authentication phase, certificate management can be built into a central function. Whilst this may not be desirable for all uses of secured file transfer, it offers advantages in certain structured environments such as access to corporate data sources. - Co-existence and interoperation with authentication mechanisms that are already in place for the HTTPS protocol. This allows web browsers to incorporate secure file transfer using the same infrastructure that has been set up to allow secure web browsing. The TLS protocol is a development of the Netscape Communication Corporation's SSL protocol and this document can be used to allow the FTP protocol to be used with either SSL or TLS. The actual protocol used will be decided by the negotiation of the protected session by the TLS/S "Architecture of the WHOIS++ service", Patrik Faltstrom, Leslie Daigle, S. Newell, 03/13/1998, This document describes Whois++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. We describe an extension to the simple WHOIS data model and query protocol and a companion extensible, distributed indexing service. A number of options have also been added such as the use of multiple languages and character sets, more advanced search expressions, structured data and a number of other useful features. An optional authentication mechanism for protecting all or part of the associated Whois++ information database from unauthorized access is also described. "Definition of an Object Class to Hold LDAP Change Records", G. Good, 03/12/1998, In order to support more flexible replication methods, it is desirable to specify some manner in which an LDAP client may retrieve a set of changes which have been applied to an LDAP server's database. The client, which may be another LDAP server, may then choose to update its own replicated copy of the data. This document specifies an object class which may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object which holds these change records, so that clients and servers have a common rendezvous point for this information. "Internationalization of Domain Names", M. Duerst, 07/30/1997, Internet domain names are currently limited to a very restricted character set. This document proposes the introduction of a new 'zero-level' domain (ZLD) to allow the use of arbitrary characters from the Universal Character Set (ISO 10646/Unicode) in domain names. The proposal is fully backwards compatible and does not need any changes to DNS. Version 02 is reissued without changes just to keep this draft available. "Multicast Tag Binding and Distribution using PIM", D. Farinacci, Y Rekhter, 11/16/1998, This document describes a method for advertising labels for multicast flows. It strives to use downstream label assignment to be consistent with unicast label distribution. This proposal is media- type independent. Therefore, it works for multi-access/multicast capable LANs, point-to-point links, and NBMA networks. "Originator-Info Message Header", Chris Newman, 05/28/1998, This proposal is an attempt to provide a standard header to indicate information about the message originator without implying that there is a deliverable mailbox or mandating that internal network information be revealed. The 'Originator-Info' header is intended to make the 'X-Sender' and 'X-X-Sender' headers obsolete. "POP3 Service Extensions", D. Rauschenbach, 01/10/1997, This memo defines a framework for extending the POP3 service by defining a means whereby a POP3 server can inform a client as to the service extensions it supports. "Camera Recorder Control Protocol", T. Tsushima, H. Fujiwara, M. Ohta, 03/16/1998, CRCP (Camera Recorder Control Protocol) is designed after FTP to be useful to operate realtime/batch analog/digital video cameras and video/audio recorders over the Internet. The design of CRCP is completely modular. A unit consists of several subunits and CRCP currently specifies units POWER, STREAM, TAPE and CAMERA. However, CRCP allows arbitrary combination of subunits to make it useful to control any home electronics units. "NICS Network of Identifier and Credential Servers", G. Hoare, 01/17/1997, NICS is a proposed system which meets the requirements of large-scale, unique principal identification, for use in conjunction with an arbitrary set of security systems such as have been proposed by members of the IETF. This proposal outlines the motivation for the development of NICS, and gives a general description of its internal workings and interfaces with higher-level protocols. It should be emphasized up front that NICS is not a complete security system, nor does it aim to replace any existing components of the internet which already work. The design draws off the fact that many security systems already have flexible name schemes, and are therefore considered components which are used in conjunction with NICS to achieve an improved level of service, flexibility and reliability, while introducing many desirable features such as anonymous identifiers, self-optimization, and low-overhead operation. For the purpose of initial evaluation, the remainder of this paper is short and to the point, and requires a little work on the reader's side to understand the reasoning. Additional discussion is welcome on the mailing list. "The Multicast Attribute Framing Protocol", Ross Finlayson, 01/19/1998, The Internet has recently seen the emergence of applications that involve the ongoing transmission, or ''pushing'', of structured data from a server to one or more client nodes. Most current applications send this data using unicast communications - usually over TCP connections. However, similar applications can also be implemented using multicast-based protocols. Multicast not only improves the scalability of this particular class of application, but also makes possible an additional class of application in which the participants can act as peers - sending data as well as receiving. This Internet Draft describes the ''Multicast Attribute Framing Protocol'' (MAFP) - a generic, attribute-based data representation, intended for a wide variety of multicast-based applications. It is currently being used to implement the ''multikit'' generic multicast session browser (http://www.lvn.com/multikit). This draft describes an early version of MAFP that is likely to undergo changes in the future. However, it is being described now, in the hope that it will promote open discussion of this and similar protocols - ideally leading to the adoption of an open, interoperable standard for this class of application. "Network Tuning for Efficiency and Throughput", L. Breit, 01/23/1997, Network tuning is usually performed after the network design is completed, but should also be done at intervals during the life cycle of the network. There are four basic areas that directly affect the efficiency of the network and its associated throughput: Frame and packet size optimization Segmentation avoidance or limitation Minimization of device delay Window sizing to avoid degradation This draft has been written to document for the internet community a basic overview of network tuning and its benefits. "Network Control Protocol for the Configuration of Mobile Wireless Beam-formed GPS-Based Networks", S. Bush, S. Jagannath, 02/25/1998, The Network Control Protocol (NCP) facilitates the configuration and rapid reconfiguration of mobile wireless beam-formed networks. It controls the operation of a network of omni-directional packet radios (orderwire) that overlays the mobile wireless network. Each network element in this network uses Global Positioning System (GPS) information to control a beamforming antenna subsystem which provides for spatial reuse. The GPS information is shared among the network elements over the orderwire and an optimal topology for the beam-formed links is determined. "StarBurst Multicast File Transfer Protocol (MFTP) Specification", K. Robertson, K. Miller, M. White, A. Tweedly, 04/07/1998, The Multicast File Transfer Protocol (MFTP) is a protocol that operates above UDP in the application layer to provide a reliable means for transferring files from a sender to up to thousands (potentially millions with network ''aggregators'' or relays) of multiple receivers simultaneously over a multicast group in a multicast IP enabled network. The protocol consists of two parts; an administrative protocol to set up and tear down groups and sessions, and a data transfer protocol used to send the actual file reliably and simultaneously to the multiple recipients residing in the group . "Extensions to the Internet Relay Chat Protocol (IRCX)", D. Abraham, 07/01/1998, This document describes IRCX, a set of extensions to the Internet Relay Chat (IRC) protocol defined in RFC 1459[1]. Only client-server interactions are defined. The added functionality includes user authentication for multiple security providers, support for UNICODE[2] characters, multilayer security, and a unified property mechanism. Chat server implementations can support channel or server services with full control over all messages and events. These services communicate with the core server over an extended IRC connection. All changes to the IRC protocol are designed such that existing clients will continue to work against servers implementing the extensions. Support for the extended protocol can be queried by clients to take advantage of the added functionality or to conform to the basic protocol as defined in RFC1459. "UUIDs and GUIDs", P. Leach, R. Salz, 02/05/1998, This specification defines the format of UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and if generated according to the one of the mechanisms in this document, is either guaranteed to be different from all other UUIDs/GUIDs generated until 3400 A.D. or extremely likely to be different (depending on the mechanism chosen). UUIDs were originally used in the Network Computing System (NCS) [1] and later in the Open Software Foundation's (OSF) Distributed Computing Environment [2]. This specification is derived from the latter specification with the kind permission of the OSF. "DIAMETER Base Protocol", Allan Rubens, Pat Calhoun, 11/18/1998, The DIAMETER base protocol is intended to provide a framework for any services which require AAA/Policy support. The protocol is intended to be flexible enough to allow services to add building blocks (or extensions) to DIAMETER in order to meet their requirements. This draft specifies the message format and transport to be used by all DIAMETER extensions and MUST be supported by all DIAMETER implementations, regardless of the specific underlying service. "DIAMETER Extensible Authentication Protocol Extensions", Allan Rubens, B Aboba, Pat Calhoun, 11/18/1998, The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This document describes how the EAP-Message and Signature attributes may be used for providing EAP support within DIAMETER. "DIAMETER User Authentication Extensions", William Bulley, Pat Calhoun, 07/28/1998, DIAMETER is a Policy and AAA protocol which can be used for a variety of services. This document defines DIAMETER messages that are used for the authentication, authorization and accounting of users. A considerable amount of effort was put into the design of this protocol to ensure that an implementation could support both DIAMETER and RADIUS concurrently. "SMTP Service Extension for Secure SMTP over TLS", Paul Hoffman, 11/09/1998, This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. "QoS Routing Mechanisms and OSPF Extensions", R. Guerin, D. Williams, Antoni Przygienda, S. Kamat, A. Orda, 03/10/1998, This memo describes extensions to the OSPF [Moy97] protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed. The goal of this document is to identify a framework and possible approaches to allow deployment of QoS routing capabilities with the minimum possible impact to the existing routing infrastructure. "Aggregation of Internet Integrated Services State", S. Berson, S. Vincent, 12/23/1997, The Internet Integrated Services (IIS) architecture[2] has a fundamental scaling problem in that per flow state is maintained at all routers and end-systems supporting a flow. This paper examines the use of aggregation as a technique to reduce the amount of state needed to provide IIS. In our approach, routers at the edge of a region doing aggregation keep detailed IIS state, while in the interior of this region, routers keep a greatly reduced amount of state. Packets will be tagged at the edge with scheduling information that will be used in place of the detailed IIS state. The aggregation scheme described will allow large scale deployment of IIS without overloading routers with state and associated processing. "Sieve -- a Mail Filtering Language", T. Showalter, 08/11/1998, This document describes a mail filtering language for filtering messages at time of final delivery. It is designed to be independent of protocol, and implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box IMAP servers, as it has no variables, loops, or ability to shell out to external programs. "DHCP Options For Host System Characteristics", M. Henry, E. Dittert, 07/31/1998, The interoperability of configuration services based on the Dynamic^M Host Configuration Protocol (DHCP) [1] in an environment of^M heterogeneous clients depends on clients accurately identifying^M themselves and their relevant characteristics to configuration^M servers. The class identifier provided through DHCP option 60 [2]^M helps in this regard, but such identifiers essentially only enable^M clients and servers that are 'good friends' to find each other. This^M draft proposes the definition of two options that convey particular,^M generally useful information about the client system. This enables^M all servers to recognize this information, and is a step toward a^M richer form of interoperability for configuration services.^M The proposed options are^M * Client System Architecture^M * Client Network Device Interface^M * UUID/GUID-based Client Identifier^M "Distributed Registration Extension to Mobile IP", M. Chuah, Y. Li, 12/23/1997, This document proposes an extension to the Mobile IP base protocol. The features in this extension allow us to (i) reduce frequent distant registrations at the mobility agents, (ii) be more scalable by a separation of registration and forwarding services, (iii) ease the key management problem among mobility agents, and (iv) be interoperable with other mobility agents/mobile nodes running standard Mobile-IP specified in RFC2002. "A Protocol for the Transmission of Net News Articles over IP multicast", H. Rupp, 03/09/1998, Mcntp (Multicast News Transfer Protocol) provides a way to use the IP multicast infrastructure to transmit NetNews articles between news servers. Doing so will reduce the bandwidth that is actually needed for transmission of articles which is mostly done via NNTP. This does not affect how news reading clients communicate with servers. "Internationalized Uniform Resource Identifiers (IURI)", Larry Masinter, M. Duerst, 11/11/1998, URIs [RFC 2396] are defined as sequences of characters chosen from a limited subset of the repertoire of ASCII characters both for transmission in network protocols and representation in spoken and written human communication. This document defines IURIs (Internationalized URIs) as a sequence of characters from the repertorie of the UCS (Universal Character Set). A mapping of IURIs to URIs and guidelines for the use and deployment of IURIs in various elements of software that deal with URIs are given. "Creating 40-Bit Keys for DES", Russ Housley, Paul Hoffman, 05/11/1998, This document describes an method for shortening DES keys from 56 bits to 40 bits. The shortened keys are generally known as 'DES-40'. The motivation for this weakening is that some localities (such as the United States) give special preference to applications that use 40-bit keys. The weakened keys are then used with the DES encryption algorithm in the same manner as full-strength keys. There are many possible methods for reducing a 56-bit key to a 40-bit key. The method in this draft was chosen because one method is needed for interoperability. Further, this method has been known to occasionally have been approved for export from the United States. "Access Protocol", R. Earhart, 01/05/1998, The Access Protocol defines a standard extensible framework upon which application-specific protocols may be layered, providing a piece of infrastructure for a common class of internet protocols. "The IP Network Address Translator (NAT)", Pyda Srisuresh, Kjeld Egevang, 03/05/1998, Basic Network Address Translation or Basic NAT is a feature by which IP addresses are mapped from one group to another, transparent to users. Network Address Port Translation, or NAPT is an extension to Basic NAT, in that many network addresses and their TCP/UDP ports are translated to a single network address and its TCP/UDP ports. Together, these two operations, traditionally referred to as NAT, provide a mechanism to connect an isolated routing realm with private unregistered addresses to the external routing network with globally unique registered addresses. "Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers", J. Palme, 11/02/1998, Separate Internets standards documents define the e-mail headers In-Reply-To, References, Supersedes and Expires. This document, which is an informational RFC, gives some advice on the implementation of these features. "Cache Array Routing Protocol v1.1", K. Ross, V. Valloppillil, 02/27/1998, This draft documents the Cache Array Routing Protocol (CARP) v1.0 for dividing URL-space among an array of loosely coupled proxy servers. An HTTP client agent (either a proxy server or a client browser) which implements CARP v1.0 can allocate and intelligently route requests for the correct URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates are improved. "Key Management for Multicast: Issues and Architectures", D. Wallner, E. Harder, R. Agee, 09/14/1998, This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group. "Path MTU discovery in the presence of security gateways", M. Richardson, 09/04/1998, This document describes the problem of getting accurate Path MTU infor- mation in the presence of untrusted routers. Typical Path MTU discovery is done by sending packets with the don't fragment bit set, and listen- ing for ICMP messages from routers that want to fragment the packets. Unfortunately, these messages could be forged, and IPsec based security system(s) can not pass make direct use of these messages. An alternate, backwards compatible algorithm is suggested. "Guidelines for Next Hop Client (NHC) Developers", L. Winkler, R. Carlson, 10/14/1998, This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). It assumes that the clients are directly connected to an ATM based NBMA network. The same principles will apply to clients connected to other types of NBMA networks. The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. The NHC is capable of sending NHRP requests to a Next Hop Resolution Protocol Server (NHS) to resolve both inter and intra LIS addresses. The NHS reply may be positive (ACK) indicating a short-cut path is available or negative (NAK) indicating that a shortcut is not available and the routed path must be used. The NHC must cache (maintain state) for both the ACK and NAK replies in order to use the correct shortcut or routed path. The NAK reply must be cached to avoid making repeated requests to the NHS when the routed path is being used. "IMSS: IP Multicast Shortcut Service", T. Anker, D. Breitgand, D. Dolev, Z. Levy, 01/14/1998, This memo describes an IP Multicast Shortcut Service (IMSS) over a large ATM cloud. The service enables cut-through routing between routers serving different Logical IP Subnets (LISs). The presented solution is complementary to MARS [2], adopted as the IETF standard solution for IP multicast over ATM. IMSS consists of two orthogonal components: CONnection-oriented Group address RESolution Service (CONGRESS) and IP multicast SErvice for Non-broadcast Access Networking TEchnology (IP-SENATE). An IP class D address is resolved into a set of addresses of multicast routers that should receive the multicast traffic targeted to this class D address. This task is accomplished using CONGRESS. The cut-through routing decisions and actual data transmission are performed by IP- SENATE. IMSS preserves the classical LIS model [8]. The scope of IMSS is to facilitate inter-LIS cut-through routing, while MARS provides tools for the intra-LIS IP multicast. "ESP with Cipher Block CheckSums (CBCS)", W. Simpson, 07/24/1997, This document describes the Cipher Block Chaining mode with addi- tional single or double parallel CheckSums for integrity, used with a number of Internet Encapsulating Security Payload (ESP) transforms. This version is described in terms of 64-bit block ciphers, but can be expanded to other block sizes. "Universal Forms Description Language Specification Version 4.0.1", David Manning, Richard Bennett, John Boyer, Sonja McLellan, Michael Mansell, 07/28/1998, The Universal Forms Description Language (UFDL) describes complex business forms for use over the Internet. The objective of the UFDL is to enable the creation of cross-platform Internet business forms that (1) contain both the complex logic and precise layout that administrators require, (2) are simple to maintain and distribute, and (3) integrate easily with existing business systems. As more and more business is done over the Internet, the need for a form description language that incorporates these features grows. HTML is designed for Internet pages, and is severely limited as a form language. This document specifies the vocabulary, syntax, and meaning of the UFDL. "Network Security API for Sockets", C. Metz, 01/16/1998, This API is a means for sockets applications to request network security services from an operating system. It is designed to move most of the work and intelligence of security policy processing into the operating system so that the burden on application authors is light enough to encourage the use of network security. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of applications that use network security services (e.g., the IP Security ESP and AH protocols). "Performance Issues in VC-Merge Capable ATM LSRs", Anwar Elwalid, Indra Widjaja, 10/09/1998, VC merging allows many routes to be mapped to the same VC label, thereby providing a scalable mapping method that can support thousands of edge routers. VC merging requires reassembly buffers so that cells belonging to different packets intended for the same destination do not interleave with each other. This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. The main result indicates that VC merging incurs a minimal overhead compared to non-VC merging in terms of additional buffering. Moreover, the overhead decreases as utilization increases, or as the traffic becomes more bursty. "An Internet Firewall Transparency Requirement", Ned Freed, Kevin Carosso, 12/30/1997, This memo defines a basic transparency requirement for Internet firewalls. While such a requirement may seem obvious, the fact of the matter is that firewall behavior is currently either unspecified or underspecified, and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent and correct. "URLs for Telephone Calls", Antti Vaha-Sipila, 08/04/1998, This document specifies URL (Uniform Resource Locator) schemes ''tel'', ''fax'' and ''modem'' for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers. "Using TLS with IMAP4, POP3 and ACAP", Chris Newman, 11/13/1998, This specification defines extensions to IMAP [IMAP4], POP [POP3] and ACAP [ACAP] which activate TLS [TLS]. This also defines a simple PLAIN SASL [SASL] mechanism for use underneath strong TLS encryption with ACAP or other protocols lacking a clear-text login command. "Short Passive (SPASV) Command for FTP", C. Metz, 01/13/1998, RFC 1639[Pis94] documents experimental long port (LPRT) and long passive (LPSV) commands that many IP Version 6 implementations are using as the replacement for the PORT and PASV commands in FTP [PR85]. The author believes that this is the incorrect direction to be heading and that the replacement for PORT and PASV should carry less information instead of more. The passive command (SPASV) is a replacement for the PASV command. It only carries port numbers and does not carry addresses. This makes it usable with IPv4 and IPv6. A benefit of not carrying addresses is that pure network address translators (NAT) do not have to do a search-and-replace on the TCP stream, which is an expensive operation. This also eliminates three-way FTP, which is a rarely used mode of operation that leaves most existing FTP servers wide open to the FTP Bounce Attack [Hob95]. Because the FTP PORT command is unfriendly to some kinds of firewall configurations [Bel94] and that unfriendliness is there to support three-way FTP, there is no replacement for the PORT command -- all transfers should use passive mode instead. The author's inet6-apps kit (available on ftp.ipv6.inner.net and ftp.inner.net) includes a client and server that supports the current version of these commands. Those FTP servers implement this command. "IMAP4 Implementation Recommendations", B. Leiba, 05/14/1998, The IMAP4 specification [RFC-2060] describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. "The Use of DES-MAC within ESP and AH", D. Frommer, Sara Bitan, 09/10/1997, This draft describes the use of the DES-MAC algorithm [Kaufman95] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. DES-MAC[Kaufman95] is based on the DES encryption algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. "Confirmation of Mail Message Reception", Alexandre Steinberg, 09/10/1997, Currently, Internet SMTP transport does not allow the sender to know if the recipient receive or open a mail message. This limitation frequently causes one question: did my message really arrive? This proposes a simple solution, that could be easy implemented in the mail software. "Salted Challenge Response Authentication Mechanism (SCRAM)", Chris Newman, 03/05/1998, SCRAM is a simple passphrase-based SASL [SASL] authentication mechanism suitable for a wide variety of usage scenarios. It combines good properties of CRAM-MD5 [CRAM-MD5] and OTP [OTP], adds some management features and some protection from active attacks without a significant increase in complexity. SCRAM is intended for use with services which need a simple, fast and flexible authentication mechanism. [NOTE: Public discussion of this mechanism may take place on the ietf-sasl@imc.org mailing list with a subscription address of ietf-sasl-request@imc.org. Private comments may be sent to the author]. "The 'news' URL scheme", Alfred Gilman, 03/05/1998, This document defines the format of Uniform Resource Locators (URLs) identifying news messages and groups. The syntax of 'news' URLs from RFC 1738 is extended to allow specification of the site from which the message is to be sought and to incorporate protections via 'snews' URLs. This combines into the 'news' scheme enough capability so that the previously-proposed 'nntp' scheme can be retired and URL usage simplified. "Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0", D. Mills, J Mogul, Poul-Henning Kamp, Jan Brittenson, Jonathan Stone, Ulrich Windl, 06/10/1998, RFC1589 describes a UNIX kernel implementation model for high-precision time-keeping. This is meant for use in conjunction with the Network Time Protocol (NTP, RFC1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC1589 did not define an API for managing the PPS facility. This document specifies such an API. "Avoiding the TCP TIME_WAIT state at Busy Servers", J. Touch, Ted Faber, Wei Yue, 09/11/1997, This document describes the problems associated with the accumulation of TCP TIME_WAIT states at a network server, such as a web server, and details two methods for avoiding that accumulation. Servers that have many TCP connections in TIME_WAIT state experience performance degradation, and can collapse. One solution is a TCP modification that causes clients to enter TIME_WAIT state rather than servers. The other is an HTTP modification that allows the client to close the transport connection, maintaining the TIME_WAIT state at the client. The goal of both approaches is ensure that TIME_WAIT states accumu- late at the less loaded endpoint. The document also presents initial performance data from reference implementations of these solutions, which suggest that the modifica- tions improve HTTP connection rates at the server by as much as 50%, and allow servers to operate at small transaction throughputs that they cannot sustain their default configuration. "Extending POP Version 3 To Do Mailbox Compression", Harish Pillay, Marvin Tay, 09/11/1997, This document suggests an extension to the Post Office Protocol version 3 (RFC 1725) that adds an extra command to selective compress the maildrop before transferring the mail to the recipient. Given the extensive and explosive growth of mobile uses of the Internet especially the numbers of people who access their e-mail via dialup modems, it does not make sense to have to transfer e-mail to the client in uncompressed form. This draft discusses a new command that will make the pop3 server to intelligently compress the maildrop into a single file and then for it to be sent to the client. The client will then process the compressed mail accordingly. "The SRP Authentication and Key Exchange System", Tom Wu, 11/06/1998, This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords. This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge- response techniques, making it an ideal drop-in replacement where secure password authentication is needed. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", M. Crispin, 09/14/1998, 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 (see also [IMAP-DISC]). IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] 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 [ACAP]. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocol have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE]. Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest. "Generation of the Age header field in HTTP/1.1", J Mogul, 09/15/1997, The 'Age' response-header field in HTTP/1.1 [RFC 2068] is intended to provide a lower bound of an estimate of a response message's age (time since generation), by explicitly indicating the amount of time that is known to have passed since the response message was retrieved or revalidated. There has been considerable controversy over when the Age header field should be added to a response. This document explains the issues, rebuts a previous proposal, and provides a set of proposed changes for the revision of RFC 2068. "Internet Protocol Multicast Problem Statement", Scott Bradner, 09/15/1997, This document outlines the evolving requirements for Multicast functionality within next generation Internet Protocol networks, and is the product of an ad hoc Internet2 working group meeting held August 25-27, 1997 hosted by Cisco Systems, Inc. This document is offered to the IP community for its consideration and comments. "Internet Protocol Quality of Service Problem Statement", Scott Bradner, 09/15/1997, This document outlines the requirements for a Quality of Service (QoS) function for the Internet Protocol, and is the product of an ad hoc Internet 2 working group meeting held August 25-27, 1997 hosted by Cisco Systems, Inc. This document is offered to the IP community for its consideration and comments. This document is organized as follows: Section 1 proposes a simple classification scheme to describe QoS models. Subsequent sections discuss requirements for Measurement, Administrative Policy, Provisioning Issues, Network Environment and Implementation Issues. "Telnet Authentication: SRP", Tom Wu, 11/06/1998, This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 1416, using the SRP authentication mechanism. The specific mechanism, SRP-SHA1, is described in [SRP-DRAFT]. "RIDE referencing", David R. Conrad, Wilfried Woeber, David Kessens, 09/19/1997, This document describes two variants of a proposal on how to find information regarding some critical resources (domain names, IP addresses and routing registry information) on the Internet. The proposed solution uses globally unique registry identifiers that are derived from a domain name in use by a registry. "RIDE functional requirements", David Kessens, 09/19/1997, This document describes the (functional) requirements for the RIDE format and protocols. "IPv6 over Point-to-Point ATM Link", K. Yamamoto, Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, Kenjiro Cho, Atsushi Hagiwara, 02/10/1998, This memo defines a communication mechanism to exchange both IPv6 unicast and multicast packets over an ATM network used as a point-to-point link. "VCID: Virtual Connection Identifier", Noritoshi Demizu, Hiroshi Esaki, K. Nagami, P. Doolan, 10/07/1997, Several label switching schemes have been proposed to fuse and integrate the cost-performance and QoS assurance of Layer 2 devices and the flexibility and functionality of Layer 3 protocols. Some of these proposals assume that Label Switching Routers (LSRs) are placed in a homogeneous LSR cloud in a campus area network or a backbone network, and they are connected directly to each other. However, this assumption sometimes does not hold true in the real situation. For example, some campuses will be connected via ATM SVC service, and LSR networks will be constructed hierarchically. To deal with Virtual Connections (VCs) in these environments, this document proposes to identify a VC with a VCID instead of a label. "Using LDAP for SMTP Mailing Lists & Aliases", Bruce Steinback, 09/24/1997, Directory services based on the Lightweight Directory Access Protocol (LDAP) [1] and X.500 [2] provide a general-purpose means to store information about users and other network entities. One such use is to store information on groups. There are LDAP standards established for this purpose, e.g. the groupOfUniqueNames [3]. However, currently there are no standards for a very important use of Groups, as SMTP Mailing Lists or Aliases. This document discusses how we at Netscape have made this extension, with the intent of providing useful information towards perhaps creating standards for this important use of LDAP. "SDP syntax for H.263 options", Petri Koskelainen, Harri Honko, Jouni Salonen, 06/29/1998, This document defines the SDP syntax for 1998 version of H.263 codec options and parameters for IETF multimedia conferencing architecture. It is often useful to know beforehand (in call setup phase) what features of H.263 the other end supports. This document specifies the format spefic parameters for H.263, which exists in a=fmtp: as defined in the SDP document. Moreover, the usage of this feature with SIP and SAP is specified. "Java LDAP Controls", C. Y. Ho, R. Weltman, 09/28/1997, This document defines support for the Preferred Language Control, the Server Sorting Control, and the Virtual List Control in the java LDAP API. Controls are an LDAP protocol version 3 extension, to allow pass- ing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. "ISO 7812/7816 Based Card Numbers and the Domain Name System (DNS)", Don Eastlake, 08/11/1998, There are a variety of servers, web pages, and the like, which holders of ISO 7812 financial transaction identification card numbers and ISO 7816 smart card or related numbers may need to locate on the Internet. For example, some systems assume a smart card holder can contact the issuer of a smart card application for maintenance and update functions and the SET protocol assumes that a card holder can locate the appropriate certification authority to obtain a card holder certificate. This document specifies a method using the DNS as an important element in locating card related facilities on the Internet by mapping ISO 7812 and ISO 7816 based number systems into domain names within in the card.reg.int domain. Disclaimer The methods proposed herein are not, at the time of the issuance of this document, endorsed by the credit card brands or associations for use in connection with SET. "Use of the IPv4 TOS Octet to Support Differential Services", Juha Heinanen, 12/03/1997, This document describes how the TOS octet in the IPv4 header can be used to support differential Internet services. The proposal is based on the existing format of the TOS octet as defined in [RFC791] and [RFC1349]. "Two Modes of MPLS Explicit Label Distribution Protocol", Y. Katsube, K. Nagami, Y. Ohba, 10/06/1997, This memo discusses characteristics of two types of MPLS protocol operations, which we call 'Edge Control' operation and 'Distributed' operation individually, and proposes that these two mode of protocol operations should be specified as the explicit Label Distribution Protocol for the MPLS. "VC Pool", Noritoshi Demizu, Hiroshi Esaki, K. Nagami, P. Doolan, 10/07/1997, Several label switching schemes have been proposed to fuse and integrate Layer 2 and Layer 3. They can be applied to various datalinks including intermittent links such as ATM SVC. Intermittent links require signaling to establish VCs before employing them and to release VCs after utilizing them. Because signaling often introduces delays and costs, some kind of optimization is necessary. This document proposes to introduce a VC pool to reduce the delays and the costs of signaling. "A MIME Directory Profile for LDAP Schema", M. Wahl, 11/10/1997, This document defines a MIME directory profile [1] for holding an LDAP [2] schema. It is intended for communication with the Internet schema listing service [3]. "Security issues for the ATMARP protocol", G. Armitage, 10/13/1997, This document discusses some security issues associated with IP over ATM operation. RFC1577 defines the Classic IP model for sending IP traffic over ATM. However, security issues were not addressed in the standard. Since internet is an open architecture, security measures to protect network integrity are essential for normal operation. The security loopholes in the current RFC 1577 model are analyzed and discussed. Possible solutions are proposed. "LDAP Schema for Role Based Access Control", Larry Bartz, 10/14/1997, Role Based Access Control (RBAC) is an authorization strategy in which an entity's permission to access and manipulate targeted resources is determined by the entity's role or function within a certain organizational context. RBAC's principal motivation is to streamline security policy administration. Many discrete authoriza- tions can be aggregated within a defined role. One or many roles may be assigned or attributed to individuals. This draft describes LDAP object classes and attributes which support RBAC. Adoption of this schema across multiple LDAP implementations will enable RBAC intero- perability among heterogeneous underlying directory services. "HTTP Traffic over Satellite", Robert Pohlmann, 10/14/1997, Internet use over satellites (LEO, MEO and GEO) has not received enough attention. Satellites have an inherent broadcasting ability useful for transmitting Internet traffic. They can send information to many locations simultaneously depending on the coverage beam of the satellite. The issue of Internet use over satellites needs to be addressed so that future implementations of networking protocols can be used with this medium. The vast majority of Internet traffic is TCP traffic resulting from the HTTP protocol so this issue will be addressed here. It is hoped that this facilitates the transition from the use of terrestial networks, to networks incorporating satellite links. "Requirements for Distinguished Names in Autonomous to Loosely-coupled LDAP-based Directory Services", J. Hodges, 10/21/1997, This document analyzes the issues involved in the Distinguished Name- spaces of autonomous to loosely-coupled, LDAP-based directory services (LLDSs). It folds in experience learned from the global X.500-based Dis- tinguished Name-space, and proposes requirements for the construction of Distinguished Names for LLDSs of varying scopes. "URLs for GSM Short Message Service", Antti Vaha-Sipila, 06/26/1998, This document specifies a URL (Uniform Resource Locator) scheme 'gsm-sms' for specifying a recipient for an alphanumeric message (Short Message) in a GSM-based mobile phone system. Short Messages are two-way paging messages that can be sent from a suitable equipped computer or a phone. "PPP Over SONET Mapping", Jon Anderson, Al White, Demos Kostas, Brent Allen, 10/23/1997, This Internet Draft addresses the PPP/SONET interface defined in the IETF RFC 1619 and the standards work underway in T1X1 on SONET. "One Planet, One Net: Principles for the Internet Era", Nathaniel Borenstein, Harry Hochheiser, Andy Oram, 04/07/1998, This document presents a suggested set of basic principles that the authors believe should underlie all future work in the area of Internet governance. The purpose of this document is to work towards as broad a consensus as possible, in the diverse Internet community, about principles that should inform the way the Internet is administered for the benefit of all humanity. The principles have been drafted under the auspices of Computer Professionals for Social Responsibility, with several iterations internal to that organization. However, they are still very much seen as a work in progress. Comments are solicited from all interested parties. Future versions will be refined based on these comments and published as future Internet-Drafts, with a goal of publication of a finalized version of the declaration as an Internet RFC in summer, 1998. All comments on this document are welcome; please send them to onenet-comments@cpsr.org. Open discussion of this document is encouraged on the onenet-discuss list, which is archived at http://www.findmail.com/listsaver/onenet- discuss. "Self-Describing Data Representation (SDR)", Colin Low, Jim Randell, Mike Wray, 10/23/1997, This document describes a human-readable, textual syntax for representing self-describing structured data. This representation was designed as a transfer syntax for loosely-coupled distributed applications where one cannot depend on sender(s) and receiver(s) sharing a schema for exchanged data. The syntax is compact, expressive, intuitive, and simple to implement. "''shared-mtrace'': A Multicast 'traceroute' facility for Shared Trees", Tony Ballardie, 10/27/1997, ''mtrace'' [1] is a very useful tool for diagnosing IP multicast rout- ing problems, such as multicast routing loops and misconfigured mul- ticast routers, associated with source-rooted RPF-based distribution trees. For ''mtrace'' to be useful in a shared tree environment (e.g. PIM [2], CBT [3], GUM [4]) its behaviour must be modified. This draft speci- fies that behaviour, which is sufficiently general to be applicable to all shared tree types and operating modes. A new ''wildcard'' mode of behaviour is also described, which allows a trace of a complete shared tree. Authentication is recommended in this mode because of its potential as a vehicle for denial of service attacks. It is intended that this draft become a document of the Mbone Deploy- ment (mboned) working group of the IETF. Therefore, comments are solicited and should be sent to mboned's mailing list and/or the author. "HARP - ''Home Agent Redundancy Protocol''", Jim Binkley, Bjorn Chambless, 10/30/1997, This document presents a protocol called the Home Agent Redundancy Protocol or HARP. HARP is an optional extension to Mobile-IP [RFC- 2002]. Mobile-IP includes the notion of a Home Agent which is a host located on the home IP subnet for Mobile Nodes. Home Agents forward packets to Mobile Nodes that are away from home. Since Mobile Nodes are dependent on the Home Agent for connectivity when away from home, the Home Agent represents a possible single source of failure for the Mobile IP system. HARP is a protocol which allows a pair (or set) of Home Agents to cooperate and share Mobile-IP Mobile Node registration information. If one of the HARP peers should fail, the Mobile-IP system will not necessarily fail, hence HARP introduces Home Agent redundancy into the Mobile-IP system. Mobile Nodes are not aware that HARP exists, so HARP requires no changes to Mobile-IP as a protocol. In this document, we present the HARP architecture and protocol. "DNS and URL Level Addressing for Public Circuit-Switching Network Devices", H. Zhu, 10/31/1997, Recently there are a number of efforts [sw1, sw2, in,tpc, etc.] of trying to connect the packet-switching network with circuit-switching network, especially connecting the Internet with public telephone networks. The first problem of such interconnection is naming and addressing, later will come with directory services and routing problems. This draft concentrates on naming for DNS and URL. Other problems are discussed in other documents [utrpt, framework]. "Self-Synchronous Scramblers For PPP Over Sonet/SDH: Some Analysis", D. Ferguson, Ravi Cherukuri, 11/03/1997, The use of a self-synchronous scrambler to minimize the possibility that a carefully chosen PPP over SONET/SDH payload can cause a long sequence of zero bits to be transmitted is examined. It is pointed out that, while self-synchronous scramblers have some attractive properties for the application, the x^43 + 1 scrambler used by ATM for the same purpose has some unfortunate interactions with the 16-bit CRC Frame Check Sequence which is the PPP default FCS. It is suggested that adding a third term to the self-synchronous generator polynomial might improve its behaviour, and that inverting the scrambler bit ordering so it is applied to the data in the same bit order as the PPP CRC FCS algorithms are defined for may eliminate any remaining effect such scramblers have on either PPP FCS. "On-Demand Mail Relay", R Gellens, 07/06/1998, With the spread of low-cost computer systems and Internet connectivity, the demand for local mail servers had been rising. Many people now want to operate a mail server on a system which has only an intermittent connection to a service provider. If the system has a static IP address, the [ESMTP] [ETRN] command can be used. However, systems with dynamic IP addresses (which are very common with low-cost connections) have no widely-deployed solution. This memo proposes a new service, On-Demand Mail Relay, which is a profile of [ESMTP], providing for a secure, extensible, easy to implement approach to the problem. "Gateways and MIME Security Multiparts", Ned Freed, 09/10/1998, This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. A set of requirements for gateway behavior are defined which provide facilities necessary to properly accomodate the transfer of security multiparts through gateways. "To Be Multihomed: Requirements & Definitions", H. Berkowitz, 03/11/1998, As organizations find their Internet connectivity increasingly critical to their mission, they seek ways of making that connectivity more robust. The term ''multi-homing'' often is used to describe means of fault-tolerant connection. Unfortunately, this term covers a variety of mechanisms, including naming/directory services, routing, and physical connectivity. The ''home'' may be identified by a DNS name, an IP address, or an IP address and transport-layer port identifier. Any of these identifiers may be translated in the path between source and destination. This memorandum presents a systematic way to define the requirement for resilience, and a taxonomy for describing mechanisms to achieve it. Its intended audience is primarily people concerned with planning and performing multihoming deployments, rather than protocol developers. It examines both requirements and applications, with the emphasis on the former. "BGP-4 Capabilities Negotiation for BGP Multiprotocol Extensions", Pedro Marques, 04/15/1998, This document defines the usage of the BGP-4 Capabilities Negotiation parameter to negotiate the support for a particular Address Family, Sub-address Family pair between BGP-4 speakers using BGP-4 Multiprotocol Extensions. "Lightweight Directory Access Protocol (v3): Extension for PPP Authentication", B Aboba, 11/21/1997, This document defines the ''PPP Authentication Operation'' for LDAP. This operation provides for PPP authentication in an LDAP association and is defined in terms of an LDAP extended operation. It is expected that this extended operation will be useful in inte- grating authentication protocols such as RADIUS and TACACS+ with LDAP- based directory services. Consolidation of information stores is desirable since it results in lessened administrative workload and a consistent view of user information throughout the enterprise. "Lightweight Directory Access Protocol (v3): Dynamic Attributes for the Remote Access Dialin User Service (RADIUS)", B Aboba, 11/21/1997, This document defines dynamic attributes used by the Remote Access Dialin User Service (RADIUS). These attributes are written to a dynamic directory service by the RADIUS server in order to provide information about sessions in progress. This information can then be used in order to provide for control of simultaneous logins, or for detection or tracking of security incidents in progress. "Lightweight Directory Access Protocol (v3): Schema for the Remote Access Dialin User Service (RADIUS)", B Aboba, 02/05/1998, This document defines a schema for the Remote Access Dialin User Ser- vice (RADIUS). This schema makes it possible to integrate a RADIUS server with an LDAP-based directory service, making it possible for an organization to maintain a single store of user information. This con- solidation is desirable since it results in a reduction in the admin- istrative workload, and eliminates the need to synchronize across mul- tiple user information stores. "One Pass Multipart/Alternative Processing", L Lundblade, 08/11/1998, Most MIME syntax and semantics can usually be processed in a single pass through the data. For example, the MIME boundary parameter always appears before it is used. This is not the case with multipart/alternative MIME entities. The processor of the data cannot know the MIME types of the altnernatives present until all alternatives have been processed. Thus, it is not possible for a one pass processor to consider more than the first and most limited representation, because a subsequent part may be something that cannot be handled. "Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference", P. Ferguson, 03/12/1998, Recent opinions and sentiments expressed in the Internet Service Provider (ISP) community, as well as the Internet community at-large, have voiced concern over the applicability and scalability of RSVP and the Integrated Service model in the global Internet infrastructure. Convincing arguments have been made for a differential services model which offers packet delivery services better than traditional best effort, especially in the face of congestion, yet not as resource intensive as RSVP. As a result, the Differentiated Service (diffserv) working group in the IETF has been examining methods to provide simpler, less resource intensive methods of offering differentiated services. This draft provides a practical method to use bit values expressed in the IP Type or Service (TOS) and IP precedence subfields of the TOS byte in the IP packet header for delay indication and packet drop preference, respectively. "Notary Protocols", C. Adams, Robert Zuccherato, 02/27/1998, This document describes a general notary service and the protocols to be used when communicating with it. The Notary Authority is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Notary Authority responsibilities in a PKI are to validate signatures and to provide up- to-date information regarding the status of certificates. We give examples of how to use the notary to extend the lifetime of a signature beyond key expiry or revocation and to query the notary regarding the status of a certificate. "Time Stamp Protocols", C. Adams, B. Pinkas, Patrick Cain, Robert Zuccherato, 06/05/1998, This document describes the format of the data returned by a Time Stamp Authority and the protocols to be used when communicating with it. The time stamping service can be used as a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). In order to reduce the amount of trust required of a TSA we introduce (in Appendix C) the optional Temporal Data Authority (TDA) whose function is to provide further corroborating evidence of the time contained in the token. We also give an example of how to place a signature at a particular point in time, from which the appropriate certificate status information (e.g. CRLs) may be checked. "Japanese Character Encoding for Internet Messages",, 11/10/1997, This memo describes the encoding used in electronic mail, NetNews, and world wide web messages in Japanese networks. It was first specified by and used in JUNET then described in RFC 1468. The name of this encoding was originally known as ''JUNET code'' and is now called ''ISO-2022-JP'' when used in the context of MIME. In ISO-2022-JP text, both one 7-bit byte Latin script (ASCII or JIS X 0201 Latin set) and two 7-bit bytes Kanji, Hiragana, Katakana and some other symbols and characters (JIS X 0208) are employed. Switching the graphic character sets is based on the extension techniques defined in ISO 2022. This memo eliminates some ambiguities of RFC 1468. However, it NEVER introduces any essential changes against RFC 1468. Since the encoding is now widely used in Japanese IP communities, backward compatibility is most important in this revision. This memo revises RFC 1468 on the following points: 1. It is clarified that ISO-2022-JP does NOT conform to ISO 2022. 2. The formal syntax is divided into two new yet compatible rules, namely, ISO-2022-JP decoding syntax and ISO-2022-JP encoding syntax. 3. The bit combinations permitted in JIS X 0208 are explicitly described in the syntax so that the invalid character positions will be excluded in ISO-2022-JP text. 4. Recommended graphic character sets are specified. That is, ASCII is RECOMMENDED rather than JIS X 0201 1976 Latin set. ONLY to embed YEN SIGN and OVER LINE, JIS 0201 Latin set MAY be used. Also, JIS X 0208 1983 (including 1990) is RECOMMENDED rather than JIS X 0208 1978. "Supporting IP Multicast Integrated Services in ATM Networks", M. Smirnow, H. Sanneck, D. Witaszek, L. Salgarelli, A. Corghi, 11/10/1997, This memo presents an integrated, server-based mechanism for the efficient support of the IP Integrated Services (IIS) model in ATM networks, namely the Multicast Integration Server (MIS) architecture. Instead of viewing IP-ATM multicast address resolution and QoS support separately, the approach in this memo is to consider such issues in an integrated manner. In particular, the MIS architecture defines how a layer-3 setup protocol as RSVP can be mapped to and integrated with a layer-2 multicast address resolution protocol as EARTH - EAsy Multicast Routing THrough ATM clouds. With the use of EARTH, several ATM point-to-multipoint connections with different QoS parameters can be associated to a single IP multicast address. An RSVP server (RSVP-S) within the MIS is used to distribute RSVP messages inside the ATM cloud and to set the corresponding QoS state in the address resolution table of EARTH (setup protocol mapping). In addition, this memo defines a quantized heterogeneity model which supports, together with the MIS, advanced IIS features as QoS heterogeneity and dynamic QoS changes in IP-ATM networks. "Persistent Document Identifiers", John Mallery, 11/11/1997, This document specifies the syntax and semantics of the Persistent Document Identifier (PDI) namespace within the URN framework defined by RFC 2141 [17]. PDIs provide a means to refer to digital objects and fragments that does not depend their storage location or the protocol used to access them. Since 1994, several large-scale applications with these requirements have used PDIs [12] [21]. PDIs are intended primarily as permanent identifiers for archival reference to long-lived documents. PDIs have a fragment syntax to allow permanent references to parts of documents (within specific formats) as well as a citation syntax to allow references to appearances of such fragments in composite documents. PDIs are most useful for any document series that is distributed via multiple protocols, is available from multiple sources, migrates to new locations, needs fragment references, or participates in distributed assertion semantics related to collaboration or access control. "Simple Server Discovery Protocol", Charles Honton, 01/28/1998, The Simple Server Discovery Protocol allows clients to use a multicast address to discover the unicast interface of a cooperating server for a desired service port and optionally authenticate the identity of the client and/or server. "Anti-Spam Recommendations for SMTP MTAs", Gunnar Lindberg, 11/12/1998, This memo gives a number of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [6]) to make them more capable of reducing the impact of spam(*). The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature. The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack. A brief summary of this memo is: o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam. "IMAP4 Language Extension", M. Gahrns, Andrew McCown, 11/13/1997, The Internet Message Access Protocol [RFC-2060] allows server responses to include human-readable text that in many cases needs to be presented to the user. This document specifies a way for a client to negotiate which language the server should use when sending human-readable text. "Bulk Mail Transfer Protocol", John Levine, 11/13/1997, Bulk Mail Transfer Protocol (BMTP) provides a channel for the delivery of ''bulk mail'' electronic mail. BMTP is a service parallel to but sepa- rate from SMTP. The specification of BMTP is intended to be similar enough to SMTP that existing SMTP clients and servers can easily be adapted for BMTP. Extensions provide for categorizing messages by class, and for authorizing the client to the server, to aid in the implementation of cost-sharing systems. "Metadata Content-Disposition Type", Chris Newman, 07/23/1998, The Content-Disposition [CDISP] header defines two disposition types: ``inline'' and ``attachment'' which can affect presentation of a MIME [MIME-IMB] body part. There have been a number of cases where one MIME body part contains metadata for another MIME body part and is neither suitable for inline display by itself, nor is it useful if treated as an independent attachment and saved to a file by itself. If the recipient UA is not familiar with the specific media type, the user often is presented with a useless unrecognizable attachment. This memo proposes a third disposition type, ``metadata'', to address this situation. "POP3 Extension Mechanism and Error Codes", Chris Newman, 11/13/1997, The POP3 protocol [POP3] includes a number of optional commands and some useful protocol extensions have also been published. Currently these optional features and extensions can only be detected by probing. This has resulted in some clients including manual configuration options for POP3 server capabilities. "The Audio/L16 MIME content type", Harald Alvestrand, 11/13/1997, This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. Possible application areas include E-mail, Web served content, file upload in Web forms, and more. "Form-based Device Input and Upload in HTML", James Salsman, 01/05/1998, Currently, HTML forms allow the producer of the form to request information -- including files of data -- from the operator reading the form. However, this capability is limited because HTML forms don't provide a way to ask the operator to submit input from arbitrary sources such as audio devices like microphones. Since input and upload from various devices is a feature that will benefit many applications, this draft proposes an extension to the HTML INPUT TYPE=FILE form element specified in RFC 1867 to allow information providers to express requests for uploads from audio and other devices uniformly. A discussion of MIME audio data types to facilitate useful audio upload responses follows. Also security discussions, audio usability and quality discussions, and a description of a backward compatibility strategy allowing new user agents to utilize HTML written with earlier proposals for audio input in mind. Motivations, including language instruction assistance, voice transcription, and other applications, conclude. "IMAP4 Child Mailbox Extension", M. Gahrns, 11/14/1997, Many IMAP4 [RFC-2060] clients present to the user a hierarchical view of the mailboxes that a user has access to. Rather than initially presenting to the user the entire mailbox hierarchy, it is often preferable to show to the user a collapsed outline list of the mailbox hierarchy (particularly if there is a large number of mailboxes). The user can then expand the collapsed outline hierarchy as needed. It is common to include within the collapsed hierarchy a visual clue (such as a ''+'') to indicate that there are child mailboxes under a particular mailbox. When the visual clue is clicked the hierarchy list is expanded to show the child mailboxes. The CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST '' * or a LIST '' % for each mailbox name. "IPV6 NUMBER ASSIGNMENT PROTOCOL Rev 0.1", K. Denninger, 11/17/1997, This memorandum shall be entitled ''IPV6 NUMBER ASSIGNMENT PROTOCOL'', and describes a proposed policy, procedure and control structure for the allocation of IPV6 Internet addresses. This memorandum discusses the issues surrounding IPV6 numbering on a hierarchial structure and overview. It also presents, where possible and relevant, justification for the positions expressed in this paper. Distribution is unlimited and comments are invited. "A Proposal to add Explicit Congestion Notification (ECN) to IP", K.K. Ramakrishnan, Sally Floyd, 10/27/1998, This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a Congestion Experienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. "Use of Label Switching With ATM", Keith McCloghrie, Bruce Davie, George Swallow, Y Rekhter, E. Rosen, P. Doolan, Jeremy Lawrence, 07/13/1998, A Multi Protocol Label Switching architecture is described in [1]. Label Switching enables the use of ATM Switches as Label Switching Routers. The ATM Switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. This document describes how the label switching architecture is applied to ATM switches. "Recording MBone Sessions to ASF Files", Anders Klemets, E. Fleischman, 11/17/1997, This document specifies two approaches by which multimedia data (e.g., MBone conferences), transmitted using the Real-Time Protocol (RTP), may be recorded to Advanced Streaming Format (ASF) files. The first method requires a minimum amount of buffering at the recording station but results in recordings which identically preserve the received content including out of order packets, network ''jitter'', etc. The second approach requires buffering at the recording station but results in enhanced recordings (i.e., higher percentage of correctly ordered packets, elimination of a percentage of received jitter, potential recovery of a percentage of lost packets). Both approaches record all received RTP content and the relevant subset of RTCP information. This recording occurs transparently to the MBone conference or RTP session, and does not involve any alterations to normal RTP, RTCP, or ASF use. "A Directory for organizations and services from DNS and WHOIS.", Glenn Mansfield, Kohei Ohta, Tomoshiro Ika, 11/17/1997, An Internet Directory is a necessity. The lack of an Internet Directory is posing serious problems. There are several Directory Protocols ready for deployment in the Internet. But, among other factors, content generation for the directory has been a major stumbling block. A simple and straight-forward method of generating contents for a directory of organizations and their network services using information from the Domain Name System (DNS) and the WHOIS servers is described in this memo. "Framework for Interconnecting Internet with Public Circuit-Switching Network", H. Zhu, 11/17/1997, Recently there are a number of efforts trying to connect the packet- switching network with circuit-switching network, especially the Internet with public telephone networks. The first problem of such interconnection is naming and addressing, which are described in some other drafts ([dnsurl], [telurl1], [faxemail]). This draft gives a brief framework on what the problems we may have in architecture and technology when connecting these two networks, and the possible solutions for these problems. "Comparison of MPLS LAN Encapsulation Proposals", Keith McCloghrie, Tony Li, E. Rosen, A. Fredette, Milan Merhar, 11/18/1997, [1] describes how to encode an MPLS label stack as a ''shim'' between the data link and network layer headers of a labeled frame, but [1] does not require that this encoding be used to encode the top of the label stack on LAN media. This document examines the alternative encapsulations that have been proposed for LANs. One alternative is to use the shim as the MPLS encapsulation on LAN interfaces [2]. Another alternative is to encode the top label in the MAC header, rather than in the shim [3]. We describe the implications of each approach. "MPLS Label Stack Encoding on LAN Media", D. Farinacci, Tony Li, Y Rekhter, Dan Tappan, E. Rosen, 11/18/1997, ''Multi-Protocol Label Switching (MPLS)'' [1,2,3] requires a set of procedures for augmenting network layer packets with ''label stacks'', thereby turning them into ''labeled packets'' [4]. Routers which support MPLS are known as ''Label Switching Routers'', or ''LSRs''. In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on LAN data links. "Handle System: A Persistent Global Naming Service Overview and Syntax", Sam Sun, 07/17/1998, The Handle System (r) is a comprehensive system for assigning, managing, and resolving persistent identifiers, known as ''handles,'' for digital objects and other resources on the Internet. Handles can be used as Uniform Resource Names (URNs). The Handle System includes:(a) an open set of protocols, (b) a namespace, and (c) an implementation of the protocols. This is the first of a series of planned documents that will specify the handle protocol and services, and relate the Handle System to other IETF activities in URN/URI/URL working groups. This document provides a concise overview of the system and the syntax of handles. Additional information can be found on CNRI and related project web sites [4, 5, 6, 8, 16, 17, 18, 19]. "The ISAKMP Applications on Security Related Failure Handling", Lein Harn, Yongnan Xu, 11/19/1997, A Security Association is a set of security related information between two or more entities. The Internet Security Association and Key Management Protocol defines procedures and packet formats to authenticate a communicating peer, and establish, negotiate, modify and delete Security Associations. This document describes a new ISAKMP application that utilizes ISAKMP negotiation functions to handle security operation failures of other security protocols. "The UDP Multicast Tunneling Protocol", Ross Finlayson, 09/29/1998, Many Internet hosts - such as PCs - while capable of running multicast applications, cannot access the MBone because (i) the router(s) that connect them to the Internet do not yet support IP multicast routing, and (ii) their operating systems cannot support a tunneled implementation of IP multicast routing. The ''UDP Multicast Tunneling Protocol'' (UMTP) enables such a host to establish an 'ad hoc' connection to the MBone by tunneling multicast UDP datagrams inside unicast UDP datagrams. By using UDP, this tunneling can be implemented as a 'user level' application, without requiring changes to the host's operating system. It is important to note, however, that this tunneling mechanism is *not* a substitute for proper multicast routing, and should be used *only* in environments where multicast routing cannot be used instead. This document describes this protocol, as is currently implemented by the liveGate multicast tunneling server (http://www.lvn.com/liveGate). "Requirements for DAV Searching and Locating", J. Slein, Saveen Reddy, Jim Davis, 03/05/1998, The Distributed Authoring and Versioning protocol [WEBDAV] defines simple mechanisms to assign and retrieve values for properties. This document presents requirements for a WEBDAV extension to support efficient searching for resources based on WEBDAV properties and content. These requirements are intended to be the basis for the DAV Searching a Location (DASL) protocol. "IMAP MailConnect 3 Report", Paul Hoffman, B. Leiba, 11/19/1997, In an effort to help increase the depth of interoperability in the Internet mail industry, over 80 people from 16 companies participated in MailConnect 3, a two-day event sponsored by the Internet Mail Consortium and held in San Jose, California, October 30 and 31, 1997. This document reports the findings of the MailConnect 3 event. "Scalable Resource Reservation for the Internet", T Ferrari, J. Le Boudec, W. Almesberger, 11/20/1997, Current resource reservation architectures for multimedia networks don't scale well for a large number of flows. We propose a new architecture that aggregates flows on each link in the network. Therefore, the network has no knowledge of individual flows, and resource management functions traditionally implemented in the network (such as flow acceptance control) are delegated to hosts. "The uuid: URI scheme", C. Kindel, 11/20/1997, This memo describes a Universal Resource Identifier (URI) scheme that allows resources to be uniquely named over time and space using Universally Unique Identifiers (UUIDs). A UUID URI is a pure URI, in that it contains no information about location. However due to the uniqueness of UUIDs, a UUID URI is persistent over time, much like URNs. UUID URIs are useful in situations where a unique identifier is required that cannot or should not be tied to a particular physical root namespace (such as a DNS name). "Network Service Discovery using RMON-MIB.", Glenn Mansfield, Kohei Ohta, Tomoshiro Ika, 11/20/1997, The Remote network monitoring MIB may be conveniently utilised to discover network services. This memo briefly outlines the technique of carrying out the discovery. "Firewall Management Information Base", Cindy Grall, 04/20/1998, This document 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 monitoring firewall devices. "Generic Label Distribution Protocol Specification", G. Armitage, A Ghosh, Eric Gray, 11/21/1997, This document describes the specification of generic Label Distribution Protocol (LDP) for Multi-Protocol Label Switching (MPLS). Its purpose is to define those parts of LDP that are media/technology independent. Other documents, both existing works in progress and yet to come, will describe specifics of MPLS protocol behavior that apply to a particular media or technology. "BGP-4 MD5 Authentication", Antoni Przygienda, 11/21/1997, This memo describes MD5 authentication scheme for BGP-4 routing protocol analogous to the one proposed for SNMP Version 2 and RIP-2. The mechanism provides greatly enhanced probability for a system attacked to detect and ignore messages received. A sequence number improves additionally the resistance against replay attacks. "BGP-4 over ATM and Proxy PAR", Antoni Przygienda, 03/13/1998, This draft specifes for BGP-4 implementors and users mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy PAR. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost-effective network designs. Proxy PAR can help to distribute changes of peer relationships when BGP-4 capable routers are reconfigured on the ATM cloud. "IPv6 traceroute option", A. Durand, 11/21/1997, The traceroute program has proven very useful and has been extensively used in the Internet for measurement and debugging purposes. However, it only shows the originator to target path and gives no indication on the reverse path. Source routing may sometimes be used to find it, but it's very often disable by intermediary routers. Another problem occurs when packets do not follow the same routes: traceroute outputs are very difficult to read. Other solutions has been proposed to record the route taken by an IPv4 packet. Originally, IPv4 contains an option in which every intermediary router can add its address [RFC791]. Unfortunately, the limitation in size imposed by the options design of IPv4 limits its use to 9 routers. In [RFC1393] another strategy was proposed. An new IPv4 option was created. When a router receives a packet containing this option, it generates a ICMP Echo message to the source. This technique couldn't be widely deployed in IPv4 because it needed a change in every single router to be efficient. These two methods create less traffic on the network and are more accurate, since they give the real route taken by packets and are less sensitive to fluttering. The IPv6 deployment could be the opportunity to widely deploy a new traceroute mechanism based on those two methods. We propose to combine the two previous methods by defining a new hop-by-hop option and a new ICMP message type to record the direct path from the originator to the target and the reverse path from the target to the originator. "IP Extension for Reliable Multicast", Man Lim, D. Kim, 06/02/1998, This memo presents IP extension for recovering multicast packets from congestion. Dropped packets can be recovered far faster by IP routers with extension of this memo than by group member end-hosts. Because necessary interactions are limited among adjacent routers, this scheme substantially reduces overall signaling overhead among group members for packet recovery. "Java LDAP Controls", R. Weltman, Christine Ho, 07/14/1998, This document defines support for the Server Sorting Control, the Virtual List Control, and the Persistent Search Control in the java LDAP API. Controls are an LDAP protocol version 3 extension, to allow passing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. "LDAP Proxied Authentication Control", Tim Howes, R. Weltman, 10/26/1998, This document defines support for the Proxied Authentication Control. Controls are an LDAP protocol version 3 extension, to allow passing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. The Proxied Authentication Control allows a connection with sufficient privileges to assume the identity of another entry for the duration of an LDAP request. "Using the UTF-8 Character Set in the Domain Name System", S. Kwan, James Gilroy, 03/02/1998, The Doain Name System standard specifies that names are represented using the ASCII character encoding. This docuent expands that specification to allow the use of the UTF-8 character encoding, a superset of ASCII and a translation of the UCS-2 character encoding. "A Communication Mechanism between IPv4 and IPv6", Yoshifumi Atarashi, Ken Watanabe, Munechika Sumikawa, Kazuaki Tsuchiya, 11/26/1997, In the late stage of the transition from IPv4 to IPv6, IPv4 lands are interconnected by IPv6 ocean and it is necessary for an IPv4 node and an IPv6 to communicate directly. This memo proposes a mechanism to enable such direct communication with extension name servers, an address mapper, and translators for each IPv4 land. "Explicit Route Support in MPLS", Bruce Davie, Tony Li, Y Rekhter, E. Rosen, 11/26/1997, We define an `explicit route' as a route which is explicitly specified as a sequence of hops rather than being determined solely by conventional routing algorithms on a hop by hop basis. Using the explicit route object proposed for use in RSVP [1] and the ability to bind MPLS labels to RSVP flows [2] we describe how explicit routes may be set up in an MPLS environment. The resulting label switched paths may have associated resource reservations, or may be purely best effort. "GSS Algorithm for TSIG (GSS-TSIG)", S. Kwan, James Gilroy, Praerit Garg, 11/18/1998, The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) [RFC2078]. "Lightweight Directory Access Protocol (v3): Schema for the Routing Policy Specification Language (RPSL)", B Aboba, 11/26/1997, This document defines a schema for the Routing Policy Specification Language (RPSL). It is expected that this schema will be useful in providing a standardized format for representation of RPSL within LDAP-based directory services. "Enabling Transparency for the PPP over SONET/SDH Mapping", James Manchester, Subrahmanyam Dravida, Jon Anderson, Bharat Tarachand Doshi, 11/26/1997, Recent Internet Draft submissions and discussion on the PPP Extensions Working Group email list have highlighted a transparency deficiency with the PPP over SONET/SDH mapping described in IETF RFC 1619. This ID proposes that a 1+x**43 scrambler be used to overcome the transparency deficiency of IETF RFC 1619. "VPIM Directory Schema Definition & Profile", Anne Brown, 11/26/1997, One use of a directory service is the retrieval of information, such as email address and spoken name, to support voice messsaging. This document defines the directory schema required for an X.500/LDAP-based directory service for use by applications supporting Voice Profile for Internet Mail [VPIM2]. The directory service is intended to assist the exchange of voice messages between voice messaging systems. Interaction with desktop applications is outside the scope of this draft. Some schema elements defined herin may be of more general use than just for voice messaging. They are included here because they are not defined elsewhere. It is anticipated that the next version of this schema will only reference such definitions if they get defined in more appropriate areas. This schema will be used to support a pilot VPIM directory service based on X.500 93 and LDAPv2. This next version of the schema will support X.500 97 and LDAPv3. "RVP: A Presence Notification Protocol", Martin Calsyn, 03/16/1998, A new kind of application is emerging on the Internet, driven by the desire of individuals to know instantly whether another individual is online, to be notified when another individual arrives online, and to send messages in \021real time\022. These are all special cases of the more general problem of Internet-wide notification. This protocol for facilitating rendezvous between users, known herein as RVP, is designed to enable such notifications and messages across a loosely coupled (federated) constellation of servers. RVP is designed to address the need for notification in a secure, reliable and scaleable fashion. RVP encompasses the client-server and server-server interactions. The authors recognize that there is significant overlap with between RVP and HTTP, though there are also significant differences. We expect RVP to evolve and either converge or diverge with HTTP and/or other existing protocols. The protocol described in this document represents a very viable starting point for a discussion of a standardized solution to the problem. Comments on this draft are solicited and should be sent to the authors or the RVP discussion list. To join the RVP discussion list, send email with the body 'subscribe' to rvp- request@iastate.edu. "Authentication Scheme Extensions to NTP", D. Mills, T. Glassey, Michael McNeil, 09/01/1998, The purpose of this document is to extend the NTP/SNTP authentication scheme to support additional features, including Public Key Infrastructure (PKI) cryptography, in order to certify the identity of the sender and verify the integrity of the data included in an NTP message, as well as provide support for other facilities such as a timestamp and non-repudiation service. This document describes a new extension field to support new services for securely binding sender credentials to the NTP message stream. One or more of these fields can be included in the NTP header to support designated security services or other services should they become necessary. The presence of these fields does not affect the operation of the NTP timekeeping model and protocol in any other way. Additional fields may provide means to securely bind arbitrary client data to be signed along with the other information in the message. The ability to sign arbitrary client data provides an important non- repudiation feature that allows this data to be cryptographically bound to an NTP timestamp, together with sender credentials and signature. "Aggregating RSVP-based QoS Requests", R. Guerin, Shai Herzog, S. Blake, 11/26/1997, This document describes issues and approaches related to aggregation of QoS requests, when RSVP [BZB+97] is the protocol used to convey such requests. Aggregation is an important component to provide scalable QoS solutions, especially in the core of the backbone where the sheer number of flows mandates some form of aggregation. However, aggregation needs to be provided without impacting the ability to provide end-to-end QoS guarantees to individual flows. In this document, we review some of the main goals of aggregation and describe possible solutions, that do not preclude support for end-to-end QoS guarantees. Those solutions are targeted at unicast flows as we expect them to represent a large fraction of the flows requesting reservation, and hence to be the main contributors to potential scalability problems with RSVP. "THE TRANSMISSION OF IP OVER THE VERTICAL BLANKING INTERVAL OF A PAL TELEVISION SIGNAL", Nick Thorne, 11/26/1997, This is an Internet-Draft, which describes a method for broadcasting multicast IP data using the vertical blanking interval of a PAL television signal. It includes a description for compressing multicast IP headers on unidirectional networks, a framing protocol identical to SLIP, forward error correction schemes for the WST standards. A related Internet-Draft, Ref.[1], is progressing transmission of IP over the VBI of an NTSC television signal. Keywords: VBI, PAL, broadcast, push, FEC, television, NABTS, WST, IP "Pre-Shared Key Extensions for ISAKMP/Oakley", Shawn Mamros, 11/26/1997, The application of IP Security for remote access over the Internet requires that it support ''traditional'' authentication paradigms. This document describes how a traditional username and passphrase-style mechanism can be integrated into the existing pre-shared key authentication mechanism in ISAKMP/Oakley. "Token Card Extensions for ISAKMP/OAKLEY", John O''''Hara, Michael Rosselli, 11/26/1997, The application of IPsec within corporations requires that it integrate existing authentication systems. This internet draft describes how 2 such systems from Axent Technologies, Inc. and Security Dynamics, Inc. can be integrated into ISAKMP. "Configuration of Tunnel Mode Ipsec Endpoint Parameters", John O''''Hara, 11/26/1997, This document describes the assignment of configuration parameters to IPsec tunnel mode client endpoints. Single user computers that are connecting into corporations via Internet Service Providers, ISP's, using Tunnel mode IPsec may need to have configuration information supplied to them, such as inner ip address, DNS server addresses, WINS server addresses, etc. This document describes a method utilized by New Oak Communications to pass these parameters between it's Extranet Access Switch and it's IPsec client software. "LDP Specification", N. Feldman, P. Doolan, Loa Andersson, A. Fredette, 12/02/1997, An overview of Multi Protocol Label Switching (MPLS) is provided in [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using the Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and [ARCH]. This document defines the LDP protocol. "Heuristics for utilizing ISSL Mechanisms for A/V Streams Over Low Bandwidth Links in the absence of Announcement Protocols ", David Putzolu, 12/03/1997, The ISSLOW subgroup of the ISSL working group has defined a set of mechanisms for providing integrated services over low bandwidth links [1]. These mechanisms rely on an announcement protocol (typically RSVP [2]) to determine which streams require other than best-effort service and to determine what level and type of service to provide for such streams. It is anticipated that at least some of the mechanisms defined by the ISSLOW subgroup, specifically Compressed RTP [3] (CRTP) [4] and Multi-Channel Multi-Link PPP (MCML) [5], will be available well before RSVP has been widely deployed. Given the proliferation of applications streaming audio and video using the mechanisms defined in the AVT working group (e.g., RTP), a means of utilizing these mechanisms in the absence of an announcement protocol would be beneficial. Such means have been proposed in [6], but they require changes to applications so as to be able to indicate the need for special treatment. This document describes a set of heuristics for use with the mechanisms defined in the ISSLOW subgroup that provide an enhanced degree of service for audio/video streaming applications without requiring that changes be made to applications. The approach taken is to provide a default set of heuristics that implementations of MCML and CRTP can use to provide enhanced service over PPP links for audio and video streams without requiring any application or infrastructure changes. "Staged Refresh Timers for RSVP", R. Guerin, H. Schulzrinne, Ping Pan, 12/03/1997, The current resource Reservation Protocol (RSVP) design has no reliability mechanism for the delivery of control messages. Instead, RSVP relies on periodic refresh between routers to maintain reservation states. This approach has several problems in a congested network. End systems send Path and Resv messages to set up RSVP connections. If the first Path or Resv message from an end system is accidentally lost in the network, a copy of the message will not be retransmitted until the end of a refresh interval, causing a delay of 30 seconds or more until a reservation is established. If a congested link causes a tear-down message (PathTear or ResvTear) to be dropped, the corresponding reservation will not be removed from the routers until the RSVP cleanup timer expires. "A Proposal for the Format and Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6 Headers", Ed Ellesson, S. Blake, 12/03/1997, This draft proposes an arrangement of fields in the IPv4 TOS byte [RFC795, RFC1349], and in the IPv6 Traffic Class byte [IPv6], and proposes a definition for their associated semantics. The intention is to enable the preservation of currently useful differential class- based queueing behavior on existing network devices, while simultaneously enabling new methods of bandwidth allocation and policing via drop preference, all within the context of flows which may be encrypted at the IP layer using IPSEC. (Note: the IPv6 Class field has recently been expanded to eight bits, but this in not yet available in any version of the specification). "User-Share Differentiation (USD) Scalable bandwidth allocation for differentiated services", A Ghosh, 12/04/1997, In this memo, we present a new differentiated service scheme called ''User-Share Differentiation (USD)''. The USD scheme is based on the principle of link sharing. The scheme allows ISPs to differentiate traffic flows on a per-user basis, providing minimum bandwidth guar- antee and share-based bandwidth sharing. We first look at the objec- tives of differentiated services, and the problems with the current proposals, then present the details of the USD scheme. Finally we examine the implementation and standardization issues "Stream Aggregation", P. Doolan, Loa Andersson, A. Fredette, Christopher White, 12/04/1997, This document describes issues with aggregating streams of data in an MPLS system and suggests alternatives for increasing the level of aggregation possible. "IP Multicast over ATM Networks with Cut-through Forwarding", T. Nishida, Ajay Bakre, 12/04/1997, This document proposes a scheme for IP multicasting in ATM networks, which can achieve cut-through forwarding for inter LIS multicast traffic using ATM protocols. "DNSSEC Signature and Data Verification Semantics", O. Gudmundsson, J Gilmore, 12/04/1997, This draft discusses authorization models for DNSSEC that can be used to determine the relationship of a KEY RR and a DNS RRset in the validation process. Is this key trusted to sign for this data? Is this data trusted because it was signed by this key? This draft defines a number of different policies that can be used and what the signing authority of keys are in each. This draft also addresses what steps are recommended in the secure DNS resolution process and how the authorization policy is put to use. The ideas and definitions expressed here are based on the authors experience in implementing a reference secure resolver. "Dynamic Tunnel Configuration Protocol", Noritoshi Demizu, H. Izumiyama, 12/04/1997, As the Internet grows, the importance of Uni-Directional Links such as satellite links has been increasing. However, most of existing routing protocols assume that datalinks are bi-directional. To incorporate UDLs into the Internet, an IP tunneling approach has been proposed, where tunnels are set up as a virtual back-channel of a UDL to carry routing information between Feeders and Receivers. Dynamic Tunnel Configuration Protocol (DTCP) supports to setup tunnels dynamically between Feeders and Receivers in such environments. "Protocol for shopping over the Internet", Ravi Reddy, 12/04/1997, This Internet-Draft specifies a standard method for shopping on the Internet. Using this protocol client programs can enumerate all the products sold by category, search for a particular product and find the cost or quantity of each product. After realizing the cost of a particular product, client programs can compare the price of this product sold on other Internet sites. "End to End Aggregation of Multicast Addresses", Martin Tatham, B Briscoe, 12/22/1997, This paper presents an approach for solving the inherent problem with multicast routing scalability - by co-operation between end-systems and the network. We introduce an extremely efficient, elegant way to name arbitrary sized inter-meshed aggregations of multicast addresses. This is done in such a way that it is easy to calculate how to change the name to encompass many more related names. We describe how these aggregate names could be used anywhere in place of the set of addresses to which they refer, not by resolving them into multiple operations, but by a single bulk action throughout the routing tree, and in session descriptions potentially including those for reservations. Initial aggregation in end-systems might only reduce the problem by an order of magnitude, but it is believed that this will provide sufficient structure for routers to be able to recognise further aggregation potential. To improve the chances of router aggregation, address set allocation schemes must fulfil certain criteria that are laid down in this paper. "Conversational Multimedia URLs", P. Cordell, 12/23/1997, The evolving technologies for real-time conversation over the Internet require URLs to provide user contact information. As there are many protocols (including some that are not Internet based) that can be used for inter-user conversation, this document describes a two stage transaction process for obtaining a URL that can be used to initiate conversation. The first stage involves retrieving a list of protocol specific URLs in a MIME encoded file. The MIME type enables an appropriate application to be launched which will analyse the presented URLs and select the most appropriate one. The second stage involves interpreting the protocol specific URL and initiating the conversation. The protocol specific URLs are encoded in a URL form so that they can be embedded directly into HTML pages. This allows the first stage to be omitted. The document describes the format of the MIME encoded list of URLs, and the format of a number of protocol specific URLs. "A Two-bit Differentiated Services Architecture for the Internet", Lixia Zhang, V. Jacobson, Kathleen Nichols, 12/23/1997, This document presents a differentiated services architecture for the internet. Dave Clark and Van Jacobson each presented work on differentiated services at the Munich IETF meeting [2,3]. Each explained how to use one bit of the IP header to deliver a new kind of service to packets in the internet. These were two very different kinds of service with quite different policy assumptions. Ensuing discussion has convinced us that both service types have merit and that both service types can be implemented with a set of very similar mechanisms. We propose an architectural framework that permits the use of both of these service types and exploits their similarities in forwarding path mechanisms. The major goals of this architecture are each shared with one or both of those two proposals: keep the forwarding path simple, push complexity to the edges of the network to the extent possible, provide a service that avoids assumptions about the type of traffic using it, employ an allocation policy that will be compatible with both long-term and short-term provisioning, make it possible for the dominant Internet traffic model to remain best-effort. NOTE: This document includes figures that are an integral part of its content. The IETF's choice of ascii as the standard document form precludes the inclusion of those figures. The complete document, with all its figures, is available at: http://ftp.ee.lbl.gov/papers/dsarch.pdf "UTF-9, a transformation format of UCS", J. Abela, 12/24/1997, ISO/IEC 10646 defines a multi-octet character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-9, the object of this memo, has the characteristic of preserving the full ISO-Latin1 range, providing compatibility with file systems, parsers and other software that rely on ISO-Latin1 values. ISO-Latin1 is almost as widespread as ASCII in many countries, especially in most of western Europe, and is the default character set for HTML. A compatible encoding seems desirable, where possible. "LDAP Schema Definitions for Intranet Mail Routing - The mailRecipient Object Class", H. Lachman, 10/12/1998, Directory services based on the Lightweight Directory Access Protocol (LDAP) [1] and X.500 [2] provide a general-purpose means to store information about users and other network entities. One of the many possible uses of a directory service is to store information about users' email accounts, such as their email addresses, and how messages addressed to them should be routed. In the interest of interoperability, it is desirable to have a common schema for such email-related information. This document defines an object class called 'mailRecipient' to support SMTP [3] message transfer agents (MTAs) in routing RFC 822- based email messages [4] within an organization. The intent is to suggest a model for MTA interoperability via the directory, to provide information about a solution that has been implemented and deployed, and to stimulate discussion about whether and how to standardize the functionality in question. "Cell Switch Router - Architecture and Protocol Overview -", Y. Katsube, Hiroshi Esaki, K. Nagami, Y. Ohba, 12/29/1997, This memorandum describes an internetworking architecture of Cell Switch Router (CSR) and related control protocol overview. Cell Switch Router is an ATM-based label switching router that can provide ATM cut-through paths for packet flows with various levels of granularity while retaining current router-based internetworking architecture. The proposed architecture is able to provide the cut-through path in response to the creation of IP forwarding entry (topology-driven), the arrival of data packets (traffic-driven), and the reception of control packets such as RSVP (request-driven). One important feature that is provided by the proposed architecture is interoperability with the emerging ATM network platform, specified by the ATM Forum and/or ITU-T, which provides PVC (Permanent Virtual Channel), VP (Virtual Path), or SVC (Switched Virtual Channel) services. "Multicast Address Alloctation Protocol (AAP)", Mark Handley, 12/29/1997, The document defines a Multicast Address Allocation Protocol (AAP) that forms a part of a larger multicast address allocation architecture currently being defined. AAP addresses the specific issue of intra-domain multicast address allocation between multicast address allocation servers. "The Internet Multicast Address Allocation Architecture", Deborah Estrin, Mark Handley, David Thaler, 12/29/1997, This document proposes a multicast address allocation architecture for the Internet. The architecture is three layered, comprising a client->server protocol, an intra- domain protocol and an inter-domain protocol. "A Description of the MISTY1 Encryption Algorithm", M Matsui, H Ohta, 06/17/1998, This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It is designed on the basis of the theory of provable security against differential and linear cryptanalysis, and moreover it realizes high-speed encryption on hardware platforms as well as on software environments. As the result of weighing strength and speed, 8-rounds of MISTY1 is recommended and used in most cases. Our implementation shows that MISTY1 with eight rounds can encrypt a data stream in CBC mode at a speed of 57Mbps and 40Mbps on Pentium II/266MHz and PA-7200/120MHz, respectively. For its hardware performance, we have produced a prototype LSI by a process of 0.8- micron CMOS gate-array and confirmed a speed of 512Mbps. "BGP Security Analysis", S. Murphy, 11/23/1998, BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, is designed with little consideration for protection of the data it communicates or of its own behavior. There are no mechanisms in BGP to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to be destructive of overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination, and possible security solutions and the costs of those solutions. This internet draft does not discuss security issues with forwarding of packets. "Some Issues and Applications of Packet Marking", S. Blake, 12/29/1997, ''Packet marking'' is proposed as an architectural generalization of the type of service (TOS) and precedence facilities of IPv4 [RFC795, RFC1349], as well as the traffic class facilities of IPv6 [IPv6]. It is intended to encompass all mechanisms by which a host or a router may mark a packet to invoke some differentiated packet handling behavior by another node along the transit path of the packet. This memo examines several proposed applications of a packet marking facility and attempts to categorize each application in terms of the behavioral requirements it imposes on hosts and routers. In addition, issues related to the deployment of packet marking, including provisioning, authorization, and security, are examined. This memo is proposed as a framework to focus discussion on implementation issues and mechanisms as new differentiated services enabled by a packet marking facility are introduced into the Internet. "An SMTP URL Interface", R. Earhart, 12/29/1997, It is occasionally useful to be able to reference a generic server to be used for message submission. URLs provide a good mechanism for refering to arbitrary network resources. The SMTP URL scheme allows a URL to specify an SMTP server, thus allowing other protocols to use a general ''URL to be used for message delivery'' in place of an explicit reference to SMTP. "Flow Attribute Notification Protocol Version 2 (FANPv2) Distributed Control Mode", Y. Katsube, K. Nagami, Akiyoshi Mogi, Shigeo Matsuzawa, Koutarou Ise, 12/29/1997, This memo describes the specification of FANPv2 (Flow Attribute Notification Protocol version 2) distributed control mode (DC-mode). The FANPv2 is a protocol used by Cell Switch Routers (CSRs) to communicate mapping information between a specific packet flow and a virtual connection that conveys the packet flow. In the DC-mode, the control message exchange for a packet flow between each pair of neighboring CSRs is initiated independently from the message exchange for the same flow between any other pair of CSRs. The DC-mode is applicable to the control of both unicast and multicast cut-through paths. "Flow Attribute Notification Protocol Version 2 (FANPv2) Ingress Control Mode", Y. Katsube, Y. Ohba, J Takahashi, Shigeo Matsuzawa, 12/30/1997, This memo describes the specification of FANPv2 (Flow Attribute Notification Protocol version 2) Ingress Control Mode (IC Mode). The FANPv2 is a protocol used by Cell Switch Routers (CSRs) to communicate mapping information between a specific packet flow and a virtual connection that conveys the packet flow. The IC Mode is used for establishing and releasing a loop-free cut-through path from an ingress node to an egress node by forwarding FANP control messages along the path. The IC mode provides a simple potential-loop prevention mechanism by using hop count and ingress node information, and a ''retry'' mechanism that tries to extend the cut-through path after setup failures. "VPN support for MPLS", Juha Heinanen, E. Rosen, 03/09/1998, This document provides a high-level description of how Virtual Private Networks can be supported by using MPLS. "Definition of a Common Management Interface Format", Quentin Liu, 12/30/1997, This document defines a common interface format for describing the configuration of a Virtual Private Network (VPN) in the context of IPSec and equipment from different vendors. The configuration format would be both importable and exportable by various vendors of VPN equipment and software that is IPSec compliant, facilitating an uniform and perhaps automated method of interoperability (creating a VPN) between VPN products from different vendors. This document will only discuss the proposed configuration format. The mechanism by which the file is propagated is beyond the scope of this document and will not be discussed. A security association is not mandatory between two management stations from different vendors wishing to employ this method of VPN configuration, as this configuration format can easily be packaged in a file and propagated out of band. "Flow Attribute Notification Protocol Version 2 (FANPv2) Neighbor Discovery", K. Nagami, Y. Ohba, Akiyoshi Mogi, Shigeo Matsuzawa, Koutarou Ise, 12/30/1997, This memo describes the specification of FANPv2 (Flow Attribute Notification Protocol version 2) Neighbor Discovery protocol (ND). The ND is used for (1) automatically detecting FANPv2 neighbors, (2) obtaining FANPv2 protocol attributes of the neighbors, and (3) checking whether consistent states are maintained by the neighboring nodes. Both DC-mode (Distributed Control mode)[4] and IC-mode (Ingress Control mode)[5] of the FANPv2 use the ND for these purposes. The ND operates over multi-access interfaces as well as over point-point interfaces. "An Architecture and Protocols for Initiation and Control of Telephone Calls From Terminals Connected to a CallBroker over a TCP/IP Connection", Tony DeSimone, Kamlesh Tewani, F. Burg, Raj Vishwanathan, 12/30/1997, This Internet Draft describes a framework, consistent with the model defined in the PINT group in the IETF, for controlling voice and voice-band data (e.g., FAX) calls on the PSTN from an IP Client. As such, it is solely concerned with call control and associated functions. It is not concerned with how to convert packetized voice into a form suitable for carriage over the PSTN. We introduce a logical entity (called CallBroker) that initiates and manages calls on the PSTN and controls the session on behalf of an IP Client to establish a telephone connection between two or more end points specified by the customer (i.e., IP Client). By way of this session, as mediated by the Call Broker, the customer can set up calls and receive notifications regarding the status of the calls and its participants. The interface between the CallBroker and the Service Control Function (as defined in the work on Intelligent Network Standards in ITU-T) in the Service Node (SN) in the PSTN will be defined and standardized as part of this activity. The interface between the IP client and the CallBroker also nees to be defined and standardized as part of this activity. This Internet Draft further advances the discussion on the issues involved in interconnecting the Internet and the Public Switched Telephone Networks (PSTNs), focusing on potential interfaces between Internet-based entities and Intelligent Network (I.N.) entities. The services identified and discussed earlier (e.g., Click-to-Dial, Click-to-FAX, etc.) can be provided using the architecture identified here. "Hierarchical Operational Bindings - a profile", Keith Richardson, Anthony Hodson, Erik Andersen, Louis Visser, Patrick Fantou, Jacqueline Pasquerau, 02/25/1998, Where LDAP servers are based on X.500 DSAs for the holding of distributed Directory information, the maintenance of the necessary security and networking relationships between DSAs is an important factor to consider. The '93 X.500 Directory standards define HOB (Hierarchical Operational Binding) procedures for the creation of a new naming context in another DSA, and also for the maintenance of the relationship between two DSAs where one holds a superior naming context and the other holds a subordinate naming context. The standards also define the use of the Directory Operational Binding Management Protocol (DOP) to mediate these procedures. The use of HOBs provides a major simplification for managers of X.500 systems, since it provides a way to update policies automatically from one DSA to another. But practical design for HOBs requires decisions in a number of respects not fully treated by the standards. This document simplifies the implementor's task by defining viable and practical subsets of the standards and by clarifying some of the issues left undefined by the standards. HOBs always represent an intimate relationship between DSAs which must be protected from masquerade. A method of providing this protection is given in the '93 Directory standards by requiring mutual authentication at the bind between DSAs. HOBS will normally only be established between DSAs owned by a single administrative authority, so security needs to be considered in this somewhat easier context than complete openness. Although simple unprotected authentication (name and password) can be a valid option in an already-secure environment, simple protected authentication using an encrypted password is potentially a much more secure technique, as is strong authentica "Setting up Reservations on Explicit Paths using RSVP", Der-Hwa Gan, Tony Li, R. Guerin, E. Rosen, S. Kamat, 12/31/1997, This document presents motivations for extensions to RSVP in order to enable setting up of reservations on explicit routes. The advantages of providing this support are discussed in the context of MPLS and QoS routing. An approach to providing these extensions by means of opaque routing objects in RSVP messages is presented. "A POP3 URL Interface", R. Earhart, 01/05/1998, It is occasionally useful to be able to reference a generic server to be used for message submission. URLs provide a good mechanism for refering to arbitrary network resources. The POP3 URL scheme allows a URL to specify a POP3 [POP3] server, allowing other protocols to use a general ''URL to be used for mail access'' in place of an explicit reference to POP3. "PGM Reliable Transport Protocol Specification", D. Farinacci, A. Lin, Tony Speakman, A. Tweedly, 08/27/1998, Pragmatic General Multicast (PGM) is a reliable multicast transport pro- tocol for applications that require ordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guaran- tees that a receiver in the group either receives all data packets from transmissions and retransmissions, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for sca- lability and network efficiency. "Delta encoding in HTTP", J Mogul, Y. Goland, Arthur van Hoff, Fred Douglis, Anja Feldmann, Balachander Krishnamurthy, 01/13/1998, Many HTTP requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called ``delta encoding.'' This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. "Instance Digests in HTTP", J Mogul, Arthur van Hoff, 01/13/1998, HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1, may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. "NAT Bypass for End 2 End 'sensitive' applications", Alan O''''''''Neill, George Tsirtsis, 01/14/1998, This document attempts to generate discussion on methods to run end 2 end 'sensitive' protocols and capabilities, like IPSEC, on networks that use Network Address Translators (NAT). The proposal does so by outlining one method to bypass NAT, when the required capabilities cannot be supported by NAT. The method uses a tunnel between a local host and the NAT box in order to dynamically allocate addresses to those hosts that need to communicate with external networks. With an allocated external address, the local hosts are able to communicate with external hosts without breaking the end 2 end principle. This proposal does not introduce any new protocols, it simply reuses existing protocols to provide an example solution. "Multipath Issues in Unicast and Multicast", David Thaler, 11/17/1998, Various routing protocols, including OSPF [1] and ISIS, explicitly allow 'Equal-Cost Multipath' routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. Using equal-cost multipath means that if multiple equal-cost routes to the same destination exist, they can be discovered and used to provide load balancing among redundant paths. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. "Division of IPv6 Neighbor Discovery Into Separable Mechanisms", Margaret Wasserman, 01/14/1998, This memo proposes a formal division of the existing IPv6 Neighbor Discovery protocol into eight separable, related mechanisms: Address Resolution, Duplicate Address Detection (DAD), Router Discovery, Prefix/Parameter Discovery, Address Autoconfiguration, Router Unreachability Detection (RUD), Neighbor Unreachability Detection (NUD) and ICMPv6 Redirects. These mechanisms all depend upon a common set of ICMPv6 Neighbor Discovery messages, but can be enabled and disabled independently, subject to the restrictions and recommendations outlined in this draft. It is not the intention of this memo to propose substantive changes to the existing IPv6 Neighbor Discovery protocol, but to allow the separate portions of IPv6 Neighbor Discovery to be unambiguously identified, making it possible to specify or configure different portions of IPv6 Neighbor Discovery for use on specific link-types, links or interfaces. "talk: a historical protocol for interactive communication", Michael Hunter, 01/16/1998, The BSD talk utility is used for interactive communication between two users. This memo outlines the protocol used. "Common Internet Message Header Fields", J. Palme, 01/18/1998, This memo contains a table of commonly occurring header fields in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 2045, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring header fields which are not defined in RFCs are also included. For each header field, the memo gives a short description and a reference to the RFC in which the header field is defined. This document is a revision of RFC 2076. The following new header fields, not included in RFC 2076, have been added: Content-Alias, Disposition-Notification-Options, Disposition-Notification-To, Expiry- Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List- Post, List-Software, List-Subscribe, List-Unsubscribe, Original- Recipient, PICS-Label, X-Envelope-From, X-Envelope-To, X-List-Host, X- Listserver, X-MIME-Autoconverted, X-No-Archive, X-Priority, X-UIDL. "IP Private Address Identification (PAID)", Thompson Teo, Y. Li, 11/23/1998, This memo describes a hierarchical IP addressing scheme that provides end-to-end host connectivity across routing realms with overlapping address space. PAID agents are routers that connect an internal private network to the global public Internet. The PAID agents' public IP addresses augment the locally significant private addresses to form globally unique binary IP addresses for private hosts. This extends the IPv4 address space and allows Internet hosts to use private instead of public IP addresses for global Internet communication. The proposal does not need any changes to the current routing infrastruture but requires an extension to the end hosts' network socket descriptors and the domain name system. "Simple General Awareness Protocol (SGAP) Revision 1", Mark Day, 03/17/1998, The Simple General Awareness Protocol (SGAP) provides notifications of changes to small data items. The changes are selectively made available to a large collection of viewers. This facility is most useful for a class of applications variously called people locators, colleague-awareness tools, people browsers, or ''buddy lists''. "Globally-Distributed Troubleshooting (GDT): Protocol Specification", David Thaler, 01/26/1998, This document describes a protocol for ''globally-distributed troubleshooting'' (GDT). GDT automates, where possible, the process of problem reporting and referral between customers and Internet Service Providers (ISPs), as well as between ISPs. GDT also provides an automatic mechanism for periodic status reports, and allows an ISP to make information (such as expected time to repair) on a current problem readily accessible to those directly affected by it, without requiring human intervention. "Mandatory Extensions in HTTP", P. Leach, H. Nielsen, Scott Lawrence, 01/27/1998, HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. This document proposes the use of a mandatory extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The proposal associates each extension with a URI[2], and use a few new RFC 822[1] style header fields to carry the extension identifier and related information between the parties involved in an extended transaction. "Telnet SASL Option", Chris Newman, 11/09/1998, It is common today for Internet client software to implement multiple Internet protocols. SASL [SASL] provides an authentication framework which permits multi-protocol clients and servers to reuse security-sensitive authentication code. This memo defines a SASL profile for the Telnet [TELNET] protocol. This proposal will be discussed on the telnet-ietf mailing list. To subscribe, send the word 'subscribe' to . "DSS Secured Password Authentication Mechanism", Chris Newman, 03/05/1998, Some system administrators are faced with a choice between deploying a new authentication infrastructure or sending unencrypted passwords in the clear over the Internet. Deploying a new authentication infrastructure often involves modifying operating system services or keeping parallel authentication databases up to date and is thus unacceptable to many administrators. Solutions which encrypt the entire session are often crippled with weak keys (due to government restrictions) which are unsuitable for passwords. In addition, such solutions often reduce performance of the entire session to an unacceptable level. This specification defines a SASL [SASL] mechanism which is compatible with existing password-based authentication databases and does not require a security layer for the remainder of the session. [NOTE: Public discussion of this mechanism may take place on the ietf-sasl@imc.org mailing list with a subscription address of ietf-sasl-request@imc.org. Private comments may be sent to the author]. "Sieve -- Vacation Extension", T. Showalter, 01/27/1998, This document describes an extension to the Sieve mail filtering language for an autoresponder similar to that of the Unix ''vacation'' command. The extension is offered in the hopes of making frequently used commands availible (and discouraging users from implementing it themselves). "The Ted.Net protocol for messaging based business interchanges", Jean Paul Laroche, 01/29/1998, The Ted.Net protocol improves messaging systems while being fully compatible with all of them. Ted.Net improvements bring to messaging systems' end users : - large file transfers capabilities, - pretty good level of privacy, - integrity control of the transfered data, - time stamped proofs of the acceptance of data by the recipient. With the secure and stable services of Ted.Net, users can rely on private or public messaging systems, SMTP, X400, or editors' ones, to put on Electronic Data Interchanges (EDI). "Duplicate IP Address Detection Based on Gratuitous ARP", Tyan-Shu Jou, 09/08/1998, The Address Resolution Protocol defines the way to resolve the hardware address of a host on a broadcast network based on the target host's IP address. The hardware address is always unique for each hardware module, but no guarantee on the uniqueness of IP addresses. With current trend of connecting every hosts, the chance of the same IP address is used on different hosts is increasing due to users' or network administrators' mistake, or a configuration error from an IP address assigning program such as a BOOTP or DHCP server. This memo is to define an extention to the original protocol to prevent a newly configured host from making any damage to the host that has been the owner of the same IP address. The solution is based on using the de-facto gratuitous ARP packet plus modification on processing of this packet. "Multicast Address Request Protocol (MARP)", Steve Hanna, 01/30/1998, The Multicast Address Request Protocol (MARP) serves as a front end to the Multicast Address Allocation Architecture. Any host that wishes to allocate a multicast address may contact a Multicast Address Allocation Server and use MARP to request an address allocation for a specific interval, scope, etc. Later, the host may request an extension of the address allocation or deallocate the address if it is no longer needed. "Cachebusting - cause and prevention", M. Hamilton, A. Daviel, 02/03/1998, Cachebusting is the sometimes deliberate, sometimes inadvertant, practice of defeating caching. This document explains the nature of the problem with relation to proxy cache servers using the World-Wide Web's HTTP protocol, and outlines some simple measures which may be taken to make an HTTP based service more ''cache friendly''. Since Web caching is still a novel concept, we also explain the basic principles behind it. This document should be read by developers of HTTP based products and services - we assume that the reader is already familiar with HTTP. "Telnet Data Encryption Option", Theodore Ts''o, 11/10/1998, No Abstract Submitted. "Telnet Authentication Option", Theodore Ts''o, 11/09/1998, No Abstract Submitted. "Telnet Authentication: Kerberos Version 5", Theodore Ts''o, 11/10/1998, No Abstract Submitted. "Telnet Encryption: DES 64 bit Cipher Feedback", Theodore Ts''o, 11/10/1998, No Abstract submitted. "Telnet Encryption: DES 64 bit Output Feedback", Theodore Ts''o, 11/10/1998, No Abstract submitted. "DNS-based NLRI origin AS verification in BGP", Tony Li, Randy Bush, Y Rekhter, T. Bates, 02/06/1998, This document describes how a BGP speaker may verify that the Network Layer Reachability Information (NLRI) of a prefix received from a peer is consistent with the allocation of IP address space as determined by the Internet Registry system. These verification procedures rely on the DNS to provide a repository of information about address space allocation provided by the Internet Registry system. Note that this is not a repository of announceable prefixes, but rather of allocation of delegated address space. "Architecture of the Resource Reservation Service for the Commercial Internet", M. Suzuki, 02/09/1998, With the development of new multimedia applications, such as voice, audio, picture, and video communication, the demands on the resource reservation service are increasing, especially as Internet traffic volume grows explosively due to these applications. Therefore, tariff systems for Internet service have tended to adopt measured rate billing, and the resource reservation setup protocol [1, 2] is increasingly important as a method for implementing measured rate billing. The resource reservation setup protocol must support billing if it is to be applied to the commercial Internet, especially measured rate billing between interconnected Internet Service Providers (ISPs) is needed. The purpose of this document is to clarify the architecture that should be used for the resource reservation service for the commercial Internet. First, this document explains the basis of the tariff for current telecommunication and Internet services. Then it clarifies problems in the billing for Internet service, and describes how billing can be improved by using the resource reservation setup protocol. Finally, it also studies technical and application models for a commercial resource reservation service model, and clarifies an architecture for the resource reservation setup protocol. Incidentally, it is essential to examine billing based on business administration issues, not technical ones. For example, on a telephone service, it technically makes sense to charge the caller when the user being called is on another line. This is because, telephone switches were in operation when they notified the caller that the number he called was busy. However, such a billing policy is contrary to the customs of business. Readers should note that the billing problems and solutions discussed in this document are not only based on the technical viewpoint. "The Keyword Protocol (KP)", Peter Lakov, 02/10/1998, This document provides a proposal for a new Internet protocol, which should improve the relevance of results of search requests for information in the WWW. It contains a description of the basic model and the minimum set of commands necessary to run properly. It is neither meant to nor should be regarded as a definitive version, but rather as a suggestion to a new way of looking at the relations between the search engines on one hand and hosts running WEB servers on the other. "Presence Information Protocol Requirements", Mark Day, Lisa Dusseault, Martin Calsyn, Gordon Mohr, Sonu Aggarwal, 02/10/1998, Online users have demonstrated a desire to know instantly whether another individual is online, to be notified when another individual arrives online, and to send instant messages. These applications currently use independent, non-standard and usually non-interoperable protocols. The goal is to define a standard protocol so that independently written client and server implementations can participate in a global network of ''online'' users. This draft outlines requirements for a Presence Information Protocol to support these applications. Distribution of this document is unlimited. Please send comments to the RVP discussion list at rvp@iastate.edu, which may be joined by sending a message with subject ''subscribe'' to rvp- request@iastate.edu. Archives of past messages are available. Send the single word \021help\022 to rvp-request@iastate.edu for more information. "Modification in Datagram Too Big message", Vivek Kashyap, 02/10/1998, This memo describes a small modification in the 'Datagram Too Big' message for both the IPv4(ICMPv4) and IPv6(ICMPv6) standards. The document addresses possible reduction in resources on large servers when implementing the Path MTU discovery process. "Telnet Authentication Using DSA", P. Yee, Russ Housley, Todd Horting, 07/29/1998, This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA) [2]. It relies on the Telnet Authentication Option [1]. "The Text/Paragraph Media Type", Ned Freed, Chris Newman, 02/12/1998, The text/plain media type is defined to represent plain text where the CRLF sequence represents a line break [MIME-IMT]. Many modern computer systems have a different concept of ``plain text'' from the systems where the text/plain media type originated. These modern systems usually use a proportional-spaced font and use CRLF to represent paragraph breaks. Numerous software products have erroneously labelled this media type as text/plain. In order to correct this interoperability problem, the text/paragraph media type is defined. [NOTE: This proposal may be discussed publicly on the ietf- 822@imc.org mailing list. The subscription address is ietf-822- request@imc.org.] "Network Address Translation issues with IPsec", Robert Moskowitz, 02/12/1998, This document looks at a number of issues surrounding the need for network address translation (NAT) when IPsec is used to create virtual private networks (VPN). This document only looks at simple VPNs. That is VPNs consisting of a single IPsec tunnel as compared to VPNs consisting of \021chained\022 and/or \021nested\022 IPsec tunnels and/or transports. It proposes a method to vastly reduce the extent that NAT is needed in a VPN. "Use of Block Ciphers for Message Authentication", Ben Rogers, 02/13/1998, This draft describes CBC-MAC, a method for using encryption functions to produce message authentication hashes. CBC-MAC can be used with any block cipher (eg. DES, 3DES, Blowfish) in combination with a secret key appropriate for that cipher. The cryptographic strength of this authentication depends on the strength of the algorithm, and may be influenced by other factors appropriate to the algorighm (eg. Weak Keys for DES). "Advanced Streaming Format (ASF) Specification", E. Fleischman, 02/27/1998, The Advanced Streaming Format (ASF) is an extensible file format designed to store synchronized multimedia data. It supports data delivery over a wide variety of networks and protocols while still proving suitable for local playback. ASF supports advanced multimedia capabilities including extensible media types, component download, scaleable media types, author-specified stream prioritization, multiple language support, and extensive bibliographic capabilities, including document and content management. "Language Tagging in Unicode Plain Text", G. Adams, Ken Whistler, 02/16/1998, This document proposed a mechanism for language tagging in [UNICODE] plain text. A set of special-use tag characters on Plane 14 of [ISO10646] (accessible through UTF-8, UTF-16, and UCS-4 encoding forms) are proposed for encoding to enable the spelling out of ASCII-based string tags using characters which can be strictly separated from ordinary text content characters in ISO10646 (or UNICODE). "Don't Go Postal - An argument against improperly overloading the HTTP POST Method", Josh Cohen, 02/16/1998, As time goes on, more and more groups are extending HTTP's functionality. In using HTTP, a decision is made to either use a new method name for new functionality or to overload an existing one such as POST. Our belief is that in most cases, overloading existing method names, with POST as a particularly troublesome example, is a bad idea. We, as a group of individuals, suggest that the default requirement for new HTTP functionality must be to create a new method name. "Preferred Language Tag", Marc Blanchet, 02/16/1998, This memo defines a new tag which will help users and servers to determine the best language in their communications. For example, error messages coming from SMTP servers or HTTP servers can use this tag to send those error messages in the preferred language for the user. "ROAMING-ELGAMAL SASL Authentication Mechanism", P. Overell, 02/24/1998, ROAMING-ELGAMAL is an SASL [SASL] authentication mechanism in which ElGamal [ELG] public key cryptography is used to encrypt the persona and password thus giving a high degree of security. Although specifically designed for the Simple Roaming Authentication Protocol [SRAP], ROAMING-ELGAMAL is intended to be a registered SASL mechanism and so could be adapted to other protocols. The mechanism has been designed to resist attack from interception, man in the middle, and replay. The security of the mechanism rests with the protection of the private key. "Simple Roaming Authentication Protocol: SRAP", P. Overell, 02/24/1998, The Simple Roaming Authentication Protocol is intended to provide an authentication facility for other non-authenticated protocols. It utilises registered SASL [SASL] mechanisms. This protocol has been developed in order that an ISP's roaming customers can be authenticated when connecting via other networks or ISPs. Rather than deploying new client software to handle authenticating versions of all protocols (SMTP, POP3, NNTP etc) a single SRAP applet is deployed that handles the authentication for all other protocols. When the server of a non-authenticated protocol wishes to authenticate a client the server starts another connection back to the client using SRAP. The SRAP conversation authenticates the client to the server. The original non-authenticated protocol can now proceed. For example with SMTP consider two machines Alice's and Bob's. Alice's runs an SMTP client and a SRAP authenticatee; Bob's runs an SMTP server and a SRAP authenticator. Alice's machine connects to Bob's using SMTP. SMTP does not support authentication so another connection is made back from Bob's machine to Alice's, this time using SRAP. The SRAP conversation authenticates Alice to Bob. The SMTP conversation can now proceed. "The Use of Post: A Response to draft-cohen-http-postal-00.txt", T. Hastings, F. Wright, H. Lewis, S. Isaacson, R. deBry, Carl Kugler, Stee Gebert, 02/24/1998, A recent Internet Draft [1] argues that the common use of POST to proide a uniform method of passing blocks of data to an application, is being misused in the definition of new application protocols, such as the Internet Printing Protocol. Cohen et. al. argue that a new PUSH method be defined for this purpose. This Internet Draft argues that the existing POST method proides all of the required functionality for back end applications, such as Print, without sacrificing the leels of security that customers expect. More importantly, from the customer\022s point of iew, it does this without any impact to existing, installed network components. "WASRV Architectural Principles", Jonathan Rosenberg, H. Schulzrinne, Erik Guttman, R. Moats, 02/25/1998, This document defines the problem of wide area service location, describing its key attributes, and giving examples of location prob- lems which do or do not fall under its definition. It also touches on a number of related protocols, and looks at how they fit, or do not fit, the problem of wide area service location. "INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION", M. Crispin, 02/26/1998, This document describes the server-based sorting extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer sorted views. "Message Tracking Model", G. Vaudreuil, Gordon Jones, Bruce Ernst, 02/27/1998, This document defines an SNMP-based message tracking model for electronic messaging management usage. Message tracking is the ability to find out, after the fact, the path that a particular message took through the messaging system, the current status of that message, and its characteristics. This document defines the model, architecture, and requirements for message tracking. An SNMP MIB to support message tracking is found in a related document. "Message Tracking MIB",, 02/27/1998, This document defines a message tracking Management Information Base (MIB) for electronic messaging management. Message tracking is the ability to find out, after the fact, the path that a particular message took through the messaging system and the current status of that message. "Mobile IP extension for Private Internets Support (MPN)", T. Teo, Y. Li, 11/23/1998, This memo specifies enhancements to Mobile IP that allow IP mobility support across routing realms. The protocol allows a mobile node to have the same home network connectivity, regardless of its current routing realm network point of attachment. It is designed to work in the presence of address collisions and network address translations. Private networks connected to the public Internet can extend IP mobility support to cover the public Internet and other private networks. Movement from a private home network to the public foreign network, from a private home network to another private foreign network or from the public home network to a private foreign network are possible under the MPN framework. "Distributed Robots: a Technology for Fast Web Indexing", Roberto Di Cosmo, Pablo Ernesto Martin Lopez, 03/04/1998, We propose a protocol (the Remote Update Protocol, RUP) for cooperation between Web Servers and Web Robots in order to increase the reliability of Web indexing, and decrease the load both on the server and the robot side. If the servers conform to the RUP protocol, the task of the Robot will appear to be distributed between the servers that it consults - for that reason we choose to call this note ``Distributed Robots``. "Hyper Text Caching Protocol (HTCP/0.0)", P. Vixie, Duane Wessels, 09/01/1998, This draft describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. "LDAPv3 Security Parameters", Vesna Hassler, 03/05/1998, Two security services that are required in many applications but have not been addressed by LDAPv3 [ldapv3] in a satisfactory manner yet are integrity and non-repudiation. According to the latest LDAPv3 security draft [ldapv3-auth] integrity can be achieved within a secure association only. Non-repudiation, and by this we mean digital signing of operations, is mentioned in [ldapv3] as an example of the use of the LDAPv3 extended operation mechanism. A disadvantage of this approach is that it would be necessary to define a new Extended Request/Response pair for each basic operation that should be signed. This document defines an LDAP control called LDAPSecurityParameters for transferring security parameters with LDAP operations. With this control it is possible to append digital signature to LDAP operations and in this way provide for message authenticity, message integrity, non-repudiation of message origin and message freshness. "WhoDP: Widely Hosted Object Data Protocol", Gordon Mohr, 03/05/1998, The Widely Hosted Object Data Protocol (WhoDP) exists to communicate the current location and state of large numbers of dynamic, relocatable objects. Initially and most commonly, these objects are people, and the groupings or spaces that people use to enable communication. Loosely patterned after HTTP, WhoDP implements a publish-and- subscribe model, with objects' location and identity specified via URLs. A WhoDP program ''subscribes'' to locate and receive information about an object; a WhoDP program ''publishes'' to control the location and visible state of an object. "DIAMETER IP Security Policy Extensions", Pat Calhoun, Sumit Vakil, 03/05/1998, The DIAMETER User Authentication/Authorization extension defines a mechanism which is used by a Network Access Server (NAS) to authenticate dial-up users. IP Security defines a mechanism of establishing a secure link between two entities over a network. This document defines a mechanism for DIAMETER to inform the NAS of the security policies required for secure communication with a host. "DIAMETER Resource Management Extensions", Pat Calhoun, Nancy Greene, 07/28/1998, DIAMETER is a policy protocol used between a client and a server for authentication, authorization and accounting of various services. Examples of such services are for dial-up users (ROAMOPS), RSVP Admission Policies (RAP), FAX Over IP (FAXIP), Voice over IP (SIPTel), Integrated services, etc. This document defines a set of commands which allow DIAMETER servers to maintain session state information. An example of the use of Resource Management would be to limit the number of sessions for a given user. "Use of Anycast Clusters for Inter-Domain Multicast Routing", D. Farinacci, L. Wei, John Meylor, 03/09/1998, Anycast Clusters is a proposal to connect multiple ISP sparse-mode PIM domains together. The environment we anticipate is multiple interconnection points among a set of ISPs when they are unable to colocate their respective RPs at the same dense-mode interconnect point. This is an alternative to the Multi-Level RP design and requires less new code in routers. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment and is upward compatible with the IDMR protocols being proposed for subsequent phases. "Domain names for part-time Internet hosts", R. Nelson, 03/05/1998, Several large providers use subdomains for their dialups, but no subdomain is popular enough to be recognizable. This memo standardizes the names of Internet hosts which are not connected to the Internet at all times. "The Java SASL Application Program Interface", John Myers, Prasad Yendluri, R. Weltman, Christine Ho, 10/27/1998, This document defines a client-side java language interface for using the Simple Authentication and Security Layer (SASL) mechanisms for adding authentication support to connection-based protocols. The interface promotes sharing of SASL mechanism drivers and security layers between applications using different protocols. It complements but does not replace [1], which defines and exemplifies use of the SASL protocol in a language-independent way. "Security Analysis to Server Cache Synchronization Protocol", Felix Wu, Cliff Wang, 03/09/1998, Server Cache Synchronization Protocol SCSP [1], [2], [3], [4] is used to solve the generalized cache synchronization/cache -replication problem for distributed protocol entities. In a client-server paradigm, SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group. This document provided a security analysis of the current SCSP framework and identified potential threats to the protocol operation. Possible solutions to secure the SCSP from potential attacks are presented and discussed. "Credential Management for SPKM", D. Huehnlein, H. Schupp, 03/09/1998, The GSS-API [GSS-API1,2] offers security services independent of underlying mechanisms. A possible GSS-mechanism is the Simple Public Key Mechanism [SPKM]. This paper complements [SPKM] by providing concrete rules for the Credential Management. Our proposal allows beside the standard Credential Management based on X.509v3 [X509v3] and PKIX [PKIX] the self certification of temporary public keys, which may be used to implement a Secure Single Login variant, which works with temporary keys instead of the sensitive long term keys. The benefits of this approach are discussed in [SSLogin] more detailed. Since DL-based signature- and encryption algorithms are very well suited for the efficient generation of the temporary keys we propose two new RECOMMENDED algorithms for SPKM. "A One-bit Feedback Enhanced Differentiated Services Architecture", Shivkumar Kalyanaraman, Surendra Arora, Khem Wanglee, Greg Guarriello, David Harrison, 04/27/1998, This document proposes the use of one bit in the DS-byte to facilitate ECN-type control in the differentiated services architecture. Specifically during periods of congestion along a flow's path (indicated using the one-bit mechanism), the out-of- profile packets of the flow (packets for which the 'In profile' bit is cleared) can be either delayed or dropped by the ingress network edge routers. This scheme would allow interior routers to preserve their resources for processing in-profile packets during congestion and guard against certain types of denial-of-service attacks. The proposed mechanism could also be used to build differentiated services networks with lower average delay, and aid the implementation of congestion-based pricing schemes in such architectures. The mechanism interoperates well with the baseline differentiated services architecture and can also interoperate with ECN-TCP and future ECN-enabled transports/applications. Further, the ECN-type flow control can be deployed within a differentiated services network even if end-to-end ECN support is unavailable, allowing a quick migration path. "Telnet Authentication Using KEA and SKIPJACK", P. Yee, Russ Housley, Todd Horting, 07/29/1998, This document defines a method to authenticate telnet using the Key Exchanage Algorithm (KEA), and encryption of the telnet stream using SKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. It relies on the Telnet Authentication Option [1]. "Differentiated Services over Symmetric NHRP Shortcuts", Bernd Staegemeir, Steve Turner, 03/10/1998, There is a need, for relatively simple and scaleable methods of providing differentiated classes of service for IP traffic over various WAN media, to support different types of applications and specific business requirements. The Differentiated Services approach to providing quality of service (QoS) in Networks, employs a small, well-defined set of building blocks from which a variety of services may be built. A small bit-pattern in each packet in the IPv4 ''TOS octet'' or in the IPv6 ''Traffic Class octet'' is used to mark a packet to receive a differentiated forwarding treatment or per-hop behavior at each network node. IETF Working Groups will standardize a common layout for both octets, called the ''DS byte'' superseding the IPv4 TOS octet definitions or RFC 1349 [1]. The goal of this contribution is to suggest how the Next Hop Resolution Protocol (NHRP) may be extended and deployed in conjunction with the IP ToS octet (DS-Byte) to create both differentiated forwarding and differentiated class of service over an NBMA network such as ATM or Frame-Relay. In the proposed solution, any SVC created between the same two points in an NBMA network will be used bi-directionally by traffic with the same class of service. This is achieved by extending the scope of the existing NHRP protocol to include QoS information in the extensions part of both the NHRP resolution request and resolution reply, and by implementing a NBMA addressing scheme that dynamically maps CoS, to subaddresses that are unique within the NBMA network. The proposal is compliant with the NHRP specifications, and every effort is made by the proposal to build on the work currently underway within the IETF that is attempting to standardize on the use of the ToS octet (DS-byte) within the IP datagram. "Host Resources MIB V2", Bobby Krupczak, 10/01/1998, This memo modifies the original Host Resources MIB (RFC 1514) by converting it to the SNMPv2 SMI. Further, this memo adds clarifying text, based on implementation and deployment experience, to ambiguous MIB object specifications. It does not add nor remove managed objects from the original specification nor change their fundamental semantics. The original memo defines a MIB for use with managing host systems. This memo does not modify the original RFC's definitions or assumptions. Included from the original RFC [1]: The term 'host' is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. "Receiver control in Differentiated services", Borje Ohlman, Petri Koskelainen, 09/30/1998, This draft addresses the issue of receiver control for the specific case where the receiver needs to control incoming traffic on its own access link. This is of particular importance for low bandwidth links. "MPLS Routing Dynamics", Siamack Ayandeh, Yanhe Fan, 03/11/1998, This Internet draft outlines how transients in protocols such as OSPF [7] (intra-domain routing) and MPLS LDP [2] can lead to periods of time with loops and other undesirable routing phenomenon. It defines a set of metrics to quantify this dynamic behavior. Quantification of these metrics, using a simulation model, for various local vs. egress label allocation schemes is used as the basis of a comparative analysis. This includes quantifying any incremental impact that MPLS may have once it is introduced into an autonomous IP routing area. The resulting insights would help develop a better understanding of routing dynamics. This includes identifying key nodal and network variables which impact routing dynamics hence guiding MPLS feature selection and IP network design. "Best Current Practice for Modem Outsourcing", Nancy Greene, Fernando Cuervo, 03/11/1998, This document describes an architecture and the protocol used with respect to a Network Access Server (NAS), when modems are outsourced from the data network operator to the carrier network operator. At the heart of modem outsourcing there are several key areas, namely, varied mechanisms for authentication, authorization based on network wide state and policy for resource sharing, accounting/auditing and other management functions. "Guide lines for Key words use to indicate requirement levels in RFCs", Duekyoon Kang, Shin Fang, 03/11/1998, In many IETF documents several key words are used to signify the requirements in the spefcification. This document defines the requirement levels imposed by these words as they should be interpreted in IETF documments. The requirement levels are basically equivalent to the ones proposed by RFC 2119[1]. But easier to understand the strength of key words and to introduce new key words to the hierarchy of requirement levels if ever there's a need. "DAV Searching and Locating", Saveen Reddy, Surendra Reddy, Rick Henderson, Jim Davis, Alan Babich, Dale Lowry, 11/23/1998, This document specifies a set of methods, headers, and content- types composing DASL, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client- supplied criteria. "SRP essentials", J. Le Boudec, W. Almesberger, Tiziana Ferrari, 03/11/1998, This paper gives a succinct description of the design of SRP, a highly scalable resource reservation protocol for Internet traffic. "ACAP Email Personality Dataset Class", R Gellens, 03/12/1998, It has become common for Internet mail users to receive and compose mail in the capacity of different roles or identities (for example, personal and work), to receive and compose mail at different machines, and to use multiple programs which require mail composition configuration information. These different roles or identities have become known as email personalities. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of email personality data. This specification defines a standard ACAP dataset class for email personalities, and a common option for indicating a default. "ACAP Bookmarks Dataset Class", R Gellens, 03/12/1998, Storing URLs [URL] for later access has become common in Internet applications (for example, web browsers, FTP clients); these saved URLs have become known as bookmarks. It would be desirable to access one's bookmarks from multiple clients and multiple machines. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of bookmarks, providing for ease of coordination and synchronization of bookmarks between diverse applications and systems, as well as for hierarchy, inheritance, and sharing. "ACAP Email Account Dataset Class", R Gellens, 03/12/1998, It has become common for Internet mail users to have more than one account where mail is received, to access multiple accounts from the same machine, to access the same accounts from different machines, and to use multiple programs which require account configuration information. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of email account data. This specification defines a standard ACAP dataset class for email accounts, and a common option for indicating a default. "Techniques in OSPF-based Network Deployment", H. Berkowitz, 03/12/1998, OSPF is the preferred interior routing protocol of the Internet. It is a complex protocol intended to deal with complex networks. While it is a powerful mechanism, it does not handle all situations, and its appropriate use may not be obvious to beginners. Standards track documents deal with protocol design, but deployment of OSPF in many enterprise networks has been limited by lack of information on best current practice information for interior routing. Best Current Practices documents have focused on general exterior connectivity. This memorandum is intended to complement the protocol specification by describing the experience-based, vendor-independent techniques of OSPF and complementary technologies in representative networks. Better understanding of the use of OSPF features to help exterior connectivity will help reduce the demand for complex user BGP configuration. "Access-restricted, HTTP/1.1 Cache Control Extension", Ingrid Melve, Simon Wilkinson, 03/12/1998, User agents such as caches and web indexers, which act on behalf of more than one user are often given access to documents which are restricted by IP address or domain. These agents then republish this information to users outside the allowed block, as there is currently no means of marking these objects with their access restrictions. This document details an extension to the Cache-control header in HTTP/1.1 [HTTP/1.1] to add information about IP or domain based access restrictions. It also stresses that Cache-control should apply to all User-agents which work on behalf on a number of users, and not just to caches. "Encoding of SRP packet types in the DS byte", T Ferrari, J. Le Boudec, W. Almesberger, 03/12/1998, We propose an encoding of the packet types used by SRP (Scalable Reservation Protocol) in the DS byte under study by the Differentiated Services working group. "Network News Distribution Protocol: Architecture and Design Guidelines", C. Bormann, 03/12/1998, This document describes an architecture and a set of protocols for distributing Netnews [RFC0977, RFC1036] via IP multicast enabled networks. The architecture is designed to be useful in the global Internet. In particular, it allows multiple news servers to cooperate on multicasting each new article only once. To facilitate scalability to tens of thousands of news servers, it also provides for receive-only multicast participants (that continue to send articles via conventional NNTP). This document is a submission to the IETF MNNP working group. Comments are solicited and should be addressed to the working groups' mailing list at ietf-mnnp@va.pubnix.com and/or the author. "Using IPv6 Addresses in URLs", Brian Carpenter, Larry Masinter, Jim Gettys, 09/02/1998, The normal textual representation for IPv6 addresses as a set of colon-separated hexadecimal numbers does not work well with most deployed URL-parsing software. This document describes an alternate format which will pass unharmed through most URL-parsing software. "IGMP Extension for Authentication of IP Multicast Senders and Receivers", N. Yamanouchi, O. Takahashi, N. Ishikawa, 08/05/1998, The security enhancement is one of the most important enhancements to IP multicast. IP multicast requires many security functions that include user authentication of IP multicast, encryption of IP multicast datagrams and key management protocols for IP multicast. Among them, the user authentication function for IP multicast is considered one of the most important security functions for IP multicast. This document describes the extension to IGMP, version 2 (IGMPv2) [1] for the authentication of IP multicast senders and receivers, which prevents an unauthorized user from sending and receiving IP multicast datagrams. "Distributing control of the Domain Name System", M. Hamilton, J Knight, 03/13/1998, This proposal outlines a way in which the Internet community may be able to route around the legal and political issues associated with control of the Domain Name System. We suggest a new mechanism for the distribution of domain name information, based on strong cryptographic authentication. In this new system, anyone is free to ''publish'' domain name information, with control over whether or not it is accepted left to the local site DNS server administrators. "The Content-MD5-Origin: header", M. Hamilton, 03/13/1998, The Content-MD5: header specified in RFC 1864 has not been widely deployed, though this would be highly desirable for a number of reasons. The author conjectures that this lack of usage is due at least in part to the requirement that only originating user agents may add a Content-MD5: header. This proposal updates RFC 1864 to remove that requirement, and defines the header Content-MD5-Origin: for use by relaying hosts to indicate the point at which a Content- MD5: header was added. "Internet Public Key Infrastructure Real Time Certificate Status Protocol - RCSP", C. Adams, Ambarish Malpani, Rich Ankney, Slava Galperin, 03/13/1998, The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies a protocol useful in determining the current status of a digital certificate without the use of CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. Section 2 provides an overview of the protocol. Section 3 goes through the functional requirements, while section 4 provides the details of the protocol. In section 5 we cover security issues with the protocol. Appendix A demonstrates RCSP over HTTP. Please send comments on this document to the ietf-pkix@tandem.com mail list. "An Abstract API for Multicast Address Allocation", Ross Finlayson, 11/19/1998, This document describes the ''abstract service interface'' for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications. Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service. "MPLS Loop Prevention Mechanism", Y. Katsube, Y. Ohba, E. Rosen, P. Doolan, 11/19/1998, This paper presents a simple mechanism, based on 'threads', which can be used to prevent MPLS from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path-vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved. "Elevating RTP to Protocol Status", Jonathan Rosenberg, H. Schulzrinne, B Aboba, 03/13/1998, This document discusses the issues involved in elevating RTP to the status of protocol, equivalent to TCP or UDP. This will result in all RTP packets being explicitly labeled as such in the packet header. This vastly simplifies the problem of classifying real time streams. Such classification operations are essential for successful deploy- ment of RTP header compression, differentiated services, and traffic isolation. We define the format of the RTP protocol header, and dis- cuss issues of backwards compatibility. "Delivering Media Generically over RTP", M. Speer, D. Singer, Alagu Periyannan, 03/13/1998, This document specifies a method for delivering generic media streams over the Realtime Transport Protocol (RTP). This proposal is intended for media or codec types that are not already handled by other RTP payload specifications. Three packetization schemes are defined for carrying the media data. The Session Description Protocol (SDP) is used to convey to receivers the packetization scheme used, the media data encoding format and parameters for the media encoding format. "Support for RTP in a stored QuickTime Movie File", D. Singer, Alagu Periyannan, Jay Geagan, Kevin Gong, 03/13/1998, This document proposes structures within a QuickTime movie file which permit easy transmission of the media content over RTP. This specification is intended to assist those who wish to stream stored movies over RTP, those wishing to prepare movies for streaming, and for those who might wish to record into QuickTime while preserving RTP information. The bit-stream(s) of RTP packets are normally compliant with the RTP payload definitions for their content, and full inter-operability can be achieved. Each QuickTime media track within a movie is sent over a separate RTP session and synchronized using standard RTP techniques. This specification builds on the published QuickTime file format specification. "Static Multicast", Jon Crowcroft, Masataka Ohta, 11/02/1998, The current IP Multicast model appears to achieve a level of simplicity by extending the IP unicast addressing model (historically the classful A,B, and C net numbers) from the mask and longest match schemes of CIDR, with a new classful address space, class D. The routing systems have been also built in a deceptively simple way in one of three manners - either broadcast and prune (DVMRP, Dense Mode PIM), destination list based tree computation (MOSPF) or single centered trees (current sparse mode PIM and CBT). The multicast service creates the illusion of a spectrum that one can 'tune in to', as an application writer. Due to this view, many have seen the multicast pilot service, the Mbone, as a worldwide Ethernet, where simple distributed algorithms can be used to allocate 'wavelengths' and advertise them through 'broadcast' on a channel (the session directory), associated with a spectrum. These three pieces of the picture have tempted people to construct a distributed architecture for a number of next level services that cannot work at more than a modest scale, since they ignore the basic spirit of location independence for senders and receivers of IP packets, whether unicast or multicast. The problem is that many of these services are attempting to group activities at source, when it is only at join time that user grouping becomes apparent (if you like, multicast usage is a good example of very late binding). These services include Address Allocation and Session Creation, Advertisement and Discovery. This memo proposes approaches to solve some current multicast problems rather statically with DNS and URL based approach, and avoid the misguided pitfalls of trying to use address allocation to implement traffic aggregation for different sources or aggregation of multicast route policy control through control of such aggregated sources. Note "HTTP Extension Framework", P. Leach, Henrik Nielsen, Scott Lawrence, 11/12/1998, A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. However, HTTP extensions are uncoordinated, and there has been no standard framework for defining extensions or keeping them separate from each other. This document describes a generic extension mechanism for HTTP/1.1, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication. "MARS Proxy", David Allan, 03/13/1998, The Point-to-Point Protocol (PPP) [1] has been proposed as an access vehicle for public ATM networks. Support for multicast in this environment via either RAS replication, or a adding MARS client side by side with PPP is problematic on several fronts. This document describes how an ATM attached system can act as a MARS proxy on behalf of a PPP client. This solution circumvents many of the associated problems with respect to VC frugality, scalability, and authentication. "The Common Intrusion Detection Framework - Data Formats", Brian Tung, Stuart Staniford-Chen, Phil Porras, Cliff Kahn, Dan Schnackenberg, Rich Feiertag, Maureen Stillman, 03/16/1998, This document defines portions of the Common Intrusion Detection Framework (CIDF), specifically the data formats used. CIDF is designed to allow intrusion detection systems (IDS) to interoperate with one another. Two layered formats are defined here: Gidos, which are a high-level data structure intended to allow IDS systems to exchange messages describing the state of the world, events occurring, and recommended actions with somewhat standardized semantics. Gidos can be encoded in CIDF messages, the format for which is also defined here. " RealMedia File Format", Rahul Agarwal, Jeff Ayars, Brad Hefta-Gaub, Dale Stammen, 03/16/1998, The RealMedia File Format (RMFF) is designed to be a generic container for streaming media data. This data may then be played back locally or streamed over a network using protocols such as RTSP and RTP. The format is data-independent, allowing any data type to be recorded, manipulated and played back. Note: This document is intended to be informational in nature of what the file format in use by RealNetworks' RealServer and RealPlayer implementations. Though we think that there are a lot of important concepts embodied in this specification, and that it may even make the basis of a ''standard'' file format, this is intended to eventually end up as an Informational RFC. "Integrated Services Over Differentiated Services", Peter Ford, Y. Bernet, 03/16/1998, This document describes a mapping of IETF Integrated Services[3] over Diff-Serv Networks built from network elements having diff-serv defined Per Hop Behaviours (PHBs)[11]. In many ways, this document should look like an ISSLL document assuming that a differentiated service network looks like an instance of _media_ within a integrated services network. It describes parameter mappings for supporting Controlled Load [6] and Guaranteed Service [7] using the capabilities of diff-serv networks in routers and switches. These mappings fit within an overall Framework for Integrated and Differentiated Services[to be submitted]. "''HTTP Envy'' and Presence Information Protocols", Mark Day, 03/16/1998, There are a variety of proposals [Calsyn, Mohr] for building a presence information protocol as a variant or version of HTTP. This document summarizes why I believe that is not a good idea. "WIRE - W3 Identifier Resolution Extensions", B. Chen, H. Nielsen, L. Girod, John Mallery, 03/16/1998, WIRE extends HTTP with a new type of redirect response that permits a resolver to explicitly delegate a resolution to other resolvers and protocols. WIRE is an effort to make delegation more explicit, redirection more flexible, and resolution processes more efficient through the use of hints. This document defines WIRE and describes the expected behaviors of resolvers and clients using WIRE. WIRE is an extension of the HyperText Transfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0 and above [4][5]. WIRE encourages use of long-lived URIs and at the same time supports protocol evolution without having to change currently deployed URIs or URI schemes. The extension is based on a simple URI resolution model that allows an application to dynamically request metadata describing where and how to access a resource. The model can use any generic metadata description language (e.g. RDF) and as the metadata itself is interpreted as a first class resource, metadata resources are no different than any other resource on the Web. "URN Resolution Using WIRE", B. Chen, L. Girod, John Mallery, 03/16/1998, The identifier resolution extensions proposed in WIRE [11] add new mechanisms for redirection and resolver delegation to HTTP. While these mechanisms are generalized to support resolution of all URIs, they were designed in part to meet the specific needs of URN resolution systems. This document describes how the WIRE model maintains consistency with existing models of URN resolution, how WIRE can be used as a URN resolution protocol, and how WIRE fits into the existing URN resolution infrastructure, including NAPTR [8] and THTTP [9]. "The application/whoispp-response Content-type", Leslie Daigle, 03/16/1998, This document defines the expression of Whois++ protocol (originally defined in [RFC1835], updated in [draft-asid-whoispp-02.txt]) responses within MIME [RFC2046] media types. The intention of this document, in conjunction with [draft-daigle-wppresp-00.txt] is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. "The application/whoispp-query Content-Type", Patrik Faltstrom, Leslie Daigle, 03/16/1998, This document defines the expression of Whois++ protocol (originally defined in [RFC1835] and updated in [draft-ietf-asid-whoispp-02.txt])queries within MIME [RFC2046] media types. The intention of this document, in conjunction with [draft-daigle-wppquery-00.txt] is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. "Requirements for Presence and Instant Messaging", Mark Day, 03/16/1998, This document is an alternative approach to defining the requirements for a presence information protocol. It may be usefully compared and contrasted with ''Presence Information Protocol Requirements'' by Lisa Dusseault, draft-dusseault-pipr-00.txt. Although worthy in many respects, that document includes numerous desiderata, design considerations, and implementation concerns. This document attempts to define only requirements, and a minimal set of requirements at that. In addition, this document treats ''presence'' and ''instant messaging'' as distinct entities for the purpose of defining requirements. We leave open the possibility of a single protocol fulfilling both sets of requirements, without requiring it. "Addressing and Location for RVP", Lisa Dusseault, 03/16/1998, A core part of a presence and instant messaging protocol, such as RVP [7], must be the ability to find users online. This draft defines several aspects of finding a user online: - Schema of RVP URL - How to find a user\022s RVP address (URL) - How to find a RVP server The problem may be generalized to finding a non-user object online. In this draft, the client is the process which is searching for a RVP object. This can be a RVP server acting as a client or on behalf of a user. The server is the process which is responsible for answering queries and receiving messages for a RVP object. A RVP client may sometimes act as its own server. "VPN Point to Multipoint Tunnel Protocol (VPMT)", Dwight Jamieson, Scott Pegrum, Matthew Yuen, Alicja Celer, 08/10/1998, For many carrier's, the implementation of Virtual Private Network (VPN) services using current IP Tunneling technology is problematic because of onerous configuration requirements. The VPMT is an protocol for the dynammic distribution of VPN information throughout a shared network, which in turn allows the automatic formation of point to multi-point tunnels between VPN routers. The method described in this internet draft is intended for single AS where the AS administrator is a trusted third party. Traffic seperation is maintained between VPNs. "RVP Schemas", Lisa Dusseault, Jeff Bone, 03/16/1998, The RVP protocol [2] can be used to query properties of objects, subscribe to certain kinds of events, and send instant messages to objects. These objects are often users, but there are other classes of objects as well. A schema needs to be defined which applies to all kinds of RVP objects, as well as more detailed schemas for the most commonly used objects, users and groups. The required properties for all RVP objects include common name (Cn), schema type and access control list. The required properties for a user object, which represents a single human user of the system, include status, status message, email address and directory server address. The required properties for a group object, which represents a list of objects which may be messaged all at once by messaging this group, include member- count and owner. "Providing Differentiated Services through Cooperative Dropping and Delay Indication", Walter Weiss, 03/16/1998, The current state of the Internet only supports a single class of service. To further the success of the Internet, new capabilities must be deployed which allow for deterministic end to end behavior irrespective of location or the number of domains along the path. Experience with existing signaling based protocols have proven diffi- cult to deploy due to technical and economic factors. This document proposes using in-band frame marking to support a diverse set of ser- vices. In addition, the mechanisms described here will provide end users and/or enterprise backbones with new capabilities such as ser- vice validation, congestion localization, and uniform service irrespective of the type of service contract. For ISPs this document proposes mechanisms providing more available bandwidth by creating strong incentives for adaptive behavior in applications as well as mechanisms for providing both sender based and receiver based service contracts. "RADIUS Extension for Multicast Router Authentication", N. Yamanouchi, O. Takahashi, N. Ishikawa, 03/18/1998, This memo describes an extension of RADIUS authentication protocol (RFC2138) and RADIUS accounting protocol (RFC2139) to provide authentication service about multicast receivers and senders to the ingress and egress routers, and to keep track of the receiving and sending clients for multicast data feed service management. New services and attributes are added to the RADIUS definitions while the authentication transaction mechanisms are preserved. The authentication server authenticates the multicast receiver/sender by using the CHAP-based mechanism. The account server logs the start and stop points of multicast route usage. This extension is intended to be used in conjunction with the IGMP extension for multicast receiver and sender authentication. "ARP and IP Broadcast over HIPPI-800", Jean-Michel Pittet, 11/23/1998, This document specifies a method for resolving IP addresses to ANSI High Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (a.k.a. Gigabyte Systems Network, GSN). "Framework for Traffic Management in MPLS Networks", Ravadurgam Ravikanth, Pasi Vaananen, 03/19/1998, It has been recognised that the success of the MPLS depends on the ability to better support the multiservice traffic integration with some levels of service guarantees, which are not feasible to implement with the current destination prefix only based packet forwarding paradigms. The efficient support for these services throughout the network is expected to be possible using label based forwarding paradigm in the network. However, the service categories and the enabling mechanisms to support those service categories are not well addressed in the current proposals for the MPLS working group; the effort has mostly concentrated on the handling of the best effort traffic and associated scalability and routing related issues. The goal of this document is to define a framework for traffic management in MPLS networks. We discuss the set of mechanisms that have been proposed for enabling the implementation of the more advanced services than pure best-effort packet forwarding, and the impact of those mechanisms with respect to MPLS network environments and MPLS protocol implementation. The document describes the mechanisms and their application with the intent to approach the level of the traffic management capabilities that are currently available in hybrid router/ATM or frame relay networks using the MPLS. The approach taken is that no modifications are required in the end station protocol or application software in the first phase of deployment, while this might be allowed later, if deemed necessary. This document concentrates on the issues from the public network operators point of view, although most of the discussion applies as well in the local network environments. Concepts and mechanisms described in this document are based on the previous work done in the subject on various working groups of IETF and other standardisation bodies. It has been attempted to use applicable concepts and terminology from previous work as "Codes for language transformation", M. Benitez, 04/06/1998, This is a draft proposal to extend the RFC1766 to cover language transformations (transliteration/transcription/trans-anything) from one language (the source language) to another (the target language). "Bay Networks SS7-Internet Gateway Architecture", Lyndon Ong, Robert Dalias, Jiri Matousek, 06/03/1998, This memo describes the Bay Networks Gateway architecture for interworking of PSTN SS7 with Internet. Signaling System 7 (SS7) networking is the primary means used in the PSTN for control of circuit-switched connections and value added PSTN services such as freephone (800/888) number translation, calling card validation and Intelligent Network services. The Gateway architecture provides a scalable method of supporting interworking between SS7 network elements and Internet elements such as a Remote Access Server (RAS). The Gateway architecture can support connection control and database access. Gateway design, functions and protocol are described. "Nothing Other Than A Simple Internet Phone (NOTASIP)", Masataka Ohta, K. Fujikawa, 08/10/1998, This memo describes a simple protocol for Internet phone without QoS guarantee. "Efficient Referral Chasing in LDAP Directories", David Watts, Steve Orbell, 04/07/1998, This document defines an extension to the LDAP URL format and a control on a LDAP search operation which, together, permit LDAP clients to chase LDAP referrals in a more efficient and more X.500-like manner. "The audio/mpeg Media Type", Martin Nilsson, 11/25/1998, The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform MIME type for these files. The intention of this draft is to standardize the use of audio/mpeg as its media type. "RTP Payload Format for PureVoice(tm) Audio", E. Rosen, Kyle McKay, 08/06/1998, This document describes the RTP payload format for PureVoice(tm) Audio. The packet format supports variable interleaving to reduce the effect of packet loss on audio quality. "THE RMTP-II PROTOCOL", Todd Montgomery, Brian Whetten, Murali Basavaiah, Sanjoy Paul, Naveen Rastogi, Jim Conlan, Thomas Yeh, 04/10/1998, The Reliable Multicast Transport Protocol II, RMTP-II, is a reliable multicast protocol, designed to reliably and efficiently send data from a few senders to large groups of simultaneous recipients. It is designed primarily for use over controlled network topologies. It works over both symmetric networks, as well as over asymmetrical network topologies such as those provided by satellite, cable modem or Asymmetrical Digital Subscriber Line (ADSL) carriers. Before sending, each sender must connect with a trusted Top Node, to receive permission and control parameters for its data stream. The top node provides network managers with a single point of control for the senders, allowing them to monitor and control the traffic being sent. "THE RMTP-II PROTOCOL APPENDICES", Todd Montgomery, Brian Whetten, Murali Basavaiah, Sanjoy Paul, Naveen Rastogi, Jim Conlan, Thomas Yeh, 04/10/1998, These appendices furnish supplementary information for the RMTP-II protocol draft. The appendices contain information on design rationale, congestion control algorithms, SNMP MIBs, forward error correction, time bounded reliability, and work in progress "A Legal Basis for Domain Name Allocation", Owain Vaughan, 04/14/1998, The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. "Routing of Site-Scoped Addresses in the Internet Protocol Version 6 (IPv6)", Brian Haberman, 04/14/1998, This document outlines a mechanism for generating routing tables that include site-scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward site-scoped addresses regardless of the routing protocol. "LDAP Replication Requirements", E. Stokes, R. Weiser, 04/17/1998, This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", M. Eisler, 11/03/1998, This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations. "Building Directories from DNS: Experiences from WWWSeeker", Rick Huber, R. Moats, 11/09/1998, There has been much discussion and several documents written about the need for an Internet Directory. Recently, this discussion has focussed on ways to discover an organization's domain name without relying on use of DNS as a directory service. This draft discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. The back end database that drives this application was built from information obtained from domain registries via WHOIS and other protocols. We present this information to help future implementors avoid some of the blind alleys that we have already explored. This work builds on the Netfind system that was created by Mike Schwartz and his team at the University of Colorado at Boulder [1]. "Duplicate Suppression in HTTP", J Mogul, Arthur van Hoff, 04/16/1998, A significant fraction of Web content is often exactly duplicated under several different URIs. This duplication can lead to suboptimal use of network bandwidth, and unnecessary latency for users. Much of this duplication can be avoided through the use of a simple mechanism, described here, which allows a cache to efficiently substitute one byte-for-byte identical value for another. By doing so, the cache avoids some or all of the network costs associated with retrieving the duplicate value. "Requirements for Event Notification Protocol", Surendra Reddy, 04/16/1998, This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. "The application/smil Media Type", Philipp Hoschka, 09/02/1998, This document specifies the Media Type of the Synchronized Multimedia Integration Language (SMIL 1.0, pronounced 'smile'). SMIL allows integrating a set of independent multimedia objects into a synchronized multimedia presentation. "Possible Mechanisms and Components for AATN", Alan O''''''''Neill, Martin Tatham, George Tsirtsis, Richard O''Brien, 04/20/1998, This document attempts to list mechanisms that if added to the Internet protocols could take us some way in providing well desirable alternatives and improvements to NAT. Some of the techniques and components described here are controversial and their appearance in this document does not mean that the author supports them. We merely attempt to list the options and issues (most of them already known) as a starting point for an elimination and selection process. "PIM-SM over ATM and Proxy PAR", Cheng-Yin Lee, 04/20/1998, This document describes how PIM-SM [PIM-SM, PIM] operates in ATM networks in the presence of Proxy PAR. [PPAR, OSPF_PPAR]. The mechanisms described allow for simpler, more efficient and cost-effective network designs. "Use of Aliases within LDAP", E. Stokes, Debbie Byrne, Ludovic Poitou, 04/22/1998, This document describes the suggested behavior for aliases for LDAPv3 and above to improve LDAP server interoperability . The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to be interpreted as described in [Bradner97]. "The Mandatory-to-Implement Authentication Problem", Chris Newman, 04/23/1998, This memo defines the ``mandatory-to-implement authentication mechanism'' problem (at the per-TCP-connection level), describes the requirements necessary for a solution, and identifies the mechanisms which meet a significant subset of the requirements. It is hoped this will help the IETF come to an understanding of the problem and a rough consensus on a solution. "SDP URL Scheme", Kenji Fujikawa, 08/07/1998, This document describes a format for an Session Description Protocol Uniform Resource Locator (SDP URL) which will allow Internet clients to have direct access to multimedia sessions. "Distributed Network Address Translation", Brian Petry, Michael Borella, David Grabelsky, Ikhlaq Sidhu, 10/20/1998, NAT (Network Address Translation) has been proposed to extend the lifetime of IPv4 by allowing one or more subnets to exist behind a single IP address. It is desirable to support dozens, if not hundreds, of nodes on a NAT subnet. As it is currently defined, NAT may not gracefully scale beyond networks containing a few dozen nodes. In particular, the computational burden placed on the NAT router may be significant, especially if the router is shared by several NAT-enabled subnets. Additionally, NAT requires that support for many protocols be specifically programmed into the translation mechanism. In this document, we introduce DNAT (Distributed Network Address Translation), an alternative to NAT. In particular, DNAT will eliminate all address and port translation at the router, providing an application independent mechanism for sharing an IP address amongst many hosts while providing end-to-end connectivity. "EDIFACT-S [EDIFACT Security (Batch)]", Juan-Carlos Cruellas-Ibarez, Terry Dosdale, 04/24/1998, The aim of this document is to raise awareness about the built in security features of batch EDIFACT, for use when transmitted over any type of network. It is not intended to reproduce the syntax, which is documented elsewhere, nor is it intended to be a full tutorial on EDIFACT, data security, or EDIFACT security. "Web based Simple Calendar Access Protocol - SCAP", Surendra Reddy, 04/27/1998, Distributed calendaring is gradually becoming more demanding than standalone calendaring and scheduling. The use of calendaring and scheduling has grown exponentially and enterprise and inter- enterprise business has become so dependent on group scheudling applications. But there is no Internet standard to provide interoperability among various calendaring applications. Consequently, user need to install different conduit programs to access these calendaring stores. This memo proposes a HTTP based simple calendaring access protocol which allows web, email and any HTTP compliant clients to access and manipulate calendar store. The motivation for this proposal is the expanded scope and diversity of the World Wide Web. The World Wide Web provides a simple and effective means for users to search, browse, retrieve, and publish information of their own available for others. Now that Web browsers and servers are ubiquitous on the Internet, it is worthwhile to use HTTP as transport protocol and XML to encode calendar objects. The power and extensibility of XML allows us to represent calendar data objects as well-formed XML documents. Simple Calendar Access Protocol(SCAP) allows exchanging calendaring information between scheduling systems using the Hypertext Transfer Protocol (HTTP). This allows users to schedule meetings with anyone else, no matter what scheduling software they use. This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of calender properties, creation and management of calendar objects, and namespace manipulation. "General Event Notification Architecture Base", Josh Cohen, Sonu Aggarwal, 07/10/1998, This specification defines an HTTP notification architecture that transmits notifications between HTTP resources. An HTTP resource could be any object which might need to send or receive a notification, for example a distribution list, buddy list, print job, etc. "The Coherent File Transport Protocol", Jere Beauchamp, 04/29/1998, As in RFC-1235, our implementation uses UDP [2] as the transport protocol but this is not a requirement of the protocol. Any broadcast datagram protocol could be employed. The satellite broadcast implementation assumes that there is only a single, unidirectional link (the satellite channel) between the source and recipient and that acknowledgment information from the recipient to the source is carried on a separate and independent media. "Role Names in X.509 Certificates", B. Ramsdell, 04/30/1998, The subjectAltName X.509 extension described in [KEYM] provides a mechanism where information regarding the entity that signed and/or encrypted some data can be identified. However, there is a case where the subject may not be a concrete entity, but may be a 'role' within an organization or network. This document will specify a set of these roles and their definitions. "Negotiated Address Reuse (NAR)", G. Montenegro, 05/05/1998, Network address (and port) translation is a useful technology. However, several shortcomings have been identified (Mobile IP, IPSEC and QOS flows). In these cases, NAT may be complemented by the use of NAR (Negotiated Address Reuse). The negotiation phase in NAR is based on SOCKS. "Designing QoSMIC: A Quality of Service sensitive Multicast Internet protoCol", Anindo Banerjea, Michalis Faloutsos, Rajesh Pankaj, 05/05/1998, We present, QoSMIC, a multicast protocol for the Internet that supports QoS-sensitive routing, and minimizes the importance of a priori configuration decisions (such as core selection). The protocol is resource-efficient, robust, flexible, and scalable. In addition, our protocol is provably loop-free. Our protocol starts with a resources-saving tree (Shared Tree) and individual receivers switch to a QoS-competitive tree (Source-Based Tree) when necessary. In both trees, the new destination is able to choose the most promising among several paths. An innovation is that we use dynamic routing information without relying on a link state exchange protocol to provide it. Our protocol limits the effect of pre- configuration decisions drastically, by separating the management from the data transfer functions; administrative routers are not necessarily part of the tree. This separation increases the robustness, and flexibility of the protocol. Furthermore, QoSMIC is able to adapt dynamically to the conditions of the network. The QoSMIC protocol introduces several new ideas that make it more flexible than other protocols proposed to date. In fact, many of the other protocols, (such as YAM, PIM-SM, BGMP, CBT) can be seen as special cases of QoSMIC. The goal of this document is to present the motivation behind, and the design of QoSMIC, and to provide both analytical and experimental results to support our claims. NOTE: The text version of the draft is missing several figures, that facilitate the understanding of the work. For this, the authors suggest the postscript version. "Requirements for Simple Workflow Access Protocol", Surendra Reddy, Matthew Pryor, 11/23/1998, Workflow is intuitive and powerful paradigm for capturing business processes, reasoning about them, and process specifications to produce corresponding implementations that are supported by the information systems. There has been a growing acceptance of workflow technology in numerous application domains such as telecommunications, software engineering, manufacturing, production, finance and banking, laboratory sciences, healthcare, shipping and office automation. In the last few years, pervasive network connectivity, exploded growth of Internet and web technologies has changed our computational landscape to distributed, heterogeneous and network centric computing model from centralized, desktop-oriented, and homogenous computing. This has raised challenging requirements for workflow technologies in terms being required to support heterogeneous, distributed computing infrastructures, interoperability, scalability and availability. The main objective of this document is to identify various business requirements for Internet based Workflow Access Protocol to instantiate, control and monitor the workflow process instances. Definition and administration of process specifications are not discussed in this requirements. "Photuris: Secret Exchange", W. Simpson, 05/06/1998, Photuris is a session-key management protocol. Extensible Messages are provided to enable future implementation changes without affect- ing the basic protocol. The Secret Exchange messages provide the capability to create ephemeral symmetric secrets between parties. "TFTP Multicast Option", Weng-Chin (Winson) Yung, 05/06/1998, The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a new TFTP option. This new option will allow the multiple client to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2]. Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency. This document assumes that the reader is familiar with the terminology and notation of both [1] and [2]. "Schema for Representing Java(tm) Objects in an LDAP Directory", Vincent Ryan, Scott Seligman, Rosanna Lee, 10/22/1998, This document defines the schema used to represent Java(tm) objects in an LDAP directory [LDAPv3]. It defines schema elements to enable Java objects to be represented in either of two ways: as serialized byte streams [Serial] and as JNDI references [JNDI]. "DIAMETER Framework Document", Glen Zorn, Ping Pan, Pat Calhoun, 07/31/1998, As the number of new internet services has increased in the past cou- ple of years, routers and network access servers (NAS) have had to undergo re-engineering to support them. These new services could often benefit from an Authentication, Authorization and Accounting (AAA) protocol to facilitate off-loading policy information to an external server. The DIAMETER protocol defines a policy protocol used by clients to perform Policy, AAA and Resource Control. This allows a single server to handle policies for many services. "Simple Gateway Control Protocol (SGCP)", Christian Huitema, Mauricio Arango, 09/25/1998, This document describes an application programming interface (SGCI) and a corresponding protocol (SGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. The SGCP assumes a call control architecture where the call control 'intelligence' is outside the gateways and handled by external call control elements. The document is structured in 5 main sections: * The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP. * The interface section presents a conceptual overview of the SGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the five procedurs that compose SGCP: Notifications Request, Notification, Create Connection, Modify Con- nection and Delete Connection. * The protocol description section presents the SGCP encodings, which are based on simple text formats, and the transmission procedure over UDP. * The security section presents the security requirement of SGCP, and its usage of IP security services (IPSEC). * An example section presents two detailed examples of call set up procedures using SGCP. * The description of the changes between version 1.0 and version 1.1 "Armenian Character Sets: Implementation Guide", Hovik Melikyan, 05/18/1998, The document presents the set of Armenian characters that is used in the information systems in accordance to AST 34.001 and AST 34.002 standards of the State Standards Commission of the Republic of Armenia, as well as provides classification and sorting thereof and recommendations for implementation of basic algorithms of text processing. "TN3270E Service Location and Session Balancing Templates", Jim Naugle, Kathuri Kasthurirangan, 05/20/1998, These Service Location Protocol templates are to be used to provide service attributes associated with TN3270E servers to client software, or to end users. For more information refer to TN3270E Service Location and Session Balancing Internet-Draft, [1] work in progress. "ACC's Vendor Specific Attributes", Koral Ilgun, 05/22/1998, This document describes vendor specific attributes for carrying authentication, authorization and accounting information between ACC's Network Access Server (NAS) and an Authentication/Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2058 and RFC 2059. "NNTP Authentication", Chris Newman, 11/18/1998, Although NNTP [NNTP] has traditionally provided public access to newsgroups, it is often useful to use authentication to control resource consumption as well as to create restricted-access newsgroups. The NNTP AUTHINFO command described here provides a way to do this. "PPP LCP extensions for Initial Program load, Discard received, Link Bandwidth and Link Delay measurement", Gerard Passera, 06/29/1998, This document presents five extensions to the PPP/LCP Protocol : * Assistance from a router to another router (or a host) looking for its Operating System file. * Assistance from a router to another router (or a host) looking for its configuration file. * Request from an equipment to receive Discard frame when no Data frame can be sent. When no Discard or Data frames are received the link will be brought down. This method is more efficient than using a timeout and/or a keepalive mecanism. * Interface Bandwidth and Delay measurements. These informations can be used by OSPF or any other IGP protocol. "HTTP Proxy State Management Mechanism", D. Kristol, 05/27/1998, This document specifies a way to create a stateful session, using HTTP requests and responses, between an HTTP proxy server and its client. It describes two new headers, Pcookie and Set-Pcookie, which carry state information between participating HTTP proxy servers and their clients. "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", Ravinder Chandhok, Geoffrey Wenger, 10/21/1998, Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers [RFC2369] it has become even more important to provide an identifier to use to identify a mailing list regardless of the particular host that serves as the list processor at any given time. The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use. By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available. The key words ''MUST'', ''MUST NOT'', ''REQUIRED'', ''SHALL'', ''SHALL NOT'', ''SHOULD'', ''SHOULD NOT'', ''RECOMMENDED'', ''MAY'', and ''OPTIONAL'' in this document are to be interpreted as described in RFC 2119. "The WWW Common Gateway Interface Version 1.1", David Robinson, Ken Coar, 05/28/1998, The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the World-Wide Web since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications [NCSA-CGI]. This document also defines the use of the CGI/1.1 interface on the Unix and AmigaDOS(tm) systems. Discussion of this draft occurs on the CGI-WG mailing list; see the project Web page at for details on the mailing list and the status of the project. "The Zone Referral Key", E Lewis, J Scharff, J Gilmore, 05/28/1998, A new type of key is defined to address the problems of performance in large delegeted zones and issues of liability of registrars with regards to the storing of public keys belonging to zone cuts. This new key type also brings DNSSEC more in line with the DNS treatment of zone cuts and speeds recovery in handling key exposure. The new type of key is a referral record that is stored, signed, at the parent zone's place for the delegation point. A resolver receiving this record is being informed that there are genuine public keys at the child's authoritative name servers. The parent no longer needs to store the child's public keys locally. "DIAMETER QOS Extension", M. Speer, Ken Peirce, Pat Calhoun, 05/28/1998, This document describes a simple client/server model for supporting QOS policies. A router that supports RSVP or one of the proposed differentiated service schemes will require a policy database and a means to access it. This document describes the extensions to a protocol based originally on RADIUS [1] called DIAMETER[2]. This document does not describe the policy database or policy enforcement. "Drop Preference Services", Wu-chang Feng, 06/02/1998, Drop preference has been proposed as a possible means for providing differentiated services in the Internet. Used as a parameter in a PHB group, drop preference can provide weighted bandwidth sharing amongst flows and flow aggregates of a PHB group. This memo documents a number of services which can be implemented using either a single drop preference PHB setting or multiple drop preference settings. "Lightweight Directory Access Protocol (v3): Schema for Dynamic Host Configuration Protocol (DHCP)", Tom Miller, Alpesh Patel, Patnala Rao, 06/02/1998, This document defines a schema for Dynamic Host Configuration Protocol (DHCP). This schema makes it possible to integrate DHCP servers with an LDAP-based directory service, allowing an organization to maintain a single store of IP addresses and other configuration data provided to clients using the DHCP protocol. Integration of DHCP into LDAP directories is desirable since it reduces administrative overhead and eliminates the need to maintain multiple server centric configuration databases. It is anticipated that this schema will be useful for providing a standardized format for the representation of attributes needed by DHCP implementations within LDAP-based directory services. "Class-Based Service Differentiation", Constantinos Dvorolis, 06/02/1998, This document describes the Class-Based Service Differentiation (CBSD) architecture and it proposes a set of Per-Hop-Behaviors that can be used for implementing it. According to CBSD, the network traffic is mapped to a set of classes. The differentiating factor between traffic classes is the relative forwarding quality in a DS capable router. The Class PHBs have quite similar semantics with the Precedence PHBs, recently proposed by Baker et.al. in [PREC], but an attempt is made here to define them in a more general manner, decoupling them from specific implementation possibilities. There is also a semantical overlap between the Expedited Forwarding PHB of [DSFIELD] and the highest Class PHB. Consequently, the Diffserv working group may want to combine these three PHB proposals in a single one, minimizing the number of DS Field bits used. "A proposal for Backward ECN for the Internet Protocol (IPv4/IPv6)", Biswajit Nandy, Nabil Seddigh, Jamal Hadi Salim, 06/04/1998, This memo proposes an alternative approach to the current ECN mechanism as proposed in the internet draft [draft-kksjf]. A Backward-ECN(BECN) is proposed which uses the existing IP signalling mechanism, the Internet Control Messaging Protocol (ICMP) [RFC 792] Source Quench message. The use of ICMP Source Quench (ISQ) allows a basic ECN mechanism for IP which does not require any negotiation between end systems. Congestion notification is kept at the network(IP) level. The congestion state can be reflected up to the transport layer (e.g. TCP or UDP) for appropriate action. The ISQ based approach reduces the reaction time to a congestion in the network. In addition, the ISQ message can include information on the severity of the congestion allowing the end host to react accordingly so as to make maximal use of the resources while maintaining network equilibrium. "Data Certification Server Protocols", C. Adams, Robert Zuccherato, 06/05/1998, This document describes a general data certification service and the protocols to be used when communicating with it. The Data Certification Server is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Data Certification Server responsibilities in a PKI are to validate signatures and to provide up-to-date information regarding the status of public key certificates. We give examples of how to use the Data Certification Server to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Certification Server regarding the status of a public key certificate. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [RFC2119]. "Guaranteed Rate in Differentiated Services", Avri Doria, Tom Worster, Robert Wentworth, 06/08/1998, We propose a diff-serv per hop behavior (PHB) for the transport of non-real time traffic with a guaranteed rate (GR). This proposal is based on principles developed for the specification of the Guaranteed Frame Rate (GFR) service category currently being specified for ATM [TM5]. It is shown that a diff-serv network using the GR PHB together with a explicit routing capability can support edge-to-edge guaranteed rate service. Interconnection of diff-serv networks deploying GR to achieve end-to-end service and interworking with ATM's GFR service are also discussed. "The Extended LDAP Data Interchange Format (LDIFext) Technical Specification", Erik Andersen, 06/08/1998, This document describes a file format known as Extended LDAP Data Interchange Format (LDIFext) that builds on the LDAP Data Interchange Format (LDIF). LDIFext is backward compatible with LDIF. Based on the LDIFext specification it is possible to build either a basic LDIF file or an LDIFext file. LDIFext is in particular applicable in situation where several participating systems are masters of pieces of information about the same object and where the participating systems do not necessarily use the same name space. LDIFext also allows for more efficient bulk transfer. "Bay Networks SS7-Internet Access Signaling Protocol", Lyndon Ong, Jiri Matousek, 06/08/1998, This memo describes the Bay Networks SS7 Access Signaling Protocol (ASP). This protocol is used between an SS7-Internet Gateway and a Remote Access Server/Network Access Server (NAS). The protocol supports call setup and termination by both Gateway and Access Server, and includes circuit management functions such as circuit blocking and procedures for registration of the Access Server. "A taxonomy of multicast security issues (temporary version)", B. Pinkas, R. Canetti, 06/08/1998, With the growth and commercialization of the Internet, the need for secure IP multicast is growing. In this draft we present a taxonomy of multicast security issues. We first sketch some multicast group parameters that are relevant to security, and outline the basic security issues concerning multicast in general, with emphasis on IP multicast. Next we suggest two `benchmark' scenarios for secure multicast solutions. Lastly we review some previous works. This is a temporary version of the document. The authors will be grateful for remarks, and will update and revise this document accordingly. "A Web Versioning Protocol", Jim Whitehead, 06/10/1998, This document describes a set of methods, headers, and properties which extend the HTTP and WebDAV protocols to support versioning and variant authoring of Web resources. Operations are provided to support differencing two resources, applying a difference to a resource, checkin and checkout, along with creation, manipulation, and listing a version and variant history graph. "POP3 XTND Extensions", Tony Hansen, 06/12/1998, This Internet Draft describes some extensions to the Post Office Protocol [POP3] and are described here for historical purposes. The status of this Internet Draft will be Historic. [XTND] describes a mechanism to extend the POP3 protocol, called XTND. Two extensions which have been implemented on some server implementations are XTND XMIT and XTND XLST; this memo describes these extensions. New implementations of POP3 clients and servers are not expected to implement these extensions; other mechanisms should be used instead. For example, [SMTP] should be used instead of XTND XMIT for sending email. If authentication is needed for sending email, then the proposed [ESMTP] [AUTH] extension should be used. "Event Notification Protocol - ENP", Surendra Reddy, Mark Leighton Fisher, 06/15/1998, As the complexity of distributed applications increases, an increasing amount of processing is done using distributed processes, which typically execute without the direct supervision of an end user. The user must poll these processes periodically to check if they are completed successfully or not. This polling results in unnecessary wastage of network bandwidth as well as computing resources. The user generally cannot see intermediate results or progress reports for long running processes, they must wait till the process is completely finished before viewing the results. Thus the problem of monitoring events is central in distributed applications and protocols. A repeated need in such applications is receive notifications when a resource property value changes or event state changes. Current database systems provides mechanisms like constraints, triggers and active database rules. These facilities provides an automated means to ensure the database integrity or perform specific action when data changes. Need for such kind of requirement is fundamental is network applications. Event Notification Protocol(ENP) abstracts the notification requirements from the applications. ENP provides a lean and mean protocol with a client side semantics for processing notifications. The goal of ENP is to provide a service which allows users to select resources or events for which they wish to be notified in case changes of property values or state values occur. The Event Notification Protocol will also allow users to define what events or state changes they are interested in. This document describes the Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise enviro "Simple RTP Multiplexing Transfer Methods for VoIP", Tohru Hoshi, Koji Tsukada, Keiko Tanigawa, 11/16/1998, This document proposes a simple voice stream multiplexing method which is designed to reduce the IP-UDP header overhead of RTP (real-time transport protocol) streams and to decrease the number of packets in the end-to-end transport functions. The proposed multiplexing method is to concatenate RTP packets destined for the same Internet Telephony Gateway (IP-GW) into a single UDP packet. The benefits of this method are that no new additional headers are required and the current well-defined H.323 and RTP standards can be used. Furthermore, this method is a general RTP packet multiplexing method that is applicable not only to an IP-GW but also to other multiplexing applications, as well as trunking VoIP streams application with insertion and deletion of RTP streams on the way. "HNEWS: An HTTP-Tunneling News Protocol", Ted Stockwell, 06/17/1998, This document defines HNEWS (HTTP News Protocol), an HTTP-tunneling news protocol. The NNTP(Network News Transfer Protocol) protocol described in RFC 977 is recast as HTTP CGI (Common Gateway Interface) requests that may be filled by any server that supports CGI. Two new commands are defined for connecting and disconnecting from an HNEWS server. Also, a mechanism for session state management is described. This document assumes that you have a working knowledge of the Common Gateway Interface [2] for running executable content on a web server and some familiarity with the NNTP news protocol [1]. A new URL scheme has also been specified for HNEWS and is described in a separate document [5]. "The hnews URL scheme", Ted Stockwell, 06/17/1998, HNEWS [1] is an HTTP-tunneling variant of the NNTP news protocol. This document defines the format of Uniform Resource Locators(URLs) identifying news messages and groups provided by HNEWS servers. The syntax of 'hnews' URLs is designed to be compatible with the current common usage of the 'news' URL scheme. Specifically, the 'hnews' URL scheme is designed according to recommendations made in [NEWS_URL_SCHEME]. [NEWS_URL_SCHEME] is based on the general specification of all URL schemes in 'Uniform Resource Locators (URL): Generic Syntax and Semantics' [RFC URI SYNTAX]. "The Reliable Signaling Gateway Control Protocol (RSGCP)", Matt Holdrege, 06/17/1998, This memo describes the Control Protocol used between a Network Access Server (NAS) and a Signaling Gateway (SG). The requirements of this protocol are Call Control, Circuit Maintenance and Resource Management. This protocol must be reliable in nature and support redundant links between the NAS and SG. It's important to note that the NAS could be handling either packetized voice or data for access to the Internet. "Secure, Remote Access over the Internet using IPSec", V. Gupta, 11/19/1998, This memo describes the use of IPSec [KeAt98a-c] for secure access to protected networks by authorized users connected to the Internet. An example target scenario is a corporate employee on the road accessing resources on his company's Intranet. It addresses firewall traversal, user authentication, data confidentiality and the use of private address spaces (the latter impacts routing and name lookups). A comparison to other mechanisms such as those based on Layer-2 tunneling or session layer security, is also included. This memo draws upon several ideas from [Dora97,Mosk98] and would not have been possible without the contributions of the IETF working groups on IP Security (IPSec) and Network Address Translation (NAT). "A Hybrid Authentication Mode for IKE", Moshe Litvin, Roy Shamir, 06/26/1998, This document describes a new authentication mode for the Internet Key Exchange (IKE). This mode extends the authentication modes defined in [IKE]. The proposed mode assumes an asymmetry between the authenticating entities. One entity, typically an edge device (e.g. firewall), authenticates using public key techniques, while the other entity, typically a remote user, authenticates using challenge response techniques. The mode is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. "NHRP for Destinations off the NBMA Subnetwork",, 06/26/1998, The NBMA Next Hop Resolution Protocol (NHRP) [1] specifies a mechanism that allows a source station (e.g., a host or a router) on an NBMA subnetwork to find the NBMA subnetwork address address of a destination station when the destination station is connected to the NBMA subnetwork. For the case where the destination station is off the NBMA subnetwork the mechanism described in [1] allows to determine the NBMA subnetwork address of an egress router from the NBMA subnetwork that is ``nearest'' to the destination station. If used to locate an egress router wherein the destination station is directly behind the egress router, the currently document NHRP behaviors are sufficient. However, as documented elsewhere [2], there are cases where if used between routers for generalized transit, NHRP can produce loops. This document describes extensions to the NBMA Next Hop Resolution Protocol (NHRP) [1] that allow to acquire and maintain the information about the egress router without constraining the destination(s) to be directly connected to the egress router. "A Protocol For Identifying The Bulk Mail Receipt Preferences of an Electronic Mail Address.", Troy Rollo, 07/31/1998, BMPP is a protocol which allows bulk emailers to discover if a mailbox is willing to accept bulk email. From the bulk emailer's point of view, it allows them to find out for certain if their email will be accepted or rejected by the recipient. From the mailbox owner's point of view, it allows them to provide permission to bulk emailers in jurisdictions where permission is required, and allows them to express their desire not to receive such bulk mailings in jurisdictions where permission is not required. "TELNET SUPPRESS LOCAL ECHO OPTION", Wirt Atmar, Jeff Bandle, 06/26/1998, Telnet is a protocol that may be operated in either a peer-to-peer, fully symmetric mode, or asymmetrically, in a host-terminal mode. Although the original intention for the NVT mode of operation was both asymmetric and half-duplex, where neither the host nor the terminal echoed characters back to one another, the most common mode of usage has come to be one of asymmetric full-duplex communications, where all terminal characters are first transmitted to the host computer and then echoed back to the terminal before being displayed. "Multicast Source Discovery Protocol (MSDP)", D. Farinacci, Peter Lothberg, Y Rekhter, Hank Kilmer, Jeremy Hall, 06/29/1998, This proposal describes a mechanism to connect multiple PIM-SM domains together. Each PIM-SM domain uses it's own independent RP(s) and do not have to depend on RPs in other domains. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment in the Internet and may be upward compatible with the IDMR protocols being proposed for subsequent phases. "Where to terminate a phone call", Patrik Faltstrom, Bjorn Larsson, 11/23/1998, This document discusses the use of DNS [1] for identifying available services that can be used to contact a phone number. It also, for some of these services, discusses how to route the message(s) to a specific destination using the same techniques. Specifically it presents a way of implementing portable phone numbers, where the services used can be the H.323 protocol [2], POTS [4] phone call or something else like SMTP. "Content-Specific Hypertext Transfer Protocol", Randy Garbrick, 06/30/1998, This document describes HTTPX, a protocol for providing access to materials that may be objectionable or that have age or locale-based restrictions, while providing a simple method to filter such content where required. HTTPX uses the protocol HTTP 1.1 ([RFC 2068]), with the single exception of designating a separate range of TCP and UDP port numbers that are allocated to a specific content type. "A flexible allocation scheme for IP addresses (IPv4 and IPv6)", Marc Blanchet, 07/06/1998, This draft presents an IP address allocation scheme that enables the IP allocator (the organisation that allocates addresses) to postpone the final decision of prefix length by keeping space between allocated bits of the different parts of the IP address. This enables the allocator to change the different part lengths of the prefix (TLA, subTLA, SLA, ...) even after allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the address space is larger and more flexible. "iCalendar v2.0 Formal Public Identifier", Paul Hoffman, F. Dawson, 07/06/1998, The IETF has defined a standard format for exchanging calendaring and scheduling data, called iCalendar. This format is useful for exchange of personal calendar data across the Internet, as well as in non-Internet environments. "vCard v3.0 Formal Public Identifier", Paul Hoffman, F. Dawson, 07/06/1998, The IETF has defined a standard format for electronic business card data, called vCard. This format is useful for exchange of personal directory data across the Internet, as well as in non-Internet environments. "PGPticket", Vinnie Moscaritolo, Antonino Mione, 11/16/1998, OpenPGP specifies message formats and certificate formats used for exchange of encrypted and/or authenticated objects. This document discusses methods of extending OpenPGP's message formats to support an authorization system. This system would use public key cryptography to authenticate a user to a server and establish the user's access permissions. The concept is that the user acquires a ticket signed by some issuer that specifies what they are entitled to do. That ticket is then submitted to a server. The server uses a challenge/response method to verify that the holder really has the matching private key. The server then allows the access specified. "Authentication Responses for Protocols (SMTP, IMAP, POP, etc)", Chris Newman, 07/13/1998, This memo assigns client authentication error codes for those situations where a client may take specific corrective action in the face of a failed authentication attempt. Some of these codes are used by one strategy to transition users away from unencrypted clear text passwords. "Definitions of Supplemental Managed Objects for the SONET/SDH Interface Type", Kenneth Chapman, 07/14/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes supplemental objects used for managing SONET and SDH interfaces. This document is a companion document to the definitions of managed objects and supplemental managed objects for the DS1/E1, DS2/E2, DS3/E3 and SONET/SDH interface types: [1], [2], [3], [4] and [5]. This MIB is designed to provide support for ASNI T1.231- 1997 [6] standard information not already supported by . Support for this MIB is optional. "Textual Conventions for MIB Modules Using Performance History Based on 24 Hour Intervals", Kenneth Chapman, 07/14/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes tectual conventions used to define 24 hour inteval counters which supplement the interval counters defined in the 15 Minute Based Performance History TCs MIB [1]. See for example the DS1/E1, DS2/E2, DS3/E3 and SONET/SDH supplemental MIBs [2][3][4]. This MIB is designed to provide support for ASNI T1.231-1997 [6] 1-day registers. "A TINA service architecture experiment in Internet / PSTN interworking", Gilles Lecorgne, Abdul Akram, Anastasius Gavras, 07/15/1998, This internet draft is about the use of TINA architecture in the development of a common control platform for the Internet /PSTN interworking. Our aim is to apply TINA service architecture for both internet and PSTN service platforms in order to allow interactions. "Applications Response Time MIB (ART MIB)", Jim McQuaid, Albin Warth, 07/16/1998, This memo defines a MIB for application response time, based on the RMON2 MIB for use with the SNMP network management architecture. This memo does not specify a standard for the Internet community. "The ID-based Key Management System (IDKMS)", Tsuyoshi Nishioka, Taka Kubo, 07/21/1998, This informational document describes some cryptographic protocols on an ID-based system called Key Predistribution System (KPS). "Transmission of IPv6 Packets over IEEE 1394 Networks", Kenji Fujisawa, 11/05/1998, IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document proposes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also proposes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network. "The vCard v3.0 XML DTD", Paul Hoffman, F. Dawson, 11/20/1998, This memo defines a [XML] Document Type Definition (DTD) that corresponds to the vCard, electronic business card format defined by [VCARD]. This DTD provides equivalent functionality to the standard format defined by [VCARD]. Documents structured in accordance with this DTD may also be know as 'XML vCard' documents. The mailing list for discussion of this memo is 'ietf-vcard- xml@imc.org'. Send an email to ' ietf-vcard-xml-request@imc.org' with the message 'SUBSCRIBE' to add your email address to this mailing list. Send an email to ' ietf-vcard-xml-request@imc.org' with the message 'UNSUBSCRIBE' to remove your email address from this mailing list. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' and 'OPTIONAL' in this document are to be interpreted as described in [RFC 2119]. "SS7-Internet Interworking - Architectural Framework", Christian Huitema, Matt Holdrege, Nancy Greene, Lyndon Ong, Fernando Cuervo, 08/03/1998, This document describes an architectural framework for SS7-Internet interworking, onto which existing protocols and future protocols in this space can be mapped. It also provides an ordering of importance for the standardization of these protocols. "Bi-Directional Session Setup Extension to Diameter", Nancy Greene, Fernando Cuervo, 07/23/1998, The document [1] describes an architectural framework for protocol standardization for telephony interworking with the internet. Interworking deals with both signalling and bearer connections (i.e., media stream), which can either be carried together (e.g., in-band, BRI, PRI) or separately (e.g., SS7). "The ESP Triple DES Transform",, 07/28/1998, This document describes the 'Triple' DES-EDE3-CBC block cipher trans- form interface used with the IP Encapsulating Security Payload (ESP). "End-to-end QoS provisioning mechanism for Differentiated Services", Luigi Fratta, Flaminio Borgonovo, Antonio Capone, Mario Marchese, Chiara Petrioli, 07/29/1998, This document presents an end-to-end mechanism to guarantee bandwidth and delay into the Differentiated Services mechanism to constant rate traffic such as voice and video. The mechanism requires network routers to be able to serve packets according to three classes of priority. The needed call admission control is performed by an end- to-end signaling procedure that implicitly looks for the required bandwidth and seizes it, if available. Short delays are guaranteed by the regular structure of constant rate traffic. No entities other than source and destination are involved and multicast operation comes at no further cost, which makes the mechanism fully scalable and integrable into the existing Internet. "TCP Window Probe Deadlock", Juan Freniche, 07/30/1998, In the course of developing/testing a TCP/IP stack for embedded computers, a situation that can be called 'TCP window probe deadlock' and subsequent connection abort has been observed. "DIAMETER: Policy and Accounting Extension for SIP", H. Schulzrinne, Ping Pan, Pat Calhoun, 11/18/1998, This document describes a policy and accounting information exchange mechanism between a DIAMETER policy server and a SIP proxy server. A DIAMETER server is responsible for maintaining a user policy and accounting database and a means to update it. A SIP proxy server needs to contact a DIAMETER server during multimedia session setup and teardown time to perform admission control and accounting tasks. To provide proper data-forwarding level service guarantees to the SIP sessions, the DIAMETER servers are also responsible for interfacing with the network resource management database. However, this is beyond the scope of this document. The objectives of the proposed DIAMETER extension are 1) providing accurate accounting information, 2) flexible and 3) simple to implement. The protocol does not make any assumption about policy and billing algorithms at DIAMETER servers. "Enabling Byte Stuffing Transparency for RFC-1619", Peter Lothberg, Robert Broberg, M. Takefman, 07/31/1998, Recent Internet Draft submissions and discussion on the PPP Extensions Working Group email list have highlighted transparency issues with the PPP over SONET/SDH mapping described in IETF RFC1619 and RFC1549. The HDLC byte stuffing described by RFC1549 can result in a worst case expansion of the actual payload data by a factor of 2. An algorithm suggested below limits the expansion factor to be a maximum of 6% the actual data to be transported. "Web-based Integrated CA services Protocol, ICAP", Y. Sameshima, H. Kikuchi, M. Sakurai, H. Hattori, Hitoshi Kumagai, 07/31/1998, This document provides a sub set of specifications how to issue, publish X.509 certificates and certificate revocation lists (CRLs). It also provides the certificate validation service by online. In the proposed specifications, the World Wide Web (WWW) is used for secure distributing certificates across a firewall in both human and machine readable syntax. These specifications define not only the protocols between the PKI clients and a single CA, but also the protocols between the CAs. With the CA-CA communications, the PKI clients can retrieve any certificates and CRLs without specifying the location of the appropriate CA, by only asking to the neighbor CA. "ISAKMP Certificate Key Exchange Type Specification", Shigeyoshi Shima, 07/31/1998, This document defines a new key exchange type of ISAKMP that reduce the number of transmission and encrypt message contents from first transmission. The Certificate Key Exchange is effective since it does not use Diffie-Hellman key exchange algorithm but public key cryptography. The Certificate Key Exchange use certificates as authentication information. Please send comments on this document to the ipsec@tis.com. "VPP: Virtual Presence Protocol", Klaus Wolf, 07/31/1998, The purpose of the Virtual Presence Protocol (VPP) protocol is to enable the exchange of document based virtual presence information. Virtual presence information is the foundation for virtual neighborhood services which provide users with information about virtual neighbors, i.e. other users who are close within the virtual document space. VPP enables the creation of dynamic vicinities based on hypertext references. It is not meant to replace or supersede presence notification protocols, but it augments online presence with location information. The protocol described in this document is based on 2 years of experience with location based virtual presence and presence notification. The purpose of presence notification protocols such as the drafted [RVP] is to tell whether another individual is online or arrives online, etc. As opposed to such real online presence, the presence on documents in the World Wide Web is a virtual one. The authors recognize that VPP shares methods, mechanisms, and formats with HTTP, and drafted presence notification protocols (e.g. RVP), however the functionality is significantly different. "IPDC Base Protocol", Allan Rubens, Pat Calhoun, Tom Taylor, 08/03/1998, The protocol described in this document provides the basis for the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. According to the framework provided by Cuervo et al [1], the IPDC protocol suite operates between the Media Gateway Controller and the Media Gateway. In terms of previous contributions to the experts of Questions 13-14/16, the corresponding entities are the Call Control and Media Control portions of the H.323 Gateway. The operation of IPDC in the service of H.323 is clarified in a companion contribution entitled 'IPDC Architectural Framework' [3]. "DIAMETER Mobile IP Extensions", C Perkins, Pat Calhoun, 11/18/1998, DIAMETER is an Authentication, Authorization and Accounting (AAA) Policy Protocol that is used between two entities for various services. This document defines an extension that allow a DIAMETER Client to request authentication and receive autorization information for a Mobile IP Mobile Node. "IPDC Media Control Protocol", Isaac Elliott, 08/03/1998, The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross-connect. Using the IP Media Control protocol presented here, the media gateway controller can send messages to the media gateway to cause events such as tones to be generated or detected within a media stream. "XDR Extensions", Thomas Davis, 09/10/1998, This document describes extensions to the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. "Simple Workflow Access Protocol (SWAP)", Keith Swenson, 08/04/1998, A standard protocol is needed to integrate work providers, asynchronous services, across the intranet/internet and provide for their interaction. The integration and interactions consist of control and monitoring of the work. Control means creating the work, setting up the work, starting the work, stopping the work, being informed of exceptions, being informed of the completion of the work and getting the results of the work Monitoring means checking on the current status of the work and getting a history of the execution of the work. The protocol should be light weight and easy to implement, so that a variety of devices and situations can be covered. The Simple Workflow Access Protocol is a proposed way to solve this problem through use of HTTP protocol, and by transferring structured information encoded in XML. A new set of HTTP methods is defined, as well as the information to be supplied and the information returned in XML, that accomplish the control of generic asynchronous services. This has applicability to workflow because a workflow is itself an asynchronous service, and it also has the need to be able to call asynchronous services aoutside of itself. "HTTP-ng Architectural Model", Bill Janssen, H. Nielsen, Mike Spreitzer, 08/04/1998, This document defines the architectural model for a new HTTP framework called HTTP-ng, along with a set of terms for referring to parts of it. "w3ng: Binary Wire Protocol for HTTP-ng", Bill Janssen, 08/04/1998, This document describes a binary `on-the-wire' protocol to be used when sending HTTP-NG operation invocations or terminations across a network connection. "The WebMUX Protocol", Jim Gettys, Henrik Nielsen, 08/04/1998, This document defines the experimental multiplexing protocol referred to as 'WebMUX'. WebMUX is a session management protocol separating the underlying transport from the upper level application protocols. It provides a lightweight communication channel to the application layer by multiplexing data streams on top of a reliable stream oriented transport. By supporting coexistence of multiple application level protocols (e.g. HTTP and HTTP/NG), WebMUX should ease transitions to future Web protocols, and communications of client applets using private protocols with servers over the same TCP connection as the HTTP conversation. WebMUX is intended for, but by no means restricted to, transport of Web related protocols; the name has been chosen to reduce confusion with other existing multiplexing protocols. This document is part of a suite of documents describing the HTTP-NG design and prototype implementation: * HTTP-NG Short- and Longterm Goals, ID * HTTP-NG Architectural Model, ID * HTTP-NG Wire Protocol, ID * The Classic Web Interfaces in HTTP-NG, ID * Description of the HTTP-NG Testbed, ID "HTTP-NG Web Interfaces", Dan Larner, 08/04/1998, Part of the charter of the Protocol Design Group of the HTTP-NG project is to identify a set of formal interfaces that will allow the current functionality of the Web to be captured, as well as support future needs. Before delving into the specific interfaces, the kinds of concepts involved need to be described. The actual interface descriptions here are cast in terms of distributed object systems, the merits of which as a foundation for the Web have been discussed in 'Migrating the Web toward Distributed Objects' (ftp://ftp.parc.xerox.com/pub/ilu/misc/webilu.html) and elsewhere. The intent is not to imply that what is presented here is complete or final, but rather to provide a starting point for how the Web should look in the future. "Proxy Mail Address Protocol", Derek Coulter, 08/04/1998, Perhaps the most intrusive form of Internet mail abuse, the unsolicited mail problem is a chronic aggravation that users are generally powerless to stop or prevent. Many forums have played host to endless criticism of the problem, particularly leveled against those who engage in the activity and their tactics, but few solutions have come to the forefront that provide users an adequate defense. While economic and social influences define the human side of the problem, the permissiveness of the Internet mail architecture with regard to the freedoms it grants senders, as well as the fixed relationship between mailbox and address, are the critical factors that provide opportunity to those who would abuse it. "Reliable Signaling Gateway Protocol (RSGP)", Matt Holdrege, Lyndon Ong, Jiri Matousek, 08/05/1998, This memo describes a combined message set and function set for the Control Protocol used between a Network Access Server (NAS) and a Signaling Gateway (SG), based on the ASP and RSGCP drafts previously submitted [asp, rsgcp]. The Control Protocol supports Call Control, Circuit Maintenance and Resource Management. "Framework for IP Multicast in MPLS", Bernard Sales, Wim Livens, Dirk Ooms, Maria Fernanda Ramalho, 08/05/1998, This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP 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 LDP modes are discussed. Focus is on ATM as a L2 technology. "DES Applicability Statement for Historic Status", Scott Bradner, W. Simpson, 08/05/1998, 'The ESP DES-CBC Transform' [RFC-1829] and 'The PPP DES Encryption Protocol' [RFC-1969] have been re-classified to Historic status, and implementation is Not Recommended. This Applicability Statement pro- vides the supporting motivation for that classification. The primary reason is that DES alone provides insufficient strength for the pro- tection of moderate value information for any length of time. "Loss Metrics of Grouped Packets for IPPM", Satoshi Ono, Teruko Miyata, Harumoto Fukuda, 08/05/1998, This memo defines several metrics for loss of grouped packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document (currently ''Framework for IP Performance Metrics'' ); the reader is assumed to be familiar with that document. "PPP in Ether-like Framing", W. Simpson, 08/05/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ethernet-like framing for PPP encapsulated packets. "Proxy Mail Address Protocol", Derek Coulter, 08/05/1998, This specification defines a service that manages a type of disposable Internet mail address known as a proxy address. Proxy addresses conform to the standard addressing scheme [RFC 822] and exist in the same address space, but act as aliases for regular, fixed addresses. Users may own many at a time and allocate and deallocate them at will. The service also defines a distinct command-response interface for use between client and server implementations to conduct management chores. "Reverse Network Address Translators (RAT)", Wee Tuck Teo, S. Yeow, 08/06/1998, Mobile IP faces difficulties in deployment as all mobile nodes need to support the protocol. While the implementation and deployment issues of the Mobile IP home agents do not affect the mobile end-users, the users are more constrained to the operating systems which support MobileIP on their mobile nodes. This document describes an alternative protocol that attempts to solve the deployment problem. It provides IP reachability for mobile users through the use of Reverse Network Address Translators (RAT). This technique leverages on the popularity of Network Address Translators (NAT) and NAPTs to provide transparent mobility to end hosts.The protocol's requirements for the mobile node are thus minimal. Moreover, the RAT protocol is interoperable with the MobileIP base protocol. "IPDC Connection Control Protocol", Andrew Dugan, 08/06/1998, The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Connection Control protocol presented here, the media gateway controller can setup, modify and teardown connections within or between media gateways. "The MIME application/nntp8bit Content-type", Maurizio Codogno, 08/06/1998, The application/nntp8bit content-type is proposed and defined as an efficient and simple way to transmit raw ('binary') data over an NNTP connection, taking into account the foreseeable limitations of that standard. "Deliver By SMTP Service Extension", Daniel Newman, 10/15/1998, This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a 'delayed' delivery status notification (DSN) [6] is to be issued. This extension should not be viewed as a vehicle for requesting 'priority' processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a Deliver By request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period. "Internet Cache Protocol Extension", Ivan Lovric, 10/01/1998, ICP (see [RFC2186]) is a protocol allowing standardized communication management between caches. This document describes an extension to the ICP protocol whose aim is to reach the following three goals : - locating requested data more efficiently among a cache hierarchy, - reducing network traffic between caches by exchanging compressed data over different protocols, - offering a suitable protocol for the forthcoming techniques of push and intelligent prefetching. "IPDC Device Management Protocol", Bob Bell, Scott Pickett, Alan Mikhak, 08/06/1998, The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Device Signaling Transport protocol presented here, the media gateway can receive a signaling from a circuit switched network and deliver the signaling to a media gateway controller on an intervening IP network. The media gateway controller can also send signaling to a media gateway for delivery on a circuit switched network. "Mobile IP Public Key Based Authentication", Stuart Jacobs, 08/06/1998, This document proposes an extension to the Mobile IP base protocol. The purpose of this extension is to allow Mobile Nodes (Hosts) and Mobility Agents (both home network and foreign network) to use X.509 digital certificates, public keys and digital signatures as the basis of authenticating Mobile IP control messages. The use of these mechanisms will allow Mobile IP to scale to tens of thousands of mobile nodes across networks owned-operated by different organizations and service providers. "SOCKSv5 Protocol Extensions for IPv6/IPv4 Communication Environment", Hiroshi Kitamura, 08/06/1998, This document describes three types of extensions of SOCKS Version 5 protocol [RFC1928]. A new address type and a new command for Requests and Replies are introduced. These extensions supplement the insufficient generic functions of the SOCKSv5 protocol. These extensions are basically designed to support IPv6 based efficient communication environment. In addition, they make both IPv4 and IPv6 based communications efficient. Also, they enable a SOCKS server to be used as a translator between IPv4 and IPv6 based communications with ease. "MPLS Mappings of Generic VPN Mechanisms", Juha Heinanen, A. Lin, 08/06/1998, This document describes a set of generic mechanisms which can be used to set up network based Virtual Private Networks (VPN) across IP networks. In particular, it describes how these mechanisms can be mapped into a network running the Multi-Protocol Label Switching (MPLS) specification. The mechanisms described, however, can apply to any type of IP network running various forms of IP tunneling mechanisms, and are not solely restricted to MPLS networks. This Draft serves to introduce these generic mechanisms, which are part of the broader VPN framework which will be described more fully in forthcoming Drafts. "Address utilization in the MASC/BGMP architecture", Mikhail Smirnov, Graham Phillips, 08/06/1998, This memo provides a simple analysis for the address utilization in the MASC architecture and concludes that the number of levels in the hierarchy should be kept small. More specifically, we believe that the number of levels should not exceed 3 MASC levels. The memo also motivates that MASC should not rely on hints from applications for future address requirements, but should rather guess future address demand and allocate addresses pro-actively thereby reducing the latency for address requests. "Similarities and Differences between SWAP and IPP", T. Hastings, Keith Swenson, 08/06/1998, IPP (Internet Printing Protocol) has been compared in conversations to SWAP (Simple Workflow Access Protocol). Both are for starting an asynchronous job, and then being able to check up on it later. The IPP is specifically designed for printers and print jobs. SWAP is more generic, and is generally oriented toward more computational jobs. But many of the problems encountered are the same, and the approach to the solutions can be examined and compared. This document goes through the features point by point and shows in what ways they are similar, and more importantly in what ways their approaches differ. The purpose of this is to guide discussions about the two protocols. "IDentity Infrastructure Protocol (IDIP)", Shingo Fujimoto, Dave Marvit, 08/06/1998, The IDentity Infrastructure Protocol (IDIP) is designed to support a new class of services known as 'Identity Services'. These constitute online extensions of a person's identity leading to the formation of an 'extended individual'. IDIP supports the coordinated communications between online identities (so called IDOs) and facilitates the invocation of applications. This document presents a specification for IDIP and provides some examples. "Extensions to RSVP for Traffic Engineering", Der-Hwa Gan, Tony Li, George Swallow, Vijay Srinivasan, Daniel Awduche, 08/06/1998, This document describes the use of RSVP, including all the necessary extensions, to support traffic engineering with MPLS as specified in [6]. "Requirements for Internet-Scale Accounting Management", Jari Arkko, 08/06/1998, Over the years, as Internet services have evolved, sophisticated inter-domain applications such as roaming, voice over IP, Internet fax, and QoS provisioning have arisen. This document discusses whether accounting for these services services can be reliably and securely accomplished using established techniques, and explores the requirements for Internet-scale Accounting Management. "Introduction to Accounting Management", B Aboba, Jari Arkko, 08/06/1998, The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend anal- ysis, cost allocation, auditing, and billing. This document describes the problems encountered in Accounting Management, as well as some of the issues encountered in the design of accounting systems. It also reviews the state of current practice. "MATE: MPLS Adaptive Traffic Engineering", Anwar Elwalid, Indra Widjaja, 08/07/1998, This document describes an MPLS Adaptive Traffic Engineering scheme, called MATE. The main goal of MATE is to avoid network congestion by balancing the loads among the LSPs. MATE makes minimal assumptions in that the intermediate LSRs are not required to perform traffic engineering activities or measurements beside forwarding packets. Moreover, MATE does not impose any particular scheduling, buffer management, architecture, or a priori traffic characterization, on the LSRs. "The TEXT/PLAIN FORMAT Parameter", R Gellens, 11/18/1998, Interoperability problems have been observed with erroneous labelling of paragraph text as TEXT/PLAIN, and with various forms of 'embarrassing line wrap.' (See section 4.) Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and TEXT/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end. What is desired is a format which is in all significant ways TEXT/PLAIN, and therefore is quite suitable for display as TEXT/PLAIN, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate. "Lightweight Directory Access Protocol (v3): Schema for Domain Name System (DNS)", B. Narayana, Tom Miller, Peter Quinto, 08/07/1998, This document defines a schema for the Domain Name System (DNS). This schema makes it possible to integrate DNS servers with an LDAP-based directory service, allowing an organization to maintain a single store of DNS information. Integration of DNS into LDAP directories is desirable since it reduces administrative overhead and eliminates the need to maintain multiple server centric configuration databases for DNS and other services. It is anticipated that this schema will be useful for providing a standardized format for the representation of attributes needed by DNS implementations within LDAP-based directory services. "A Method for Transmitting PPP Over Ethernet 'PPPoE'", Louis Mamakos, David Carrel, Kurt Lidl, Ross Wheeler, Jeff Evarts, Dan Simone, 11/17/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet "Network Access Server Requirements Next Generation (NASREQNG) Operational Model", David Mitton, 08/07/1998, This document describes the terminology and an operational model of typical Network Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFC 2138, 2139) and follow-on efforts like Diameter (draft-calhoun-diameter-04.txt). These are protocols for carrying authentication, authorization, and user configuration information between a Network Access Server which desires to authenticate its calls and a shared Authentication Server. "The Internet Routing Registry MIB", Glenn Mansfield, 08/10/1998, A routing registry(RR) is a repository of routing policy information. The IETF-RPSL-WG has developed a Routing Policy Specification Language (RPSL) for describing routing policy constraints. This document addresses the need for providing the means of managing the routing registry as well as to provide access to the routing registry from within the Internet standard network management framework. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community to monitor and manage the RRs. "MPLS-VNS Interworking", Dwight Jamieson, Bilel Jamoussi, Paul Beaubien, 08/10/1998, This document specifies MPLS [1,2] to VNS [3] interworking in an efficient manner that preserves the label switching property when crossing an MPLS/VNS boundary. The interworking function also ensures that COS characteristics of an LSP are preserved when going from VNS to MPLS and vice versa. "The Network Access Server", M. Beadles, 11/16/1998, The Network Access Server is the initial entry point to a network for the majority of users of network services. It is the first device in the network to provide services to an end user, and acts as a gateway for all further services. As such, its importance to users and ser- vice providers alike is paramount. However, the concept of a Network Access Server has grown up over the years without being formally defined or analyzed. This document offers a framework for the defini- tion and analysis of a modern Network Access Server. "Management Information Base", George Kajos, Irina Suconick, Joon Maeng, Dan Klenke, Zvi Mizrahy, Pnina Vortman, 08/10/1998, This Recommendation describes the Multimedia Management Information Base for H.323 and H.320 Multimedia Terminals. The purpose of HMultimediaMIB is to standardize the management information in multimedia conferencing systems based on one of more of the ITU-T H-series recommendations. The goal of Multimedia Management is to provide the appropriate level of management support for the particular Multimedia device. Multimedia management must permit the resources that are being used by individual Multimedia sessions to be identified for the purposes of fault detection, fault isolation, performance monitoring, configuration management, and capacity analyses. Multimedia management is applicable to both intermediate-system as well as end-system Multimedia devices such as terminals, multipoint control units (MCUs), gatekeepers, and gateways. "INTERNET KERMIT SERVICE", Frank da Cruz, Jeffrey Altman, 08/10/1998, This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. The Internet Kermit Service provides access to both authenticated and anonymous users. The use of Kermit protocol over a Telnet connection provides several advantages over FTP, including easy traversal of firewalls, transfers over multiple transports, and security via a combination of supported Telnet authentication and encryption option negotiations, plus significant functional benefits. "TELNET KERMIT OPTION", Frank da Cruz, Jeffrey Altman, 08/10/1998, This memo proposes an optional extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol within a Telnet session. "MPLS Ships in the Night Operation with ATM", N. Feldman, Loa Andersson, Bilel Jamoussi, 08/10/1998, Multi-Protocol Label Switching (MPLS) can have several modes of operation over ATM. The MPLS Framework document [1] indicates that MPLS MUST allow 'ships in the night' (SIN) operation with existing L2 switching protocols (e.g., ATM Forum Signaling). This document identifies the technical requirements that have to be resolved in order to allow for a successful SIN operation between MPLS and ATM Forum protocol stack. Solutions to the various challenges are proposed. "RSVP Extensions for IPv6 Flow Label Support", Andrew Scott, Stefan Schmid, Martin Dunmore, Nicholas Race, 09/01/1998, This document is an addendum to Version 1 of RSVP (Resource ReSerVation Protocol) as defined in the proposed standard [RFC2205]. The flow label, one of the new header fields of the IPv6 protocol, allows improvements to resource reservation protocols on IPv6 capable networks. Utilization of the flow label simplifies packet classification and optimizes packet processing in routers along the transport path. The main objectives of this document are to specify the proper usage of the IPv6 flow label and to promote its support within RSVP. This memo defines extensions required to the Version 1 specification and additional processing rules needed to ensure correct operation. Rather than simply presenting the specification with no justification, we have tried to present the benefits of adopting the flow label within RSVP for IPv6. This addendum does not have any effect on the implementation or usage of RSVP for IPv4. "Wireless Networking for the MNCRS", G. Montenegro, Spencer Dawkins, 08/10/1998, In view of the unpredictable and problematic nature of wireless networks, arriving at an optimized wireless transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. "Modifications to OCBT for Static Multicast", Masataka Ohta, Manolo Sola, 08/10/1998, OCBT is a CBT-based multicast protocol that allows multiple cores for a multicast group. The goal in OCBT is to set up and mantain a unique bidirectional multicast tree connecting members with cores, and also cores among themselves. This tree is used to deliver multicast traffic to members of the multicast group. To accomplish that objective, members, non-member senders, routers with members and cores must know the IP unicast address of cores and the IP multicast address for the multicast group. This is a key issue in tree-based multicast protocols using centers, cores, or rendevous points, and their main source of lack of scalability. In OCBT this key issue is open. In this Internet-Draft we proposed to use Static Multicast as an scalable solution to this problem. "Preliminary Simulation Evaluation of an Assured Service", Kathleen Nichols, Juan-Antonio Ibanez, 08/10/1998, This draft presents a simulation analysis of Assured Service, an end-to-end service based on the differentiated services enhancements for IP. Assured Service has been the subject of much discussion in the past year in the IETF, but solid information on its applicability to the entire Internet has been lacking. This report is aimed at providing a first step in this direction. Assured Service requires an active queue management algorithm with preferential packet drop. The RIO algorithm (an extension of the RED algorithm) has been the primary method suggested and is the one evaluated here. Our results show that Assured Service does not provide clearly defined and consistent rate guarantees; the advantage gained by connections using Assured Service is not a quantifiable one. Further work would be required to determine an appropriate use of the Assured Service. A pdf version of this document is available and recommended for the figures it contains. "MULTI_NETWORK DATAGRAM TRANSMISSION PROTOCOL", Randall Stewart, Qiaobing Xie, 09/08/1998, This Internet Draft discusses an experimental protocol, namely the Multi-network Datagram Transmission Protocol (MDTP), that is intended to provide fault-tolerant reliable/unreliable data transfer between communicating processes over IP networks [1]. MDTP is proposed as an application-level protocol which is designed with a high emphasis on supporting redundant networks and transparent fault management. MDTP also gives the application a great degree of timing control and configuration flexibilities. The motivation of developing MDTP is to establish a framework for supporting Internet-based high reliability real-time commercial applications such as signaling and call control for Internet telephony. "MPLS VPN Architecture", Dwight Jamieson, Bilel Jamoussi, Paul Beaubien, Gregory Wright, 08/10/1998, This Internet Draft defines an architectural model for building Virtual Private Networks (VPNs) in an MPLS domain. The proposed model takes advantage of both network layer peering and packet switching, and link layer circuits and per-stream switching. The model provides a set of simple mechanisms for controlling VPN membership, including registration, propagation, discovery, and dynamic creation of Label Switch Paths to provide connectivity. The architectural constructs described in this document, when combined with the MPLS architecture [1], provide a flexible and scaleable basis for building VPNs. "Layer Two Tunnelling Protocol : ATM access extensions.", Bernard Sales, Paolo Crivellari, Yves T''Joens, Laurent Hermans, 11/20/1998, The L2TP working draft describes a protocol which permits the tunnelling of the link layer of PPP. This document augments the procedures described in the L2TP working draft to support ATM SVC or PVC based access networks. The necessary extensions to the L2TP working draft are defined in order to allow for non-HDLC based framing (and related link options negotiation according to 'PPP over AAL5' as defined in [3]) and asymmetric bi-directional call establishment in the access network. "ACAP Mailbox Dataset Class", Lawrence Greenfield, 11/23/1998, IMAP [IMAP4] allows users to access the mail store in an efficient way, but has insufficient support to export detailed meta-level information about mailboxes, subscriptions, and multiple servers. The mailbox dataset provides a fast, flexible way of exporting this "Simplified Call Control Protocol - Etheric", Harri Toivanen, Petteri Laamo, George Wayne, Paul Harding-Jones, 08/10/1998, This memo describes Simplified Call Control Protocol called Etheric between Signalling System 7 (SS7) controlled Public Switched Telephony Network (PSTN) and Network Access Server (NAS) created by Oy LM Ericsson Ab in co-operation with Advanced Computer Communications inc (ACC). "MDN profile for IMAP", Alexey Melnikov, 08/10/1998, Message Disposition Notification [MDN], also known as 'acknowledgements' or 'receipt notifications' is one of the widely used features of X.400 and the proprietary 'LAN-based' messaging systems. [MDN] defines how this functionality may be supported by Internet Mail, however it doesn't describe how multiple Mail User Agents (MUAs) may use MDN together with the Internet Message Access Protocol [IMAP4]. This document should be considered as guidelines for implementers of the Internet Message Access Protocol [IMAP4] that want to add MDN support to their products. "Integrating SDP Functionality Into SMIL", Philipp Hoschka, 09/02/1998, This document describes an approach for integrating the functionality currently contained in [47]SDP (Session Announcement Protocol) into [48]SMIL (Synchronized Multimedia Integration Language). The motivation is to make it easier for SMIL authors to interface with the existing RTP/MBone infrastructure. Currently, this requires maintaining two different sets of files, each of which use a different text format. Another motivation is to save one network round-trip per RTSP URL in the SMIL file, since the information contained in the SDP file is now directly included in the SMIL file. "A Design for Simple, Low-Overhead Multicast", R. Perlman, Jon Crowcroft, Tony Ballardie, Cheng-Yin Lee, 08/11/1998, This paper describes how a lot of the complexity and overhead of multicast can go away if a slightly different approach is taken. Approaches like this have been proposed in the past, but the design has not been carried through to completion. This paper describes the approach and then compares it with other approaches. "SCRAPI - A Simple 'Bare Bones' API for RSVP", Bob Lindell, 11/19/1998, This document describes SCRAPI, a simple 'bare bones' API for RSVP. The goal of this API is to produce an interface which simplifies the augmentation of applications with RSVP support. "Conformance Statements for SMIv2", Keith McCloghrie, David Perkins, J. Schoenwaelder, 11/03/1998, Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the Structure of Management Information (SMI) [2]. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. "PIP-DEMO: An Interoperable Presence Information Protocol", Mark Day, Gordon Mohr, Dave Marvit, Sonu Aggarwal, Avshalom Houri, Youji Kohda, 08/11/1998, PIP/0.2 is a demonstration protocol designed as a testbed for certain ideas about meeting 'Presence Information Protocol' requirements in a straightforward, interoperable fashion. Drawing from earlier proposals in this area, PIP/0.2 aims to: 1) Enable basic 'presence information' sharing 2) Enable simple text messaging; and 3) Remain easy to understand and implement PIP/0.2 specifically makes NO attempt to be: 1) Secure 2) Scalable/efficient; or 3) Rigorously specified "Structure of Management Information Version 2 (SMIv2)", Keith McCloghrie, David Perkins, J. Schoenwaelder, 11/03/1998, Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. "Textual Conventions for SMIv2", Keith McCloghrie, David Perkins, J. Schoenwaelder, 11/03/1998, Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the Structure of Management Information (SMI) [2]. "Routing Policy Configuration Language (RPCL)", Antoni Przygienda, Ardas Cilingiroglu, 08/11/1998, Routing policies define a set of rules and actions to be applied by proto- cols when they send and receive routing updates. When a protocol receives an updates, routing policies are used to determine if, and with what infor- mation a route gets added to the Routing Information Base (RIB). When preparing to send a routing update, routing policy is consulted to see if the route is to be sent and if so, what information is to be included in the update. The Routing Policy Configuration Language (RPCL) specifies a language for defining routing policies in a router. "The KeyNote Trust-Management System", J. Ioannidis, Angelos Keromytis, Matt Blaze, Joan Feigenbaum, 08/11/1998, This memo describes KeyNote, a simple trust-management system. It outlines the syntax and semantics of KeyNote credentials, describes action environment processing, and describes the application architecture into which a KeyNote implementation would fit. "UNITE: An Architecture for Lightweight Signaling", K.K. Ramakrishnan, Michael Wong, Gisli Hjalmtysson, Kobus van der Merwe, Flavio Bonomi, Sateesh Kumar, 08/11/1998, Communication networks need to support a wide range of applications with diverse service quality requirements. The current widespread use of best-effort communication also suggests that the overhead for establishing communication both in processing and latency needs to be kept at a minimum. With ATM signaling, every flow, including a best-effort flow, suffers the overhead of end-to-end connection establishment. ATM signaling complexity is further exacerbated by having variable length messages with a large number of information elements using a very flexible encoding, sent on a single control channel. The inclusion of QoS processing and connectivity in the initial setup of a connection requires sequential hop-by-hop processing. Variable length messages involves both a single point of resequencing as well as relatively slow, software based processing. In recognition of these shortcomings, the MPLS working group has opted to use topology driven label distribution as its default label distribution mechanism, while at the same time acknowledging the possible need for on-demand label distribution. We see these different approaches as points on a range of solutions and we do not wish to open a debate concerning the relative merits of each approach. However, we believe that if there is a need for on-demand label distribution, then there is a need to do this very efficiently. In this light we have decided to bring to the MPLS working group our architecture for lightweight signaling. While in its current form it is applicable to an ATM environment, we believe that it represent a step forward in the evolution of signaling for high speed networks. It holds the promise of processing signaling in hardware, thereby enabling substantial speed up of connection setup, so as to meet the needs of contemporary applications. Our proposed lightweight architecture f "An LDAP Schema for Dynamic Host Configuration Protocol Service", Ye Gu, Ramesh Vyaghrapuri, 08/11/1998, This document defines a schema for representing DHCP service in an LDAP-based directory. The integration of DHCP with a directory makes it possible for an organization to centrally administer its DHCP service, regardless of the number of DHCP servers it deploys. This management approach further reduces the total cost of ownership and improves scalability of DHCP service. "Presence Information Protocol Requirements",, 08/11/1998, Instant Messaging has recently emerged as a new medium of communications over the Internet. Instant messaging has spawned a whole new category of applications that are surging in popularity. "Modifications to PIM-SM for Static Multicast", Masataka Ohta, Manolo Sola, 08/11/1998, The Protocol Independent Multicast - Sparse Mode (PIM-SM) is currently defined as an intra-domain multicast protocol. Although in PIM-SM more than one Candidate Rendezvous Point (C-RP) may exist, only one can be active at a given time, and this will be the one to which receivers will send Join messages or sources will send Register messages. The method used in PIM-SM to make public the set of C-RPs for a multicast group is to flood all over the domain packets with the list of C-RPs using the so-called Bootstrap method. This approach may scale in domains with few routers but does not scale if the protocol would have to be applied to provide multicast throughout the whole internet. In this draft we specify the modifications needed in PIM-SM in order to support more than one active RP simultaneously, and also show how Static Multicast can be used to make public in an scalable way the information regarding RPs as well as the IP multicast address for the multicast group. In the presence of more than one source, having more than one RP and placing them according to sources and receivers' distribution on the internet will reduce the average number of hops from sources to receivers, and will also improve the multicast protocol's fault tolerance. "Packet over Sonet/SDH", Thomas Narten, 08/11/1998, T1.X1 is the ANSI accredited T1 Technical Subcommitee responsible for developing SONET standards, including SONET rates, formats and payload mappings. Its output is also brought into the ITU, for example as in ITU-T Recommendation G.707 [G.707]. The IETF-recommended way to run HDLC over SONET is to use the definition found in T1.X1 ANSI documents [T1.105.02, T1.105] and ITU document [G.707]. "Aggregation of Internet Integrated Services State", S. Berson, S. Vincent, 08/12/1998, The Internet Integrated Services (IIS) architecture[2] has a fundamental scaling problem in that per flow state is maintained at all routers and end-systems supporting a flow. This draft examines the use of aggregation as a technique to reduce the amount of state needed to provide IIS, and describes the modifications to RSVP to support aggregation. In our approach, routers at the edge of a region doing aggregation keep detailed IIS state, while in the interior of this region, routers keep a greatly reduced amount of state. Packets will be tagged at the edge with scheduling information that will be used in place of the detailed IIS state. The aggregation scheme described will allow large scale deployment of IIS without overloading routers with state and associated processing. "PPP Over SONET Applicability Statement for Historic Status", Thomas Narten, 08/12/1998, PPP over Sonet [RFC 1619] uses 'HDLC-like framing' as defined in [RFC 1662]. These documents were developed to address a void in existing SONET standards at that time. T1.X1 is the ANSI accredited T1 Technical Subcommitee responsible for developing SONET standards, including SONET rates, formats and payload mappings. Its output is also brought into the ITU, for example as in ITU-T Recommendation G.707 [G.707]. At the December, 1997 IETF in Washington DC, a BOF was held to discuss a potential weakness in previous mappings. Specifically, long packets (where 'long' can include those carried by PPP) containing a special bit pattern can cause a SONET reciever to declare a 'loss of signal'. The minutes of the BOF are included in Appendix A. T1.X1 has recently defined a mapping for HDLC over SONET [T1.105.02, T1.105] that addresses the potential weakness described above. The work done by T1.X1 on SONET supersedes past efforts that have taken place within the IETF. The recommendation of this applicability statement is that all PPP over SONET implementations use the combination of RFC 1662 plus 'Packet Over Sonet/SDH' [POS]. The first document describes how to encapsulate PPP in HDLC; the second document describes how to encapsulate HDLC in SONET. We also recommend that RFC 1619 be reclassified as Historic. "IPDC Device Management Protocol",, 08/12/1998, The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Device Management protocol presented here, the media gateway controller can obtain status and receive notification of management events from the Media Gateway or between Media Gateways. "Definition of the LZJU90 MIME Content Transfer Encoding Type", A. Costanzo, 09/04/1998, This memo defines a new transfer encoding type for MIME, namely LZJU90. LZJU90 specifies a section consisting of an encoded binary or text object. The encoding provides both compression and representation in a text format. "Creating File System Object Attachments with MIME", A. Costanzo, 08/28/1998, This memo defines a new top level type for MIME and its subtypes and mappings to file types. The intent of this draft is to both define a new comprehensive top level type and define a method and usage for one of the to be defined subtypes. This new subtype in itself is a media type. The purpose of which provides a mechanism to move a structured set of files system object structures (directories and/or files) as a MIME attachment from one environment to another while preserving common elements. "Definitions of Managed Objects for Service Level Agreements Performance Monitoring", K. White, 10/02/1998, This memo defines a Management Information Base (MIB) for performing performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The MIB defined by this document is based upon the content of 'Schema for Service Level Administration of Differential Services and Integrated Services in Networks', refer to [19]. "Anti-UBE and Anti-UCE Keywords in SMTP Banners", Paul Hoffman, John Levine, 11/16/1998, Legislators writing laws that would limit or prohibit the sending of unsolicited bulk email (UBE) or unsolicited commercial email (UCE) have begun to include rules that require mail servers to include particular wording in the SMTP banner. To date, this wording has had two distinct purposes: to warn senders that they may not send UBE or UCE to that SMTP host, and to state the physical location of the host so that the sender may know which laws apply. This document is meant to help clarify how such legislation might be worded, and to help increase interoperability of various laws. It is not meant to be a standard of any kind, but is meant only for its informational value. "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering", C. Partridge, 10/09/1998, Suppose you want TCP implementations to be able to fill a 155 Mb/s path. Further suppose that the path includes a satellite in a geosynchronous orbit, so the round trip delay through the path is at least 500 ms, and the delay-bandwidth product is 9.7 megabytes or more. If we further assume the TCP implementations support TCP Large Windows and PAWS (many do), so they can manage 9.7 MB TCP window, then we can be sure the TCP will eventually start sending at full path rate (unless the satellite channel is very lossy). But it may take a long time to get the TCP up to full speed. "ISAKMP Key Recovery Extensions", Tom Markham, 09/14/1998, This document describes the proposed approach for negotiating and exchanging key recovery information within the Internet Security Association Key Management Protocol (ISAKMP). "Pluggable Authentication Modules", Andrew Morgan, 09/03/1998, This document is concerned with the definition of a general infrastructure for module based authentication. The infrastructure is named Pluggable Authentication Modules (PAM for short). "Simple Commerce Messaging Protocol (SCMP)", Tom Arnold, Jason Eaton, Michael Jimenez, 09/03/1998, The Simple Commerce Messaging Protocol (SCMP) is a general-purpose commerce transport protocol for securely communicating a set of data from a sending agent's application to a receiving agent's server. And, where the response by the receiving agent's sever to the sending agent is, in fact, the reply from the transaction represented by the set of data in the message's payload. The intent of this protocol is to define a method where trading partners can perform on-line business transactions in an environment where the sending partner is fully authenticated, and the message cannot be repudiated. The SCMP message content, hereinafter referred to as message payload, is not intended to be defined or specified. SCMP does not specify payload contents or how trading partners are expected to process the payload, beyond basic server-level functions related to processing SCMP-headers.This intent is to permit trading partners the flexibility to implement either a standard commerce message format as in ANSI-X12 Electronic Data Interchange (EDI) or some other proprietary transaction format. The only requirement on the message payload is that it be identified to the receiver utilizing MIME naming and formatting [MIME] and used to identify the type of payload contained in the SCMP data area. In this manner, SCMP fundamentally differs from many emerging commerce message protocols. Beyond specifying the method for transport, encryption, authentication and handling, these other protocols specify the contents of the message and details how a server is to process and respond to the message payload. SCMP is intended as both an on-line and batch protocol. The exact content of the message and the processing constraints are specified in SCMP-headers. "DIRECTORY SUPPORTED CERTIFICATE STATUS OPTIONS", Alan Lloyd, 09/15/1998, This Internet Draft specifies some proposed enhancements to the X.500 information schema and matching rules to support Certificate path processing, certificate status and CRL mechanisms. These enhancements provide advantages over existing Certificate validation and CRL mechanisms. In particular, the mechanisms proposed can: (a) reduce the need for unnecessarily fetching CRLs; (b) allow certificate status-CRL evaluation time to be improved; (c) provide a directory supported certificate test and fetch capability; (d) better support use of certificates in multiple environments with different CRL arrangements. (e) simplify the client software in the areas of certificate path, certificate validity and CRL processing. (f) provide the client a range of trust options when validating certificates. (g) provide a range of implementation options so that gradual adoption is possible. This document is submitted for consideration as the basis of possible future IETF/ITU standardization. Please send comments on this document to the ietf-pkix@imc.com mail list. "Basic Definition of Message Tracking", G. Vaudreuil, Gordon Jones, Bruce Ernst, 09/08/1998, This document defines message tracking as a prelude to the creation of a message tracking model. Message tracking is a messaging management function; it provides the ability to find out, after the fact, the path that a particular message took through the messaging system, the current status of that message, and its characteristics. "Multicast Manager (MCM): A Multipoint-to-Multipoint Multicasting Protocol for ATM", Yasser Seif, Hani Harb, 10/27/1998, This document describes MCM, a protocol for controlling a shared ATM multicast tree supporting Mutipoint-to-Multipoint communication. The protocol guarantees that there is no cell interleaving at any group receiver. No cell buffering inside the network is required, and all cell forwarding is performed at the ATM layer. "MIME Types for Use with the ISO ILL Protocol", Mark Needleman, Ruth Moulton, 11/02/1998, This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). Two MIME types are specified below. The first is a media type to carry objects which are BER [BER] encoded ISO ILL Protocol Data Units (PDU's). BER are the basic Encoding Rules used to encode PDU's which have been described using ASN.1 (Abstract Syntax Notation 1) [ASN.1] . The second is for use with the associated document delivery instructions. Document Delivery Instructions (DDI) is an emerging protocol which enables automatic electronic delivery of items. It allows a request management system (which might have received a request for an item via the ISO Interlibrary Loan Protocol (ISO 10160/10161)) to pass details of the request, item, and delivery, to a delivery module, and to receive back reports on the delivery process or arrival of an item. It is currently being submitted to the ISO TC46/SC4/WG4 committee for approval as an ISO standard. "Admin Core - Administrative Container Metadata", R. Iannella, Debbie Campbell, 09/09/1998, Administrative metadata - referred to as 'Admin Core' - is useful to designate information about the creation and availability of other sets of metadata. The objective of Admin Core is to provide simple authentication to verify the integrity and provenance of information retrieved from networked resources. The Admin Core elements are utilised to associate date and creator information about metadata. "Notification - An extension to POP3", Torbjorn Tornkvist, 09/11/1998, This memo describes an optional extension to the Post Office Protocol version 3 (POP3), which introduces a possibility for a POP3 client to be notified by a POP3 server whenever the clients maildrop is accessed. "DIAMETER Proxy Server Extensions", William Bulley, Pat Calhoun, 09/14/1998, This DIAMETER Extension defines commands and AVPs that are used when DIAMETER messages must be proxied by DIAMETER Servers. This extension is intended to clearly define how proxying can be done with DIAMETER. "DIAMETER Device Configuration Extensions", Pat Calhoun, Nancy Greene, 09/14/1998, This DIAMETER Extension defines commands and AVPs that are used by two peers to exchange DIAMETER configuration information. The intent of this draft is to minimize configuration of devices prior to deployment. "Requirements for A Telephony Gateway Device Control Protocol", Tom Taylor, 09/15/1998, This document describes the requirements for a protocol to control a device which supports telephone lines or trunks on one side and packet network ports on the other. The primary functions of the device are to make, modify, and break media stream connections between these edge-points, to perform operations on the media streams, and to detect and report specific events associated with those streams or the edge-points. This device may also terminate call signalling which it processes itself and/or passes to the device which controls it. Using the terminology provided by Cuervo et al [1], the device just described is a Media Gateway, and is controlled by a Media Gateway Controller. The requirements for the protocol separate into two major parts: operational and functional. The operational requirements are concerned with reliability and security of control messaging, control session startup and takedown, handling of control session failures, and control system performance. The functional requirements cover connection control, media processing, event notification, and resource status tracking. They may also include signalling backhaul from the Media Gateway to the Media Gateway Controller. The protocol should extend to the control of devices which contain telephony edge-points only (such as digital cross-connects) or packet network ports only (such as transcoders or announcement servers). "The Role of DMIF in Support of RTP MPEG-4 Payloads", Vahe Balabanian, 09/21/1998, This draft technical proposal describes how RTP carrying MPEG-4 payloads interacts with the MPEG-4 Sync layer through the MPEG (Delivery Multimedia Integration Framework) DMIF. Single or multiple MPEG-4 streams can be carried over one RTP session. MPEG-4 information essential for the efficient packing and unpacking of MPEG-4 streams into/from RTP is identified. The DMIF end-to-end signaling protocol is applied to identify the MPEG-4 RTP payload types and ensure stack compatibility at both sender and receiver locations. DMIF also interprets the RTCP reports by comparing its statistics to the requested MPEG-4 media based QoS. If the statistics fail to meet the requested QoS then action is taken to either continue with the impaired performance, upgrade the network service class, scale down the stream or delete the stream. This action is apart from scalability using the stream back-channel flow control which may be present between an encoder and its decoder. This is an update of the draft-ietf-avt-rtp-mpeg4-dmif-00. It reflects the latest MPEG-4 specs. In addition some clarifications are included and an open issues section is established based on feedback received. "Requirements for DAV Searching and Locating",, 09/21/1998, The Distributed Authoring and Versioning protocol [WEBDAV] defines simple mechanisms to assign and retrieve values for properties. This document presents requirements for a WebDAV extension to support efficient searching for resources based on WEBDAV properties and content. These requirements are intended to be the basis for the DAV Searching and Location (DASL) protocol. "IANA Address MIB", M. Daniele, 09/21/1998, This document contains an initial version of a MIB module for commonly used network addressing information. It defines a registry for identifiers that identify protocols and a set of textual conventions for representing addresses. This document also establishes IANA as the maintainer of this registry. "LDAP Replication Architecture", Ed Reed, U. Srinivasan, John Merrells, 11/23/1998, This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. "List and Read Operations: LDAP-X.500 Alignment", Alan Lloyd, 09/21/1998, LDAP was originally developed as a lightweight protocol but through its development it has added many features to a point where there is very little difference in terms of simplicity or code size to that of DAP. However, DAP included features which provided efficient navigation through a multi server distributed directory systems (List), efficient retreival (Read)and the ability to provide service controls to select operation requestpriority, permit/deny chained operations and the ability to select master/replica data in the operation response. LDAP is now widely used as the access for X.500 distributed directory systems, however LDAP in its original form omitted the items (List, Read and Service Controls) as defined above. The List/Read requirements were serviced by LDAP through the use of 'pre-selected' Search operations. The Service Controls as per X.511 for distributed operation control have in most part been omitted from LDAP. (These are the subject of another proposal.) Experience in the field is showing that not having a List (and to a lesser degree, Read) operations in LDAP accessing to distributed directory system causes very inefficient multi server navigation compared to that of an LDAP Search being used. A Search operation is the most complicated of directory services, yet in the LDAP case it is being used for lesser and more efficient functions. For instance, in the LDAP only multi - server environments, not having a List operation causes considerable client re processing and protocol exchanges due to dealing with system referrals. This leads to extended user/client response times. For those who have already implemented a LDAP Search operation a Read and List should be of little consequence. This document defines two additional operations for LDAP namely List and Read that extend the LDAPv3 [LDAP] operations to provide a simple navigation/browsing and information retrieval mechanism by which a LDAP client can be "Service Controls: LDAP-X.500 Alignment", Alan Lloyd, 09/21/1998, This document defines service controls that extend the LDAPv3 [LDAP] operations to provide a simple mechanism by which an LDAP client can select master or replica directory information, control chaining and specify other service requirements when connected to an X.500 directory service. These service control mechanisms are not required when LDAP clients are connected to a single(non X.500) LDAP server because, for example, chaining [X.518]is not supported by these servers. Chaining protocols (DSP in X.500) also permit the extraction of master or replica data from within the X.500 directory system and provide this to the client (via LDAP) without the need for client based LDAP referrals to different servers. In addition, the controls proposed provide major step in the 'control' alignment of LDAP and DAP and their use of X.500. This will permit functional consistency to be achieved in directory enabled applications that use LDAP for access. In order to distinguish this functionality from LDAP V3 capable systems, an upgrade to LDAP V4 is also proposed. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. "Scenarios for DASL", Rick Henderson, 09/21/1998, The Distributed Authoring and Versioning protocol [WEBDAV] defines simple mechanisms to assign and retrieve values for properties. This document presents scenarios for a WebDAV extension to support efficient searching for resources based on WEBDAV properties and content. These scenarios are intended to suggest some of the uses that DASL could be put to. This may in turn motivate decisions on what is essential to DASL and what may be considered extra. "The Use of MPEG-4/DMIF and RSVP with Integrated Services", Vahe Balabanian, 09/21/1998, This draft proposal explains how the ISO/IEC MPEG DMIF (Delivery Multimedia Integration Framework) can be used to carry MPEG-4 streams according to required media specific QoSs using RSVP with Integrated Services. Comments are solicited and should be addressed to the working group's mailing list at int-serv@isi.edu and/or the authors. "Use of the Content-Disposition header with HTTP.", Claus Andre Faerber, 09/22/1998, [RFC2183] introduces a Content-Disposition header field for Internet Mail Messages to transmit presentation information as well as a suggested file name for saving the content to disk and the file's date information. All of this information is missing from HTTP entities [RFC2068]. However, there is nothing that would prevent the use of the Content- Disposition header with this HTTP. Without being standard, the Content-Disposition header has already been introduced by some software products. [HTTP1.1-REV] documents this practice, based on [RFC1806]. This memo also extends the specification to cover [RFC2183] and corrects the common abuse of the Content-Type header to cover presentation information. "The Role of DMIF with RTSP and MPEG-4", Vahe Balabanian, 09/22/1998, This draft technical proposal describes how MPEG DMIF (Delivery Multimedia Integration Framework) can be used with RTSP for setting MPEG-4 service sessions and subsequently detaching the service. DMIF creates an instance of DMIF RTSP augmented with QoS appropriate for each MPEG-4 stream and also makes use of the FlexMux to carry multiple streams on a single UDP or TCP IP flow. The stream control play/pause etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "Distribution: LDAP server transition to X.500", Alan Lloyd, 09/28/1998, This document defines chaining arguments that can be applied to any LDAP operation for distributed/chained server to server operations. This approach to distribution for LDAP systems, enables a consistent transition of the LDAP single server environments, to the full functionality of X.500 distributed directory systems. This proposal is supported by two other proposals previously submitted as and . These proposals require that LDAP V3 is evolved to LDAP V4. LDAP V4 will enable LDAP clients and servers that access and interwork with X.500 systems, to more readily use (and integrate with) the full distribution and replication services offered by X.500. In addition this approach will provide better compatability with the higher functionality afforded to X.500 DAP clients. (Although the commonly known information restrictions of LDAP string encoding may still apply). The Chaining controls proposed in this draft will be carried with the original LDAP access client controls as defined in in the standard LDAP V4 operations (Search, List, etc) when it is used for server - server communication. ie. chaining. "The RealName System: a Human Friendly Naming scheme", Larry Masinter, Nicolas Popp, 09/30/1998, The notion of a 'Human Friendly Naming scheme' (HFN) has been discussed in a variety of contexts, as an alternative to the use of URIs or URNs as a way of designating Internet resources (see [RFC 2276], for example). This document introduces the RealName system, and its use as a HFN. It provides a mapping for RealNames into a URN namespace ('rn') as well as a URL scheme ('vnd.rn'). This is a preliminary draft, intended to raise the discussion of HFNs and the uses of RealNames as an initial example in creating a standard for access and resolution. "IPSec Re-keying Issues", Tim Jenkins, 09/30/1998, For a number of reasons, re-keying in IPSec has become problematic, such that packets can get dropped by IPSec implementations during re-keying. Worse, there exists the possibility that IPSec implementations from different vendors may not be interoperable because of the way they re-key. The purpose of this paper is to propose methods of performing both phase 1 and phase 2 re-keying for IPSec implementations in such a way to to minimize packet loss and to maximize compatibility. "A Framework for IP Based Virtual Private Networks", Juha Heinanen, G. Armitage, B. Gleeson, 10/01/1998, This document describes a framework for virtual private networks (VPN) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this Draft is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions. "Using Digest Authentication as a SASL Mechanism", Chris Newman, P. Leach, 11/23/1998, This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. "Requirements for Human Friendly Identifiers", Michael Mealling, 10/02/1998, This document includes a set of requirements for an identifier that is engineered for human consumption. While the identifier is still machine consumable, the services and capabilities of the underlying system are designed with humans in mind. This includes concepts of geographic and context specific constraints, non-uniqueness, and natural language match semantics. "CPE based VPNs using MPLS", Tony Li, 10/05/1998, This document describes a proposed architecture for the construction of Virtual Private Networks (VPNs). This proposal differs from [1] and [2] in that the functionality of the VPN is shared by the Customer Premises Equipment (CPE). Multi-Protocol Label Switching (MPLS) is used as a tunneling mechanism across the ISP network. "Secret Handshakes: How to get RFCs published in the IETF", Scott Bradner, 10/13/1998, There is confusion over how to get an RFC published in the IETF. Recently a long time IETF participant asked me what 'secret handshake' was need to get documents published as RFCs since he had been trying unsuccessfully to get that done. This memo is the result of that query and describes the procedures required, gives the proper references and the required email addresses. "Publicly Verifiable Random Selection", Don Eastlake, 10/05/1998, This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. "Core IP VPN Architecture", Andy Malis, Karthik Muthukrishnan, 10/07/1998, This draft presents an approach for building core VPN services in the service provider backbone, as described in [Heinanen]. This approach does not depend on MPLS running in the backbone but will benefit from it. The central vision is for the service provider to provide a virtual router service to their customers. Ease of configuration, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications are the keystones of this architecture. "Atomic Certificates", Narayan Raghu, 10/07/1998, The existing PKI has a few inherent limitations like: 1. It is implicitly assumed that the two trading parties have ONE mutually trusted third party that can attest ALL of each party's attributes. It provides no mechanism to separate out the fields in a certificate for attestation by different Certification Authorities. 2. This standard in no way gives the flexibility to expose only certain fields of a certificate to the other party. This memo proposes a model which, while working well within the X.509v3 framework, overcomes these limitations by breaking up a certificate into pre-signed 'unit attestations' referred to as 'Atomic Certificates' and packaging them in the X.509v3 format only at the time of sending the certificate to the other party. "Light-weight Reliable Multicast Protocol Specification", Tie Liao, 10/08/1998, This document describes LRMP, the Light-weight Reliable Multicast Protocol. LRMP provides a minimum set of functions for end-to-end reliable network transport suitable for bulk data transfer to multiple receivers. LRMP is designed to work in heterogeneous network environments and support multiple data senders. A totally distributed control scheme is used for error recovery so that no prior configuration and no router support are required. LRMP also includes a selective feedback mechanism allowing to monitor the quality of service at receivers. In LRMP, flow and congestion control is performed based on NACK packets and congestion indication from receivers. Forward error correction is supported as an independent optional module. "H.323 Signaling and SS7 ISUP Gateway: Procedure Interworking", Gene Ma, 10/08/1998, This document describes protocol procedure interworking in designing signaling gateway between H.323 and SS7 ISUP, especially the procedure and message mapping between H.225/H.245 and SS7 ISUP. "Disconnecting TCP connection toward IPv6 anycast address", Jun-ichiro Itoh, 10/09/1998, IPv6 specification implicitly disallows TCP connection toward IPv6 anycast address. However, if such a connection request happens by mistake, currently there is no way to report the incident to the originator of the TCP connection. The document tries to define a way to disconnect TCP connections made toward IPv6 anycast addresses. "Applicability of GSMP as an IETF Protocol", Avri Doria, Kenneth Sundell, Tom Worster, 10/13/1998, This memo discusses the applicability of the General Switch Management Protocol, GSMP, to network control protocols such as Multiprotocol Label Switching (MPLS). It discusses the need for this protocol to be standardized and discusses areas where development is still necessary. Finally, it recommends that the IETF establish a working group with the objective of furthering the protocol and working toward making it a standard. A PDF version of this draft can be found at: http://www. apocalypse.org/~avri/papers/draft-doria-gsmp-applicability-00.pdf "IS-IS Optimized Multipath (ISIS-OMP)", Tony Li, Curtis Villamizar, 10/13/1998, IS--IS may form multiple equal cost paths between points. This is true of any link state protocol. In the absence of any explicit sup- port to take advantage of this, a path may be chosen arbitrarily. Techniques have been utilized to divide traffic somewhat evenly among the available paths. These techniques have been referred to as Equal Cost Multipath (ECMP). An unequal division of traffic among the avail- able paths is generally preferable. Routers generally have no knowl- edge of traffic loading on distant links and therefore have no basis to optimize the allocation of traffic. Optimized Mulitpath is a extension to IS--IS, utilizing additional Type/Length/Value (TLV) tuples to distribute loading information. An algorithm to adjust forwarding, gradually enough to insure stability yet provide reasonably fast adjustment when needed, is provided in the related document OSPF--OMP [5]. The IS--IS encapsulation and minor differences in the dynamics of ISIS--OMP relative to OSPF--OMP are described here. "IVR control", Simon Tsang, Jerome Privat, 10/14/1998, This document describes IVR (Interactive Voice Response Unit) control. It is intended as an input for the device control interface defined by the IETF. "PAX PDL - a non-procedural packet description language", Misha Nossik, Michael Richardson, Feliks Welfeld, 10/19/1998, This document describes PAX Pattern Description Language (PDL). PAX is a special purpose language for definitions of filters (recognizers) for sequential inputs. The language is suitable for describing pattern matching criteria in policy-based networking devices such as QoS routers and switches, packet filters, RMON probes, traffic shapers, etc. It pro- vides consistent means of programming policy-based networking devices based on different hardware and software platforms. Programs written in PAX can be built incrementally, where elementary patterns can be used as building blocks for more complex ones. The language encourages modular and object-oriented design. "Generic Architecture for Information Availability", Mikhail Blinov, Mikhail Bessonov, Ciaran Clissmann, 10/20/1998, This memo introduces a domain and supplier independent generic architecture for the information brokerage, designed as a part of the ACTS project GAIA (Generic Architecture for Information Availability). "HTML REFRESH LANGUAGE (HTMLR/1.0)", Ross Nelson, 10/21/1998, This document describes HTML REFRESH, an EXPERIMENTAL language and protocol for refreshing HTML pages and allowing serious thin-client/server applications via HTTP [RFC2068]. "The Use of the Internet Print Protocol [IPP] as a Facsimile Service [FAX]", Richard Shockey, 11/12/1998, This memorandum discusses the use of the Internet Print Protocol [IPP] as a facsimile service. IPP has most of the functional attributes necessary to be a successful real time facsimile service on the Internet with little or no modification to the core IPP V 1.0 protocols [IPP-MOD] [IPP-PRO]. IPP compliance with the legal and general custom and practice surrounding General Switched Telephone Network [FAX] will require some modification to the behavior of IPP clients and the common usage of time/date stamping on local IPP device transactions and logs. "Media Gateway Control Protocol (MGCP)", Christian Huitema, Mauricio Arango, Isaac Elliott, Andrew Dugan, Scott Pickett, 11/10/1998, This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gate- ways from external call control elements. The MGCP assumes a call con- trol architecture where the call control 'intelligence' is outside the gateways and handled by external call control elements. "Management Information Base for IS-IS", Jeff Parker, 10/28/1998, This document describes a management information base for the IS-IS Routing protocol, as described in RFC 1142 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [3]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on a draft revision of an IETF MIB dated September 1992 and titled 'Integrated IS-IS Management Information Base'. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. "LDP State Machine", Liwen Wu, Pierrick Cheval, Christophe Boscher, 11/02/1998, In the current LDP draft [Ref5], there is no state machine specified for processing the hop-by-hop routed LDP messages. We think that defining a common state machine is very important for interoperability between different ldp implementations. This draft provides state machine tables for ATM switch LSRs. We begin in section 2 by defining a list of terminologies. Then in section 3, we propose the state machine tables for ATM switch LSRs. Finally, in section 4, we outline the possible future working items. Even though the state machines in this document are specific for ATM-LSR, they can be easily adapted for other types of LSRs. "Neda's Efficient Mail Submission and Delivery (EMSD)", M. Banan, 11/02/1998, This document specifies the protocol and format encodings for Efficient Mail Submission and Delivery (EMSD). EMSD is a messaging protocol that is highly optimized for submission and delivery of short Internet mail messages. EMSD is designed to be a companion to existing Internet mail protocols. This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. EMSD is designed specifically with wireless network (e.g., CDPD, Wireless-IP, Mobile-IP) usage in mind. EMSD is designed to be a natural enhancement to the mainstream of Internet mail protocols when efficiency in mail submission and mail delivery are important. As such, EMSD is anticipated to become an initial basis for convergence of Internet Mail and IP-based Two-Way Paging. The reliability requirement for message submission and message delivery in EMSD are the same as existing email protocols. EMSD protocol accomplishes reliable connectionless mail submission and delivery services on top of Efficient Short Remote Operations (ESRO) protocols as specified in RFC-2188 [1]. Most existing Internet mail protocols are not efficient. Most existing Internet mail protocols are designed with simplicity and continuity with SMTP traditions as two primary requirements. EMSD is designed with efficiency as a primary requirement. The early use of EMSD in the wireless environment is manifested as IP-based Two-Way Paging services. The efficiency of this protocol also presents significant benefits for large centrally operated Internet mail service providers. "T/UDP: UDP for TCAP", Gene Ma, 11/02/1998, This document proposes the T/UDP, UDP for TCAP, which uses Internet protocols UDP and ICMP, plus part of SS7 SCCP, to provide network services for SS7 TCAP in IP network. "Shared Registry System Protocol (SRSP)", Kent Crispin, 11/02/1998, This specification describes a protocol for a Shared Registry System (SRS) that allows multiple registrars to register domain names within a single Top Level Domain (TLD). The protocol is high-level, text-based, and can be used over many underlying transport mechanisms, including email. The semantic content of the protocol is expressed as a set of keyword-value pairs; the semantics and structure of this content is, in this document, loosely described as the 'payload'. The protocol described herein is essentially identical to the SRS version 1.5 protocol, specified by the CORE SRS RFP and developed by Curt Meyer of Emergent Corporation. "The 'eid' URL Scheme", C. Finseth, 11/03/1998, This document defines a new URL scheme, 'eid'. This scheme provides a mechanism by which the local application can reference data that has been obtained by other, non-URL scheme means. The scheme is intended to provide a general escape mechanism to allow access to information for applications that are too specialized to justify their own schemas. "DIAMETER Reliable Transport Extensions", Allan Rubens, Pat Calhoun, 11/03/1998, Many services that require DIAMETER need retransmission and timeout faster than TCP can provide. An example would be in a NAS environment where DIAMETER is used for the authentication and authorization of users. The amount of time that it takes for TCP to determine that a connection to a server is broken is longer than the disonnect timeout of the PPP clients on whose behalf the server is being contacted. RADIUS has been able to handle this situation by operating over UDP. However, RADIUS fails to define a standard retransmission and timeout scheme, which has resulted in many different methods across implementations. This DIAMETER specification defines the extensions necessary for the base protocol to operate over a non-reliable transport (e.g. UDP). "Route Reflection Considered Harmful", J. Scudder, Rohit Dube, 11/04/1998, Route reflection as defined by [2] is a popular way of reducing the full-mesh IBGP peering required by routers running the Border Gateway Protocol [1]. There are cases where a topology built using route reflectors produces persistent loops or does not produce the same results as what one would expect with a full IBGP mesh. This document describes these problems. "Tree-based Reliable Multicast (TRAM)", Miriam Kadansky, Joe Wesley, Dah Ming Chiu, 11/04/1998, This paper describes TRAM, a scalable reliable multicast transport protocol. TRAM is designed to support bulk data transfer from a single sender to many receivers. A dynamically formed repair tree provides local error recovery allowing the multicast group to support a large number of receivers. TRAM provides flow control, congestion control, and other adaptive techniques necessary to operate efficiently with other protocols. Several bulk data applications have been implemented with TRAM. TRAM has been tested and simulated in a number of network environments. "Scoped Address Discovery Protocol (SADP)", Roger Kermode, 11/05/1998, This document defines a protocol, the Scoped Address Discovery Protocol (SADP), for discovering the scoped multicast address(es) associated with a session at particular scopes within a hierarchically nested set of multicast zones. SADP is designed to work within the context of Multicast Address Allocation Architecture [MAAA] consisting of the MZAP [MZAP], MASC [MASC], and AAP [AAP] protocols. It is intended that SADP will provide the necessary general services for reliable multicast and searching applications to use expanding-zone searches in lieu of the well known, but less efficient expanding-ring search. "Requirements For Control Of A Media Services Function", Michael Durling, David Cromwell, 11/06/1998, This document describes the functional requirements for protocol used by a call processing agent in a packet network to control an media services function located in the same packet network or at the inter- face of the packet network and the traditional telephone network. The primary focus of the protocol is on audio, however the protocol could be extended in the future to support other media streams such as video. The protocol provides the standard audio operations of play audio, collect DTMF, and record speech. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides multi-language audio variables, interruptibility of audio, digit buffer control, special key sequences, and support for reprompting during data collection. The approach used in specifying protocol functionality was to look at several existing protocols currently in use in the telephone network, taking the best concepts from each and attempting to avoid any limi- tations. The following protocols were examined: ITU CS1-R [2], Nor- tel Extended CS1-R [3], Bellcore GR-1129 [4], and Bellcore SR-3511 [5]. The protocol described in this document provides at a minimum a superset of the functionality of these protocols. "Dynamic RT/NRT PHB Group", K. Kilkki, Mika Loukola, Jussi Ruutu, 11/09/1998, This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Dynamic RT/NRT (DRT) PHB Group. This PHB Group provides delivery of real-time and non-real- time IP traffic. DRT introduces two independently forwarded classes: a real-time (RT) class, and a non-real-time (NRT) class. Within each class an IP packet can be assigned one of six different levels of drop precedence. These levels have a relative order so that a single service (RT / NRT) is formed inside which the packet loss of lower levels does not have any significant effect on upper levels. This concept introduces dynamic RT and NRT services that allow the user to dynamically adjust the packet loss probability in response to the varying network load. A DS node does not re-order IP packets of the same microflow if they belong to the same DRT class. Recommended codepoints for this PHB Group are given. "An Architecture for Supporting Human Friendly Identifiers", Michael Mealling, 11/09/1998, This document describes an architecture that satisfies the requirements for Human Friendly Identifiers as specified in [HFI-REQ]. Specifically it describes the URI scheme 'go' as an HFI encoding mechanism, a protocol for the resolution of HFIs, and a scalable and open infrastructure for resolving those HFIs. "A Multihoming solution using NATs", Y Rekhter, Praveen Akkiraju, 11/10/1998, Multihoming to upstream ISPs is a requirement today for most networks in the Internet. The most common motivation to multihome is for reliable, non-stop access to the Internet. However, Multihoming creates scaling problems for the global routing infrastructure by making route aggregation more difficult for multihomed networks. Multihoming also complicates the addressing scheme used by the network. Another requirement for multihomed networks is the ability to load balance traffic between the multiple links to upstream ISPs. This requirement is difficult to fulfill for traffic flow in both directions as the multihomed network has no control over the return path of the packet. "BGP/MPLS VPNs", Y Rekhter, E. Rosen, 11/11/1998, This document describes a method by which a Service Provider with an IP backbone may provide VPNs for its customers. MPLS is used for forwarding packets over the backbone, and BGP is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. With a few modifications, these techniques can also be used to provide a VPN which itself provides IP service to customers. "Media Gateway Control Protocol (SGCP) Call Flows", Christian Huitema, Mauricio Arango, Flemming Andreasen, 11/11/1998, The Media Gateway Control Protocol (MGCP) organizes the communication between a Media Gateway controller, or call agent, and a Media Gateway, e.g. a Voice over IP gateway or a Network Access Server. MGCP is defined in a companion document [1]. This document provides example of MGCP usage by providing a variety of call flows, in the case of telephony and network access servers. "Security Considerations for Mobility and Firewalls", Jim Binkley, John Richardson, 11/11/1998, In this paper we discuss various security issues concerning Mobile Hosts using Mobile-IP or other mobility systems (DHCP standalone) and current firewall technology. We first present some recent attacks on the Internet and what they might mean for mobile systems like Mobile-IP that rely on tunneling technologies. We point out that tunnels are a security threat and suggest how mobile systems may be made 'less insecure' with the use of IP layer security (IPSEC) as one means for creating Virtual Private Networks. The goal is to describe a security model wherein mobile systems can work across the Internet and not just as an interior routing protocol within one security and/or interior routing domain. Both the protection of Mobile Systems abroad and of Security Enclaves that tolerate mobile visitors must be considered. "Diffie-Hellman Signing Algorithm", H. Prafullchandra, Jim Schaad, 11/12/1998, This document describes a method for producing a signature from a Diffie-Hellman key pair. This behavior is needed for such operations as creating a signature of a PKCS #10 certification request. This document describes two different flavors of the signature algorithm, one using a D-H key from a CA and the other using a temporary key created by the signer. "UTF-16, an encoding of ISO 10646", Paul Hoffman, F. Yergeau, 11/12/1998, This document specifies the UTF-16 encoding of Unicode/ISO-10646 and contains the registration for three MIME charset parameter values: UTF-16BE, UTF-16LE, and UTF-16. "Registration for the 'widetext' Media Type", Paul Hoffman, 11/12/1998, This document defines a new MIME top-level media type, 'widetext', which can be used to carry text that is in the UTF-16 character encoding scheme. The use of the 'widetext' media type is limited to text-like MIME bodies that cannot be represented in the 'text' media type. "A Performance Oriented Service Interface for Virtual Private Networks", K.K. Ramakrishnan, Partho Mishra, Alan Greenberg, Naganand Doraswamy, Nick Duffield, Shantigram Jagannath, Pawan Goyal, Kobus van der Merwe, 11/12/1998, This document presents a quality of service (QoS) framework for IP based virtual private networks (VPNs). For IP based VPNs to provide a service comparable to private line networks it has to provide a number of features including closed user groups, security and performance guarantees. This document focuses primarily on the issue of performance, and provide a QoS framework which is applicable to various VPN solution that have been proposed. "RTSP-based Stream Control in MPEG-4", Paul Christ, Christine Guillemot, Stefan Wesner, 11/16/1998, In order to support advanced interactivity as envisaged for MPEG-4 applications, this document proposes a simple RTSP- based [1] streams control framework - including necessary extensions to RTP methods syntax and semantics. Reflecting syntax and semantics of the MPEG-4 BIFS scene description [2], VRML nodes [4] and the MPEG-4 media delivery framework (DMIF)[3], in the spirit of HTMLSMIL [5], Random Access Point information, Range and Time parameters are introduced into the relevant URL(s) and related signaling methods accordingly. Two additional optional methods, R-MUTE, for Remote-MUTE, and RESUME are also proposed. "Partitioning Label Space among Multicast Routers on a Common Subnet", D. Farinacci, Y Rekhter, 11/16/1998, There are 3 major functions that must be performed to achieve multicast Label Switching. 1) Label Allocation, which requires each multicast Label Switching Router (LSR) to have a label value range that it uses. 2) Label Binding, using the labels allocated, a LSR must assign them to multicast routes. 3) Label Binding Distribution, after binding label values to routes, they must be distributed to other LSRs so they all forward on a common and consistent distribution tree. In this document we present how labels are allocated uniquely across multicast capable LSRs on a LAN and point-to-point IP subnets. "A SOCKS-based IPv6/IPv4 Translator Architecture", Hiroshi Kitamura, 11/16/1998, This document describes an IPv6/IPv4 Translator architecture that is based on the SOCKSv5 [RFC1928] mechanism. In this architecture, the SOCKS mechanism is extended by adding adaptive address family distinguish functions for supporting heterogeneous communications. By applying the mechanism together with protocol conversion functions, the IPv6/IPv4 Translator architecture is accomplished. This Translator provides communications between IPv6 and IPv4 nodes without sacrificing any convenience and functionalities of current communication methods. It is NOT necessary to modify the current DNS system at all. Only socksify environment is needed to communicate between IPv6 and IPv4 nodes. By using multiple chained Translators, a tunneling-like communication topology can be realized. With the architecture, there is no vulnerability of the packet fragmentation, and the connection can be authenticated by the native SOCKS authentication methods. "Regional Aware Foreign Agent (RAFA) for Fast Local Handoffs", K. Chua, S. Foo, 11/16/1998, This document proposes an extension to the Mobile IP base protocol. The purpose of this extension is to solve the distant registrations, handoff latency, and key management problems among mobility agents. It provides a easy and robust solution for secure ubiquitous deployment of IP mobility while still maintaining interoperability with the base protocol. "E.164 Resolution", Anne Brown, 11/16/1998, This paper addresses global access to address information and additional subscriber and equipment information, given a telephone number as input. "SMTP Service Extension for Command Pipelining",, 11/16/1998, This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. The present document is an updated version of RFC 2197 [5], which in turn was a revision of RFC 1854 [2]. Only textual and editorial changes have been made; the protocol has not changed in any way. "Sieve -- IMAP flag Extension", Alexey Melnikov, 11/16/1998, Recent discussions have shown that it was desirable to set different [IMAP] flags on message delivery. This can be done, for example, by SIEVE interpreter that works as a part of Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. "IP Multicast Applications: Challenges and Solutions", Bob Quinn, 11/16/1998, This document highlights the challenges of creating multicast applications, and describes the solutions available or under development. It provides a taxonomy of multicast applications in terms of their requirements, and discusses some existing multicast- based protocols. Many of the solutions--especially in the areas of reliable multicast data delivery, congestion control, and security-- have not yet emerged from the research realms. We describe the general state of on-going research in these areas, highlighting the strategies under investigation. "Aggregation of Internet Integrated Services State using Parameter-based Admission Control", Marc Greis, Markus Albrecht, 11/16/1998, Aggregation has been proposed as one possible solution to the scalability problem of the Internet Integrated Services. The current suggestions for aggregation are based on measurement-based admission control, which allows for the omission of RSVP soft state in the interior routers of an aggregating domain. However, measurement-based admission control has certain flaws which may lead to over-reservations on links in the network under certain conditions. This can result in packet losses for reserved traffic. Hence, we believe that it will be necessary to discuss the possibility of using parameter-based admission control with aggregation. In this document, we present a technique for using parameter-based admission control with aggregation as a basis for further discussions, and we evaluate possible advantages and disadvantages. "Service Requirements for Internet Telephony Signaling and Device Control Protocols", Henry Sinnreich, Francois Menard, 11/16/1998, This memorandum discusses the requirements for telephony signaling and device control over the Internet from the perspective of meeting the needs of Internet service providers (ISPs) and telecom carriers wishing to provide Internet services that include telephony. The requirements apply equally to various Internet telephony and non-Internet telephony devices. For the purpose of this Internet draft, the notion of telephony is broadened to include control of other types of streaming media sessions, such as RTSP based media server device control. Rather than severely restricting the device control framework to a particular set of devices, such as IP telephony gateways and telephony network access servers, this Internet draft presents requirements that are broad enough to satisfy the needs of any device that is expected to provide telephony and related services on the Internet. "RTP Generic Payload with Scaleable & Flexible Error Resiliency", Paul Christ, Christine Guillemot, Stefan Wesner, 11/16/1998, This document describes a payload, generic in the sense of useable and unique for both audio, video and scene description streams. Relying on a simple, yet sufficient, fragmentation and grouping mechanism, the proposed payload allows for protection against packet loss, with a mechanism intended to be generic. This mechanism allows to avoid extra connection management complexity - for separate FEC channels - in high-number-of-streams applications. It allows the support of a hierarchy of error control mechanisms ('no', FEC, redundant data, to network characteristics. "Common Gateway Interface for SIP", Jonathan Rosenberg, H. Schulzrinne, Jonathan Lennox, 11/16/1998, In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI seems a good candidate for service creation in a SIP environment. This draft proposes a SIP-CGI interface for providing SIP services on a SIP server. "SIP For Presence", Jonathan Rosenberg, H. Schulzrinne, 11/16/1998, We describe an extension to SIP for subscription, notification, fetching, and indication of presence events. The extensions consist of two new methods, SUBSCRIBE and NOTIFY. "Mail Monitoring MIB",, 11/16/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC XXXX [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. "IEEE 1394 Asynchronous Streams", Peter Johansson, 11/17/1998, This document proposes modifications to some of the packet formats defined by Internet-Draft draft-ietf-ip1394-ipv4-11, specifically those intended for transport by asynchronous stream packets. "Logical addressing and routing for multicasting(LAR)", Jean-Jacques Pansiot, Dominique Grad, Thomas Noel, Abdelghani Alloui, 11/17/1998, This document describes an architecture based on two levels of addressing. A logical addressing level is used to identify logical objects independently of their current IP address, such as multicast groups or mobile hosts. This schema is then used to define in a unified way mechanisms for inter-domain multicasting and mobility. "TCP Performance Enhancing Proxy Terminology", Jim Griner, 11/17/1998, This document presents definitions for many terms to be used during the discussion of various TCP Performance Enhancing Proxies (PEP). A PEP, located between two end-systems, is used to, in some way, enhance a TCP connection. PEP's are commonly referred to as spoofing, connection splitting gateways, etc. "Bulk File MIB", Bob Stewart, 11/17/1998, This memo defines an enterprise 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 the creation of files containing MIB objects. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. "A Syntax For The MGCP Audio Package", David Cromwell, 11/17/1998, The MGCP protocol describes a protocol for controlling a VOIP (Voice Over IP) gateway from an external call agent. The protocol defines a number of event packages, each of which defines a group of events supporting a particular type of gateway functionality. For example, there is a package for MF trunks, one for DTMF, and one for RTP. A gateway may support one or more packages depending on the functional- ity it provides. A Residential Gateway might support the Generic Media, DTMF, Line, and RTP packages while an MF Trunk Gateway could support the Generic Media, MF, DTMF, MF Trunk, and RTP packages. This document proposes a set of IVR-related events that constitute an MGCP Announcement Package for use by an Announcement Server Gateway. This event package provides support for the standard IVR operations of Play Announcement, Play Collect, and Play Record. It supports direct references to simple audio as well as indirect references to simple and complex audio. It also provides multi-language audio vari- ables, control of audio interruptibility, digit buffer control, spe- cial key sequences, and support for reprompting during data collec- tion. "Amendments to the Assured Forwarding PHB Group", Victor Firoiu, Alessio Casati, 11/18/1998, This note was motivated by the ongoing discussion in the Differentiated Services Working Group regarding the definition of the Assured Forwarding (AF) Per-Hop Behavior (PHB) Group. We consider two issues with the current proposal for AF PHB Group in [Heinanen]: the recommendation for AF discard mechanism, and the definition of AF classes. We discuss the implications of the definitions and recommendations that have raised comments and propose alternative texts. "TLSMUX - Multiplexed TLS for uniform encrypted access to local services", Clinton Wong, 11/17/1998, This document describes a multiplexing protocol that allows remote machines to access local services in a secure manner. All clients must connect to the multiplexer using TLS, allowing encrypted network communications to normally cleartext protocols. TLSMUX is an application level protocol that does not require a kernel upgrade or extensions to existing protocols in order to operate. By offering a TLS connection to a multiplexer, current servers and protocols do not need to be modified to benefit from the encryption features of TLSMUX. Some clients may need to be updated to support TLSMUX, although it is possible for some clients to use a TLSMUX proxy without modification. "FTP Client MIB", Bob Stewart, 11/17/1998, This memo defines an enterprise 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 the transfer of files as an FTP client. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. "Media Gateway Architecture: A Functional Model of the Media Gateway", Fernando Cuervo, Graeme Gibbs, 11/18/1998, This document presents a functional model of a Media Gateway. The model extends the functional model of the base architecture draft[1]. The model identifies the functions that the MG may expose to other functions of the architecture, namely, the Media Gateway Controller and the Signalling Gateway [1]. The objective of the model is to identify completeness of the protocol functions, flexibility to handle the optionality of functions and ensure that the protocol is not biased towards a particular implementation of the Media Gateway. "A Bounded-delay service for the internet", Alan O''''''''Neill, Simon Carter, Terry Hodgkinson, David Mortimore, 11/18/1998, This document outlines a proposed new service class for the internet which is intended to provide for some small proportion of the total traffic on each link, a quantifiable, low-delay service having essentially no packet-loss. We call this proposed service, Bounded- delay (BD). The approach is consistent with the architecture and philosophy of diff-serv, and could potentially make use of the proposed EF PHB. BD is similar in many respects to Premium service which has been described previously [Twobit], except that BD is intended specifically to allow control of end-to-end delay in a quantifiable manner. "Requirements TV Broadcast URI Schemes", C. Finseth, Warner ten Kate, Gomer Thomas, 11/18/1998, This document lists the requirements posed to URI schemes for use in TV Broadcast environments. The document summarizes the outcome of discussions on this subject by the W3C TV-Web Interest Group [1]. "PPP Internet Protocol Control Protocol Extensions for IP Subnet", Juha Heinanen, A. Lin, David Allan, Paul Shieh, 11/18/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2] by defining an IP Subnet configuration option. "RSVP Killer Reservations", Mohit Talwar, 11/18/1998, This document describes the Killer Reservation Problem encountered when merging RSVP reservation requests. These requests get merged as they travel up the multicast distribution tree, losing information about individual requests. A request, which would have succeeded on its own, may suffer denial of service when the 'merged request' fails admission control. This is the problem for which we present different solutions. "An extended IP VPN Architecture", Liam Casey, 11/18/1998, This Internet Draft extends the framework for IP VPN's, as, for example, described by Heinanen et al.[1] and Gleeson et al [2], to include the concept of VPN Areas. VPN areas relate to the scoping of the mechanisms (membership dissemination, tunneling etc.) used to provide IP VPN service. VPN areas are a partitioning of the shared service provider's network. In general, all sites within a VPN area are one tunneled hop from each other, but multiple tunneled hops will be required for traffic between sites served by different VPN areas. Two reasons why Service Providers might partition their IP network into areas in support of VPN's are to achieve scalability, and to match administrative domain. VPN areas also facilitate the use of different IP VPN mechanisms in different parts of the network. There are multiple proposals for tunnel technology and discovery mechanisms for IP VPN's. The VPN area concept allows them to co-exist in one provider's network as well as smoothing migration to new mechanisms. This draft also examines the impact that VPN areas have on the IP VPN framework mechanisms described in [2]. The conclusion reached is that the best mechanism for intra-VPN reachability dissemination is a full routing protocol run by Virtual Routers. "RSVP Support for Mobile IP Version 6 in Wireless Environments", George Fankhauser, Stathes Hadjiefthymiades, Neda Nikaein, Lorraine Stacey, 11/18/1998, This draft describes a specific problem encountered when using RSVP (Resource Reservation Protocol) over optimised routes in MIPv6 (Mobile IP Version 6). The address translation in the MIP's binding cache creates a mismatch between the flow-id of the packets sent from correspondent node to mobile node and the flow-id signalled by RSVP. We discuss several solutions to this problem: (1) By modifying RSVP at mobile and correspondent nodes to become aware of MIPv6 address- ing, we provide a simple repair that allows RSVP flows to be esta- blished between the fixed network and mobiles; (2a) By adding optional objects to RSVP messages, a performance enhancement is pro- posed to make handovers smooth and seamless; (2b) A different tech- nique with the same goal is called flow extension and it provides flows with fixed flow-ids from the correspondent node into the wire- less access network at the expense of forwarding traffic inside the access network, whenever the mobile node moves. We conclude that the minimal solution (1) is a requirement in order to make MIPv6 and RSVP interoperable; our favored approach requires only minor changes to the correspondent and mobile node's RSVP and MIP specification. However, for well performing and uninterrupted operation we strongly recommend one of the solutions (2a or 2b) that support fast re-establishment or preservation of resource reserva- tions when mobile nodes move. "IP VPN Realization using MPLS Tunnels", Robert Eros, Liam Casey, Ian Cunningham, 11/18/1998, This Internet Draft describes a method of using MPLS to realize a provider IP VPN capability. The approach described here exploits the Label Switch Path (LSP) mesh implicitly established between all edge routers in an MPLS domain [4]. It uses 2 levels of LSP tunneling. The outer or base level is the hop by hop LSP tunnels that interconnect all VPN Border (Label Switch) Routers (VBR\022s). The 'bottom of label stack', nested level provides logically single hop tunnels between VBR\022s. For each IP VPN, single hop nested tunnels are established between all VBR's serving that particular VPN. The draft outlines the components involved in the MPLS IP VPN architecture and outlines how they interact. The proposed realization is caste in terms of the VPN areas introduced in [1] and is geared to take advantage of a virtual router (VR) capability in the VBR's. This results in a powerful and flexible method of providing an IP VPN service that meets the requirements outlined in [3]. Also described are two extensions: offering MPLS VPN service to the customer (rather than IP service) and using Label Switching to traverse VPN areas[1]. "The iCalendar XML DTD", F. Dawson, 11/18/1998, This memo defines a [XML] Document Type Definition (DTD) that corresponds to the iCalendar, calendaring and scheduling core object format defined by [RFC2445]. This DTD provides equivalent functionality to the standard format defined by [RFC2445]. Documents structured in accordance with this DTD may also be know as 'XML iCalendar' documents. The mailing list for discussion of this memo is 'ietf- calendar@imc.org'. Send an email to ' ietf-calendar-request@imc.org' with the message 'SUBSCRIBE' to add your email address to this mailing list. Send an email to ' ietf-vcard-xml-request@imc.org' with the message 'UNSUBSCRIBE' to remove your email address from this mailing list. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' and 'OPTIONAL' in this document are to be interpreted as described in [RFC 2119]. "On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks", Mario Gerla, Guangyu Pei, Sung-Ju Lee, Ching-Chuang Chiang, 11/18/1998, On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing protocol designed for ad-hoc networks with mobile hosts. ODMRP is a mesh-based, rather than a conventional tree-based, multicast scheme and uses a Forwarding Group concept (only a subset of nodes forwards the multicast packets via scoped flooding). It applies on-demand procedures to dynamically set up routes and maintain multicast group membership. ODMRP is well suited for ad-hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and rapidly, and power is constrained. "A Functional Description of a SIP-PSTN Gateway", Matthew Cannon, Steve Donovan, 11/18/1998, This document describes a functional model of a gateway between the Public Switched Telephony Network (PSTN) and a SIP-based IP network providing telephony service. In this document, the SIP-based IP network will be referred to as Telephony over IP Service (TIPS). The primary function of the gateway is to handle connections involving one or more PSTN phones (i.e.; PSTN black phones) as if those PSTN phones are SIP clients. The goal of this approach is to ensure that SIP-based TIPS service logic applies to both native Internet- based SIP clients and PSTN phones without modification. "Mobile Service Discovery Over Wireless Links", Jastinder Jawanda, 11/18/1998, In this document, a concept of main directory agent (MDA) is introduced. The main directory agent utilizes conjoined operations of Mobile IP and SLP including new proposed extensions. The MDA expedites service & location discovery process for mobile hosts and provides local system administrators with control over the usage of deployed services. It provides a mechanism for local system administrators to enforce local policies for the allocation of local access resources when desired. The MDA based service discovery by mobile hosts is particularly effective in the case of wireless networks. Wireless links have substantially lower bandwidth, suffer from higher error rates and need to support higher mobility of hosts/data terminals compared to wired links (e.g. LAN). Thus, to disseminate any information to mobile hosts over the wireless links the multicasting or broadcasting paradigm should be used sparingly. In view of this, optional extensions to Mobile IP and SLP protocol are recommended and discussed in this document. Again, the intent is to make the overall service discovery process expeditious and effective for mobile hosts. "Scenarios for an Internet-Scale Event Notification Service (ISENS)", R. Khare, Adam Rifkin, 11/18/1998, This document's goal is to organize the discussion of a potential 'Internet Scale Event Notification Service' (ISENS) working group effort by defining a model of Event Notification Service (ENS), identifying a taxonomy of design choices and their tradeoffs, sketching some usage scenarios, and briefly evaluating a host of candidate solutions, old and new. [NOTE: this edition is largely unchanged from an August 13th, 1998 draft presented at the Chicago NOTIFY BOF.] "Problem Statement, Requirements, and Solution Outline", Bill Janssen, H. Nielsen, Jim Gettys, Mike Spreitzer, 11/18/1998, This document gives the authors' opinion of a rough outline of (1) the problems to be addressed by the proposed IETF HTTP-NG Working Group; (2) the requirements on the solution; and (3) the architecture of the solution. It draws heavily on contributions from the whole Protocol Design Group of the W3C HTTP-NG Activity. A suite of problems should be addressed, summarized as observing that the World Wide Web's tremendous success has created some strains on the Internet, its users, and its application developers. The requirements on the solution include modularity, extensibility, scalability, and efficiency. The proposed solution is to factor HTTP, the Web's central protocol, into three layers and look into performance improvements in the lower two of those resultant layers. "Simpler and More Secure Architectures for SNMPv3", D. Maughan, Stephen Borbash, Bill Freeman, 11/18/1998, This document presents simpler and more secure architectures for SNMPv3 agents than the ones specified in RFCs 2271-2275. Agent security is improved by restricting each module's access to data, using the 'principle of least privilege'. The new agent architectures are analyzed in terms of software complexity as well as security, and are shown in some respects to be simpler. "Optimizing TCP over Satellite ATM Networks", Raj Jain, Rohit Goyal, 11/19/1998, This document discusses techniques to improve the performance of TCP over satellite-ATM networks. ATM provides the ABR, UBR and GFR service categories for data traffic. TCP experiences poor performance over UBR due to bursty packet losses during congestion. Buffer management and guaranteed rate techniques to improve TCP performance over UBR are presented. The performance of TCP over ABR and the interaction of ABR congestion control mechanisms with TCP congestion control mechanisms are also described. This document is intended to be in informational document for the efficient transport of TCP over satellite-ATM networks. "Routing of Multimedia Connections when Interworking with PSTN, ATM, and IP Networks", Gerald Ash, Young Lee, 11/19/1998, This contribution presents the ongoing work in ITU-T SG2 Question 2/2 on Draft Recommendation E.MM 'Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks.' As an outcome of the November 1998 ITU-T SG2 meeting in Geneva, it was agreed to send a Liaison Statement with Draft Recommendation E.MM attached to the ATM Forum and IETF. The objectives of the liaison are to a) bring this ITU-T routing work to the attention of these other standards organizations, b) communicate ITU-T's understanding of the routing interworking issues involved between network types, such as path selection and quality of service resource management, c) gain information on the views of the other fora on these issues and identify any additional issues, and d) collaborate on developing the work and provide cross-communication as the work is progressed in each organization. In the contribution, the most effective routing functionalities employed within each network type are recommended for application across network types, to enable and ease interworking and include the following: a) the E.164/NSAP based numbering/addressing method applied successfully in PSTN and ATM networks, b) the automatic generation of routing tables based on network topology and status applied successfully in PSTN, ATM, and IP networks, c) the dynamic path selection methods applied successfully in PSTNs, d) the routing table design information exchange messaging applied successfully in PSTNs, e) the QoS resource management methods applied successfully in PSTNs, f) the automatic update and synchronization of topology database methods applied successfully in ATM and IP networks, g) the topology update information exchange messaging methods applied successfully in ATM and IP networks, and h) the connection control signaling methods applied successfully in ATM networks. The latter includes originating switch controlled (source) routing, specification of via and terminating "Requirements for the Reference Point ('N') between Media Gateway Controller and Media Gateway", Jozef Vandenameele, 11/19/1998, This Internet-Draft contains those excerpts of ETSI-TIPHON's work that focus on the reference point between Media Gateway Controller and Media Gateway (reference point 'N' in TIPHON parlance). ETSI-TIPHON is working on standards to connect VoIP (Voice over IP) networks and phone networks. PLEASE NOTE THAT THIS INPUT FROM TIPHON IS WORK IN PROGRESS. IT HAS BEEN APPROVED NEITHER ON THE TIPHON WORKING GROUP 2 LEVEL, NOR ON THE TIPHON PROJECT LEVEL. However, as input is always welcome, we are herewith submitting the current status of the discussion within TIPHON to the IETF. "Constraint-Based LSP Setup using LDP", Ross Callon, Andy Malis, Joel Halpern, Juha Heinanen, N. Feldman, Eric Gray, Kenneth Sundell, P. Doolan, Loa Andersson, A. Fredette, Pasi Vaananen, Tom Worster, Bilel Jamoussi, Liwen Wu, Muckai Girish, Timothy Kilty, Ram Dantu, 11/19/1998, Label Distribution Protocol (LDP) is defined in [LDP] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on an explicit route constraint, a Service Class (SC) constraint, or both. Constraint-based routing (CR) and Traffic Engineering requirements have been proposed by [FRAME], [ARCH] and [TER]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CRLSPs). Other uses exist for CRLSPs as well ([VPN1] and [VPN2]). This draft specifies mechanisms and TLVs for support of CRLSPs using LDP. The Explicit Route object and procedures are extracted from [ER]. "Internet Telephony Gateway Location Service Protocol", Ciprian Agapi, Chien-Hsiu Chiu, Thoong-Shin Chong, Harold Phillips, Brian Willingham, 11/19/1998, The development of IP to PSTN gateways has made it possible for users of the two disparate networks to place 'telephone' calls between the two networks with little effort. Users placing calls from an IP network to the PSTN network must choose a gateway to act as a bridge between the two networks. Selection of a gateway can be based on any number of criteria, such as price, codecs, version, billing, etc. In this draft we propose a gateway location service for this purpose. The gateway location service protocol is an instantiation of the Service Location Protocol that has been modified to run in a wide area network across many administrative domains. "Client-Cache Communication", Ingrid Melve, 11/19/1998, This document gives an overview of the current state of the art in web client proxy configuration. The two most common ways of configuring a client to use proxy are manual configuration and the semi-manual Automatic Proxy Configuration (PAC). Other proposals are briefly presented. Some information on HTTP and security is present, these issues are not fully documented in this draft. "Inter Cache Communication Protocols", Ingrid Melve, 11/19/1998, This document gives a brief overview of inter cache communication protocols and techniques for web proxy caches. ICP, WCCP, HTCP, CARP, Cache Digest are presented briefly, and a list of some other protocols and techniques is provided for background information. "Solicitation Extensions for BGP-4", Dwight Jamieson, Rong Wang, 11/19/1998, This document describes an extension to BGP-4 which may be used by a BGP-4 speaker to solicit Virtual Private Network (VPN) reachability information from other IBGP speakers. The motivation of the proposed technique is to provide a means of reducing the memory requirements of routers which use BGP-4 to distribute VPN reachability information as described in [1] and [4]. The extension is backward compatible in that a router which supports the extension can interoperate with a router which doesn't. "Performance Requirements for Signaling in Internet Telephony", Christian Huitema, Al Broscius, Huai-An Lin, Taruni Seth, 11/19/1998, To allow interoperability between the existing telephone network and Internet Telephony (IT) it is necessary for the signaling performance to be comparable to that of the current standards to avoid introducing degradation in the service. In this Internet Draft, we highlight the problem of providing high-quality signaling across an IP network that is built on a SONET infrastructure. We show that there are cases where the current PSTN standards are not satisfiable by a naive mapping of the IT signaling directly to the UDP or TCP transport protocols, even neglect- ing packet loss in router queues. "Capability Card: An Attribute Certificate in XML", Koji Otani, Hiroyasu Sugano, Madoka Mitsuoka, 11/19/1998, This document describes basic ideas and data components of 'Capability Card,' which is a kind of attribute certificates designed from the standpoint of a secure communication framework on the Internet. Similar to the SPKI certificates, a capability card can be used to grant a person particular access privileges to resources like WWW pages, IRC channels, and message boxes. In addition, it can carry a variety of descriptive information about the issuer, the resources, and the privileges specified in it. A capability card is written in XML, which is becoming a standard format rapidly for the internet data exchange. Consequently, users can handle various information in capability cards visually with an XML viewer. This is a fairly desirable feature for the existing internet services. In this document, following the motivation and the basic concepts, the elements of XML DTD of capability cards are described. "SOCKS64: An IPv4-IPv6 intercommunication gateway using SOCKS5 protocol", Akira Jinzaki, Shinji Kobayashi, 11/19/1998, This memo describes an IPv4-IPv6 intercommunication method based on the SOCKS5 protocol. The method is called SOCKS64, and was first announced in the 40th IETF meeting at Washington DC in December 1997 as one of three translators being developed in the WIDE Project. SOCKS64 is a gateway system that accepts SOCKS5 connections from IPv4 hosts and relays it to IPv4/IPv6 hosts using proper protocols. We have designed and implemented a prototype SOCKS64 system and have been testing the prototype in many environments. Also we are distributing the prototype as a KAME distribution package. This article describes the SOCKS64; its principle, implementation, experimental results and comparison to other IPv4-IPv6 intercommunication methods. "Transport SS7 Signalling Over IP", Michael McGrew, 11/19/1998, This document proposes the transport of SS7 signalling messages over IP in a way that utilizes the existing SS7 network (MTP and SCCP) layers to ensure 'carrier class' service as expected by existing users of SS7. The transport of SS7 user information could use TCP connections or UDP. The SS7 signalling messages would include ISUP or SCCP or, if the network services are not needed, could include only TCAP. Work should begin to define the necessary adaptation layers to make these transport methods possible. "DateAndTime Extension for the MIB-2 system Group", J. Schoenwaelder, 11/19/1998, This memo defines an extension of the Management Information Base (MIB) for Version 2 of the Simple Network Management Protocol (SNMPv2) as published in RFC 1907. In particular, it defines an object which allows to read and modify the notion of wall clock time accessible by an SNMP agent. The addition of this object allows to use the DateAndTime textual convention as defined in RFC 1903 even on devices that do not have a real-time clock. "UMTS/IMT-2000 and Mobile IP/DIAMETER Harmonization", Martin Korling, Eva Gustafsson, Anders Herlitz, Annika Jonsson, 11/19/1998, The purpose of this document is to form a basis for discussion about the development of the Mobile IP standard. It is foreseen that cellular mobile systems will give rise to a widespread global use of IP mobility tunnels. We describe scenarios and identify important issues for the Mobile IP specification and the proposed DIAMETER extensions for Mobile IP. "Virtual Private Networks Identifier", B. Gleeson, Barbara Fox, 11/19/1998, Virtual Private IP networks may span multiple Autonomous Systems or Service Providers. There is a requirement for the use of a globally unique VPN identifier in order to be able to refer to a particular VPN (see section 6.1.1 of [1]). This document proposes a format for a globally unique VPN identifier. "DHCP Option 61 UUID Type Definition", M. Henry, 11/20/1998, The DHCP [1] mechanism for identifying the client as a unique entity is the DHCP client-identifier option (code 61) [2]. This draft defines for Option 61 a specific type and type number of a client-identifier based on generated UUIDs [3]. These identifiers are guaranteed to be, or are very, very likely to be unique across time and all clients. "XML Encoded Form Values", Anders Kristensen, 11/20/1998, This document proposes an XML encoding for sets of named values. The primary application is as a transmission format for form values being submitted to a processing agent over the Web. The main advantage over other form value encodings is that it allows field names to be associated with structured values without resorting to non-XML encodings. The multipart/related MIME type is used for carrying non- XML media. "Supporting Service Level Agreements using Differentiated Services", Dinesh Verma, Mandis Biegi, Raymond Jennings, Srinivasa Rao, 11/20/1998, This document describes an NT-based implementation of an Differentiated Services access router as described in [DSARCH]. This document describes our access router implementation, lessons learned, and issues in supporting service level agreements using the differentiated services architecture. "Architectural Framework for Signaling Transport", Lyndon Ong, 11/20/1998, This document defines an architecture framework for transporting PSTN signaling information over IP. It defines an architectural model, and identifies functional requirements and performance requirements for signaling transport. PSTN signaling must be encapsulated and identified for transport over IP networks, and signaling performance requirements for message loss, delay, etc. must be supported by protocol mechanisms. "MPLS for PIM-SM", Bernard Sales, Wim Livens, Dirk Ooms, 11/20/1998, This document describes the issues which rise when PIM-SM ([ESTR]) is chosen as the protocol for IP multicast deployment in an MPLS environment. The relevant characteristics of PIM-SM are further explored and a trigger for the establishment of LSPs for multicast trees is proposed. "MPLS Optimized Multipath (MPLS--OMP)", Curtis Villamizar, 11/20/1998, MPLS ingress routers may establish one or more explicit paths to a given egress to the MPLS domain. Load can be balanced across a com- plex topology using MPLS and the technique referred to here as MPLS- -OMP (Multiprotocol Label Switching -- Optimized Multipath). The technique requires the use of an interior gateway protocol (IGP) such as OSPF or ISIS with extensions to flood loading information. It re- quires the ingress router be capable of computing a hash based on the IP source and destination and selecting a forwarding entry based on the outcome of the hash with a sufficiently fine level of granularity, then load can be balanced across a complex topology. MPLS Optimized Mulitpath can be considered an extension to MPLS or a specific usage of MPLS. MPLS-OMP requires no additions or modification to the MPLS protocols. MPLS-OMP does require that the IGP be capa- ble of flooding loading information as described in the OSPF-OMP and ISIS-OMP documents. At the MPLS ingress an algorithm is applied to select alternate paths where needed and adjust forwarding. Forwarding is adjusted gradually enough to insure stability yet fast enough to track long term changes in loading. The load adjustment algorithm itself is fully defined in a related document describing OSPF--OMP. The application of this technique to MPLS is described here. "Long Thin Networks", G. Montenegro, Spencer Dawkins, Vincent Magret, Markku Kojo, 11/20/1998, In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind. We recognize that not every tcpsat recommendation will be required for long thin networks as well, and are working toward a set of TCP recommendations that are 'benign' in environments that do not require them. "MPLS Traffic Engineering Management Information Base", A. Viswanathan, Cheenu Srinivasan, 11/20/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it describes managed objects for Multi-Protocol Label Switching (MPLS) [1, 2] based traffic engineering. "iCAL in XML", Surendra Reddy, Doug Royer, Lisa Lippert, 11/23/1998, The motivation for this proposal is the expanded scope and diversity of the World Wide Web. The World Wide Web provides a simple and effective means for users to search, browse, retrieve, and publish information of their own available for others. Now that Web browsers and servers are ubiquitous on the Internet, it is worthwhile to use XML to encode calendar objects. The power and extensibility of XML allows us to represent calendar data objects as well-formed XML documents. ICAL is an existing standard format for representing calendar components. This draft explains how to represent calendar components in XML that are compatible and easily translatable to the iCAL format. Copyright (C) The Internet Society 1998. All Rights Reserved. "LDUP Replication Information Model", Ed Reed, 11/23/1998, [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (ie, subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. The controlling framework by which the relationships, types, and health of replicas of the directory content will be defined so that, as much as possible, directory content is itself used to monitor and control the environment. Security information, including access control policy identifiers and information will be treated as directory content by the replication protocols when specified by the LDAPEXT group. The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage collection of deleted objects, reconciliation of moved and renamed objects, update sequencing and transaction bracketing of changes, etc. "Dynamic Hostname Exchange Mechanism for ISIS", Naiming Shen, Henk Smit, 11/23/1998, Currently there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. "Proposal for additional RTP-SDES types", P. Parnes, 11/23/1998, The Real-time Transfer Protocol, RTP (RFC1889 and currently under revision) includes basic support for conveying some predefined membership information types within a session using its control protocol (RTCP). This document describes a proposal for extending these membership types with additional membership information for user nickname, personal information web page reference, personal image reference and currently active media in session. "Connectionless SCCP over IP Adaptation Layer (CSIP)", David Sanchez, 11/23/1998, This document describes CSIP, a protocol architecture that provides the support of TCAP user applications over an IP network. The core part of the CSIP architecture is the specification of the CSIP (Connectionless SCCP over IP) adaptation layer, that provides adaptation between the SCCP layer already defined in [2] and the IP family protocols IP, UDP, TCP and ICMP. UDP is used when SCCP class 0 is used, TCP is used when SCCP class 1 is used. CSIP provides the primitives and parameters to SCCP than MTP, and provides backward compatibility that guarantees the seamless connection between nodes implementing CSIP and classical SS7 nodes by means of a CSIP gateway. The design of CSIP is oriented to fulfill the requirements of TCAP user applications running on a WAN. "MPLS Extensions for Differential Services", Pasi Vaananen, Liwen Wu, Pierrick Cheval, 11/23/1998, This document provides new message formats and the updates of the current MPLS LDP messages and MPLS RSVP messages to support the differentiated services (DiffServ). We first discuss the extension to the current MPLS architecture [MPLSARCH] to support differentiated services [DIFFARCH] over MPLS cloud. For a Behavior Aggregate (BA), we define 'Behavior Aggregate Selector (BAS)' which related to the forwarding queue behavior, and define 'Behavior Modifier (BM)' which related to the dropping behavior. Each DiffServ Per Hop Behavior (PHB) can be represented using either BAS only or combination of BAS and BM. In brief, we propose that all LSRs on the path of a single MPLS LSP apply the same Behavior Aggregate Selector (BAS) for the traffic carried in this LSP, on the basis of behavior class selector that is specified as part of LSP set-up process. Behavior Modifier (BM), carried as part of label encapsulation header, is used to further modify the behavior selected by BAS. Behavior modifiers are carried as part of MPLS shim header, ATM cell header or Frame Relay header, and can be used to indicate, e.g. drop priority or congestion indication inside a single BAS. This proposal is not intended to prevent any potential future evolution that would accomodate multiple, different Behavior Aggregate Selectors (BAS) within a single LSP. "Efficiently transporting ad-carrying web pages", Geoffrey Baehr, Amit Gupta, 11/23/1998, This draft proposes a simple extension to HTTP, using a new set of headers, which can significantly reduce the network traffic used for sending pages containing advertising banners and other related content. We begin by describing the problems generated by the use of 'cache-busting' techniques today and why the Hit-metering scheme [RFC2227], by itself, may not be adequate. We will then describe a new scheme which relies on collaboration between the content providers and the Internet Service Providers (ISPs). "Cellular IP", Andrew Campbell, Andras Valko, Javier Gomez, 11/23/1998, This document specifies a protocol that allows routing IP datagrams to a mobile host. The protocol is intended to provide local mobility and handoff support. It can interwork with Mobile IP [1] to provide wide area mobility support. Four fundamental design principles of the protocol are: (1) location information is stored in distributed data bases (2) location information referring to a mobile host is created and updated by regular IP datagrams originated by the said mobile host (3) location information is stored as soft state (4) location management for idle mobile hosts is separated from location management of hosts that are actively transmitting or receiving data. "A Framework for E.164 Number to IP Address Mapping", Milo Orsic, Chinmei Lee, 11/23/1998, This internet draft describes a framework for mapping the E.164 number of internet telephony (IT) subscribers to an IP addresses so that calls can be delivered to IT subscribers. The draft describes: - assumptions that the framework is based on - goals that the framework is designed for - functionality of network entities Several scenarios are included to illustrate the procedure. "Remote Monitoring MIB Extensions for Differentiated Services Enabled Networks", Andy Bierman, 11/23/1998, This memo defines an experimental 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 monitoring Differentiated Services Codepoint usage in IP packets. "A Two-Tier Resource Management Model for Differentiated Services Networks", Lixia Zhang, R. Yavatkar, Francis Reichmeyer, Andreas Terzis, Lyndon Ong, 11/24/1998, This draft proposes a two-tier resource management model for differentiated services networks. Following the approach taken by the Internet routing architecture, we propose that bilateral service agreements are made for aggregate border-crossing traffic between neighboring administrative domains. We also propose that administrative domains individually make their own decision on strategies and protocols to use for internal resource management and QoS support, both to meet internal client needs and to fulfill external commitments. We sketch out one specific realization of this two-tier model by having a Bandwidth-Broker (BB) as the resource manager for each domain and a BB-to-BB protocol, equivalent to BGP in routing, for inter-domain resource management. We believe that this two-tier resource management model matches the direction of, and complement the work by, the diffserv effort. We also expect this two-tier model to scale well in the global, heterogeneous Internet. Note: This draft contains pictures that could not be included in the text version. A postscript version of the draft (including the pictures) can be found at http://irl.cs.ucla.edu/publications.f.html "The KeyNote Trust-Management System",, 11/24/1998, This memo describes the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote `assertions,' describes `action environment' processing, and outlines the application architecture into which a KeyNote implementation would fit. "LDAP Schema for Internet Mail", Daryl Huff, Anil Srivastava, Robert Allen, Ellen Siegel, 11/24/1998, The use of directory services based on the Lightweight Directory Access Protocol (LDAP) [LDAP] is becoming increasingly popular for distributed and web-based services. Since most LDAP-based applications have developed their schemas independently, new application designers find themselves faced with the dilemma of how to interoperate with an already conflicting set of existing LDAP specifications. Today's Web-aware customers expect interoperability, so it is crucial to converge existing schema in a way that supports interoperability across arbitrary applications and vendors. In this spirit, we describe an LDAP schema for internet mail routing and delivery that is designed to be modular and to support a common core for sharing user state across an arbitrary set of applications. ONC Remote Procedure Call (oncrpc) ---------------------------------- "Authentication Mechanisms for ONC RPC", A Chiu, 04/16/1998, his document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. Open Shortest Path First IGP (ospf) ----------------------------------- "OSPF for IPv6", Rob Coltun, John Moy, D. Ferguson, 11/26/1997, This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. "The OSPF NSSA Option", Rob Coltun, Vince Fuller, P. Murphy, 07/02/1998, This memo documents of an optional type of OSPF area which is somewhat humorously referred to as a 'not-so-stubby' area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix E. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. Please send comments to ospf@gated.cornell.edu. "OSPF Optimized Multipath (OSPF-OMP)", Curtis Villamizar, 10/09/1998, OSPF may form multiple equal cost paths between points. This is true of any link state protocol. In the absense of any explicit support to take advantage of this, a path may be chosen arbitrarily. Tech- niques have been utilized to divide traffic somewhat evenly among the available paths. These techniques have been referred to as Equal Cost Multipath (ECMP). An unequal division of traffic among the available paths is generally preferable. Routers generally have no knowledge of traffic loading on distant links and therefore have no basis to optimize the allocation of traffic. Optimized Mulitpath is a compatible extension to OSPF, utilizing the Opaque LSA to distribute loading information, proposing a means to adjust forwarding, and providing an algorithm to make the adjustments gradually enough to insure stability yet provide reasonably fast ad- justment when needed. "OSPF Multiple Area Links", P. Murphy, 07/17/1998, This memo describes an option to the OSPF Version 2 specification which allows multiple areas to share the same link. This option adds no additional link state flooding over shared links other than the normal link state database exchange and update originating from the link's configured primary area. The option applies to standard areas, stub areas, and NSSAreas. It eliminates the excess Area 0 link state baggage that accompanies the use of virtual links as currently practiced when configuring similar transits for standard OSPF areas. Routers with this option configured are backward compatible with routers running the standard OSPF Version 2 compliant implementation as defined in RFC 2328, and can be restricted to a subset of the OSPF routing domain. This option is applied only on OSPF border routers. "Multicast Extensions to OSPF", John Moy, 09/17/1998, This memo documents the MOSPF protocol. MOSPF, which stands for the Multicast extensions to OSPF, is an enhancement to the OSPF protocol enabling the routing of IP multicast datagrams. The extensions have been implemented so that a multicast routing capability can be introduced piecemeal into an OSPF Version 2 routing domain. Some of the OSPF Version 2 routers may run the multicast extensions, while others may continue to be restricted to the forwarding of regular IP traffic (unicasts). An implementation of this memo will interoperate with implementations of the previous MOSPF specification, RFC 1584. Differences between this memo and RFC 1584 include bug fixes, modifications which track changes to the base OSPF specification, and an assumption that IGMPv2 (instead of IGMPv1) will now be used to communicate group membership from IP hosts to MOSPF routers. See Appendix D for details. Protocol Independent Multicast (pim) ------------------------------------ "Protocol Independent Multicast Version 2 Dense Mode Specification", Deborah Estrin, V. Jacobson, D. Farinacci, David Meyer, L. Wei, Steve Deering, A. Helmy, 11/06/1998, This specification defines a multicast routing algorithm efficient for multicast groups that are densely distributed across a network. This protocol does not have a topology discovery mechanism often used by a unicast routing protocol. It employes the same packet formats sparse- mode PIM [PIMSM] uses. This protocol is called dense-mode PIM. The foundation of this design was largely built on Deering's early work on IP multicast routing [Deering91]. "Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6)", Hal Sandick, Garry Kump, Brian Haberman, 08/10/1998, This document outlines recommendations in the use of Protocol Independent Multicast routing protocol to support Internet Protocol Version 6. It describes the changes needed in order to handle the differences between IPv6 and IPv4 and conform to the logic introduced by other routing protocols enabled for IPv6. "Authenticating PIM version 2 messages", L. Wei, 11/12/1998, This draft specifies the use of IPSEC authentication header [KA98] to provide protocol message integrity protection and groupwise message origin authentication. The text in this draft will be either incorporated into or referenced by the PIM version 2 protocol specifications. PSTN and Internet Internetworking (pint) ---------------------------------------- "The PINT Profile of SIP and SDP: a Protocol for IP Access to Telephone Call Services", Scott Petrack, Lawrence Conroy, 11/20/1998, This document contains the specification of the PINT Profile 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the authors. "A Proposal for Internet Call Waiting Service using SIP An Implementation Report", Vijay Gurbani, Alec Brusilovsky, Eric Gausmann, Ajay Jain, 11/05/1998, The purpose of this Internet Draft is to start discussion on the issues involved in Internet Call Waiting Service (ICW), as part of interconnecting IP and Global Switched Telephone Network (GSTN) with the intent of providing ICW service that is much needed by numerous dial-up Internet users. Interworking of the IP network and GSTN, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: Section 2 briefly describes the services offered to the end Subscriber. It is the support of these services that necessitates the proposed internetworking project. Section 3 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized, describing experience with SIP for ICW. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document. Section 8 is the Appendix, which contains IN Tutorial and Figure A. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", D. Solo, Russ Housley, Warwick Ford, Tim Polk, 09/23/1998, This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described, and a set of required extensions is defined. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list. "Internet X.509 Public Key Infrastructure Certificate Management Protocols", C. Adams, S. Farrell, 05/22/1998, This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that 'certificate' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", Tim Howes, S. Boeyen, P. Richard, 09/24/1998, The protocol described in this document is designed to satisfy some of the operational requirements within the Internet X.509 Public Key Infrastructure (IPKI). Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. The mechanism described in this document is based on the Lightweight Directory Access Protocol (LDAP) v2, defined in RFC 1777, defining a profile of that protocol for use within the IPKI and updates encodings for certificates and revocation lists from RFC 1778. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list. "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", Warwick Ford, S. Chokhani, 04/28/1998, This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This document is being submitted to the RFC Editor with a request for publication as an Informational RFC. "Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates", Russ Housley, William Polk, 08/05/1998, This is the third draft of a profile for specification of Key Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure X.509 certificates. There are only minor changes in content from the second draft. Several modifications are required now that KEA has been declassified. A patent statement is required, and a published reference for the KEA algorithm is required. After these modifica- tions, the document will be complete. Please send comments on this document to the ietf-pkix@imc.org mail list. "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", Russ Housley, Paul Hoffman, 07/06/1998, The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. Please send comments on this document to the ietf-pkix@imc.org mail list. "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", C. Adams, M. Myers, Ambarish Malpani, Rich Ankney, Slava Galperin, 10/01/1998, This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. An overview of the protocol is provided in section 3. Functional requirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 syntactic elements and appendix C specifies the mime types for the messages. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. "Internet X.509 Public Key Infrastructure Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates", D. Johnson, Lawrence Bassham, William Polk, 12/03/1997, This is the first draft of a profile for specification of Elliptic Curve Digital Signature Algorithm (ECDSA) keys in Internet Public Key Infrastructure X.509 certificates. Please send comments on this document to the ietf-pkix@tandem.com mail list. "Internet X.509 Certificate Request Message Format", D. Solo, C. Adams, D. Kemp, M. Myers, 06/02/1998, This document describes the Certificate Request Message Format (CRMF). This syntax is used to convey a request for a certificate to a Certification Authority (CA) (possibly via a Registration Authority (RA)) for the purposes of X.509 certificate production. The request will typically include a public key and associated registration information. The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'', and ''MAY'' in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@lists.tandem.com mail list. "Certificate Management Messages over CMS", Barbara Fox, Xiaoyi Liu, M. Myers, Jeff Weinstein, 11/12/1998, This document defines a Certificate Management protocol using CMS (CMC). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA- signed certificates with Diffie-Hellman public keys. A small number of additional services are defined to supplement the core certificate request service. Throughout this specification the term CMS is used to refer to both [CMS] and [PKCS7]. For signedData the two specifications are equivalent. For envelopedData CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification. The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in [RFC 2119]. "Internet X.509 Public Key Infrastructure Certificate Management Message Formats", C. Adams, M. Myers, 07/15/1998, This is a draft of the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Messages Formats (CMMF). It establishes harmonized message formats to be used in conjunction with security protocol implementations that require interaction with a Public Key Infrastructure (PKI). "Internet X.509 Public Key Infrastructure LDAPv2 Schema", Tim Howes, S. Boeyen, P. Richard, 09/23/1998, The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in draft-ietf-pkix- ipki2opp-07.txt. Only PKIX-specific components are specified here. LDAP servers, acting as PKIX repositories should support the auxi- liary object classes defined in this specification and integrate this schema specification with the generic and other application- specific schemas as appropriate, depending on the services to be supplied by that server. The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list. "Internet Public Key Infrastructure Caching the Online Certificate Status Protocol", Marc Branchard, 04/17/1998, The Online Certificate Status Protocol [OCSP] specifies how a client process may obtain certificate status information online from a server. In order for OCSP to scale beyond small communities of users, a method to cache certificate status information at intermediary servers is required. This document describes the requirements of and assumptions behind OCSP caching, and defines the mechanisms through which such caching can be accomplished. "WEB based Certificate Access Protocol-- WebCAP/1.0", Surendra Reddy, 04/20/1998, This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Access Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that ''certificate'' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 to publish, retrieve X.509 certificates and Certificate Revocation Lists. This protocol also facilitates determining current status of a digital certificate without the use of CRLs. This protocol defines new methods, request and response bodies, error codes to HTTP/1.1 protocol for securely publishing, retrieving, and validation certificates across a firewalls. "Internet X.509 Public Key Infrastructure ENHANCED CRL DISTRIBUTION OPTIONS", Warwick Ford, P. Hallam-Baker, 08/11/1998, This Internet Draft specifies some proposed enhancements to the X.509 CRL mechanism used to determine if a public-key certificate is valid or revoked. These enhancements provide advantages over existing CRL mechanisms, including those that use static CRL partitioning as defined in ISO/IEC 9504-8/ITU-T Rec. X.509. In particular, the mechanisms proposed can: (a) reduce the need for unnecessarily fetching unchanged CRLs, thereby greatly expanding the value of caching CRLs; (b) allow CRL timeliness to be improved; (c) accommodate dynamic partitioning as opposed to fixed partitioning; (d) better support use of certificates in multiple environments with different CRL stores. This document is submitted for consideration as the basis of possible future IETF standardization. Please send comments on this document to the ietf-pkix@imc.com mail list. "Internet X.509 Public Key Infrastructure Time Stamp Protocols", C. Adams, B. Pinkas, Patrick Cain, Robert Zuccherato, 09/23/1998, This document describes the format of the data returned by a Time Stamp Authority and the protocols to be used when communicating with it. The time stamping service can be used as a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). In order to reduce the amount of trust required of a TSA we introduce (in Appendix C) the optional Temporal Data Authority (TDA) whose function is to provide further corroborating evidence of the time contained in the token. We also give an example of how to place a signature at a particular point in time, from which the appropriate certificate status information (e.g. CRLs) may be checked. "Internet X.509 Public Key Infrastructure Data Certification Server Protocols", C. Adams, Robert Zuccherato, 09/23/1998, This document describes a general data certification service and the protocols to be used when communicating with it. The Data Certification Server is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Data Certification Server responsibilities in a PKI are to validate signatures and to provide up-to-date information regarding the status of public key certificates. We give examples of how to use the Data Certification Server to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Certification Server regarding the status of a public key certificate. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [RFC2119]. "Internet X.509 Public Key Infrastructure PKIX Roadmap", Sean Turner, Alfred Arsenault, 09/30/1998, This document provides an overview or 'roadmap' of the work done by the IETF PKIX working group. It describes some of the terminology used in the working group's documents, and the theory behind an X.509-based PKI. It identifies each document developed by the PKIX working group, and describes the relationships among the various document. It also provides advice to would-be PKIX implementors about some of the issues discussed at length during PKIX development, in hopes of making it easier to build implementations that will actually interoperate. PacketWay (pktway) ------------------ "The End-to-End (EEP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters", Danny Cohen, C. Lund, T. Skjellum, T. McMahon, R. George, 05/22/1998, PktWay is an open family of specifications for inter-networking high performance SANs (System Area Networks) and high performance LANs (Local Area Networks) into computing clusters. "Part-1 of The Router-to-Router (RRP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters", Danny Cohen, C. Lund, T. Skjellum, T. McMahon, R. George, 10/23/1997, The PktWay protocol is introduced in the 'The End-to-End (EEP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters'. This document defines the basic part (Part 1) of the Router-to-Router protocol (RRP) of PacketWay. The shorter 'PktWay' is used for 'PacketWay'. "Enumerations for the PacketWay Protocol for High-Performance Interconnection of Computer Clusters", Danny Cohen, C. Lund, T. Skjellum, T. McMahon, R. George, 07/09/1998, "The Router-to-Router (RRP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters", Danny Cohen, C. Lund, T. Skjellum, T. McMahon, R. George, 07/09/1998, Process for Organization of Internet Standards ONg (poisson) ------------------------------------------------------------ "Bylaws for a Protocol Support Organization", Scott Bradner, 11/17/1998, The 'new IANA corporation' (referred to below as 'the Internet Corporation for Assigned Names and Numbers' (ICANN)) assumes the existence of a 'Protocol Supporting Organization' (PSO). This document is a draft set of bylaws for such an organization. "Procedures for IETF appointments to the Protocol Supporting Organization", Brian Carpenter, 11/11/1998, This memo describes the procedures by which the IETF appoints representatives to the various bodies of the Internet Corporation for Assigned Names and Numbers (ICANN) and to the Protocol Supporting Organization (PSO) related to ICANN. Policy Framework (policy) ------------------------- "Schema for Differentiated Services and Integrated Services in Networks", R. Yavatkar, George Powers, Dinesh Verma, Michael See, Jean-Christophe Martin, R. Rajan, S. Kamat, R. Chaudhury, 10/22/1998, This document describes the structure of a directory schema to enable and support administration of differentiated services and/or integrated services within and among Internet domains, intranets, and extranets. This draft replaces draft-ellesson-sla-schema-00.txt. "A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services", Lixia Zhang, R. Yavatkar, Fred Baker, Peter Ford, Y. Bernet, 03/16/1998, In the past several years, work on QoS enabled networks led to the development of the Integrated Services (Intserv) architecture [12] and the RSVP signaling protocol [1]. RSVP addresses the needs of applications that require QoS, promising per-flow service. As the RSVP/Intserv (from here on abbreviated to intserv) work has proceeded, we have recognized barriers to the deployment of intserv. The reliance of intserv on per-flow state and per-flow processing is an impediment to its deployment in the Internet at large, and in particular in large carrier networks. Additionally, RSVP signaling is supposed to originate from hosts, which as of yet are not RSVP enabled in large numbers. Recently, attention has shifted to Differentiated services (diff-serv). Diff-serv promises to expedite the realization of QoS enabled networks by offering a significantly simpler alternative to intserv, which eliminates scalability concerns and which can be implemented and managed in large networks, without requiring end-to-end deployment. However, unlike intserv, diff-serv focuses on the needs of the large network. This draft proposes a framework for end-to-end QoS, in which intserv and diff-serv are used together to meet the needs of large ISPs who manage the transit networks of the Internet, and the users of QoS applications and hosts, who are the ISPs' ultimate customers. This focus is important as we believe that in the coming years, there will be a proliferation of applications that depend on QoS and of hosts which are capable of QoS signaling. We envision the deployment of diff-serv capable core networks and intserv capable stub networks at the periphery. Our framework allows each to proceed at its own pace, providing immediate incremental benefits in areas of the network in which one or the other is deployed and additional benefits where both are deployed. "Terminology for describing network policy and services", Ed Ellesson, John C. Strassner, 08/11/1998, Recent work in the IETF has led to multiple protocols which support the classification of packets for the purposes of treating certain classes or flows of packets in a particular way compared to other packets. The successful wide-scale deployment of these protocols depends on the ability to administer and distribute consistent policy information to the multiple devices in the network which perform the classification and packet conditioning or treatment. As a result, there is a clear need to develop a scalable framework for policy administration and distribution that will enable interoperability among multiple devices and device types that must work together to achieve a consistent implementation of policy. Unfortunately, terms like 'policy' and 'service' are not currently defined in sufficient detail as to enable the definition, specification, and implementation of policy servers and how policy is recognized and enforced at the device level. At present, both 'policy' and 'service' (as well as other related terms) are overloaded with multiple (often conflicting) meanings. This makes communication about policy in general and specifically policy-based networking cumbersome and difficult. This document defines a set of terms that the Internet community can use to exchange ideas on how policy creation, administration, management, and distribution could work among policy servers and multiple device types. "Policy Framework Definition Language", John C. Strassner, Stephen Schleimer, 11/23/1998, Recently, the IETF has developed protocols that classify packets in order to treat certain classes or flows of packets in a particular way compared to other classes or flows of packets. The successful wide-scale deployment of these protocols depends on the ability to administer and distribute consistent policy information to different types of network devices as well as hosts and servers that participate in policy decision making, administration, distribution and control. There is a clear need to develop a scalable framework for policy administration and distribution that will enable interoperability among multiple devices and device types that must work together to achieve a consistent implementation of policy. This document defines a language, called the Policy Framework Definition Language (PFDL), that maps requirements for services to be provided by the network as defined in a business specification (e.g., an SLA) to a common vendor- and device-independent intermediate form. This enables policy information and specifications to be shared among the heterogeneous components that comprise the policy framework, and allows multiple vendors to use multiple devices to implement that framework. The PFDL is the common 'currency' that is exchanged between these heterogeneous components to enable them all to perform their function in providing, securing, distributing, and administering policy. The PFDL becomes the way to ensure that multiple vendors interpret the policy the same way while enabling vendors to provide value-added services. "Policy Framework Core Information Model", Ed Ellesson, John C. Strassner, 11/23/1998, This document defines an object-oriented information model for representing policies. This model defines structural information of objects that comprise and control policy (the 'schema', or class inheritance hierarchy) as well as information that describes how different objects are related to other objects (the relationship hierarchy). The information model described in this document consists of five very general classes: policyGroup, policyRule, policyValidityPeriod, policyCondition, and policyAction. While structural information is represented very well in LDAP schemas, relationships between objects are not. This document also defines how to map more abstract concepts, such as relationships, into LDAP schemas. One mechanism to do this mapping is to use auxiliary classes. This document defines one such class, the policyRuleContainmentAuxClass. While these classes are general, they are not abstract: they can all be instantiated. Policy solutions for specific areas, such as DiffServ and IPSec, may use the policyGroup, policyRule, policyValidityPeriod, and policyRuleContainmentAuxClass classes directly, while creating their own subclasses derived from policyCondition and policyAction. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- "PPP LCP Extensions", W. Simpson, 08/04/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines the Identification and Time-Remaining messages. "Point-to-Point Tunneling Protocol--PPTP", Glen Zorn, G. Pall, K. Hamzeh, W. Verthein, J. Taarud, W. Little, 11/23/1998, This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. "Layer Two Tunneling Protocol 'L2TP'", Allan Rubens, William Palter, T. Kolar, G. Pall, M. Littlewood, A. Valencia, K. Hamzeh, W. Verthein, J. Taarud, W. Mark Townsley, 11/06/1998, Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC 1661 specifies multi-protocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. "Semi Connected Mode for PPP links", M. Latvala, 11/23/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document introduces a new PPP feature called Semi Connected Mode. When both sides of a point-to-point link agree to use Semi Con- nected Mode, either side can transparently disconnect and re- establish a circuit-switched connection without having to reconfigure the point-to-point link each time. "PPP LCP CallBack", W. Simpson, 08/04/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines the CallBack option. "IP Header Compression over PPP", Stephen Casner, C. Bormann, M. Engan, 12/23/1997, This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. [Note to IANA, to be removed before publication: The PPP protocol type assignments suggested in this document were selected from those unassigned in ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers on December 7, 1997. These selections were presented to the PPPEXT working group at IETF in Washington, DC on December 9, 1997 and were approved as being in the appropriate ranges for this protocol.] "Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks", Pat Calhoun, W. Mark Townsley, Sumit Vakil, Donald Grosser, 07/29/1998, The L2TP document [1] defines the base protocol which describes the method of tunneling PPP [2] data. The L2TP document states that the security mechanism used over an IP network is to use the IETF's IPSEC protocols. L2TP was designed in such a way as to be able to run over any underlying layer (i.e. Frame Relay, ATM, etc.). This document specifies extensions to the L2TP protocol in order to provide authentication and integrity of individual packets in a tunneled session over a network where IPSEC or another suitable security protocol is not available. "PPP LCP Self Describing Padding", W. Simpson, 08/04/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines the Self-Describing-Padding option. "PPP EAP ISAKMP Authentication Protocol", G. Carter, 09/20/1997, The Point-to-Point Protocol (PPP) [RFC1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP) [RFC1968], used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP) [RFC1962], used to negotiate compression methods. The Extensible Authentication Protocol (EAP) [EAP] is a PPP extension that provides support for additional authentication methods within PPP. The Internet Security Association and Key Management Protocol [ISAKMP] combined with the Oakley [Oakley] key exchange protocol enables secure, mutually authenticated security association exchanges between two endpoints. This document describes how ISAKMP provides for these mechanisms within EAP. "Layer Two Tunneling Protocol 'L2TP' Management Information Base", Evan Caves, Pat Calhoun, Ross Wheeler, Gayam Reddy, Bill Vroman, 11/24/1998, 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 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "PPP EAP TLS Authentication Protocol", B Aboba, D. Simon, 10/13/1998, The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mech- anisms within EAP. "PPP over SONET/SDH",, 10/16/1997, This Internet Draft addresses the PPP/SONET interface defined in the IETF RFC 1619 and its application in public Internet backbone networks. By experimental analysis it is found that this SONET interface specification is deficient in providing payload transparency. This deficiency leads to deleterious effects in providing reliable network operations. A simple SONET payload scrambler enhancement is proposed to overcome this deficiency. This work has been brought to the ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping to T1.105 with a scrambler to be determined by T1X1. We are submitting the same proposal to IETF now with the interest to enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. To facilitate this alignment, we have recommended that T1X1 establish a formal liaison with IETF in regard to IP/SONET interface standards and associated IP transmission standards development. "L2TP Header Compression (''L2TPHC'')", A. Valencia, 12/22/1997, The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for tunneling PPP sessions over arbitrary media. There exists a class of specific media and applications for which protocol overhead may be optimized, and where such reduction results in improved operation. This document describes the solution space addressed, its underlying motivations, and the protocol modifications required. The enhancement to the L2TP protocol is called L2TP Header Compression, or ``L2TPHC''. "Multi-link Multi-node PPP", G. Malkin, 05/20/1998, This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified. "PPP over SONET/SDH", W. Simpson, 08/04/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Synchronous Opti- cal Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. "PPP Consistent Overhead Byte Stuffing (COBS)", James Carlson, Mary Baker, Stuart Cheshire, 11/18/1997, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows the negotiation of optional frame encoding methods. This document defines the Consistent Overhead Byte Stuffing (COBS) negotiation and encapsulation procedure. "PPP EAP KEA Public Key Authentication Protocol", P. Yee, James Zmuda, W. Nace, 12/03/1997, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. This document specifies yet another authentication mechanism that may be used within the EAP framework. This document defines the KEA Public Key Authentication Protocol within PPP EAP. A side effect of KEA public key authentication is the creation of a session key for encryption of data on the PPP link. "PPP Fortezza Encryption Encapsulation Protocol", James Zmuda, W. Nace, 12/03/1997, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. One of the Authentication protocols that can be negotiated is the EAP. The EAP can be used in any of a number of variants. When the EAP is used in it's KEA variant, this results in mutual authentication and key generation. This key is available for use during the PPP data transfer phase by an encryption encapsulation. The encryption encapsulation that is described in this memo is one possible encapsulation that can use the keying material generated by the EAP KEA protocol. "PPP Certificate Exchange Protocol", James Zmuda, W. Nace, 12/03/1997, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. The Certificate exchange protocol is an extension to PPP that is in the form of an additional phase, called the certificate exchange phase, that would allow for a PPP entity to request certificates from a peer. If configured, this phase would be negotiated during the LCP exchange. This exchange of certificates is aimed at easing configuration issues by providing for the exchange of certificate path information in a standard manner across different strong, or public-key certificate-based, authentication protocols. The certificate exchange protocol accomodates arbitrary sized certificates. "PPP EAP DSS Public Key Authentication Protocol", James Zmuda, W. Nace, 12/03/1997, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. This document specifies yet another authentication mechanism that may be used within the EAP framework. This document defines the DSS Public Key Authentication Protocol within PPP EAP. "PPP in Frame Relay", W. Simpson, 08/07/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of Frame Relay for framing PPP encapsulated packets. "PPP with Framing Conversion", W. Simpson, 08/07/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of converters for bridging PPP encapsulated packets between links with different framing tech- niques. "PPP in X.25", W. Simpson, 08/07/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. "Securing L2TP using IPSEC", B Aboba, B. Patel, 05/22/1998, This document discusses how L2TP may utilize IPSEC to provide for tun- nel authentication, privacy protection, integrity check and replay protection. Both the voluntary and compulsory tunneling cases are dis- cussed. "L2TP-over-IP Path MTU Discovery (''L2TPMTU'')", Richard Shea, 01/05/1998, The Layer Two Tunneling Protocol (L2TP) defines a mechanism for tunneling PPP over arbitrary media. When IPv4 or IPv6 over PPP is tunneled over L2TP, it is desirable to avoid fragmentation of the L2TP data channel packets when L2TP is run over IP. This document describes a mechanism for L2TP-over-IP to avoid fragmentation of tunneled IPv4 and IPv6 datagrams by leveraging IPv4 and IPv6 path MTU discovery mechanisms. "L2TP Alternate Data Channel (``L2TPADC'')", William Palter, 01/13/1998, The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for tunneling PPP sessions over arbitrary media. There exists a class of services for which different types of data packets should be segregated from each other, over the lower layer transport. This document describes the solution space addressed, its underlying motivations, and the protocol modifications required. This enhancement to the L2TP protocol is called L2TP Alternate Data Channel, or ``L2TPADC''. "Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension", Ken Peirce, Pat Calhoun, 07/29/1998, The L2TP document [1] defines the base protocol which describes the method of tunneling PPP [2] data. The L2TP base protocol does not address any Differential Services extensions. Since the market is reluctant to outsource dial access without any Quality of Service assurances, this draft addresses this problem by allowing each L2TP Data Session to be assigned an appropriate differential services indicator. "Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label Switching Extension", Ken Peirce, Pat Calhoun, 07/29/1998, The L2TP document [1] defines the base protocol which describes the method of tunneling PPP [2] data. The L2TP base protocol does not address any MPLS extensions. The goal of MPLS is to speed forwarding of packets by reducing the lookup required in routing. This draft proposes a method to allow L2TP Data Sessions to be assigned a Multi-Protocol Label. "Microsoft Point-To-Point Encryption (MPPE) Protocol", Glen Zorn, G. Pall, 09/22/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to Point Encryp- tion (MPPE) to enhance the confidentiality of encrypted PPP-encapsulated packets. "PPP LCP Internationalization Configuration Option", Glen Zorn, 11/18/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5]. "PPP Link Balancing Detection (LBD)", James Carlson, 04/06/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows the detection of optional link handling procedures, as well as a Multilink procedure (MP) [2] which allows operation over multiple physical links. This document defines an extension to MP called Link Balancing Detection (LBD). "L2TP Dynamic Data Window Adjustment", Richard Shea, 11/17/1998, The Layer Two Tunneling Protocol (L2TP) defines the specification of congestion window sizes for data sessions. In addition, an LNS is given the capability to turn off sequence number processing for a data session, provided the LAC did not include the Sequencing Required AVP during session setup. This document specifies a mechanism whereby an L2TP peer can dynamically change the maximum window size values being used for a data session, in order to provide the flexibility to operate with smaller window sizes when history-bound protocols are operating over a session, and larger window sizes when no history-bound protocols are operating over a session. "Layer Two Tunneling Protocol (L2TP) over Frame Relay", Rene Tio, Rohit verma, Vipin Rawat, 07/15/1998, Layer Two Tunneling Protocol describes a mechanism to tunnel PPP sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over UDP and IP. This document describes how the Layer Two Tunneling Protocol MUST be implemented over Frame Relay PVCs and SVCs. "Applicability Statement for PPP over SONET/SDH", W. Simpson, 08/04/1998, The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Synchronous Opti- cal Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. "L2TP Over AAL5 and FUNI", A. Lin, Michael Davison, J. Stephens, Ajoy Singh, Rollins Turner, 11/18/1998, The Layer Two Tunneling Protocol (L2TP) [1] provides a standard method for transporting the link layer of PPP [2] 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 ATM network for the underlying network connection. Both ATM UNI [3] with ATM Adaptation Layer 5 [4] (AAL5) and ATM with Frame based User-to-Network Interface (FUNI) [5] are supported as interfaces to the ATM network. "Deriving MPPE Keys From MS-CHAP V1 Credentials", Glen Zorn, 09/22/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) [3] is a Microsoft-proprietary PPP authentication protocol, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks. Microsoft Point to Point Encryption (MPPE) [4] is a means of represent- ing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive the initial MPPE ses- sion keys from MS-CHAP credentials. The algorithm used to change ses- sion keys during a session is described in [4]. "Deriving MPPE Keys From MS-CHAP V2 Credentials", Glen Zorn, 11/16/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. Version 2 of the Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-2) [3] is a Microsoft-proprietary PPP authentication protocol, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks. Microsoft Point to Point Encryption (MPPE) [4] is a means of representing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the ses- sion key to be used for initializing encryption tables can be negoti- ated. MPPE currently supports 40-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive the initial MPPE ses- sion keys from MS-CHAP-2 credentials. The algorithm used to change ses- sion keys during a session is described in [4]. "Microsoft PPP CHAP Extensions, Version 2", Glen Zorn, 11/18/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document describes version two of Microsoft's PPP CHAP dialect (MS- CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication. The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in an appendix. "PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing", James Carlson, James Manchester, Paul Langner, 11/06/1998, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 [2] and 1619 [3] provide a means to carry PPP over Synchronous Optical Network (SONET) [5] and Synchronous Digital Hierarchy (SDH) [6] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL) [7]. SDL provides a very low overhead alternative to standard HDLC encapsulation for SONET/SDH links. This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. "Framework for L2TP Message Extensions", Richard Shea, 11/17/1998, The Layer Two Tunneling Protocol (L2TP) defines mechanisms for extensibility. The mechanisms provided are for Attribute-Value Pair (AVP) fields received in control messages to be set as Mandatory or not. This document specifies a mechanism whereby an L2TP implementation can signal its support of the set of L2TP extensions that it supports. This then allows the L2TP implementations to use extensions such as L2TP message types not defined in [1], the presence of existing AVPs in messages they are not currently defined to be in, and the definition of new AVPs that can be marked as Mandatory, beyond those defined in [1]. "Mobile PPP (MPPP)", Jacob Teplitsky, M. Chuah, Donald Grosser, G. Rai, 11/17/1998, This document describes a new feature for L2TP: it allows for a change of LACs during the lifetime of a PPP session without the latency of re-creating a new PPP session where possible. This feature is specially useful for wireless data services where the foreign wireless service provider (WSP) may be different than the user's home service provider and where a user's mobility may result in a change of LAC during an on-going PPP session. This proposal presents 3 different methods of supporting this feature. The simplest method requires only minor changes to both LACs and LNSs. However, it may give a larger handover latency. The other two methods have shorter handover latency and allow us to extend the L2TP session by an additional hop. "Always On Dynamic ISDN (AODI).", Matt Holdrege, Andrew Kuzma, 11/18/1998, Always On/Dynamic ISDN (AO/DI) is a networking service that provides an always-available connection to TCP/IP-based services through a specific wide area connection. This service provides several advantages over current practices for dial-up access to Internet services. * For the end-user, there is no need to dial-up the service each time access is desired. * For the Internet service provider, it is possible to give the end-user a notification, such as the arrival of new mail. * For the Local Exchange Carrier, the switched circuit trunk utilization is more efficient. "L2TP Link Extensions", William Palter, W. Mark Townsley, 11/23/1998, The physical separation of the LAC and LNS with L2TP[2] and logical separation of the responsibilities of each with respect to negotiated link parameters introduces a lack of awareness between the tunnel endpoints that does not exist in a typical PPP dialup device. When possible, Proxy LCP provides a manner in which to negotiate link parameters at the LAC and communication of these in full to the LNS. If these options can be made acceptable to the LNS, then there should not be any insurmountable difficulty with regard to mismatch of link expectations. However, given that there are instances where negotiation of LCP[1] must take place at the LNS, some direction by the LAC as to what parameters are acceptable, as well as some communication from the LNS as to what parameters have been negotiated, is desirable. Printer MIB (printmib) ---------------------- "Job Monitoring MIB - V1", T. Hastings, H. Lewis, S. Isaacson, R. Bergman, 02/09/1998, This document has been developed and approved by the Printer Working Group (PWG) as a PWG standard. It is intended to be distributed as an Informational RFC. This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB", R. Bergman, 09/21/1998, This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. "Printer Finishing MIB", H. Lewis, R. Bergman, 11/19/1998, This document defines a printer industry standard SNMP MIB for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB does not apply to a Finisher Device that is not connected to a Printer System. The Finisher MIB is defined as an extension of the Printer MIB [PrtMIB] and it is expected that the information defined in this document will be incorporated into a future update of the Printer MIB. Physical Topology MIB (ptopomib) -------------------------------- "Physical Topology MIB", Ken Jones, Andy Bierman, 11/16/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. "Physical Topology Discovery Protocol and MIB", Keith McCloghrie, Andy Bierman, 11/16/1998, This memo defines an experimental protocol, and an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a physical topology discovery protocol and managed objects used for managing the protocol. Remote Authentication Dial-In User Service (radius) --------------------------------------------------- "Implementation of L2TP Compulsory Tunneling via RADIUS", B Aboba, Glen Zorn, 10/09/1998, This document discusses implementation issues arising in the provi- sioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. "RADIUS Attributes for Tunnel Protocol Support", J. Shriver, D. Leifer, Allan Rubens, Glen Zorn, 09/29/1998, This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. "Extensible Authentication Protocol Support in RADIUS", Allan Rubens, B Aboba, Pat Calhoun, 05/13/1998, The Extensible Authentication Protocol (EAP), described in [1], pro- vides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. In order to provide for support of EAP within RADIUS, two new attributes, EAP-Message and Sig- nature, were introduced as RADIUS extensions in [4]. This document describes how these new attributes may be used for providing EAP sup- port within RADIUS. "RADIUS Accounting Interim Accounting Record Extension", A. Ratcliffe, Pat Calhoun, M. Beadles, 01/27/1998, The RADIUS Accounting document [1] defines a mechanism which is used by a Network Access Server (NAS) to send accounting information to a RADIUS server. The current protocol defines a Start and Stop record. This document defines an interim record which is used to make the RADIUS accounting protocol more robust. "RADIUS Authentication Server MIB", B Aboba, Glen Zorn, 11/11/1998, This memo defines a set of extensions which instrument RADIUS authen- tication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management pro- tocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. "RADIUS Authentication Client MIB", B Aboba, Glen Zorn, 11/11/1998, This memo defines a set of extensions which instrument RADIUS authen- tication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management pro- tocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. "RADIUS Accounting Client MIB", B Aboba, Glen Zorn, 11/11/1998, This memo defines a set of extensions which instrument RADIUS account- ing client functions. These extensions represent a portion of the Man- agement Information Base (MIB) for use with network management proto- cols in the Internet community. Using these extensions IP-based man- agement stations can manage RADIUS accounting clients. "RADIUS Accounting Server MIB", B Aboba, Glen Zorn, 11/11/1998, This memo defines a set of extensions which instrument RADIUS account- ing server functions. These extensions represent a portion of the Man- agement Information Base (MIB) for use with network management proto- cols in the Internet community. Using these extensions IP-based man- agement stations can manage RADIUS accounting servers. "RADIUS Attributes for MS-CHAP Support", Glen Zorn, 11/06/1997, This document describes a set of vendor-specific RADIUS attributes designed to support the use of Microsoft's proprietary dialect of PPP CHAP (MS-CHAP) in dial-up networks. MS-CHAP is derived from and (where possible) consistent with PPP CHAP [1]; the differences between PPP CHAP and MS-CHAP are significant enough to warrant the definition of new RADIUS attributes, however. "RADIUS Attributes for MS-CHAP Support", Glen Zorn, 11/18/1997, This document describes a set of vendor-specific RADIUS attributes designed to support the use of Microsoft's proprietary dialect of PPP CHAP (MS-CHAP) in dial-up networks. MS-CHAP is derived from and (where possible) consistent with PPP CHAP [1]; the differences between PPP CHAP and MS-CHAP are significant enough to warrant the definition of new RADIUS attributes, however. "RADIUS IP Security Extensions", Pat Calhoun, Sumit Vakil, 11/10/1997, The RADIUS Authentication/Authorization protocol defines a mechanism which is used by a Network Access Server (NAS) to authenticate dial-up users. IP Security defines a mechanism of establishing a secure link between two entities over a network. This document defines a mechanism for RADIUS to inform the NAS of the security policies required for secure communication with a host. "RADIUS Accounting Modifications for Tunnel Protocol Support", Glen Zorn, David Mitton, 09/08/1998, This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks. "Salt-Encryption of RADIUS Attributes", Daniel Fox, Paul Funk, David Mitton, Oliver Tavakoli, 12/04/1997, This document defines a general mechanism for encrypting attributes within RADIUS packets. This mechanism permits more than one attribute within a RADIUS transaction (request and response) to be encrypted without compromising the security of the encryption. "RADIUS Attributes for Multilink PPP Banwidth Allocation Control", Glen Zorn, 02/16/1998, This document describes a set of vendor-specific RADIUS attributes designed to support the dynamic control of bandwidth allocation in mul- tilink PPP [1]. Attributes are defined that specify whether use of the PPP Bandwidth Allocation Protocol [2] is allowed or required on incoming calls, the level of line capacity (expressed as a percentage) below which utilization must fall before a link is eligible to be dropped, and the length of time (in seconds) that a link must be underutilized before it is dropped. "RADIUS Attributes for Multilink PPP Banwidth Allocation Control", Glen Zorn, 02/25/1998, This document describes a set of vendor-specific RADIUS attributes designed to support the dynamic control of bandwidth allocation in mul- tilink PPP [1]. Attributes are defined that specify whether use of the PPP Bandwidth Allocation Protocol [2] is allowed or required on incoming calls, the level of line capacity (expressed as a percentage) below which utilization must fall before a link is eligible to be dropped, and the length of time (in seconds) that a link must be underutilized before it is dropped. "Support for Mobile IP in RADIUS", B Aboba, 04/20/1998, RFC 2002 describes the framework for Mobile IP, while RFC 2290 describes how a mobile node and a peer negotiate the appropriate use of Mobile IP over a PPP link, through use of the IPCP IP Address and Mobile-IPv4 Configuration Options. This document describes how Mobile IP is supported within RADIUS. "Microsoft Vendor-specific RADIUS Attributes", Glen Zorn, 10/27/1998, This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft propri- etary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-spe- cific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. RSVP Admission Policy (rap) --------------------------- "A Framework for Policy-based Admission Control", R. Yavatkar, R. Guerin, D. Pendarakis, 11/20/1998, The IETF working groups such as Integrated Services (called 'int-serv') and RSVP [1] have developed extensions to the IP architecture and the best-effort service model so that applications or end users can request specific quality (or levels) of service from an internetwork in addition to the current IP best-effort service. Recent efforts in the Differen- tiated Services Working Group are also directed at definition of mechan- isms that support aggregate QoS services. The int-serv model for these new services requires explicit signaling of the QoS (Quality of Service) requirements from the end points and provision of admission and traffic control at Integrated Services routers. The proposed standards for RSVP [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a new reservation setup protocol and new service definitions respectively. Under the int-serv model, certain data flows receive preferential treat- ment over other flows; the admission control component only takes into account the requester's resource reservation request and available capa- city to determine whether or not to accept a QoS request. However, the int-serv mechanisms do not include an important aspect of admission con- trol: network managers and service providers must be able to monitor, con- trol, and enforce use of network resources and services based on policies derived from criteria such as the identity of users and applications, traffic/bandwidth requirements, security considerations, and time-of- day/week. Similarly, diff-serv mechanisms also need to take into account policies that take into account various criteria such as customer iden- tity, ingress points, and so on. "The COPS (Common Open Policy Service) Protocol", Shai Herzog, A. Sastry, R. Rajan, Ron Cohen, J. Boyle, David Durham, 11/23/1998, This document describes a simple client/server model for supporting policy control over QoS Signaling Protocols and provisioned QoS resource management. It is designed to be extensible so that other kinds of policy clients may be supported in the future. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. "RSVP Extensions for Policy Control", Shai Herzog, 11/20/1998, This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVPSP] These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events. This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [Fwk, COPS, COPS-RSVP]. "User Identity Representation for RSVP", Peter Ford, Shai Herzog, Ramesh Pabbati, Satyendra Yadav, 03/16/1998, This document describes the representation of user identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner of the communicating process (e.g. user id) and convey this information in RSVP requests (PATH or RESV) in a secure manner. We describe the encoding of user identity as RSVP policy element. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. "COPS Usage for Differentiated Services", R. Yavatkar, Keith McCloghrie, Shai Herzog, Francis Reichmeyer, David Durham, Kwok Chan, Silvano Gai, 11/20/1998, There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of services, and specific business requirements. The IETF has chartered the Differentiated Service WG to define the differentiated services architecture and a common language for differentiated services. In parallel, the IETF RSVP Admission Policy (RAP) WG has defined the COPS (Common Open Policy Service) protocol [COPS]. This document describes enhancements to the Common Open Policy Service (COPS) protocol to support policy services in a Differentiated Services (DiffServ) environment. Further modifications to COPS for DiffServ may be proposed in the future, but what is presented here is thought to be the minimum necessary additions. "COPS usage for RSVP", Shai Herzog, A. Sastry, R. Rajan, Ron Cohen, David Durham, Jim Boyle, 11/20/1998, This document describes usage directives for supporting COPS policy services in RSVP environments. "Identity Representation for RSVP", Shai Herzog, Ramesh Pabbati, Satyendra Yadav, Tim Moore, 11/23/1998, This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. Routing Information Protocol (rip) ---------------------------------- "RIP Version 2 MIB Extension", G. Malkin, Fred Baker, 06/26/1998, 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 RIP Version 2. "RIPv2 Domain Of Interpretation (DOI) for ISAKMP", Ran Atkinson, 10/16/1997, The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the RIPv2 DOI, which is defined to cover the use of ISAKMP to negotiate Security Associations for the RIPv2 routing protocol. Remote Network Monitoring (rmonmib) ----------------------------------- "Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0", Steven Waldbusser, Dan Romascanu, W. Lahaye, R. Waterman, 11/03/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. "Remote Network Monitoring MIB Protocol Identifier Macros", C. Bucci, R. Iddon, Andy Bierman, 11/16/1998, This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RMONPROT_REF]. This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document. The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RMONPROT_REF], and an 'RMON Protocol Identifier Macros' document (this document) which contains the non-normative portion of that specification. "Remote Network Monitoring Management Information Base for High Capacity Networks", Steven Waldbusser, 11/02/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This memo does not specify a standard for the Internet community. "Remote Network Monitoring MIB Protocol Identifier Reference", C. Bucci, R. Iddon, Andy Bierman, 11/16/1998, This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included. The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON Protocol Identifier Macros document [RMONPROT_MAC] now contains the non-normative portion of that specification. Roaming Operations (roamops) ---------------------------- "Roaming Requirements", B Aboba, Glen Zorn, 08/07/1998, This document describes requirements for the provisioning of 'roaming capability' for dialup Internet users. 'Roaming capability' is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. "The Network Access Identifier", B Aboba, M. Beadles, 11/20/1998, In order to enhance the interoperability of roaming and tunneling ser- vices, it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identi- fier (NAI), the userID submitted by the client during PPP authentica- tion. It is expected that this will be of interest for support of roaming as well as tunneling. 'Roaming capability' may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor rela- tionship with only one. Examples of where roaming capabilities might be required include ISP 'confederations' and ISP-provided corporate network access support. "The Accounting Data Interchange Format (ADIF)", B Aboba, D. Lidyard, 11/18/1998, This document proposes a standard accounting record format, the Accounting Data Interchange Format (ADIF), which is designed to com- pactly represent accounting data in a protocol-independent manner. As a result, ADIF may be used to represent accounting data from any pro- tocol using attribute value pairs (AVPs) or variable bindings. "Proxy Chaining and Policy Implementation in Roaming", J. Vollbrecht, B Aboba, 10/19/1998, This document describes the use of proxy chaining in roaming and how policy may be implemented concurrently with end-to-end security. "Secure Radius Server Operation Guidelines for Dial Roaming ", Y. Jiang, 10/21/1997, Authenticating and authorizing roaming dialup users requires messages to be exchanged among facilities managed by two or more service providers, and secure operation of the facilities is of vital importance. This document provides guidelines for operating such facilities when using the Remote Authentication Dial In User Service (RADIUS) protocol and the companion accounting protocol for authentication and accounting message exchange. "An LDAP Schema for Phone Books", Glen Zorn, 03/16/1998, This document describes an LDAP schema for the attributes to be included in the standard phone book. Goals of this document include: - Creating a flexible, extensible and robust framework upon which to build a standard phone book - Promoting a standard phone book format, to enhance interoperability between ISPs and roaming consortia Non-goals of this document include: - Attempting to create a ''Swiss army knife'', with phone book attributes to please everyone on Earth - Definition of either server-server or client-server phone book update or transfer protocols "End-to-End Security in Roaming", B Aboba, Pat Calhoun, 07/24/1998, As noted in Roaming Requirements, there is a need for end-to-end secu- rity in roaming, including end-to-end integrity protection, and confi- dentiality. In roaming implementations based on proxy chaining, pack- ets are routed between the NAS and home server through a series of proxies. Current roaming implementations provide only hop-by-hop security, guarding only against modification of packets in transit between hops. This makes it possible for untrusted proxies to modify packets sent between a NAS and a home server without detection, as well as to decrypt PAP passwords, Tunnel passwords, and other hidden attributes which are available to it in cleartext. This document provides a framework for end-to-end security in roaming, making it possible to provide end-to-end message integrity and attribute hiding through addition of three new attributes. Routing Policy System (rps) --------------------------- "Using RPSL in Practice", David Meyer, Cengiz Alaettinoglu, J. Schmitz, Carol Orange, 11/23/1998, This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in the IRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations. This document is targeted towards an Internet/Network Service Provider (ISP/NSP) engineer who understands Internet routing, but is new to RPSL and to the IRR. Readers are referred to the RPSL reference document [1] for completeness. It is also good to have that document at hand while working through this tutorial. "RIPE-181 to RPSL Transition Plan", David Kessens, Carol Orange, 11/24/1997, The standardization of RPSL (Routing Policy Specification Language) is imminent, and there is a user community eager to make use of the power- ful features it offers in the Routing Registry (IRR). Thus, a plan of action is needed to assure a successful transition from the RIPE-181 language currently employed to describe routing policies in the IRR to the more expressive RPSL. This document describes such a plan, which the authors believe can be used to bring about a successful transition in a timely fashion with a minimum of disruption to the IRR and its cur- rent role in Internet routing. This document will be modified to reflect the progress of the transition if appropriate. "Routing Policy System Security", David Meyer, Curtis Villamizar, Cengiz Alaettinoglu, S. Murphy, Carol Orange, 05/15/1998, The RIPE database specifications [2] and RPSL language [1] define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues on importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. "PGP authentication for RIPE database updates", Janos Zsako, 11/23/1998, This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force. "Distributed Routing Policy System", David Meyer, Curtis Villamizar, Cengiz Alaettinoglu, R. Govindan, 09/30/1998, The RIPE database specifications [2] and RPSL language [1] define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues on importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrety to be of any use. The Routing Policy System Security internet-draft [3] addresses the need to assure integrety of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate author- ity for data subsets to multiple repositories without compromising the au- thorization model extablished in [3]. "Routing Policy Specification Language (RPSL)", E. Gerich, Daniel Karrenberg, David Meyer, M Terpstra, Curtis Villamizar, Cengiz Alaettinoglu, T. Bates, David Kessens, 11/19/1998, This Internet Draft is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. RPSL is a replacement for the current Internet policy specification language known as RIPE-181 [5] or RFC-1786 [6]. RIPE-81 [7] was the first language deployed in the Internet for specifying routing policies. It was later replaced by RIPE-181 [5]. Through operational use of RIPE-181 it has become apparent that certain policies cannot be specified and a need for an enhanced and more generalized language is needed. RPSL addresses RIPE-181's limitations. Resource Reservation Setup Protocol (rsvp) ------------------------------------------ "RSVP Cryptographic Authentication", Fred Baker, Bob Lindell, Mohit Talwar, 11/24/1998, This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. "RSRR: A Routing Interface For RSVP", D. Zappala, Jeff Kann, 07/01/1998, This memo describes version 2 of RSRR, a routing interface for RSVP. By using this interface, RSVP may obtain forwarding information from routers and use it to place reservation state within the network. Version 1 of this interface was designed primarily for RSVP interaction with IPv4 multicast routing protocols. Version 2 adds support for IPv4 unicast as well as IPv6 unicast and multicast routing. A backwards compatibility mechanism is provided. "RSVP Diagnostic Messages", Lixia Zhang, Bob Braden, Andreas Terzis, S. Vincent, 11/19/1998, This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along the path. This specification describes the functionality, diagnostic message formats, and processing rules. "RSVP Operation Over IP Tunnels", Lixia Zhang, John Krawczyk, John Wroclawski, Andreas Terzis, 08/06/1998, This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then pre- sent the details of an implementation which meets our design goals. "RSVP Management Information Base",, 10/13/1997, 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 the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. "RSVP Management Information Base",, 04/15/1998, 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 the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. "Preemption Priority Policy Element", Shai Herzog, 11/20/1998, This document describes a preemption priority policy element for use by policy based admission protocols (such as [RSVP] and [COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high-priority flow. Realtime Traffic Flow Measurement (rtfm) ---------------------------------------- "RTFM Working Group - New Attributes for Traffic Flow Measurement", Gregory Ruth, Nevil Brownlee, Sig Handelman, Stephen Stibler, 10/05/1998, The Real-Time Flow Measurement (RTFM) Working Group (WG) has developed a system for measuring and reporting information about traffic flows in the Internet. This document explores the definition of extensions to the flow measurements as currently defined in [1]. The new attributes described in this document will be useful for monitoring network performance and will expand the scope of RTFM beyond simple measurement of traffic volumes. A companion document to this draft will be written to define MIB structures for the new attributes. This draft was started in 1996 to advance the work of the RTFM group. The goal of this work is to produce a simple set of abstractions, which can be easily implemented and at the same time enhance the value of RTFM Meters. This document also defines a method for organizing the flow abstractions to augment the existing RTFM flow table. Implementations of the RTFM Meter have been done by Nevil Brownlee in the University of Auckland, NZ, and Stephen Stibler and Sig Handelman at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role of the Meter Reader whose role is to retrieve flow data from the Meter. Note on flows and positioning of meters: A flow as it traverses the Internet may have some of its characteristics altered as it travels through Routers, Switches, and other network units. It is important to note the spatial location of the Meter when referring to attributes of a flow. An example, a server may send a sequence of packets with a definite order, and inter packet timing with a leaky bucket algorithm. A meter reading downstream of the leaky bucket would record a set with minimal inter packet timing due to the leaky bucket. At the client's location, the packets may arrive out of sequence, with the timings altered. A meter at the client's location would record different attributes for the "Traffic Flow Measurement: Meter MIB", Nevil Brownlee, 09/11/1998, A 'Traffic Meter' collects data relating to traffic flows within a network. This document defines a Management Information Base (MIB) for use in controlling a traffic meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. "Traffic Flow Measurement: Architecture", Gregory Ruth, Nevil Brownlee, Cyndi Mills, 09/11/1998, This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. "SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups", Nevil Brownlee, 09/11/1998, This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. Although the language is primarily intended for RTFM traffic flows, it should also be useful in other areas as a general way of specifying flows to be measured or collected. "RTFM: Applicability Statement", Nevil Brownlee, 10/15/1998, This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. Responsible Use of the Network (run) ------------------------------------ "DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)", Sally Hambridge, A. Lunde, 11/24/1998, This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow. "$$$$$ MAKE ENEMIES FAST $$$$$ or How to Advertise Responsibly Using the Internet", Don Eastlake, Sally Hambridge, 03/10/1998, Contrary to popular belief, the Internet did not spring fully-clothed from Zeus's head, but it did grow like kudzu. This growth engendered a large new user population some of whom are more than willing to use the Internet in ways for which it was never intended. This seems to be especially true about people who are new to the Internet and see it as the perfect advertising vehicle. Those people are sure to ''make enemies fast'' by sending mass unsolicited mailing or posting advertisements heedlessly to news groups. This document gives some guidelines and advice about how to advertise responsibly using the Internet. Schema Registration (schema) ---------------------------- "Requirements for the Initial Release of a Directory Schema Listing Service", Chris Apple, 04/22/1998, This memo documents requirements for listing directory services schema in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. "Directory Schema Listing File Names", Chris Apple, 04/22/1998, This memo specifies a file name syntax for use by the primary listing repository operator of the directory schema listing service. "Directory Schema Listing Procedures", Michael Mealling, Chris Apple, 04/22/1998, This memo documents procedures for listing directory service schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. "Directory Schema Listing Meta Data", Chris Apple, 04/22/1998, This memo defines a MIME directory profile for content transfer and encoding of metadata elements used for cataloging schema listings in a directory schema listing service. "MIME Directory Profile for LDAP Schema", M. Wahl, 08/03/1998, This document defines a MIME directory profile [1] for holding an LDAP [2] schema. It is intended for communication with the Internet schema listing service. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [4]. "A MIME Directory Profile for RWhois 1.5 Schema", Michael Mealling, 03/16/1998, This document defines two MIME directory profiles [1] for holding a RWhois 1.5 [2] schema. It is intended for communication with the Internet schema listing service [3]. One profile defines an attribute and the other defines a class. "A MIME Content-Type for WHOIS", R. Moats, 04/08/1998, This document defines a MIME directory profile [1] for holding a WHOIS [2] schema and is intended for communication with the Internet schema listing service. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [3]. "MIME Directory Profiles for Listing Whois++ Schema", Leslie Daigle, 04/23/1998, This document defines two MIME directory profiles [HOWE1] necessary for supporting the definition of Whois++ [FALT1] templates (schemas). It is intended for communication with the Internet schema listing service ([APPL1], [APPL2], [APPL3], [APPL4]). The profiles defined are: schema-whoispp-0 whoispp-attr-0 Also, 5 MIME directory types are defined: wpp-template-name wpp-template-desc wpp-attr-ptr wpp-attr-name wpp-attr-desc Secure Shell (secsh) -------------------- "SSH Transport Layer Protocol", T. Rinne, T. Ylonen, Tero Kivinen, Markku Juhani Saarinen, Sami Lehtinen, 08/06/1998, SSH is a protocol for secure remote login and other secure network ser- vices over an insecure network. This document describes the SSH trans- port layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It pro- vides strong encryption, server authentication, and integrity protec- tion. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algo- rithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer proto- col. "SSH Authentication Protocol", T. Rinne, T. Ylonen, Tero Kivinen, Markku Juhani Saarinen, Sami Lehtinen, 08/06/1998, SSH is a protocol for secure remote login and other secure network ser- vices over an insecure network. This document describes the SSH authen- tication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are deferred to separate documents. The SSH authentication protocol runs on top the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. "SSH Connection Protocol", T. Rinne, T. Ylonen, Tero Kivinen, Markku Juhani Saarinen, Sami Lehtinen, 08/06/1998, SSH is a protocol for secure remote login and other secure network ser- vices over an insecure network. This document describes the SSH connec- tion protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connec- tions. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. "SSH Protocol Architecture", T. Rinne, T. Ylonen, Tero Kivinen, Markku Juhani Saarinen, Sami Lehtinen, 08/06/1998, SSH is a protocol for secure remote login and other secure network ser- vices over an insecure network. This document describes the architecture of the SSH protocol, and the notation and terminology used in SSH proto- col documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major com- ponents: Transport layer protocol provides server authentication, confi- dentiality, and integrity with perfect forward secrecy. User authentica- tion protocol authenticates the client to the server. Connection proto- col multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. S/MIME Mail Security (smime) ---------------------------- "Cryptographic Message Syntax", Russ Housley, 11/20/1998, This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 [RFC 2315]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . "Enhanced Security Services for S/MIME", Paul Hoffman, 10/20/1998, This document describes three optional security service extensions for S/MIME. These services provide functionality that is similar to the Message Security Protocol [MSP4], but are useful in many other environments, particularly business and finance. The services are: - signed receipts - security labels - secure mailing lists The services described here are extensions to S/MIME version 3 [SMIME3], and some of them can also be added to S/MIME version 2 [SMIME2]. The extensions described here will not cause an S/MIME version 3 recipient to be unable to read messages from an S/MIME version 2 sender. However, some of the extensions will cause messages created by an S/MIME version 3 sender to be unreadable by an S/MIME version 2 recipient. The format of the messages are described in ASN.1:1988 [ASN1-1988]. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at . "S/MIME Version 3 Certificate Handling", B. Ramsdell, 08/07/1998, S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the S/MIME-specific requirements documented in this I-D in addition to those stated in [KEYM]. This specification is compatible with the Cryptographic Message Syntax [CMS] in that it uses the data types defined by CMS. It also inherits all the varieties of architectures for certificate-based key management supported by CMS. Note that the method S/MIME messages make certificate requests is defined in [SMIME-MSG]. "S/MIME Version 3 Message Specification", B. Ramsdell, 08/07/1998, S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. "Certificate Request Syntax", H. Prafullchandra, Barbara Fox, Xiaoyi Liu, M. Myers, Jeff Weinstein, 11/26/1997, This document defines an Internet PKI Certificate Request Syntax (CRS). It addresses a growing need within the Internet PKI community for an interface to public key certification products and services based on PKCS7 [PKCS7] and PKCS10 [PKCS10]. A small number of additional services are defined to supplement the core certificate request service. Current industry practice regarding the use of PKCS7 and PKCS10 is also documented for the benefit of the Internet community. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] which provides a superset of the PKCS7 syntax. Throughout this document, the term CMS should be taken to include the PKCS #7 document as defined in [PKCS7]. The term CRS refers to this specification. The chief differences between CRS and PKIXMGMT are: - Use of PKCS7 for security encapsulation and transaction framework - Use of PKCS10 as the certification request message content - Certification of Diffie-Hellman Public Keys based on PKCS10 requests - No assumption of reliable connectivity or persistent on-line operation - Single request/response transaction model "Signing Certificate Attribute Specification", Jim Schaad, 07/07/1998, A set of attacks on SignedData objects have been identified relating to the fact that the certificate to be used when verifying the signature in a SignerInfo is not cryptographically bound into the signature. This leads to a set of attacks where the certificate used to verify the signature is altered leading to possible incorrect results. This document describes these attacks and provides ways to deal with some of the attacks. "Certificate Distribution Specification", Jim Schaad, 10/13/1998, Current methods of publishing certificates in directory services are restricted to just certificates. This document provides a method of publishing certificates with secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . "Diffie-Hellman Key Agreement Method", E. Rescorla, 11/16/1998, This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 standard, developed by the ANSI X9F1 working group. Diffie-Hellam is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The D-H variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair. "Domain Security Services using S/MIME", Tim Dean, William Ottaway, 11/17/1998, This document describes how the S/MIME protocol can be processed and generated by a number of components of a messaging system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely - for example when two domains use incompatible messaging technologies such as X.400 and SMTP/MIME. This document is also applicable to organisations and enterprises that do not have encryption or signing capabilities at the desktop, but wish to interoperate securely using the S/MIME protocol. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at . SNA NAU Services MIB (snanau) ----------------------------- "Definitions of Managed Objects for APPN/HPR in IP Networks", B. Clouston, Robert Moore, 10/15/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications. SNMP Version 3 (snmpv3) ----------------------- "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", Bert Wijnen, U. Blumenthal, 11/23/1998, This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC-ARCH]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. "Introduction to Version 3 of the Internet-standard Network Management Framework", Russ Mundy, Jeffrey Case, Bob Stewart, D. Partain, 10/20/1998, The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard Management Framework (SNMPv1) and the second Internet-standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolu- tion of the Framework over time. "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", Keith McCloghrie, Bert Wijnen, Randy Presuhn, 11/23/1998, This document describes the View-based Access Control Model for use in the SNMP architecture [RFC-ARCH]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. "An Architecture for Describing SNMP Management Frameworks", Bert Wijnen, Randy Presuhn, D. Harrington, 11/18/1998, This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. "SNMPv3 Applications", Bob Stewart, D. Levi, P. Meyer, 10/22/1998, This memo describes five types of SNMP applications which make use of an SNMP engine as described in [SNMP-ARCH]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This memo will obsolete RFC2273. "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", Rob Frye, Bert Wijnen, Shawn Routhier, D. Levi, 11/19/1998, 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 obsoletes RFC 1908 [13] and RFC2089 [14]. "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", Jeffrey Case, Bert Wijnen, Randy Presuhn, D. Harrington, 11/18/1998, This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. Simple Public Key Infrastructure (spki) --------------------------------------- "Simple Public Key Certificate", Butler Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas, 03/16/1998, This document specifies a standard form for digital certificates and access control lists. These structures bind either names or authorizations to keys or names that resolve to keys. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. These structures are also known under the name SDSI 2.0. "SPKI Requirements", C. Ellison, 10/26/1998, The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible. The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. "SPKI Certificate Theory", Butler Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas, 11/23/1998, The SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document. This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. "SPKI Examples", Butler Lampson, T. Ylonen, R. Rivest, W. Frantz, C. Ellison, B. Thomas, 03/11/1998, SPKI structures are defined for public keys, hash values, access control list (ACL) entries and certificates. This document gives examples of such structures for real world applications. The examples here are not tied to any specific application and should be taken as informative examples rather than standard formats. However, once applications are fielded using such structures and we have experience with them, we can consider publishing those formats as proposed standards. That effort is considered out of scope for this document. Site Security Handbook (ssh) ---------------------------- "Users' Security Handbook", G. Malkin, Erik Guttman, Lorna Leong, 11/20/1998, The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. Service Location Protocol (svrloc) ---------------------------------- "Finding Stuff (How to discover services)", M. Hamilton, R. Moats, 10/19/1998, This document proposes a possible solution to the problem of finding information about which services are being offered at a particular Internet domain. By using this approach, it is possible for clients to locate services in a domain with only prior knowledge of the domain name. "Service Location Protocol Modifications for IPv6", John Veizades, Erik Guttman, 10/27/1998, The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using IP based networks no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant of or less able to fulfill the demands of network administration. The Service Location Protocol is well defined for use over IPv4 networks [SLP]: This document defines its use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. This document equally applies to SLP, version 2 [SLPv2]. "Service Templates and service: Schemes", C Perkins, Erik Guttman, James Kempf, 11/18/1998, The 'service:' URL scheme name is used to define URLs (called 'service: URLs' in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users. This document describes a formal procedure for defining and standardizing new service types and attributes for use with the 'service:' scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable. They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings. "An API for Service Location", Erik Guttman, James Kempf, 11/17/1998, The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementions to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered with SLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database. "The 'wp' and 'yp' Abstract Service Types", R. Moats, 01/26/1998, This document presents definitions for the ''wp'' and ''yp'' abstract services. The ''wp'' service is for finding people, while the ''yp'' service if for finding general things (including people). "Advertising Services (Providing information to support service discovery)", M. Hamilton, R. Moats, 09/14/1998, This document proposes a solution to the problem of finding information about that services are being offered at a particular Internet domain, based on deployment experience with the Netfind White Pages directory software. This approach makes it possible to supply clients with more information than the DNS aliases that have been widely deployed in this role - notably the port numbers being used by servers. However, it is not without problems, and we have tried to take account of these. "Wide Area Network Service Location", Jonathan Rosenberg, H. Schulzrinne, Bernhard Suter, 12/03/1997, We propose extensions to the Service Location Protocol (SLP), which allow for registration and discovery of services scattered across the wide area network. We make use of scalable wide area multicast to allow agents within an administrative domain to learn about services within other domains. We also describe a new agent, the Brokering Agent (BA), which is responsible for providing information about a particular set of services types. "Conversion of LDAP Schemas to and from SLP Templates", Pete St. Pierre, 06/10/1998, The Lightweight Directory Access Protocol (LDAP) and Service Location Protocol (SLP) are both useful mechanisms for locating service related information on a network. While they do perform similar functions, the way in which the information they provide is formated is very different. This document describes a set of rules and mappings for translating between the ASN.1 based LDAP schema and an SLP Template as described in the ''Service Template and service:Scheme'' draft. "Service Location Protocol, Version 2", Mark Day, John Veizades, C Perkins, Erik Guttman, 11/18/1998, The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. "Definition of printer: URLs for use with Service Location", S. Isaacson, Pete St. Pierre, 03/16/1998, This document defines the printer service type and the attributes associated with it. This template is designed to be used in conjuction with the Service Location Protocol [1], but may be used with any directory service supporting attribute/value pair registration. The printer service type is designed as an abstract service type. It is expected that printers advertised with the printer type may be accessible by one or more protocols. IPP and lpr are a two examples of printing protocols that may be used to perform the actual printing function. "SNMP MIB for SLP Directory Agents", Pete St. Pierre, 11/26/1997, This memo defines a Management Information Base (MIB) for the Service Location Protocol (SLP). The MIB describes the statistics and alerts required to allow management of Service Location Protocol enabled entities. The SLP MIB conforms to the Structure of Management Information (SMI), as described in RFC 1902. It is intended for use with the Simple Network Management Protocol, version 2. "The Systems Management Abstract Service Type", Mark Day, 03/09/1998, This document presents definitions for the ''sysman'' (systems management) abstract service, and the ''dmi'' (desktop management interface), ''cim'' (common information model), ''snmp'' (simple network management protocol), and ''host'' concrete service types. These definitions are suitable for use with the Service Location Protocol [1]. Systems management, as used in this document, relates to the monitoring, diagnosing, service and support of desktop and host computers. "Definition of afp: URLs for use with Service Location", Leland Wallace, 10/29/1998, This document defines the service:file-sharing:afp scheme and attributes associated with it. This template is designed to be used in conjuction with the Service Location Protocol [1], but may be used with any directory service supporting attribute/value pair registration. "The jndi-drivers Abstract Service Type", James Kempf, Jonathan Wood, 06/26/1998, This document describes the jndi-drivers abstract type. The jndi-drivers service provides access to drivers (also known as service provider classes) for the Java Naming and Directory Interface (JNDI). This type can be used in conjunction with the Service Location Protocol. "The Service Agent Service Type", Erik Guttman, 06/26/1998, This document describes the Service Agent service type. Service Agents are one of three types of agents used in the Service Location Protocol, Version 2 [1]. The Service Agent advertises all services on a given host which have been enabled to use SLPv2. "The Directory Agent Service Type", Erik Guttman, 07/29/1998, This document describes the Directory Agent service type. Directory Agents are one of three types of agents used in the Service Location Protocol, Version 2 [1]. The Directory Agent caches services for a set of Service Agents which have been enabled to use SLPv2. User Agents issue requests of Directory Agents to discover services. TCP Implementation (tcpimpl) ---------------------------- "Known TCP Implementation Problems", Bernard Volz, I. Heavens, Bill Fenner, Scott Dawson, Vern Paxson, Mark Allman, Kevin Lahey, Jeff Semke, Jim Griner, 11/09/1998, This memo catalogs a number of known TCP implementation problems. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is hoped that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet. "TCP Implementation Problems That Need To Be Documented", Vern Paxson, Mark Allman, 03/12/1998, The TCP-IMPL working group has documented a number of TCP implementation problems [PADHV98]. However, a significant number still have not been fully described and documented in the form used in [PADHV98]. This memo briefly describes a number of these, including commentary as to the authors' opinions regarding the importance of documenting the problem. This memo is *not* intended to ever see light as an RFC of some form; its sole function is to facilitate working group discussion of which problems are more pressing to document than others, and to aid in arriving at a decision as to when [PADHV98] will be sufficiently complete to merit its publication as an Informational RFC. We divide the descriptions into ''serious'' problems, meaning those we think should be included in [PADHV98] prior to its publication; ''security'' problems, which might not be viewed as implementation problems per se, but represent significant security problems of which TCP implementors should be aware; and ''less serious'' problems, those that, if the working group fails to find volunteers to document them, should not hold up [PADHV98]. It might be worthwhile to separate the security problems out into their own document. We particularly solicit working group input on this subject. "Issues in TCP Slow-Start Restart After Idle", J. Touch, John Heidemann, Amy Hughes, 04/10/1998, This draft discusses variations in the TCP 'slow-start restart' (SSR) algorithm, and the unintended failure of some variations to properly restart in some environments. SSR is intended to avoid line-rate bursts after idle periods, where TCP accumulates permission to send in the form of ACKs, but does not consume that permission immediately. SSR's original 'restart after send is idle' is commonly implemented as 'restart after receive is idle'. The latter unintentionally fails to restart for bidirectional connections where the sender's burst is triggered by a reverse-path data packet, such as in persistent HTTP. Both the former and latter are shown to permit bursts in other circumstances. Three solutions are discussed, and their implementations evaluated. This document is a product of the LSAM project at ISI. Comments are solicited and should be addressed to the authors. "TCP Congestion Control", W. Stevens, Vern Paxson, Mark Allman, 11/09/1998, This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. "The NewReno Modification to TCP's Fast Recovery Algorithm", Sally Floyd, Tom Henderson, 11/10/1998, RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2001-bis [RFC2001-bis] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to ``partial acknowledgments'' (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. TCP Over Satellite (tcpsat) --------------------------- "Enhancing TCP Over Satellite Channels using Standard Mechanisms", Luis Sanchez, Dan Glover, Mark Allman, 09/21/1998, The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards). "Ongoing TCP Research Related to Satellites", J. Touch, S. Ostermann, Dan Glover, Mark Allman, John Heidemann, Spencer Dawkins, Jeff Semke, Keith Scott, Jim Griner, Diepchi Tran, Tom Henderson, Hans Kruse, 11/20/1998, This document outlines TCP mechanisms that may help better utilize the available bandwidth in TCP transfers over long-delay satellite channels. The work outlined in this document is preliminary and has not yet been judged to be safe for use in the shared Internet. In addition, some of the work outlined in this document has been shown to be unsafe for shared networks, but may be acceptable for use in private networks. Transport Layer Security (tls) ------------------------------ "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", M. Hur, A. Medvinsky, 09/21/1998, This document proposes the addition of new cipher suites to the TLS protocol [1] to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication. "The TLS Protocol Version 1.0", C. Allen, T. Dierks, 11/12/1998, This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "HTTP Over TLS", E. Rescorla, 03/13/1998, This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the prede- cessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP. "TLS extensions for AttributeCertificate based authorization", S. Farrell, 09/22/1998, This document describes extensions to [TLS] providing authorization support based on the use of X.509 AttributeCertificates. "ECC Cipher Suites For TLS", T. Dierks, Bill Anderson, 03/16/1998, This document describes additions to TLS to support the Elliptic Curve Cryptosystem (ECC). The document assumes that the reader is familiar with the TLS protocol. The document defines cipher suites which use the Elliptic Curve Encryption Scheme (ECES), the Elliptic Curve Digital Signature Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme with Appendix (ECNRA), the Elliptic Curve Diffie-Hellman Key Agreement (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key Agreement (ECMQV) key establishment algorithms. References to these algorithms can be found in section 13. "An Internet AttributeCertificate Profile for Authorization", S. Farrell, 09/22/1998, Authorization support is required for various Internet protocols, for example, TLS, CMS and their consumers, and others. The X.509 AttributeCertificate provides a structure which can form the basis for such services [X.509]. This specification defines two profiles (a simple one and a 'full' one) for the use of X.509 AttributeCertificates to provide such authorization services. "Upgrading to TLS Within HTTP/1.1", R. Khare, 11/18/1998, This memo proposes a mechanism to upgrade HTTP/1.1 connections to use Transport Layer Security (TLS). Using an Upgrade: TLS/x.y request header would allow unsecured and secured traffic to share the same port (in this case, 80). A companion document describes the current practice of using a separate port for HTTP over TLS, . Telnet TN3270 Enhancements (tn3270e) ------------------------------------ "Base Definitions of Managed Objects for TN3270E Using SMIv2", Robert Moore, K. White, 07/30/1998, This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], RFC 854 [16], and RFC 860 [17] for a sample of what is meant by TN3270 practices. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods. It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data. "Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)", Robert Moore, K. White, 07/30/1998, This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring of TN3270 and TN3270E Sessions. This MIB has as a prerequisite the TN3270E-MIB, reference [20]. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], RFC 854 [16], and RFC 860 [17] for a sample of what is meant by TN3270 practices. "TLS-based Telnet Security", Michael Boe, 09/09/1998, Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. "5250 Telnet Enhancements", Thomas Murphy, Paul Rieth, Jeffrey Stevens, 09/03/1998, This draft describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described. By allowing a Telnet client to select the device name, the 5250 Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are 1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing, 2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange. "LU6.2 over TCP/IP", Soumitra (Ronnie) Sarkar, James Carmichael, 02/26/1998, This draft describes IBM's support for running LU6.2 applications over a TCP/IP network. This support is provided using a subset of the X/Open architecture for Multiprotocol Transport Networking, which is a general protocol conversion architecture for running any application over any transport protocol. This draft is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. Any questions or comments relative to the contents of this draft should be sent to the following Internet address: carmich@us.ibm.com. "TN3270E Service Location and Session Balancing", Gregg (Vernon) Ledford, Jim Naugle, Kathuri Kasthurirangan, 07/30/1998, This document discusses the implementation of Service Location Protocol and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. Application program developer's can locate TN3270E services and load balance among those services (3270 host sessions), by using this Service Location Protocol support. "TN3270E Functional Extensions", Gene Pullen, Marty Williams, 09/02/1998, This draft addresses issues and implementation problems defined and discussed at the TN3270E/TN5250E Interoperability Events. It does not replace the current TN3270 Enhancements protocol. It describes functional extensions to the TN3270E protocol. The TN3270E function negotiation mechanism is used to allow the server and client to determine which, if any, of these functions will be supported during a session. This preserves backward compatibility between clients and servers that do not support these features. Among the issues to be address by this draft are SNA/TN3270E Contention state resolution, SNA Sense Code support, Function Management Header support, and TN3270E header byte-doubling suppression. "Open Host Interface Objects for TN3270E", Thomas Brawn, Stephen Gunn, 10/02/1998, The purpose of this memo is to define an object oriented interface to TN3270E. Internet Open Trading Protocol (trade) -------------------------------------- "Internet Open Trading Protocol - IOTP Version 1.0", Don Eastlake, 10/27/1998, The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. "Digital Signatures for XML", Richard Brown, 11/04/1998, A syntax and procedures for the computation and verification of XML digital signatures is specified. "Internet Open Trading Protocol (IOTP) HTTP Supplement", Don Eastlake, Chris Smith, 11/09/1998, Internet Open Trading Protocol (IOTP) messages will be carried as XML documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This documents describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. DS1/DS3 MIB (trunkmib) ---------------------- "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", D. Fowler, 08/12/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0, DS3/E3 and SONET/SDH Interface Types, rfcTBD [30], rfcTBD [28] and rfcTBD [29]. "Definitions of Managed Objects for the DS3/E3 Interface Type", D. Fowler, 08/11/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0, DS1/E1/DS2/E2 and SONET/SDH Interface Types, rfcTBD [25], rfcTBD [17] and rfcTBD [18]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. This document entirely replaces RFC 1407. "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type", D. Fowler, 08/11/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2, DS3/E3 and SONET/SDH Interface Types, RFC XXXX [17], RFC XXXX [18] and RFC XXXX [19]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. UniDirectional Link Routing (udlr) ---------------------------------- "An IP tunneling approach for Uni-directional Link routing",, 11/14/1997, Since digital multichannel TV broadcasting services have been started in many areas, low cost digital data receivers are available. They can be used for not only TV broadcasting service but also any kind of data communication services. A low cost receiver can receive high bandwidth traffic from a feed, while no bandwidth from the receiver to the feed is provided. Therefore the connection between the feed and the receiver is unidirectional. Current routing protocols stand on a fact that any links are bidirectional even if the bandwidth in each direction may be different. They can not handle unidirectional links. This document defines an idea to use unidirectional links (UDLs) routing without any modifications of current routing protocols. "Dynamic Tunneling Path Configuration for Uni-directional Link Routing",, 11/14/1997, The idea to use unidirectional link(UDL) routing without any modifications of current routing protocols is described in [1], but any dynamic tunneling path configuration technique was not described. This document describe the dynamic tunneling path configuration for UDL routing. "VIPRE -- Virtual Internet Packet Relay An Encapsulation Architecture for Unidirectional Links", J. Stepanek, S. Schwab, 11/14/1997, This memo describes a method of incorporating unidirectional links into an IP network in a bidirectional mode by relaying encapsulated IP packets over a bidirectional network. "Handling of unidirectional links with RIP", Christian Huitema, Emmanuel Duros, 11/14/1997, This document defines the modifications which can be applied to RIP [rfc1723] which make the communication over asymmetric links feasible. "Handling of unidirectional links with OSPF", Emmanuel Duros, 11/14/1997, This document defines the modifications which can be applied to OSPF [rfc1583] which make the communication over asymmetric links feasible. "Handling of unidirectional links with DVMRP", Walid Dabbous, Emmanuel Duros, 11/14/1997, This document defines the modifications which can be applied to DVMRP [rfc1075] which make the communication over asymmetric links feasible. "Supporting Unidirectional Paths in the Internet", Walid Dabbous, Emmanuel Duros, 11/14/1997, Many distributed applications may benefit from a high bandwidth connection to the Internet. However, this requires high bandwidth links between remotes sites. A low-cost solution to deliver high bandwidth services over wide geographical areas via the use of broadcast satellite networks has been proposed by [ASBD]. However, this solution is based on low cost receivers with zero bandwidth return. Connection over the satellite link is therefore unidirectional. The integration of these satellite networks with the Internet requires changes in common routing protocols. "Internet Architecture Considerations for Assymetric and Unidirectional Broadcast Links",, 11/30/1998, Satellite hops, the region between a basestation and a set of mobile nodes, and a number of other similar scenarios represent a challenge to providing IP connectivity at various levels due to the 1-many broadcast nature of the link. The UDLR group has addressed these problems in some limited situations. The general case, where multiple, possibly partially intersecting set of such hops are part of a general set of Internet Paths (or need to be considered in the route computation that will buld such paths) is complex. This note is an attempt to outline a framework for the general case. We include certain recent approaches to managing connectivity that also include quality of service, multiple alternate paths, and traffic engineering considerations. In this version of this note, we are discussing techniques for connectivity, so mechanisms and techniques described are applicable to routers. We would need a seperate (and hopefully much simpler) set of mechanisms to incorporate hosts that exist on a unidirectional link or path that includes such links. Uniform Resource Locator Registration Procedures (urlreg) --------------------------------------------------------- "Guidelines for new URL Schemes", Harald Alvestrand, Larry Masinter, Rich Petke, Dan Zigmond, 11/16/1998, A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes. "Uniform Resource Locators (URL): NOREG URL Naming Scheme", Y. Goland, 11/03/1997, This document proposes mapping DNS names into the URL scheme space for the purpose of preventing namespace collisions amongst URL schemes whose syntax and functionality are not appropriate for standardization. "Registration Procedures for URL Scheme Names", Rich Petke, 11/05/1998, This document defines the process by which new URL schemes are registered. "Some Alternatives to draft-ietf-urlreg-procedures-03", Rich Petke, 08/06/1998, This document defines some alternatives to the registration trees described in draft-ietf-urlreg-procedures-03.txt, hereafter referred to as 'the current registration procedures draft'. Uniform Resource Names (urn) ---------------------------- "URN Namespace Definition Mechanisms", Patrik Faltstrom, R. Iannella, Leslie Daigle, D. van Gulik, 10/26/1998, The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual 'namespaces' within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN 'namespaces'. "URI Resolution Services Necessary for URN Resolution", Michael Mealling, R. Daniel, 10/28/1998, Retrieving the resource identified by a Uniform Resource Identifier (URI) [1] is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. A service in the network providing access to a resource may provide one or some of these options, but it need not provide all of them. This memo specifies an initial set of these operations that can be used to describe the interactions provided by a given access service. It also suggests guidelines that should be adhered to when those operations are encoded in a protocol. "A URN Namespace for IETF Documents", R. Moats, 10/09/1998, A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the 'ietf' namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework and URN syntax support this namespace. "Assignment Procedures for the URI Resolution using DNS (RFC2168)", Michael Mealling, 11/23/1998, RFC2168 defines a DNS resource record and an algorithm for using DNS as a registry for retrieving URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'uri.net' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving 'http://foo.com/' would be to look up a NAPTR record for the domain 'http.uri.net'. URN resolution also follows a similar procedure but uses the 'urn.net' zone as its root. This document describes the procedures for inserting a new rule into the 'uri.net' and 'urn.net' zones. "The Naming Authority Pointer (NAPTR) DNS Resource Record", Michael Mealling, R. Daniel, 11/18/1998, This document describes a DNS Resource Record which specifies a rewrite rule that, when applied to an existing string will produce a new domain. Reasons for rewriting a domain vary from URN Resource Discovery Systems to moving out of date services to new domains. This document updates the portions of RFC2168 specifically dealing with the definition of the NAPTR record. "Resolution of Uniform Resource Identifiers using the Domain Name System",, 11/18/1998, The architectural principles laid out in RFC2276 [15] defines the concept of a 'resolver discovery service'. This document describes an immediately-deployable RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR) [16], that provides a method for encoding incrementally discovered rules within DNS. By using these incrementally discovered rules to re-map parts of a URI, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Identifier to Location, Identifier to Description, Identifier to Resource, ...) to be offered. In conjunction with the SRV RR, the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Usenet Article Standard Update (usefor) --------------------------------------- "Identification of messages delivered via both mail and news", J. Zawinski, Matt Curtin, 07/28/1998, This draft defines a format to be used when delivering a single message to multiple destinations, where some destinations are newsgroups and some destinations are email mailboxes. "News Article Format", Dan Ritter, 07/01/1998, This Draft defines the format of network news articles, and defines roles and responsibilities for humans and software. Network news articles resemble mail messages but are broadcast to potentially large audiences, using a flooding algorithm that propagates one copy to each interested host (or group thereof), typically stores only one copy per host, and does not require any central administration or systematic registration of interested users. Network news originated as the medium of communication for Usenet, circa 1980. The term 'Usenet' refers to the protocols established in RFC 1036 and successors; the software implementing those protocols; the network of hosts exchanging traffic using that software; and also the traffic itself. Cooperating subnets are possible; these are groups of hosts which agree to hold each other and themselves to an internally adopted set of standards concerning protocol details or implementations. When a cooperating subnet does not exchange traffic with general Usenet hosts, then it is no longer a part of Usenet, but a separate entity. Since then Usenet has grown explosively, and most Internet sites participate in it. In addition, the news technology is now in widespread use for other purposes, on the Internet and elsewhere. This document is intended to provide a definitive guide to the article format and interpretations thereof. Backward compatibility is a major goal, but where this document and earlier documents or practices collide, this document should be used. "Recommendations for generating Message IDs", J. Zawinski, Matt Curtin, 07/22/1998, This draft provides recommendations on how to generate globally unique Message IDs in client software. "Cancel-Locks in Usenet articles.", Simon Lyall, 11/03/1998, This document outlines a method that may be used by authors of successor (or canceling) articles to authenticate their authorship of the original article. As a proto-article article passes through various agents they may include the hash of a secret string in a Cancel-Key header. Later if they wish to use a standard mechanism to remove the original article (eg Cancel or Supersede) they can include this string in the Cancel-Lock header to verify that they are entitled to perform this operation. Familiarity with the current News Article Format draft [ARTICLE] is assumed. "Guidelines for the Generation of Message IDs and Similar Unique Identifiers", Claus Andre Faerber, 09/02/1998, [RFC822] and [RFC1036] define so-called 'Message-IDs' that represent a unique identifier for email and netnews messages. A similar identifier is also used by [RFC2045] for the 'Content-ID' label. For each of these protocols, uniqueness of the identifiers generated is more or less essential. Unfortunately, the original Message-ID specification requires that the generator have an own, non-temporary full qualified domain name available, which does not allow hosts that are connected via dialup lines and get dynamically assigned IP addresses (and hostnames) to generate unique IDs offline. This memo provides recommendations for the generation of such IDs without risking non-uniqueness. User Services (uswg) -------------------- "FYI on Questions and Answers Answers to Commonly asked New Internet User Questions", E. Krol, R. Plzak, Amy Tracy Wells, 10/27/1998, This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of the more a technically sophisticated Internet user. Users desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand the Internet. "Obsolete FYI Documents", April Marine, Philip Nesser II, 11/18/1998, Traditionally, the User Services Area of the IETF has been responsible for keeping FYI documents updated. However, as the Internet has progressed and developed, it has become clear that not all FYIs are worth updating. Some of the information is simply obsolete. This memo documents which FYIs are considered obsolete, and lets users know not to trust the information they contain. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2", Brian Jewell, David Chuang, 11/11/1998, This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is compliant with both the SNMPv2 SMI [5], and semantically identical to the SNMPv1 definitions [2]. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "HTTP Extensions for Distributed Authoring -- WEBDAV", Jim Whitehead, D. Jensen, S. Carter, Y. Goland, A. Faizi, 11/17/1998, This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). "WebDAV Tree Operations", Y. Goland, 11/11/1997, The WebDAV protocol specification [Goland et al., 1997] defines the DELETE, COPY and MOVE methods. However these methods have a scope of a single source resource. It is common for principals to wish to perform a DELETE, COPY or MOVE on a collection and all its internal members. This specification defines the DELETE-TREE, COPY-TREE and MOVE-TREE methods that perform the equivalent of DELETE, COPY and MOVE across a collection and all its progeny. "WebDAV ACL Protocol", P. Leach, Y. Goland, 11/11/1997, This memo specifies the format and manipulation mechanisms for access control lists (ACLs) for WebDAV objects. "Requirements for Access Control within Distributed Authoring and Versioning Environments on the World Wide Web", Howard Palmer, 11/20/1997, To provide a robust model for modifying documents and data within a distributed World Wide Web authoring environment, it is necessary to furnish a methodology which controls access to objects. Access control may include the ability to read an object, modify an object, or perform other more advanced functions upon an object. Access control is necessary to prevent unauthorized access or modification of objects within the authoring environment which could lead to unintended loss, damage or disclosure of data. This document proposes requirements for the support of access control within a Web Distributed Authoring and Versioning (WebDAV) environment. It describes a model for the representation and interpretation of access control policies, and a set of operations needed to manage policies in that form. It is intended that these requirements be supported within the framework of the proposed WebDAV extensions [WEBDAV1] to HTTP [HTTP], in the form of additional protocol operations and compliance requirements for clients and servers "Requirements for Advanced Collection Functionality in WebDAV", J. Slein, Jim Davis, 11/09/1998, The base WebDAV protocol [WebDAV] provides basic support for collections. It defines a MKCOL method for creating collections and specifies how other HTTP and WebDAV methods interact with collections. It supports internal members of collections, which it defines as members whose URIs are immediately relative to the URI of the collection. This draft sets out requirements for more advanced, optional collection functionality. It extends the base functionality in two general directions: support for referential members, and support for ordered collections. A separate WebDAV specification is expected to define protocol elements providing the functionality described here. "Requirements for Event Notification Protocol", Mark Fisher, Surendra Reddy, 05/05/1998, This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the Internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. This document is one of a set of documents which together describe all aspects of a new Event Notification Protocol (ENP). ENP is an application level protocol that can be used for distributed event notification. The full set of ENP documents include: (1). Requirements for Event Notification Protocol (2). Model and Semantics Event Notification Protocol (3). Protocol Specification for Event Notification Protocol (4). Rationale for the Structure and Model for the Event Notification Protocol "WebDAV Advanced Collections Protocol", Jim Whitehead, J. Slein, Jim Davis, Alan Babich, 11/09/1998, The base WebDAV protocol [WebDAV] provides basic support for collections. It defines a MKCOL method for creating collections and specifies how other HTTP and WebDAV methods interact with collections. It supports internal members of collections, which it defines as members whose URIs are immediately relative to the URI of the collection. Many applications, however, need more powerful collections. There are two areas in particular where more powerful functionality is often needed: referential resources and ordering. This draft specifies extensions to the base WebDAV protocol to support these more powerful collections. "Versioning Extensions to WebDAV", Christopher Kaler, 10/28/1998, This document specifies a set of methods, headers, and content- types composing DAV Versioning extensions, an application of the HTTP/1.1 protocol to version DAV resources. "WebDAV Access Control Goals", Lisa Lippert, 08/10/1998, This document defines goals for an access control system for use with the WebDAV protocol. Access control systems grant or deny rights (such as 'read' or 'write') to specified principals for individual resources. "Use of Dublin Core Metadata in WebDAV", John Stracke, 10/09/1998, This document specifies a standard mapping for using the metadata vocabulary of Dublin Core ([DUBLIN]) in a WebDAV ([WEBDAV]) server. Web Transaction Security (wts) ------------------------------ "The Secure HyperText Transfer Protocol", A. Schiffman, E. Rescorla, 06/26/1998, This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applica- ble security services for transaction confidentiality, authenticity/ integrity and non-repudiability of origin. The protocol emphasizes maximum flexibility in choice of key manage- ment mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. "Security Extensions For HTML", A. Schiffman, E. Rescorla, 06/26/1998, This memo describes a syntax for embedding S-HTTP negotiation parame- ters in HTML documents. S-HTTP as described by draft-ietf-wts-shttp- 03.txt contains the concept of negotation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.