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. Authentication, Authorization and Accounting (aaa) -------------------------------------------------- "AAA Problem Statements", Pat Calhoun, 17-Jan-02, The AAA Evaluation Team's recommendation document raised some issues with the DIAMETER protocol. The AAA WG has created a design team to address these issues. This document is an attempt to describe the problems, which the WG can then concentrate on solving. "Authentication, Authorization and Accounting (AAA) Transport Profile", Bernard Aboba, Jonathan Wood, 07-Jan-03, This document discusses transport issues that arise with protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. "Diameter Base Protocol", Pat Calhoun, 22-Jan-03, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This draft specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. "Diameter Mobile IPv4 Application", Pat Calhoun, Tony Johansson, Charles Perkins, 29-Apr-03, This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IP services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. "Diameter Network Access Server Application", Pat Calhoun, Glen Zorn, David Spence, David Mitton, 14-Feb-03, This document describes Diameter applications that are used for Authentication, Authorization and Accounting (AAA) in the Network Access Server (NAS) environment. This application, combined with the Diameter base protocol, Transport Profile, EAP and CMS Security specifications, satisfies typical network access services requirements. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application was carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space, and eliminating the need to perform many attribute translations. "The DIAMETER API", James Kempf, Pat Calhoun, David Frascone, 08-Nov-02, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. "Diameter CMS Security Application", Pat Calhoun, Stephen Farrell, William Bulley, 05-Mar-02, The Diameter base protocol leverages either IPsec or TLS for integrity and confidentiality between two Diameter peers, and allows the peers to communicate through relay and proxy agents. Relay agents perform message routing, and other than routing AVPs, do not modify Diameter messages. Proxy agents, on the other hand, implement policy enforcement, and actively modify Diameter messages. "Diameter Extensible Authentication Protocol (EAP) Application", Tom Hiller, Glen Zorn, 07-Mar-03, The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary for a Diameter node to support the PPP Extensible Authentication Protocol (EAP). "Diameter Credit-control Application", Harri Hakala, 11-Jun-03, This document specifies a DIAMETER application that can be used to implement real-time credit-control for a variety of end user services such as network access, SIP services, messaging services, download services etc. Application Configuration Access Protocol (acap) ------------------------------------------------ "ACAP Personal Addressbook Dataset Class", Chris Newman, 27-Nov-02, Internet Message Access Protocol (IMAP) 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 a mechanism for storage of personal addressbooks. While ACAP permits the definition of vendor specific solutions to this problem, having a documented addressbook dataset class permits clients from different vendors to interoperably share the same personal addressbooks. This specification defines an ACAP dataset class for personal addressbooks. "ACAP Application Options Dataset Class", Steve Hole, Alexey Melnikov, 02-Dec-02, The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of application option, configura- tion and preference information. The generalized form of this run- time 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, Alexey Melnikov, 06-Jan-03, With the definition of standardized media types in MIME 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 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. Application Configuration Access Protocol (ACAP) provides appropriate facilities for this need. ACAP's dataset structure is extensible and ACAP's inheritance feature provides for enterprise default settings with per-user customization. This memo defines an ACAP dataset class for media type mapping tables. "ACAP Bookmarks Dataset Class", Randall Gellens, 03-Mar-03, 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 between users. This specification defines a standard ACAP dataset class for bookmarks. "ACAP Email Account Dataset Class", Randall Gellens, 03-Mar-03, 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 email 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 email account. "ACAP Email Personality Dataset Class", Randall Gellens, 03-Mar-03, 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. An SMTP URL scheme is also defined. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", Bob Ray, Rajesh Abbi, 12-Jun-03, This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Bob Ray, Rajesh Abbi, 12-Jun-03, This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 2493 to 64 bit resolution using the conventions presented in RFC 2856. AToM MIB (atommib) ------------------ "Definitions of Supplemental Managed Objects for ATM Interface", Faye Ly, Michael Noto, Andrew Smith, Ethan Spiegel, Kaj Tesink, 14-May-03, This memo defines objects used for managing ATM-based interfaces, devices, and services in addition to those defined in the ATM-MIB [24], to provide additional support for the management of: - ATM Switched Virtual Connections (SVCs) - ATM Permanent Virtual Connections (PVCs) "Definitions of Managed Objects for the Optical Interface Type", Kam Lam, Mark Stewart, Anni Huynh, 16-Jan-03, This memo defines a portion of the Management Information Base (MIB) for use with SNMP in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. "Definitions of Managed Objects for the SONET/SDH Interface Type", Kaj Tesink, 07-Jan-03, 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 [RFC2496][RFC2495]. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. "Definitions of Managed Objects for the DS3/E3 Interface Type", Orly Nicklass, 01-Jul-03, 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 DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", Orly Nicklass, 01-Jul-03, 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 DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document entirely replaces RFC 2495. "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Kaj Tesink, 07-Jan-03, This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. Audio/Video Transport (avt) --------------------------- "RTP Profile for Audio and Video Conferences with Minimal Control", Henning Schulzrinne, Stephen Casner, 07-Mar-03, This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards- compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. "RTP: A Transport Protocol for Real-Time Applications", Henning Schulzrinne, Stephen Casner, Ron Frederick, Van Jacobson, 07-Mar-03, This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. "MIME Type Registration of RTP Payload Formats", Stephen Casner, Philipp Hoschka, 29-Nov-01, This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. "SDP Bandwidth Modifiers for RTCP Bandwidth", Stephen Casner, 29-Nov-01, This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTCP packets in a Real-Time Transport Protocol (RTP) session. "Tunneling multiplexed Compressed RTP ('TCRTP')", B Thompson, Tmima Koren, Dan Wing, 07-Nov-02, This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path to reduce the bandwidth used when multiple RTP streams are carried over that path. This method was selected by the IETF Audio/Video Transport working group as best satisfying the need for standardized RTP multiplexing because it preserves full RTP semantics. Other methods may be more highly optimized for particular applications by constraining their applicability, for example to a small set of encodings and a subset of the RTP semantics. Those other methods may be more appropriate as proprietary protocols rather than standards. "Enhanced Compressed RTP (CRTP) for links with high delay,packet loss and reordering", Tmima Koren, Stephen Casner, 03-Mar-03, This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. "An RTP Payload Format for Generic FEC with Uneven Level Protection", Adam Li, 07-Nov-02, This document specifies a payload format for generic forward error correction to achieve uneven level protection (ULP) for media data encapsulated in RTP. It is based on the same exclusive-or (parity) operation as in RFC 2733 [1], but it generalized and included the algorithms of that RFC. This draft will obsolete RFC 2733 and RFC 3009. The payload format described in this draft allows end systems to apply protection using arbitrary protection lengths and levels, in addition to using arbitrary protection group sizes. It also enables both complete recovery or partial recovery of the critical payload and RTP header fields depending on the packet loss situation. This scheme is completely backward compatible with non-FEC capable hosts. Those receivers that do not know about ULP forward error correction can simply ignore the extensions. "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams", Guenther Liebl, 06-Mar-03, This document specifies an efficient way to ensure erasure- resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon (RS) codes together with interleaving. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By applying interleaving and RS codes a payload format is defined, which can be easily integrated into the existing framework for RTP. "The Secure Real-time Transport Protocol", Mark Baugher, 03-Jun-03, This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP/RTCP traffic. "Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)", Joerg Ott, Stephan Wenger, 11-Jun-03, Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of RTCP to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term as sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allow for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. "RTP Payload Format for Transport of MPEG-4 Elementary Streams", Jan Van der Meer, d Mackie, V Swaminathan, David Singer, Philippe Gentric, 27-Feb-03, The MPEG Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream. "RTP Payload Format for ETSI ES 201 108 Distributed Speech Recognition Encoding", Qiaobing Xie, 04-Nov-02, This document specifies an RTP payload format for encapsulating ETSI Standard ES 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems [ES201108]. "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV", Adam Li, 11-Jun-02, This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 01-Jul-03, This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. "RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback", Julian Chesterfield, 05-Mar-03, This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism. "RTP Retransmission Payload Format", Jose Rey, 06-Jun-03, RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF), is available in this memo. "RTP Payload Format for JPEG 2000 Video Streams", Eric Edwards, 30-Jun-03, This document describes a payload format for transporting JPEG 2000 video streams using RTP (Real-time Transport Protocol). JPEG 2000 video streams are formed as a continuous series of JPEG 2000 still images. This payload format will allow for scalability and robustness of JPEG 2000's potential to be maximized in streaming applications. "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", Henning Schulzrinne, Scott Petrack, 02-Jul-03, This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. This document updates RFC 2833. "Internet Low Bit Rate Codec", Steven Andersen, 07-Mar-03, This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. "RTP Control Protocol Extended Reports (RTCP XR)", Timur Friedman, 21-May-03, This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. "RTP Payload Format for Uncompressed Video", Ladan Gharai, Charles Perkins, 01-Jul-03, This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. "A More Loss-Tolerant RTP Payload Format for MP3 Audio", Ross Finlayson, 24-Feb-03, This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as 'MP3'). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. "RTP payload Format for JVT Video", Stephan Wenger, 05-Mar-03, This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec. The most up-to-date draft of the video codec was specified in February 2003, is due for final approval at the committee level late March 2003, and is available for public review [1]. This codec was designed as a joint project of the Video Coding Experts Group (VCEG) of ITU-T and the Moving Picture Experts Group (MPEG) of ISO/IEC. ISO/IEC International Standard 14496-10 will be technically identical to ITU-T Recommendation H.264. "RTP Payload Format for iLBC Speech", Alan Duric, S Andersen, 07-Mar-03, This document describes the RTP payload format for the internet Low Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and SDP. "RTP payload format for a 64 kbit/s transparent call", Ruediger Kreuter, 07-Apr-03, This document describes how to carry 64 kbit/s data streams trans- parently in RTP packets, using a pseudo-codec called 'Clearmode'. It also serves as registration for a related MIME type called 'audio/clearmode'. 'Clearmode' is a basic feature of VoIP media gateways. Border Gateway Multicast Protocol (bgmp) ---------------------------------------- "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Dave Thaler, 06-Jun-03, This document describes BGMP, a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter- domain, distribution branches where needed. BGMP natively supports 'source-specific multicast' (SSM). To also support 'any-source multicast' (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the class D space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) 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 causing the root domain to be local to at least one of the session participants. Benchmarking Methodology (bmwg) ------------------------------- "Methodology for IP Multicast Benchmarking", Debra Stopp, B Hickman, 27-Jun-03, The purpose of this draft is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", Jerry Perser, David Newman, 19-Jun-03, This document describes terminology for the benchmarking of devices that implement traffic control based on IP precedence or diff-serv code point criteria. "Benchmarking Terminology for Routers Supporting Resource Reservation", Krisztian Nemeth, Istvan Cselenyi, Andras Korn, 30-Jun-03, The purpose of this document is to define terminology specific to the benchmarking of the resource reservation signaling of IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. "Terminology for Benchmarking BGP Device Convergence in the Control Plane", Howard Berkowitz, 07-Mar-03, This draft establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. "Methodology for Forwarding Information Base (FIB) based Router Performance", Guy Trotter, 13-Feb-03, The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This document describes the methodology to be used to determine the IP packet forwarding performance of an IP router as a function of the forwarding information base installed within a router. "OSPF Benchmarking Terminology and Concepts", Vishwas Manral, Richard White, Aman Shaikh, 22-May-03, This draft explains the terminology and concepts used in [BENCHMARK] and future OSPF benchmarking drafts, within the context of those drafts. While some of these terms may be defined elsewhere, and we will refer the reader to those definitions in some cases, we also include discussions concerning these terms as they relate specifically to the tasks involved in benchmarking the OSPF protocol. "Benchmarking Methodology for Basic OSPF Convergence", Vishwas Manral, Richard White, Aman Shaikh, 22-May-03, This draft establishes standards for measuring OSPF convergence performance on a single router (SR-Convergence [4]). Its initial emphasis is on the control plane of single OSPF routers. We do not address forwarding plane performance. NOTE: Within this document, the word convergence relates to single router control plane convergence only. "Benchmarking Applicability for Basic OSPF Convergence", Vishwas Manral, Richard White, Aman Shaikh, 22-May-03, This draft describes the applicability of [BENCHMARK] and similar work which may be done in the future. Refer to [TERM] for terminology used in this draft and [BENCHMARK]. The draft defines the advantages as well as limitations of using the method defined in [BENCHMARK], besides describing the pitfalls to avoid during measurement. "Terminology for Benchmarking IPsec Devices", Michele Bustos, 30-Jun-03, This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Benchmarking Methodology for IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, 19-Jun-03, This draft describes the methodology for benchmarking IGP Route Convergence. The applicability of this testing is described in [1] and the new terminology that it introduces is defined in [2]. Service Providers use IGP Convergence time as a key metric of router design and architecture. Customers of Service Providers observe convergence time by packet loss. IGP Route Convergence is a Direct Measure of Quality (DMOQ) when benchmarking the data plane and not the control plane. The test cases in this document are black-box tests that emulate the network events that cause route convergence, as described in [1]. Black-box test design accounts for all of the factors for route convergence time, as provided in [1]. The methodology and terminology is to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. "Terminology for Benchmarking IGP Data Plane Route Convergence", Scott Poretsky, 19-Jun-03, This draft describes the terminology for benchmarking IGP Route Convergence. The motivation and applicability for this benchmarking is provided in [1]. The methodology to be used for this benchmarking is described in [2]. The methodology and terminology to be used for benchmarking route convergence can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics. The purpose of this document is to introduce new terms required to complete execution of the IGP Route Convergence Methodology [2]. "Benchmarking Applicability for IGP Data Plane Route Convergence", Scott Poretsky, 19-Jun-03, This draft describes the applicability of IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence bechmarking terminology [2]. The methodology and terminology is to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [1]. "Terminology for Benchmarking Core Router Software Accelerated Life Testing", Scott Poretsky, 20-Jun-03, This terminology document provides the terms to be used for benchmarking router software under accelerated stress conditions. A framework is defined to configure routing protocols, security policies, traffic forwarding, and management. Conditions to produce instability and accelerate operational conditions are also defined. Benchmarks for evaluating a router subjected to the accelerated life test are introduced. The DUT configuration and accelerated stress conditions emulate those of Internet Core routers. Bridge MIB (bridge) ------------------- "Definitions of Managed Objects for Bridges", K Norseth, Ernest Bell, 09-Dec-02, 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 standard 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. The MIB presented in this memo is a direct translation of the BRIDGE MIB defined in [RFC1493], to the SMIv2 syntax required for current IETF MIB standards. This memo obsoletes RFC 1493. "Definitions for Port Access Control (IEEE 802.1X) MIB", K Norseth, 11-Feb-03, 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 managing the operation of Port Access Control, based on the specification contained in Clause 8 and Clause 9 of the IEEE 802.1X standard. This clause includes a MIB module that is SNMPv2 SMI compliant. This standard defines a mechanism for Port-based network access control that makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases in which the authentication and Calendaring and Scheduling (calsch) ----------------------------------- "Calendar Access Protocol (CAP)", Doug Royer, 05-Mar-03, The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). The CAP definition is based on requirements identified by 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/ietf-calendar and at the IETF web site at http:// www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the references within this memo for further information on how to access these various documents. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control", Eric Mannie, Dimitri Papadimitriou, 28-Feb-03, This document is a companion to the Generalized Multiprotocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. "Generalized Multi-Protocol Label Switching Architecture", Eric Mannie, 19-May-03, Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. "Link Management Protocol (LMP)", Jonathan Lang, 11-Jun-03, For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. "Routing Extensions in Support of Generalized MPLS", Kireeti Kompella, Yakov Rekhter, 28-Aug-02, This document specifies routing extensions in support of Generalized Multi-Protocol Label Switching (GMPLS). "OSPF Extensions in Support of Generalized MPLS", Kireeti Kompella, Yakov Rekhter, 03-Dec-02, This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching. "Generalized Multiprotocol Label Switching Extensions to Control Non-Standard SONET and SDH Features", Eric Mannie, Dimitri Papadimitriou, 31-May-02, This document is a companion to the Generalized Multiprotocol Label Switching (GMPLS) signaling extensions to control SONET and SDH that define the SONET/SDH technology specific information needed when using GMPLS signaling. This informational document defines GMPLS signaling extensions to control four optional non-standard (i.e. proprietary) SONET and SDH features: group signals, arbitrary concatenation, virtual concatenation of contiguously concatenated signals and per byte transparency. "Link Management Protocol Management Information Base", Martin Dubuc, 30-May-03, 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 for modeling the Link Management Protocol (LMP). "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", Andre Fredette, Jonathan Lang, 26-Mar-03, The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes; i.e., nodes that peer in signaling and/or routing. In this document we propose extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the 'Optical Link Interface Requirements' described in a companion document. "Framework for GMPLS-based Control of SDH/SONET Networks", Greg Bernstein, Eric Mannie, Vishal Sharma, 14-Feb-03, The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. One area of prime consideration is to use these generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to MPLS protocols that are directed towards controlling SONET/SDH networks. SONET/SDH networks make very good examples of this process since they possess a rich multiplex structure, a variety of protection/restoration options, are well defined, and are widely deployed. The document discusses extensions to MPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to MPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an MPLS control plane would bring to SONET/SDH networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. "Generalized MPLS Signaling - Implementation Survey", Lou Berger, Yakov Rekhter, 04-Nov-02, This document provides a survey of GMPLS signaling implementations. The primary focus of this survey are the signaling protocol mechanisms specified in the Generalized MPLS signaling documents. Other specifications and documents are listed if included in the submitted form. The survey form and latest version of this document are available from http://www.labn.net/gmpls-survey. "Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control", Dimitri Papadimitriou, 29-May-03, This document is a companion to the Generalized MPLS (GMPLS) signalling documents. It describes the technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", Eric Mannie, Dimitri Papadimitriou, 09-May-03, This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. "Tracing Requirements for Generic Tunnels", Ronald Bonica, Kireeti Kompella, David Meyer, 09-Jun-03, This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that 'traceroute' currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path. "SONET/SDH Encoding for Link Management Protocol (LMP) Test messages", Jonathan Lang, Dimitri Papadimitriou, 29-May-03, This document details the Synchronous Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH) technology specific information needed when sending Link Management Protocol (LMP) test messages. "GMPLS RSVP Support for the Overlay Model", George Swallow, 04-Mar-03, Generalized MPLS defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. "Analysis of Generalized MPLS-based Recovery Mechanisms (including Protection and Restoration)", Dimitri Papadimitriou, Eric Mannie, 27-May-03, This document provides an analysis grid that can be used to evaluate, compare and contrast the numerous Generalized MPLS (GMPLS)-based recovery mechanisms currently proposed at the CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in [CCAMP-TERM]. Also, this document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. "Generalized MPLS Recovery Functional Specification", Jonathan Lang, Bala Rajagopalan, 03-Feb-03, This document presents a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON)", Dimitri Papadimitriou, 01-Jul-03, The Generalized MPLS (GMPLS) suite of protocol has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signalling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements on the GMPLS signaling protocol to support the ASON functionality. "Exclude Routes - Extension to RSVP-TE", Adrian Farrel, 13-Jun-03, The current RSVP-TE specification, 'RSVP-TE: Extensions to RSVP for LSP Tunnels' (RFC 3209) and GMPLS extensions to RSVP-TE, 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions' (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some systems where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole of a path, or to parts of a path between two abstract nodes specified in an explicit route. Shared Risk Link Groups (SRLGs) allow the definition of resources or groups of resources that share the same risk of failure. The knowledge of SRLGs may be used to compute diverse paths that can be used for protection. In systems where it is useful to signal exclusions, it may be useful to signal SRLGs to indicate groups of resources that should be excluded on the whole of a path or between two abstract nodes specified in an explicit path. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. Content Distribution Internetworking (cdi) ------------------------------------------ "Known CN Request-Routing Mechanisms", A Barbir, Bradley Cain, 04-Apr-03, The work presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can beclassified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. "Distribution Requirements for Content Internetworking", Lisa Amini, 23-Dec-02, This document specifies requirements for interconnecting, or peering, the distribution systems of Content Networks (CN). Distribution internetworking requires advertising the capabilities of a CN offering distribution services, moving content from one CN to another, and signaling requirements for consistent storage and delivery of content. This document does not address requirements for directing user agents to distributed content, nor for aggregating access information for distributed content. "Content Internetworking (CDI) Scenarios", Phillip Rzewski, Mark Day, Don Gilletti, 25-Apr-02, In describing content internetworking as a technology targeted for use in production networks, it's useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. "Security Threat for Content Internetworking", Lisa Amini, 01-Oct-02, Content internetworking (also referred to as content distribution internetworking, or CDI) is the technology for interconnecting content networks. The CDI model allows for interconnecting various Content Networks. The internetworking task requires request routing and content distribution protocols. This document investigates the security risks and threats associated with the content internetworking. Proposed remedies are viewed not as design recommendations but more as illustrations of the nature of threats. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "Cross Registry Internet Service Protocol (CRISP) Requirements", A Newton, 12-May-03, Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. "IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service", A Newton, 02-Jul-03, This document describes an IRIS (draft-ietf-crisp-iris-core-00.txt ) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. "IRIS - The Internet Registry Information Service (IRIS) Core Protocol", A Newton, 02-Jul-03, This document describes an application layer client-server protocol for a framework of representing the query and result operations of the information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. "IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", A Newton, 02-Jul-03, This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS) as described draft-ietf-crisp-iris-core-00.txt. "IRIS - An Address Registry (areg) Type for the Internet Registry Information Service", A Newton, 02-Jul-03, This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for IP address information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. "The Federated Internet Registry Service:Architecture and Implementation Guide", Eric Hall, 27-May-03, This document describes the architectural framework for the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. "The Federated Internet Registry Service: Core Elements", Eric Hall, 27-May-03, This document describes the core technical elements of the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. "Defining and Locating DNS Domains in the Federated Internet Registry Service", Eric Hall, 27-May-03, This document defines LDAP schema and searching rules for DNS domain names, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. "Defining and Locating DNS Resource Records in the Federated Internet Registry Service", Eric Hall, 27-May-03, This document defines LDAP schema and searching rules for DNS resource records, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. "Defining and Locating Contact Information in the Federated Internet Registry Service", Eric Hall, 27-May-03, This document defines LDAP schema and searching rules for contact persons, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. "Defining and Locating IPv4 Address Blocks in the Federated Internet Registry Service", Eric Hall, 27-May-03, This document defines LDAP schema and searching rules for IPv4 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. "Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service", Eric Hall, 27-May-03, This document defines LDAP schema and searching rules for IPv6 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. "Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service", Eric Hall, 27-May-03, This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE] Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control", Sally Floyd, Eddie Kohler, 12-May-03, This document contains the profile for Congestion Control Identifier 2, TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP) [DCCP]. DCCP implements a congestion-controlled, unreliable flow of datagrams suitable for use by applications such as streaming media. The TCP-like Congestion Control CCID is used by senders who are able to adapt to the abrupt changes in the congestion window typical of the AIMD (Additive Increase Multiplicative Decrease) congestion control in TCP. TCP-like Congestion Control is particularly useful for senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions. "Problem Statement for DCCP", Sally Floyd, Mark Handley, Eddie Kohler, 24-Oct-02, This document gives the problem statement underlying the development of an unreliable transport protocol incorporating end-to-end congestion control. This is also the problem statement underlying the development of DCCP, the Datagram Congestion Control Protocol. DCCP implements a congestion- controlled, unreliable flow of datagrams suitable for use by applications such as streaming media or on-line games. "Profile for DCCP Congestion Control ID 3:TFRC Congestion Control", Jitendra Padhye, Sally Floyd, Eddie Kohler, 12-May-03, This document contains the profile for Congestion Control Identifier 3, TCP-friendly rate control (TFRC), in the Datagram Congestion Control Protocol (DCCP). DCCP implements a congestion-controlled unreliable datagram flow suitable for use by applications such as streaming media. The TFRC CCID is used by applications that want a TCP-friendly send rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. "Datagram Congestion Control Protocol (DCCP) User Guide", Damon Lanphear, 28-Oct-02, This document is an informative reference for the implementation of the Datagram Congestion Control Protocol (DCCP) and its interface with the application layer "Datagram Congestion Control Protocol (DCCP)", Eddie Kohler, 20-May-03, This document specifies the Datagram Congestion Control Protocol (DCCP), which implements a congestion-controlled, unreliable flow of datagrams suitable for use by applications such as streaming media. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Ralph Droms, 07-Nov-02, The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' (RFC2462), and can be used separately or concurrently with the latter to obtain configuration parameters "DHCP Failover Protocol", Ralph Droms, Kenneth Kinnear, 06-Mar-03, 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 such synchronization between two servers. One server is designated the 'primary' server, the other is the 'secondary' server. This document also describes a way to integrate the failover protocol with the DHCP load balancing approach. "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB", Richard Barr Hibbs, Glenn Waters, 06-Mar-03, 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 for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) servers. "The DHCP Client FQDN Option", Mark Stapp, Yakov Rekhter, 05-Nov-02, DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, and about responsibility for updating DNS RRs related to the client's DHCP lease. "Resolution of DNS Name Conflicts Among DHCP Clients", Mark Stapp, 05-Nov-02, DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS(RFC1034[1], RFC1035[2]), and specifically updating the name to address and address to name mappings maintained in the DNS. The 'Client FQDN Option'[14] specifies the client FQDN option, through which DHCP clients and servers can exchange information about client FQDNs. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. "DHCP Lease Query", Richard Woundy, Kenneth Kinnear, 20-Jun-03, A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. "VPN Identifier sub-option for the Relay Agent Information Option", Kenneth Kinnear, Mark Stapp, Richard Johnson, Jay Kumarasamy, 05-Nov-02, In some environments, a relay agent resides in a network element which also has access to one or more VPNs. If one DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know the VPN on which each client resides. The vpn- id sub-option of the relay-agent-information option is used by the relay agent to tell the DHCP server the VPN for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. "DHCP VPN Information option", Richard Johnson, Kenneth Kinnear, Mark Stapp, Jay Kumarasamy, 28-Oct-02, This memo defines a new DHCP option for passing VPN information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in situations where VPN information needs to be passed to the DHCP server for proper address allocation to take place. "DNS Configuration Options for DHCPv6", Ralph Droms, 04-Mar-03, This document describes DHCPv6 options for passing a list of available DNS Servers and a domain search list to a client. "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option", Ralph Droms, John Schnizlein, 04-Nov-02, A network access device may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of an IP address for assignment to the device through its DHCP client. The RADIUS Attributes sub-option allows a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. "NIS Configuration Options for DHCPv6", a Vijayabhaskar, 03-Mar-03, This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. "Time Configuration Options for DHCPv6", a Vijayabhaskar, 03-Mar-03, This document describes the options for Time related configuration information in DHCPv6: NTP Servers and Timezone specifier. "Considerations for the use of the Host Name option", Carl Smith, Ted Lemon, 06-Mar-03, This document clarifies the use of the DHCP Host Name option. The primary point of this clarification addresses the use of the option by clients to request proxy DNS updates by DHCP servers. "The IPv4 DHCP Options for the Internet Storage Name Service", Charles Monia, Josh Tseng, Kevin Gibbons, 20-Jun-03, This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. "Client Preferred Prefix option for DHCPv6", a Vijayabhaskar, 21-Mar-03, This document describes the Client Preferred Prefix option by which the client can specify its preferred prefixes on which the addresses need to be allocated by the server. "The Authentication Suboption for the DHCP Relay Agent Option", Mark Stapp, Ted Lemon, Ralph Droms, 05-Nov-02, The DHCP Relay Agent Information Option (RFC3046[1]) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines a new authentication suboption for that option which supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC3118[2]). "KDC Server Address Sub-option", Kevin Luehrs, 30-Jun-03, This document defines a new sub-option for the CableLabs Client Configuration (CCC) DHCP option code for conveying the network address of the Key Distribution Center (KDC) server. "IPv6 Prefix Options for DHCPv6", Ole Troan, Ralph Droms, 09-Jun-03, The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. "DHCP Option for Mobile IP Mobility Agents", Henrik Levkowetz, 28-Oct-02, This document defines a new Dynamic Host Configuration Protocol (DHCP) option with suboptions. One suboption is passed from the DHCP Server to the DHCP Client to announce the presence of one or more Mobile IP Mobility Agents. For each announced Mobility Agent, information is provided which is the same as that of the Mobile IP Agent Advertisement extension to ICMP Router Advertisements. There is also one suboption which may be used by a DHCP client to provide identity information to the DHCP server. "DHCP Subscriber ID Suboption for the DHCP Relay Agent Option", Richard Johnson, Ralph Droms, 02-Jul-03, This memo defines a new DHCP Relay Suboption for passing an arbitrary number of bytes defining what will be called the 'Subscriber ID'. This value is simply defined as an array of bytes and can be interpreted in any form by the DHCP server. Its intended purpose is to give additional information which the DHCP server can use in address allocation. "PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration Option", Paul Duffy, 20-Jun-03, This document defines a new sub-option for the CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate locally persisted Kerberos tickets. "DHCP Server-ID Override Suboption", Richard Johnson, 13-Feb-03, This memo defines a new suboption of the DHCP relay information option [6] which allows the DHCP relay to specify a new value for the Server-ID option, which is inserted by the DHCP Server. In some cases it is convenient for the DHCP relay to act as the actual DHCP server such that DHCP RENEWAL requests will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on RENEWAL messages. This new relay agent suboption allows the relay to tell the DHCP server what value to use in the Server-ID option [3]. If this suboption is not present, the server should build the Server-ID option in the normal fashion. "Unused DHCP Option Codes", Ralph Droms, 30-Jun-03, Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. "Results from Interoperability Tests of DHCPv6 Implementations", Ralph Droms, 08-Apr-03, This document publishes issues with the DHCPv6 protocols specifications, based on the results of interoperability testing among several implementations. "Subnet Allocation using DHCP", Richard Johnson, 25-Feb-03, This document defines a new DHCP option which is passed between the DHCP Client to the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. "Implementation Issues with RFC 2131, 'Dynamic Host Configuration Protocol'", Richard Barr Hibbs, 05-Mar-03, This memo identifies implementation issues with RFC 2131, 'Dynamic Host Configuration Protocol,' reported by a number of implementors, assesses the severity of the problem, then proposes changes to RFC 2131 intended to overcome the issues. This is intended for use as the basis for discussion of RFC 2131 before it is proposed for Internet Standard status. "A Guide to Implementing Stateless DHCPv6 Service", Ralph Droms, 07-Apr-03, Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. "The Authentication Suboption for the DHCP Relay Agent Option", Mark Stapp, Ted Lemon, Ralph Droms, 09-Jun-03, The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines two mechanisms for securing the messages exchanged between a relay agent and a server. The first mechanism defines a new authentication suboption for the Relay Agent Information Option that supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC 3118). The second mechanism uses IPsec (RFC 2041) to protect messages exchanged between relay agents and servers. "Extending DHCP Options Codes", Bernard Volz, Ralph Droms, Ted Lemon, 19-May-03, RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP public option space which is managed by IANA as documented in RFC 2939. As this public option space has few unassigned options at this time, it is prudent to define a mechanism to extend this option space before it is too late. This Internet-Draft proposes several means to extend this option space. "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", Richard Barr Hibbs, 18-Jun-03, DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. It did not provide for authentication of clients and servers, nor did it provide for data confidentiality. This is reflected in the original 'Security Considerations' section of RFC 2131, which identifies a few threats and leaves development of any defenses against those threats to future work. Beginning in about 1995 DHCP security began to attract attention from the Internet community, eventually resulting in the publication of RFC 3118 in 2001. Although RFC 3118 was a mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203, it has had no known usage by any commercial or private implementation since its adoption. The DHC Working Group has adopted a work item for 2003 to review and modify or replace RFC 3118 to afford a workable, easily deployed security mechanism for DHCPv4. This memo provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support our chartered work improving the acceptance and deployment of RFC 3118. "DHCP RSA/DSA Authentication using DNS KEY records", Ted Lemon, Michael Richardson, 26-Jun-03, This document defines a method for using a KEY record in the DNS belonging to a particular host to authenticate that host's DHCP transactions. Distributed Management (disman) ------------------------------- "Alarm MIB", Sharon Chisholm, Dan Romascanu, 10-Jun-03, 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 management objects used for defining and storing alarms. "Alarm Reporting Control MIB", Kam Lam, Anni Huynh, Don Perkins, 17-Apr-03, 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 controlling the reporting of alarm conditions. "Event MIB", Ramanathan Kavasseri, Bob Stewart, 16-Jun-03, 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 that can be used to manage and monitor MIB objects and take action through events. "Distributed Management Expression MIB", Ramanathan Kavasseri, Bob Stewart, 16-Jun-03, 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 expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. "Notification Log MIB", Ramanathan Kavasseri, Bill Stewart, 16-Jun-03, 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 logging Simple Network Management Protocol (SNMP) Notifications. "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", Juergen Quittek, Kenneth White, 20-Jun-03, This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. DNS Extensions (dnsext) ----------------------- "DNS Zone Transfer Protocol Clarifications", Andreas Gustafsson, 02-Dec-02, In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the 'zone transfer' protocol, also known as the 'AXFR' protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. "GSS Algorithm for TSIG (GSS-TSIG)", Stuart Kwan, Praerit Garg, James Gilroy, Levon Esibov, Jeff Westhead, Randy Hall, 04-Mar-03, 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) (RFC2743). This document updates RFC 2845. "A DNS RR for encoding DHCP information (DHCID RR)", Mark Stapp, Ted Lemon, Andreas Gustafsson, 05-Nov-02, It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. "DNS Security Document Roadmap", Scott Rose, 05-Feb-03, DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation-specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. "Handling of Unknown DNS Resource Record Types", Andreas Gustafsson, 30-Jun-03, Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. "Linklocal Multicast Name Resolution (LLMNR)", Levon Esibov, Bernard Aboba, Dave Thaler, 10-Jun-03, Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. "Redefinition of DNS AD bit", Brian Wellington, Olafur Gudmundsson, 28-Jun-02, Based on implementation experience, the RFC2535 definition of the Authenticated Data (AD) bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified or the server is authoritative for the data and is allowed to set the bit by policy. "Delegation Signer Resource Record", Olafur Gudmundsson, 19-Jun-03, The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. "DNSSEC Opt-in", Roy Arends, Mark Kosters, David Blacka, 03-Mar-03, In RFC 2535, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an 'Opt-In' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. "DNS Security Introduction and Requirements", Roy Arends, Rob Austein, Dan Massey, Matt Larson, Scott Rose, 19-Feb-03, The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. "Elliptic Curve KEYs in the DNS", R Schroeppel, Donald Eastlake, 07-Jan-03, A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described which utilizes DNS KEY resource record. "TKEY Secret Key Renewal Mode", Y Kamite, Masaya Nakayama, 05-Mar-03, This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing secret keys used for TSIG [RFC2845] periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. "Threat Analysis Of The Domain Name System", Derek Atkins, Rob Austein, 27-Jun-03, Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. "Resource Records for DNS Security Extensions", Roy Arends, 24-Mar-03, This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the KEY, DS, SIG, and NXT resource records. The purpose and format of each resource record is descibed in detail and an example of each resource record is given. "The DISCOVER opcode", Bill Manning, Paul Vixie, Erik Guttman, 06-Jan-03, The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. "KEY RR Secure Entry Point (SEP) Flag", Olaf Kolkman, Jacob Schlyter, Edward Lewis, 28-May-03, With the DS resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. "DNS Extensions to support IP version 6", Susan Thomson, Christian Huitema, 27-May-03, 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 resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This Document combines RFC1886 and changes to RFC 1886 made by RFC 3152, obsoleting both. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152. "Protocol Modifications for the DNS Security Extensions", Roy Arends, 05-Mar-03, This document is part of a family of documents which describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. "Domain Name Auto-Registration for Plugged-in IPv6 Nodes", Hiroshi Kitamura, 11-Dec-02, This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document describes the Domain Name Auto-Registration mechanism as a solution to these problems. "Domain Name System (DNS) Case Insensitivity Clarification", Donald Eastlake, 30-Apr-03, Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. "Legacy Resolver Compatibility for Delegation Signer", Samuel Weiler, 17-Jun-03, As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document proposes that these interactions be avoided by changing the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). "Clarifying the Role of Wild Card Domains in the Domain Name System", Bob Halley, Edward Lewis, 17-Jun-03, The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. Domain Name System Operations (dnsop) ------------------------------------- "Root Name Servers with Inter Domain Anycast Addresses", Masataka Ohta, 07-Nov-02, This memo describes an operational guideline for millions of name servers to share an interdomain anycast address. It enables people operate as many root name servers as they want and still make them traceable. "Requiring DNS IN-ADDR Mapping", Daniel Senie, 28-Mar-03, Mapping of addresses to names has been a feature of DNS. Many sites, implement it, many others don't. Some applications attempt to use it as a part of a security strategy. The goal of this document is to encourage proper deployment of address to name mappings, and provide guidance for their use. "Observed DNS Resolution Misbehavior", Matt Larson, Piet Barber, 25-Jun-03, This Internet-Draft describes DNS name server and stub resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. In some cases we recommend minor additions to the DNS protocol specification and corresponding changes in name server implementations to alleviate these unnecessary queries. In one case, we have highlighted behavior of a popular name server implementation that does not conform to the DNS specification. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. "Identifying an Authoritative Name Server", David Conrad, 06-Nov-02, A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid. This document describes an identification convention used in one widely deployed implementation of the DNS protocol and proposes a slight modification to that convention aimed at addressing some implementation concerns. "IPv6 DNS transition issues", Alain Durand, Johan Ihren, 07-Mar-03, This memo summarizes DNS related issues when transitioning a network to IPv6. Consensus and open issues are presented. "An Interim Scheme for Signing the Public DNS Root", Johan Ihren, 07-Mar-03, This memo documents a proposed mechanism for a first stage of a transition from an unsigned DNS root to a signed root, such that the data in the root zone is accompanied by DNSSEC signatures to allow validation. The underlying reason for signing the root zone is to be able to provide a more secure DNS hierarchy, where it is possible to distinguish false answers from correct answers. For the special case of the DNS root zone, an interim scheme is proposed. This scheme is mostly aimed at securing the root zone itself for technical and operational reasons, and to give operational experience of DNSSEC. "DNS Response Size Issues", Paul Vixie, Akira Kato, 18-Jun-03, With a mandated default minimum maximum message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit. "DNS IPv6 transport operational guidelines", Alain Durand, Johan Ihren, 19-Jun-03, This memo provides guidelines and best common practice to operate DNS in a mixed world of IPv4 and IPv6 transport. Extensible Authentication Protocol (eap) ---------------------------------------- "The One Time Password (OTP) and Generic Token Card Authentication Protocols", Larry Blunk, John Vollbrecht, Bernard Aboba, 14-Oct-02, EAP is an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document defines the One Time Password (OTP) and Generic Token Card EAP methods, both of which provide one-way authentication, but not key generation. As a result, the OTP and Generic Token Card methods, when used by themselves, are only appropriate for use on networks where physical security can be assumed. These methods SHOULD NOT be used on wireless networks, or over the Internet, unless the EAP conversation is protected. This can be accomplished using technologies such as IPsec or TLS. "Eap STate machinE dEsign teaM (ESTEEM) Discussions", Bernard Aboba, 10-Jan-03, This document describes the deliberations of the EAP STate MachinE DEsign TeaM (ESTEEM). This includes minutes of meetings, as well as position papers "Extensible Authentication Protocol (EAP)", Larry Blunk, 16-Jun-03, This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "Requirements for Inter-operable Internet EDI", Mats Jansson, Rik Drummond, Charles Shih, 09-Apr-01, 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 Peer-to-Peer Business Data Interchange over the Internet Using HTTP AS2", Dale Moberg, Rik Drummond, 03-Jun-03, This document describes how to exchange structured business data securely using HTTP transfer for XML, Binary, Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport) or other data describable in MIME used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original HTTP message. "Compressed Data for EDIINT", Terry Harding, 28-Mar-03, The intent of this document is to be placed on the RFC track as an Informational RFC. The EDIINT AS1 and AS2 message formats don't currently contain any transport neutral provisions for compressing data when utilizing S/MIME as the secure packaging standard. Compressing data before transmission provides a number of advantages including 1. reducing data redundancy, and so reducing opportunities for attacks exploiting redundancy, and 2. reducing the amount of data and so speeding up cryptographic processing such as signing, encryption, archiving, and 3. reducing the overall transmitted message size, reducing both time and bandwidth needed for transport. "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", Terry Harding, Richard Scott, 30-Jun-03, This document describes how to exchange structured business data securely using FTP transfer for XML, Binary, Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport) or other data describable in MIME used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original HTTP message. Entity MIB (entmib) ------------------- "Entity MIB (Version 3)", Keith McCloghrie, Andy Bierman, 12-May-03, 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 multiple logical and physical entities managed by a single SNMP agent. "Entity State MIB", Sharon Chisholm, David Perkins, 31-Jan-03, 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 extensions to the entity MIB to provide information about the state of the entity. Telephone Number Mapping (enum) ------------------------------- "The E.164 to URI DDDS Application (ENUM)", Patrik Faltstrom, Michael Mealling, 13-May-03, This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. "Extensible Provisioning Protocol E.164 Number Mapping", Scott Hollenbeck, 20-Feb-03, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. "ENUM Service Registration for H.323 URL", Orit Levin, 27-Jun-03, The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. "enumservice registration for SIP Addresses-of-Record", Jon Peterson, 26-Feb-03, This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. "Registration for enumservices of group messages", Rudolf Brandner, 16-Jun-03, This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:'. "Registration for enumservices web and ft", Rudolf Brandner, 16-Jun-03, This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are primarily sources for information. Specifically, the 'enumservices' registered with this document are 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:'. Internet Fax (fax) ------------------ "A Simple Mode of Facsimile Using Internet Mail", Kiyoshi Toyoda, Hiroyuki Ohno, Jun Murai, Dan Wing, 27-Nov-01, This specification provides for 'simple mode' carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 10, 11], and TIFF for Facsimile [5, 12, 14]. "File Format for Internet Fax", Robert Buckley, Dennis Venable, Lloyd McIntyre, Glenn Parsons, James Rafferty, 16-Jun-03, This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. "Timely Completion for Internet Messaging Services", Graham Klyne, Dave Crocker, 06-Nov-01, This specification provides a way to request timely completion for Internet mail delivery, for services such as facsimile and voice messaging. Traditional Internet mail uses a _postal_ mail model, with normal delivery having an indeterminate gap between delivery into a mailbox and processing by the recipient. Timely completion adds a timelines service feature and extends delivery processing all the way to the recipient. This specification provides a deterministic service quality response, while preserving most of the traditional roles and responsibilities of the agents involved in email transfers. "Internet FAX Gateway Functions", K Mimura, K Yokoyama, T Satoh, C Kanaide, 14-Apr-03, An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) and the Internet. This document provides information on recommended behaviors for Internet FAX Gateway functions for email-based Internet Fax. In this context, an offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to the Internet from the GSTN. This document covers the delivery process of data with equipment which may include Internet Fax terminals, PCs on the Internet, and Fax terminals on the GSTN. "Guideline of optional services for Internet FAX Gateway", K Mimura, K Yokoyama, T Satoh, Ken Watanabe, C Kanaide, 14-Apr-03, An Internet FAX Gateway provides functions which translate a facsimile between the general switched telephone network (GSTN) and the Internet. This document provides guidelines of optional services and examples of an Internet FAX Gateway, with respect to the onramp gateway and offramp gateway. This document does not intend to specify the actions to which the IFax offramp and onramp gateways (defined in [3]) conform. This document covers drop duplication, automatic re-transmission, error behavior, when sending a return notice, and the keep log for an offramp gateway. Also covered are examples of authorization by DTMF (Dual Tone Multi-Frequency) and the keep log for an onramp gateway. "SMTP Service Extension for Fax Content Negotiation", Kiyoshi Toyoda, Dave Crocker, 05-Jun-03, A message originator sometimes sends content in a form the recipient cannot process. Such content needs to be converted to a related form, with the same or with restricted information, such as changing from color to black and white. In a store-and-forward environment, it can be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content-types, to permit authorized, accountable content form conversion by intermediaries. "IFAX service of ENUM", Kiyoshi Toyoda, Dave Crocker, 03-Apr-03, This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is 'Facsimile using Internet Mail'. For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. "Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration", Lloyd McIntyre, 20-Jun-03, This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. Forwarding and Control Element Separation (forces) -------------------------------------------------- "Netlink as an IP Services Protocol", Jamal Hadi Salim, 16-Dec-02, This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. This document is intended as informational in the context of prior art for the ForCES IETF working group. The focus of this document is to describe Netlink from a perspective of a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. The document ignores the ability of Netlink as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). "Requirements for Separation of IP Control and Forwarding", Hormuzd Khosravi, Todd Anderson, 21-May-03, This document introduces the ForCES architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device. "ForCES Applicability Statement", Alan Crouch, Mark Handley, 27-Jun-03, The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Engines in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. "Forwarding and Control Element Separation (ForCES) Framework", Lily Yang, 12-Jun-03, This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and the interaction among them. Extensions to FTP (ftpext) -------------------------- "Extensions to FTP", Robert Elz, Paul Hethmon, 23-Sep-02, This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. Geographic Location/Privacy (geopriv) ------------------------------------- "Geopriv requirements", Jorge Cuellar, John Morris, Deirdre Mulligan, 05-Mar-03, Location-based services, navigation applications, emergency services, management of equipment in the field, and other location- dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protecting the privacy of the individuals involved. This document focuses on the authorization, integrity and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the geopriv Location Object (used to securely transfer location data and other privacy-enabling information) and for the protocols that use this Location Object. "DHC Location Object within GEOPRIV", James Polk, John Schnizlein, Marc Linsner, 16-Jan-03, This document specifies a Dynamic Host Configuration Protocol Option for the geographic location of the client. The location object includes latitude, longitude, and altitude, with resolution indicators for each. "Threat Analysis of the geopriv Protocol", Michelle Danley, 26-Feb-03, This document provides some analysis of threats against the geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by geopriv. Some security properties that meet these threats are enumerated as a reference for geopriv requirements. "Location Configuration Information for GEOPRIV", James Polk, Marc Linsner, 11-Jun-03, This document specifies a Dynamic Host Configuration Protocol Option for the geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each, as well as for the datum of the location. "DHCP Option for Civil Location", , 02-Jul-03, This document specifies a Dynamic Host Configuration Protocol option for the civil (country, street and community) location of the client. Global Routing Operations (grow) -------------------------------- "Controlling the redistribution of BGP routes", Olivier Bonaventure, 02-Jun-03, This document proposes the redistribution extended community. This new extended community allows a router to influence how a specific route should be redistributed towards a specified set of eBGP speakers. Several types of redistribution communities are proposed. The first type may be used to indicate that a specific route should not be announced over a specified set of eBGP sessions. The second type may be used to indicate that the attached route should only be announced with the NO_EXPORT community over the specified set of eBGP sessions and the third type may be used to indicate that the attached route should be prepended n times when announced over a specified set of eBGP sessions. "Bounding Longest Match Considered", Ted Hardie, Robert White, 03-Jun-03, Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. General Switch Management Protocol (gsmp) ----------------------------------------- "Requirements For Adding Optical Support To GSMPv3", Hormuzd Khosravi, 12-Jun-03, This memo provides requirements for adding of optical switching support to the General Switch Management (GSMP) protocol. It also contains clarifications and suggested changes to the GSMP v3 specification. "General Switch Management Protocol (GSMP) v3 for Optical Support", Jin Choi, 01-Jul-03, This document describes the General Switch Management Protocol version 3 (GSMPv3) for the support of optical switching. GSMPv3 controller SHOULD control optical label switches and manage optical resources on them. This document describes the extended functions of GSMPv3 for optical switching and explains operational mechanisms to implement them. It SHOULD be referred with [1] for the complete implementation. "GSMPv3 Base Specification", Avri Doria, 07-Mar-03, This document describes the base General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. "GSMPv3 Packet Capable Switch Support", Kenneth Sundell, 27-Jun-03, The General Switch Management Protocol version 3 (GSMPv3) has been divided into a base specification (describing the semantics of the protocol) together with a set of documents describing protocol extensions to the base. Such extension could be to support switches capable for optical transport. This document adds extensions to the base GSMPv3 specification for controlling MPLS, ATM and Frame Relay capable switches. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Power Ethernet MIB", Avi Berger, Dan Romascanu, 25-Jun-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing a Power Source Equipment (PSE). Distribution of this memo is unlimited. "Definitions of Managed Objects for the Ethernet-like Interface Types", John Flick, 06-Mar-03, 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 managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", John Flick, 03-Jun-03, 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 managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. "Definition of Managed Objects for the Ethernet WAN Interface Sublayer", C.M. Heard, 21-Mar-03, 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 managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the SONET/SDH Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. "Applicability Statement for Reclassification of RFC 1643 to Historic Status", John Flick, C.M. Heard, 04-May-03, This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation. Internet Architecture Board (iab) --------------------------------- "Security Mechanisms for the Internet", Steven Bellovin, Charlie Kaufman, Jeffrey Schiller, 13-Feb-03, Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each. "Guidelines for Writing RFC Text on Security Considerations", Eric Rescorla, Brian Korver, 11-Feb-03, All RFCs are required to have a Security Considerations section. His- torically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. "Defining the Role and Function of IETF Protocol Parameter Registry Operators", Geoff Huston, 27-Jun-03, Many IETF protocols make use of commonly defined values that are passed within protocol objects. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses a registry function to record assigned protocol parameter values and their associated semantic intent. For each IETF protocol parameter It is current practice for the IETF to delegate the role of protocol parameter registry operator to a nominated entity. This document describes a description of this delegated function. "Considerations on the use of a Service Identifier in Packet Headers", Michael StJohns, Geoff Huston, 12-May-03, This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g. TCP) port fields to identify particular services that may be associated with that port number or protocol number. "The Rise of the Middle and the Future of End to End: Reflections on the Evolution of the Internet Architecture", James Kempf, Rob Austein, 30-Jun-03, The end to end principle is the core architectural guidline of the Internet. In this document, we briefly examine the development of the end to end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end to end principle, and try to draw some conclusion about the evolution of the end to end principle, and thus for the Internet architecture which it supports, in light of these current trends. "IETF ISOC Board of Trustee Appointment Procedures", Leslie Daigle, 27-Jan-03, This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment. "IAB Concerns & Recommendations Regarding Internet Research & Evolution", Randall Atkinson, Sally Floyd, 20-Feb-03, This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This draft is being submitted as a first step towards getting feedback from the wider community. Feedback can be sent to the IAB mailing list at iab@ietf.org, or to the editors at rja@extremenetworks.com and floyd@icir.org. We hope to set up a mailing list for feedback at research-funding@ietf.org. When this gets set up, requests to join can be sent to research-funding- request@ietf.org. "Considerations on Increasing Character Repertoires for Protocol Elements", Ted Hardie, Leslie Daigle, 24-Feb-03, This document describes a set of considerations and strategies to use in increasing the character repertoire available in a protocol element or suite of protocol elements. This document is not meant to provide normative instruction to protocol designers, but does hope to provide guidance on common issues arising from this task. This initial draft does not contain real-world examples for the different strategies outlined below; before final publication, the IAB plans to add such examples and solicits feedback from the community on examples appropriate to this draft. Feedback on this point or the draft as a whole should be sent to the editors or the IAB. "A Survey of Authentication Mechanisms", Eric Rescorla, 28-Apr-03, Authentication is perhaps the most basic security problem for design- ers of network protocols. Even the early Internet protocols such as TELNET and FTP, which provided no other security services, made pro- vision for user authentication. Unfortunately, these early authenti- cation systems were wholly inadequate for the Internet Threat Model [REF] and a vast array of other authentication mechanisms have been introduced in an attempt to close these holes. The most striking thing about these security mechanisms is how many of them are essentially similar. There are only 7 basic classes of authentication protocol but there are a large number of slightly dif- ferent protocols with essentially the same security properties. This memo surveys the space of authentication mechanisms, describes the basic classes and provides examples of protocols which fit into each class. "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", Sally Floyd, James Kempf, 24-Jun-03, This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse on underprovisioned links in the Internet. The concerns are particularly relevant in light of the absence of a widespread QoS deployment in the Internet, and the likelihood that this situation will not change much in the near term. Feedback can be sent to the IAB mailing list at iab@ietf.org, or to the editors at floyd@icir.org and kempf@docomolabs-usa.com. Feedback can also be sent to the end2end-interest mailing list [E2E]. Inter-Domain Multicast Routing (idmr) ------------------------------------- "Distance Vector Multicast Routing Protocol", Tom Pusateri, 17-May-01, 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]. "Multicast Router Discovery", Shantam Biswas, Bradley Cain, Brian Haberman, 08-Jan-03, The concept of IGMP snooping requires the ability to identify the location of multicast routers. Since IGMP (and MLD) snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this scenario can lead to interoperability issues between multicast routers and layer-2 switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. By introducing these new messages, snooping devices have a uniform means of identifying multicast routers without dependency on particular routing protocols. These messages may also be used to convey configuration parameters to all systems on a network. In addition, other devices that may need to discover multicast routers can utilize these messages. "Distance Vector Multicast Routing Protocol Applicability Statement", Tom Pusateri, 17-May-01, This document provides a framework for the use of Distance Vector Multicast Routing Protocol (DVMRP) Version 3 within a multicast routing domain. It is an interior gateway protocol designed to be used within an autonomous system. Inter-Domain Routing (idr) -------------------------- "A Border Gateway Protocol 4 (BGP-4)", Yakov Rekhter, 31-Mar-03, The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reacha- bility information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This informa- tion is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy deci- sions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", John Burruss, Susan Hares, 06-Nov-02, This memo is an extension to the SNMP MIB. The origin of this memo is from RFC 1269 'Definitions of Managed Objects for the Border Gateway Protocol (Version 3)', 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 current SNMP framework documents. This memo is intended to document deployed implementations of this MIB in a historical context, provide clarifications of some items and also note errors where the MIB fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB with a new one representing the current state of the BGP protocol and its extensions. Distribution of this memo is unlimited. Please forward comments to idr@merit.net. "Cooperative Route Filtering Capability for BGP-4", Yakov Rekhter, 30-Jan-03, This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "Graceful Restart Mechanism for BGP", Srihari Ramachandra, Yakov Rekhter, Rex Fernando, John Scudder, 30-Jan-03, This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). "BGP support for four-octet AS number space", Quaizar Vohra, Enke Chen, 16-Dec-02, Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. "BGP Extended Communities Attribute", Srihari Sangli, Dan Tappan, Yakov Rekhter, 10-May-02, This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. "Aspath Based Outbound Route Filter for BGP-4", Keyur Patel, Susan Hares, 04-Dec-02, This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4),Second Version", Jeffrey Haas, Wayne Tackabury, Susan Hares, 06-Nov-02, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that facilitate the management of the Border Gateway Protocol Version 4 (BGP4). Distribution of this memo is unlimited. "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 26-Nov-02, This document defines a new BGP capability termed 'Dynamic Capability', which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. "Subcodes for BGP Cease Notification Message", Enke Chen, V Gillet, 25-Nov-02, This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in co-relating network events and diagnosing BGP peering issues. "AS-wide Unique BGP Identifier for BGP-4", Enke Chen, Jenny Yuan, 04-Apr-03, To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the 'uniqueness' requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. "Security Requirements for Keys used with the TCP MD5 Signature Option", Marcus Leech, 13-May-02, The TCP MD5 Signature Option [RFC2385], used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. "BGP Graceful Restart - Implementation Survey", John Scudder, 06-Dec-02, This document provides a survey of BGP-4 Graceful Restart implementations. "BGP-4 Protocol Analysis", David Meyer, Keyur Patel, 13-May-03, The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. "Issues in Revising BGP-4", Andrew Lange, 01-Jul-03, This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol. "BGP Security Vulnerabilities Analysis", Sandra Murphy, 25-Jun-03, BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to the BGP protocol to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. Intrusion Detection Exchange Format (idwg) ------------------------------------------ "Intrusion Detection Mesage Exchange Requirements", Mark Wood, Michael Erlinger, 23-Oct-02, The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. "Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition", David Curry, Hervé Debar, 31-Jan-03, The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes a data model to represent information exported by intrusion detection systems, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "The TUNNEL Profile", Darren New, 06-Dec-02, This memo describes a BEEP profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall. "The Intrusion Detection Exchange Protocol (IDXP)", Benjamin Feinstein, Gregory Matthews, John White, 23-Oct-02, This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in the Intrusion Detection Message Exchange Format (IDMEF) [2], a companion document of the Intrusion Detection Exchange Format (IDWG) working group of the IETF. Internet Emergency Preparedness (ieprep) ---------------------------------------- "Framework for Supporting IEPS in IP Telephony", Ken Carlberg, Ian Brown, Cory Beard, 23-Jun-03, This document presents a framework for supporting authorized emergency related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing service in the PSTN, contribute to a constrained solution space. "Requirements for Emergency Telecommunication Capabilities in the Internet", Hal Folts, Cory Beard, Ken Carlberg, 25-Oct-02, This document outlines user requirements for IP-based networks to enable and support an authorized emergency telecommunications service (ETS)for use by authorities to organize and coordinate emergency and disaster relief operations. It provides a basis from which ETS can be negotiated to provide user-acceptable communications. The requirements in this document relate to user expectation and are general, functional, and intended to provide wide latitude in implementation options. This document also provides in-depth background on the state of emergency telecommunication capabilities as they exist today and the motivation for supporting these in IP networks. Specific system requirements involving end-to-end and network issues are presented in [2]. "Reflexive DSCP Policy", Rei Atarashi, Fred Baker, 08-Nov-02, In reviewing the specific use of the Differentiated Services Architecture for supporting the Internet Emergency Preparedness System, we found what we believe is a general issue. This is that even though a client or peer can connect to a server or peer with a predictable DSCP value, the response does not have a predictable DSCP value. We consider the issues, and recommend an approach to application policy regarding the DSCP. "IP Telephony Requirements for Emergency Telecommunication Service", Ken Carlberg, Randall Atkinson, 18-Jun-03, This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. Solutions to these requirements are not presented in this document. "General Requirements for Emergency Telecommunication Service", Ken Carlberg, Randall Atkinson, 18-Jun-03, This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). Internet Engineering Steering Group (iesg) ------------------------------------------ "An IESG charter", Harald Alvestrand, 04-Jun-03, This memo gives a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as presently understood. Discussion of this memo is encouraged on the POISED mailing list "Considerations on the Extensibility of IETF protocols", Scott Bradner, Thomas Narten, 23-Dec-02, This document discusses issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions need to be reviewed by the larger IETF community. The document also recommends that major extensions to IETF protocols only take place through normal IETF processes or if adequate controls are in place to ensure sufficient IETF review. "An IESG charter", Harald Alvestrand, 10-Jan-03, This memo describes the current operating procedures of the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). This memo is not intended to become an RFC, but provides information to the Internet community, for which the internet-drafts mechanism is a convenient distribution veichle Discussion of this memo is encouraged on the POISED mailing list Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION", Mark Crispin, Ken Murchison, 15-May-03, This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A server which supports the base-level SORT extension indicates this with a capability name which starts with 'SORT'. Future, upwards-compatible extensions to the SORT extension will all start with 'SORT', indicating support for this base level. A server which supports the THREAD extension indicates this with one or more capability names consisting of 'THREAD=' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. "IMAP4 ACL extension", Alexey Melnikov, 17-Jun-03, The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. "IMAP ANNOTATE Extension", Randall Gellens, Cyrus Daboo, 20-May-03, The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. "INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION", Mark Crispin, Ken Murchison, 08-Oct-02, This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. "IMAP4 LIST Command Extensions", Barry Leiba, 21-Feb-03, IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. "IMAP Extension for Conditional STORE operation", Alexey Melnikov, Steve Hole, 17-Jun-03, Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. "Internet Message Access Protocol Internationalization", Chris Newman, 12-May-03, Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. Instant Messaging and Presence Protocol (impp) ---------------------------------------------- "Common Presence and Instant Messaging: Message Format", Derek Atkins, Graham Klyne, 20-Jan-03, This memo defines the mime type 'message/cpim', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. "Presence Information Data Format (PIDF)", Hiroyasu Sugano, Shingo Fujimoto, 09-May-03, This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type 'application/pidf+xml' to represent the XML MIME entity for PIDF "Address Resolution for Instant Messaging and Presence", Jon Peterson, 20-May-03, Presence and instant messaging are defined in RFC2778 [5]. The Common Profiles for Presence [2] and Instant Messaging [1] define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. "Common Profile for Presence (CPP)", Jon Peterson, 20-May-03, Presence is defined in RFC2778 [12]. Today, numerous presence protocols are in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. "Common Profile for Instant Messaging (CPIM)", Jon Peterson, 20-May-03, Instant messaging is defined in RFC2778 [5]. Today, numerous instant messaging protocols are in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. Extended Incident Handling (inch) --------------------------------- "The Incident Data Exchange Format Data Model and XML Implementation Document Type Definition", Jan Meijer, 01-Apr-03, The purpose of the Incident Data Exchange Format (IODEF) is to define data formats for information related to computer security incidents typically exchanged between collaborating Computer Security Incident Response Teams (CSIRTs). The IODEF satisfies the requirements specified in RFCXXX [1] This Internet-Draft describes a data model for representing commonly exchanged incident information exported from incident handling systems managed by CSIRTs. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "Incident Object Description and Exchange Format Requirements", Yuri Demchenko, 04-Nov-02, The purpose of the Incident Object Description and Exchange Format is to define a common data format for describing and exchanging incident information between collaborating Computer Security Incident Response Teams (CSIRTs). The specific goals and requirements of the IODEF are described in [2]. One of the design principles in the IODEF is compatibility with the Intrusion Detection Message Exchange Format (IDMEF) [3] developed for intrusion detection systems. For this reason, IODEF is heavily based on the IDMEF and provides upward compatibility with it. "Requirements for Format for INcident Report Exchange (FINE)", Yuri Demchenko, 12-Jun-03, The purpose of the Format for INcident report Exchange (FINE) is to facilitate the exchange of incident information and statistics among responsible Computer Security Incident Response Teams (CSIRTs) and involved parties for reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. A common and well-defined format will help in exchanging, retrieving and archiving Incident related information across organizations, regions and countries. IP over Cable Data Network (ipcdn) ---------------------------------- "Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)", Michael Patrick, William Murwin, 05-Mar-03, This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1. "Application of the IGMP MIB, RFC 2993, and Cable Device MIB, RFC 2669, to Docsis 1,1 Devices", Howard Abramson, 01-Jul-02, This memo describes the application of a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the application of the managed objects specified in RFC 2933, [19], and proposes a new object for the Cable Device MIB, RFC 2669 [25], for SNMP-based management of DOCSIS 1.1 IGMPv2 compliant interfaces. 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@ietf.org and/or the author. "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management", Wilson Sawyer, 29-May-03, 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 a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. 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@ietf.org and/or the author. "Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus", Stan Green, Kirill Katsnelson, 10-Feb-03, 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 a set of managed objects for SNMP-based management of the Baseline Privacy Plus features [17] of DOCSIS1.1- compliant[16] 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 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@ietf.org and/or the authors. Conventions used in this document "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", Richard Woundy, 07-Mar-03, This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. 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 a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. 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@ietf.org and/or the author. "Event Notification Management Information Base for DOCSIS 1.1 Compliant Cable Modems and Cable Modem Termination Systems", Junming Gao, Pak Siripunkaw, David Raftus, 19-Feb-03, 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 a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB, RFC 2669. This memo specifies a MIB module in a manner that is compliant to the SMIv2. 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@ietf.org and/or the author. "Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces", David Raftus, 05-Mar-03, This memo is a draft revision of the standards track RFC-2670. Please see 'Section 9 Changes from RFC2670' for a description of modifications. This document or its successor will obsolete RFC-2670 when accepted. 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 a basic set of managed objects for SNMP- based management of DOCSIS compliant Radio Frequency (RF) interfaces. 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@ietf.org and/or the authors. "Network Control Signaling (NCS) Signaling MIB for PacketCable/IPCablecom MTAs", Gordon Beacham, Satish Kumar, Sumanth Channabasappa, 08-May-03, This memo defines the Signaling Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. 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. "Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable 1.0 compliant devices", Eugene Nechamkin, Jean-Francois Mule, 09-May-03, 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 a basic set of managed objects for SNMP- based management of PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. "Management Event MIB for PacketCable/IPCablecom MTAs", Wim De Ketelaere, Eugene Nechamkin, 17-Jan-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format definition for events and specifies by what means events are transmitted for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. 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. "Cable Gateway Addressing Management Information Base for CableHome compliant Residential Gateways", Eduardo Cardona, 24-Jun-03, 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 a basic set of managed objects for SNMP- based management of Network Address Translation and transparent bridging functionality within a CableHome compliant residential gateway. "Cable Gateway Device Management Information Base for CableHome compliant Residential Gateways", Eduardo Cardona, 24-Jun-03, 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 a basic set of managed objects for SNMP based management of CableHome [21] compliant WAN Gateway Devices and home routers. "Cable Gateway Quality of Service (QoS) Management Information Base for CableHome compliant Residential Gateways", Amol Bhagwat, 24-Jun-03, 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 a basic set of managed objects for SNMP- based management for prioritized Quality of Service functionality within a LAN, between a CableHome residential gateway device and CableHome compliant LAN host devices. 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. "Cable Gateway Configuration Management Information Base for CableHome compliant Residential Gateways", Eduardo Cardona, 24-Jun-03, 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 a basic set of managed objects for SNMP- based management of DHCP [22] functionality within a CableHome compliant [21] residential gateway. "Cable Gateway Security Management Information Base for CableHome compliant Residential Gateways", Eduardo Cardona, 24-Jun-03, 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 a basic set of managed objects for SNMP- based security management of CableHome 1.0 compliant residential gateway devices. 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. "Cable Gateway Tools Management Information Base for CableHome compliant Residential Gateways", Eduardo Cardona, 24-Jun-03, 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 a basic set of managed objects for SNMP- based management of CableHome compliant WAN Gateway Devices and home routers. Specifically, this MIB defines managed objects for both a connection speed tool and an ICMP 'ping' tool between the Gateway and devices on the LAN. 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. IP Flow Information Export (ipfix) ---------------------------------- "Requirements for IP Flow Information Export", Juergen Quittek, 11-Jun-03, This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes and middleboxes. "Information Model for IP Flow Information Export", Paul Calato, 18-Jun-03, This document defines an information and data model for scalable monitoring, measuring and exporting IP flow information to collectors. "Architecture Model for IP Flow Information Export", Ganesh Sadasivan, Nevil Brownlee, 19-Jun-03, This memo defines the architecture for the export of measured IP flow information out of an IPFIX device to a collector, per the requirements defined in [IPFIX-REQS]. "IPFIX Protocol Specifications", Benoit Claise, 19-Jun-03, This document discusses the IPFIX protocol that provides network administrators with access to IP flows information. This document focuses on how IPFIX flow record data, options record data and control information is carried (via a congestion-aware transport protocol) from IPFIX exporting process to IPFIX collecting process. "IPFIX Applicability", Tanja Zseby, 20-Jun-03, This document describes how various applications can use the IP Flow Information Export (IPFIX) protocol. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. IP over Optical (ipo) --------------------- "Impairments And Other Constraints On Optical Layer Routing", John Strand, Angela Chiu, 08-May-03, Optical networking poses a number challenges for GMPLS. Optical technology is fundamentally an analog rather than digital technology; and the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks which impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all- optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. "IP over Optical Networks: A Framework", Bala Rajagopalan, 08-Apr-03, The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as 'IP over optical networks'). "Optical Network Service Requirements", Yong Xue, 06-Jan-03, This Internet Draft describes the major carrier's optical service requirements for the Automatically Switched Optical Networks (ASON) from both an end-user's as well as an operator's perspectives. Its focus is on the description of the service building blocks and service-related control plane functional requirements. The management functions for the optical services and their underlying networks are beyond the scope of this document. "Optical Inter Domain Routing Considerations", Greg Bernstein, 04-Mar-03, This draft investigates the requirements for general inter-domain and inter-area routing in optical networks and reviews the applicability of existing route protocols in various optical routing applications. IP over InfiniBand (ipoib) -------------------------- "Definitions of Managed Objects for Infiniband Interface Type", Bill Anderson, Sean Harnedy, 23-Jun-03, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture to deliver scalable performance in data centers. This memo defines a portion of Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IBA defined InfiniBand interfaces. "Definition of Managed Objects for the Infiniband Subnet Management Agent (SMA)", Sean Harnedy, 23-Jun-03, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. 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 managing InfiniBand Subnet Management Agents (SMA). "Definition of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management", Sean Harnedy, 28-May-03, This memo describes Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. The intent is that these TEXTUAL CONVENTIONs (TCs) will be imported and used in IPOVERIB related MIB modules "IP over InfiniBand(IPoIB) Architecture", Vivek Kashyap, 06-Jun-03, InfiniBand is a high speed, channel based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in [IPOIB_MCAST], [IPOIB_ENCAP] and [IPOIB_DHCP]. "IP link and multicast over InfiniBand networks", John Chu, Vivek Kashyap, 05-Jun-03, This document specifies a method for setting up IP subnets and multicast services over InfiniBand(TM) networks. Discussions in this document are applicable to both IPv4 and IPv6, unless explicitly specified. A separate document will cover unicast and encapsulation of IP datagrams over InfiniBand networks. "IP encapsulation and address resolution over InfiniBand networks", Vivek Kashyap, John Chu, 01-May-03, This document specifies the frame format for transmission of IP and ARP packets over InfiniBand networks. Unless explicitly specified, the term 'IP' refers to both IPv4 and IPv6. The term 'ARP' refers to all the ARP protocols/op-codes such as ARP/RARP. This document also describes the method of forming IPv6 link-local addresses, and the content of the source/target link layer address option used in Neighbour solicitation and advertisement, router advertisement, router redirect and router solicitation on IPv6 over InfiniBand. "DHCP over InfiniBand", Vivek Kashyap, 24-Feb-03, An InfiniBand network uses a link-layer addressing scheme that is 20-octets long. This is larger than the 16-octets reserved for the hardware address in DHCP/BOOTP message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IP over InfiniBand(IPoIB) network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. "Definitions of Managed Objects for Infiniband Channel Adapters (CA)", Sean Harnedy, 13-Feb-03, 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 managing InfiniBand Channel Adapters (CA). "Definitions of Managed Objects for the Infiniband Baseboard Management Agent (BMA)", Sean Harnedy, 16-Oct-02, 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 managing InfiniBand Baseboard Management Agents (BMA). "Definitions of Managed Objects for the Infiniband Performance Management Agent (PMA)", Sean Harnedy, 13-Feb-03, 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 managing InfiniBand Performance Management Agents (PMA). IP over Resilient Packet Rings (iporpr) --------------------------------------- "A Core Standard For Transmission of IP Packets Over IEEE 802.17 (Resilient Packet Ring) Networks", Frank Kastenholz, 06-Dec-02, This memo specifies a standard method of encapsulating IPv4, IPv6, and MPLS datagrams for transmission over IEEE 802.17 Resilient Packet Ring (RPR) Networks. This method uses a minimum of IEEE 802.17 functions and capabilities. The 802.17 network is treated as a simple, flat network, similar in many ways to an Ethernet. A later specification will build upon this standard. It will make more of the features and capabilities of IEEE 802.17 networks available to IP and MPLS and specify the techniques to use those features. Internet Printing Protocol (ipp) -------------------------------- "Internet Printing Protocol: Requirements for IPP Notifications", Roger Debry, Harry Lewis, Thomas Hastings, 23-Jul-01, 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 on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a statement of the requirements for notifications as part of an IPP Service. "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", Robert Herriot, Thomas Hastings, 28-Feb-03, This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew- Subscription, and Cancel-Subscription. "Internet Printing Protocol(IPP): Job and Printer Administrative Operations", Carl Kugler, Harry Lewis, Thomas Hastings, 23-Jul-01, This document specifies the following 16 additional OPTIONAL operations for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [RFC2910, RFC2911] "Internet Printing Protocol (IPP):The 'indp' Delivery Method for Event Notifications and Protocol/1.0", Hugo Parra, Thomas Hastings, 23-Jul-01, This document describes an extension to the Internet Printing Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. This document specifies the 'indp' Delivery Method and Protocol/1.0 for use with the 'IPP Event Notifications and Subscriptions' specification [ipp-ntfy]. When IPP Notification [ipp-ntfy] is supported, the Delivery Method defined in this document is one of the RECOMMENDED Delivery Methods for Printers to support. "Internet Printing Protocol (IPP): Printer Installation Extension", Hugo Parra, Ted Tronson, Thomas Hastings, 23-Jul-01, This document describes an OPTIONAL extension to the Internet Printing Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. Various client platforms require that some setting up take place at the workstation before the client can properly submit jobs to a specific printer. "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", Robert Herriot, Carl Kugler, Harry Lewis, 28-Feb-03, This document describes an extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the 'Internet Printing Protocol (IPP): Event Notifications and Subscriptions' specification (ipp-ntfy). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support ipp-ntfy. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications using the Get-Notifications operation defined in this document. IP Performance Metrics (ippm) ----------------------------- "A One-way Active Measurement Protocol (OWAMP)", Stanislav Shalunov, Benjamin Teitelbaum, 20-May-03, With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. The One-Way Active Measurement Protocol (OWAMP) can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. "A One-way Active Measurement Protocol Requirements", Stanislav Shalunov, Benjamin Teitelbaum, 11-Jun-03, With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. "IPPM metrics registry", Emile Stephan, 18-Apr-03, This memo defines a registry of the IPPM working group metrics. It assigns an OBJECT IDENTIFIER to each metric currently standardized by the IPPM WG. It defines the rules for the identification of the metrics standardized in the future. "IPPM reporting MIB", Emile Stephan, Jessie Jewitt, 01-Jul-03, This memo defines a portion of the Management Information Base (MIB) designed for use with network management protocols in TCP/IP-based internets. In particular, this MIB specifies the objects used for managing the results of the IPPM metrics measures, for pushing alarms, and for reporting the measures results. "Packet Reordering Metric for IPPM", Al Morton, 06-Mar-03, This memo defines a simple metric to determine if a network has maintained packet order. It provides motivations for the new metric, suggests a metric definition, and discusses the issues associated with measurement. The memo includes sample metrics to quantify the extent of reordering in several useful dimensions. Some examples of evaluation using the various sample metrics are included. "One-Way Metric Applicability Statement", Henk Uijterwaal, Merike Kaeo, 07-Nov-02, Active traffic measurements are starting to become more widely used to ascertain network performance characteristics. All active measurement systems have the capability to measure one-way delay and one-way loss metrics, as defined in RFC2679 [1] A One- way Delay Metric for IPPM and RFC 2680 [2] A One-way Packet Loss Metric for IPPM, respectively. To ensure that the resulting numbers have some meaning, we attempt to characterize how the measurements are taken and what would ensure that the end numbers are indeed meaningful. This document describes an applicability statement (formerly known as best current practices) for measuring the one-way delay and one-way loss metrics in operational networks. Intellectual Property Rights (ipr) ---------------------------------- "Guidelines for Working Groups on Intellectual Property Issues", Scott Brim, 11-Jun-03, This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with IPR (Intellectual Property Rights) issues. It documents specific examples of how IPR issues have been dealt with in the IETF "Intellectual Property Rights in IETF Technology", Scott Bradner, 19-Jun-03, The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC XXXY, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028 and replaces reference 2 in RFC 2418. [note to RFC editor - replace XXXY with number of IETF SUB] "IETF Rights in Contributions", Scott Bradner, 12-Jun-03, The IETF policies about rights in submissions to the IETF are designed to ensure that IETF contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights in the document as possible. This memo details the IETF policies on rights in submissions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and with RFC XXXY, replaces Section 10 of RFC 2026. [note to RFC editor: replace XXXY with number of IETF IPR] "A Template for IETF Patent Disclosures and Licensing Declarations", Valerie See, 17-Jun-03, This document describes a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC XXXX [ii]. IP Storage (ips) ---------------- "Fibre Channel Over TCP/IP (FCIP)", Murali Rajagopal, Raj Bhagwat, Ralph Weber, 28-Aug-02, Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. "iSCSI", Julian Satran, 24-Jan-03, The Small Computer Systems Interface (SCSI) is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to 'carry' SCSI. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architectural model. "Bootstrapping Clients using the iSCSI Protocol", Prasenjit Sarkar, Duncan Missimer, Costa Sapuntzakis, 26-Jun-03, iSCSI is a proposed transport protocol for SCSI that operates on top of TCP. This memo describes a standard mechanism to enable clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. "Internet Storage Name Service (iSNS)", Josh Tseng, Kevin Gibbons, 27-Jun-03, This document specifies the Internet Storage Name Service (iSNS) protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Charles Monia, 04-Dec-02, This document specifies an architecture and gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions having the fault isolation properties of autonomous systems and the scalability of the IP network. "iSCSI Naming and Discovery", Mark Bakke, 26-Jun-03, This document provides examples of iSCSI (SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol draft. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. "FC Frame Encapsulation", Ralph Weber, Murali Rajagopal, Franco Travostino, Michael O'Donnell, Charles Monia, Milan Merhar, 06-May-02, This is the ips (IP Storage) working group draft describing the common Fibre Channel frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates Fibre Channel (FC) frames. This draft describes a frame header containing information mandated for encapsulating, transmitting, de-encapsulating, and calculating the transit times of FC frames. "Finding iSCSI Targets and Name Servers Using SLP", Mark Bakke, 05-Mar-03, The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. "Definitions of Managed Objects for iSCSI", Mark Bakke, Jim Muchow, Marjorie Krueger, Tom McSweeney, 05-Mar-03, 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 a client using the iSCSI (SCSI over TCP) protocol. "Definition of Managed Objects for FCIP", R Natarajan, Antil Rijhsinghani, 18-Jun-03, 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 FCIP entities, as defined in [FCIP] and used in FC fabrics as described in [FCBB2]. "Finding FCIP Entities Using SLPv2", Dave Peterson, 05-Mar-03, This document defines the use of Service Location Protocol, version 2 (SLPv2) [RFC2608], by FCIP Entities [FCIP]. "Securing Block Storage Protocols over IP", Bernard Aboba, 15-Jan-03, This document discusses how to secure block storage and storage discovery protocols running over IP using IPsec and IKE. Threat models and security protocols are developed for iSCSI, iFCP and FCIP, as well as the iSNS and SLPv2 discovery protocols. Performance issues and resource constraints are analyzed. "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", Kevin Gibbons, Josh Tseng, Tom McSweeney, 10-Jan-03, 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 a basic set of managed objects for SNMP-based monitoring and management of the Internet Storage Name Service (iSNS). This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. "Definitions of Managed Objects For iFCP", Kevin Gibbons, Charles Monia, Josh Tseng, Franco Travostino, 05-Mar-03, The iFCP protocol provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This draft provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. "Definition of Managed Objects for SCSI Entities", Mark Bakke, 18-Feb-03, This memo defines a Management Information Base (MIB) for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. "Fibre Channel Management MIB", Keith McCloghrie, 04-Mar-03, 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 for informantion related to Fibre Channel. "String Profile for iSCSI Names", Mark Bakke, 05-Mar-03, The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. This document describes how to prepare internationlized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. "Definitions of Managed Objects for User Identity Authentication", Mark Bakke, Jim Muchow, 05-Mar-03, 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 user identities and the names, addresses, and credentials required to authenticate them, for use with various protocols. This draft was motivated by the need for the configuration of authenticated user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB provides only the set of identities and the means to authenticate them; it is the responsibility of other MIBs making use of this one to tie them to authorization lists. "NAA naming format for iSCSI Node Names", Marjorie Krueger, Mallikarjun Chadalapaka, Roger Elliott, 24-Feb-03, iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the 'Network Address Authority' (NAA) world wide naming format used by ANSI T11 Fibre Channel (FC) protocols. "SCSI Command Ordering Considerations with iSCSI", Mallikarjun Chadalapaka, Roger Elliott, 09-Jun-03, iSCSI is a SCSI transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the SCSI I_T nexus, and the iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. IP Security Protocol (ipsec) ---------------------------- "IP Encapsulating Security Payload (ESP)", Stephen Kent, 08-Apr-03, This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. Comments should be sent to Stephen Kent (kent@bbn.com). "IPSec Monitoring MIB", Paul Hoffman, 15-Apr-03, This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec. Further, it does not provide policy information. 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. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPsec SAs. "IPsec DOI Textual Conventions MIB", John Shriver, 03-Mar-03, This document defines textual conventions for the constants used in MIBs for the IPsec protocols. In particular, it documents those numbers whose assignments are managed by the IANA, with new assignments being made over time. The textual conventions provide IPsec-related MIBs with clearer documentation, and insulate them from having to track new assignments by the IANA. The MIB documented by this document will become a separate living document maintained by the IANA, and will be the document of record for these assignments. "ISAKMP DOI-Independent Monitoring MIB", Paul Hoffman, 15-Apr-03, This document defines a DOI (domain of interpretation) independent monitoring MIB for ISAKMP. The purpose of this MIB is to be used as the basis for protocol specific MIBs that use ISAKMP as the basis for key exchanges or security association negotiation. As such, it has no DOI-dependent objects. "Internet Key Exchange (IKE) Monitoring MIB", Paul Hoffman, 15-Apr-03, This document defines monitoring and status MIBs for use when the (Internet Key Exchange) IKE protocol [IKE] is used to create IPsec security associations (SAs). As such, the MIBs provide the linkage between IKE (phase 1) SAs and the IPsec (phase 2) SAs created by those SAs. It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec SAs, except that they were created using IKE. Further, it does not provide policy information. "IPsec Flow Monitoring MIB", Cheryl Madson, L Temoshenko, c Pellecuru, r somasundaram, Natalie Timms, 06-Mar-03, This document describes a high-level MIB for monitoring, accounting trending and failure detection for IPsec-based networks. Optional features of the MIB include trending of IPsec-related metrics and archiving of VPN failures. "The AES Cipher Algorithms and Their Use With IPsec", Sheila Frankel, Scott Kelly, Robert Glenn, 02-May-03, This document describes the use of the AES Cipher Algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). "On the Use of SCTP with IPsec", Steven Bellovin, 08-Apr-03, This document describes functional requirements for IPsec [RFC2401] and IKE [RFC2409] to facilitate their use for securing SCTP [RFC2960] traffic. "IPsec-NAT Compatibility Requirements", Bernard Aboba, William Dixon, 06-Mar-03, Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses. This draft describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. "Negotiation of NAT-Traversal in the IKE", Tero Kivinen, 29-May-03, This document describes how to detect one or more network address trans- lation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in Internet Key Exchange (IKE). "UDP Encapsulation of IPsec Packets", Ari Huttunen, 14-Jan-03, This draft defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). "A Traffic-Based Method of Detecting Dead IKE Peers", Geoffrey Huang, Stephane Beaulieu, Dany Rochefort, 29-May-03, This draft describes a method of detecting a dead IKE peer. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to limit the number of IKE messages sent. DPD, like other keepalive mechanisms, is often necessary to perform IKE peer failover, or to reclaim lost resources. "Internet Key Exchange (IKEv2) Protocol", Charlie Kaufman, 02-Jun-03, This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of IKE simplifies the design by removing options that were rarely used and simplifying the encoding. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", Sheila Frankel, Howard Herbert, 28-Mar-03, A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. "IP Authentication Header", Stephen Kent, 08-Apr-03, This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98c]. Section 7 provides a brief review of the differences between this document and RFC 2402. Comments should be sent to Stephen Kent (kent@bbn.com). "The Internet IP Security PKI Profile of ISAKMP and PKIX", Brian Korver, Eric Rescorla, 01-Jul-03, ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifications such as IKE, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. "Extended Sequence Number Addendum to IPsec DOI for ISAKMP", Stephen Kent, 10-Apr-03, This document describes extensions to the Internet IP Security Domain of Interpretation for ISAKMP [DOI] that are needed to support negotiation of whether or not a Security Association will use Extended (64-bit) Sequence Numbers. (See [AH] and [ESP] for a description of Extended Sequence Numbers.) Comments should be sent to Stephen Kent (kent@bbn.com). "Using AES Counter Mode With IPsec ESP", Russell Housley, 30-May-03, This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. "IKEv2: ECN Requirements for IPsec Tunnels", David Black, 19-Feb-03, IPsec (IP Security) tunnel encapsulation and decapsulation were specified prior to the addition of ECN (Explicit Congestion Notification) to IP, with the potential result that ECN congestion indications could be discarded by IPsec tunnel decapsulators. The current ECN specification includes two ECN operating modes for IPsec tunnels to avoid this situation, and IKEv1/ISAKMP (Internet Key Exchange/Internet Security Association and Key Management Protocol) negotiation extensions to enable ECN to be used correctly with IPsec tunnels. To simplify this situation, IKEv2 requires changes to tunnel decapsulation that prevent discarding of ECN congestion indication, obviating the need for multiple ECN operating modes and associated negotiation support. "Using AES CCM Mode With IPsec ESP", Russell Housley, 30-May-03, This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. "Understanding IKEv2: Tutorial, and rationale for decisions", Radia Perlman, 05-Mar-03, The main job of a protocol specification is to document how the protocol works. It is sometimes difficult to learn how a protocol works from such a document, because there are so many details, and the necessary formalism for accuracy makes a specification long and intimidating to read. What also is usually lost in the process of creating an RFC for a protocol is documentation of the tradeoffs that were considered when making controversial choices. Sometimes it is possible to find this information on the email archives, but that is a daunting task. This document is intended to work both as a tutorial to understanding IKEv2, and a summary of the controversial issues, with the reasoning on all sides of each issue. If any differences in details exist between this document and the IKEv2 specification, the IKEv2 specification is authoritative. This document is intended only to make the IKEv2 specification more understandable on the first reading, as well as documenting reasoning behind decisions. "IPsec Flow Monitoring MIB Textual Conventions", Cheryl Madson, 02-Apr-03, This document describes the SMI textual coventions required to support the definition of IPsec MIBs. It is necessary to separate the definition of the textual conventions into a separate document due to their dependence on IANA assigned numbers for transforms and Diffie-Hellman groups supported by IPsec protocol. "DHCP over IKE", Tero Kivinen, 15-Apr-03, This document describes method of getting the IP security (IPsec) remote access client configuration information from the security gateway by tunneling dynamic host configuration protocol (DHCP) packets inside the internet key exchange (IKE) version 2 protocol. "Using DHCP server/client backend for DHCP over IKE", Tero Kivinen, 15-Apr-03, This document describes method of using dynamic host configuration pro- tocol (DHCP) as a backend for the internet key exchange (IKE) version 2 host configuration protocol. "Using RADIUS backend for DHCP over IKE", Tero Kivinen, 15-Apr-03, This document describes method of using Remote Authentication Dial In User Service (RADIUS) as a backend for the internet key exchange (IKE) version 2 host configuration protocol. "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", Jeffrey Schiller, 06-Jun-03, The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. "Cryptographic Suites for IPsec", Paul Hoffman, 13-Jun-03, The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. IPSEC KEYing information resource record (ipseckey) --------------------------------------------------- "A method for storing IPsec keying material in DNS", Michael Richardson, 17-Jun-03, This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. IP Security Policy (ipsp) ------------------------- "IPsec Configuration Policy Information Model", Jamie Jason, Lee Rafalow, Eric Vyncke, 20-Mar-03, This document presents an object-oriented information model of IPsec (IP Security protocol) [COMP, ESP, AH] policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange [DOI, IKE] protocol. Other key exchange protocols could be easily added to the information model by a simple extension. Other extensions can further be added easily due to the object-oriented nature of the model. "IP Security Policy Requirements", Matt Blaze, Angelos Keromytis, Michael Richardson, Luis Sanchez, 09-Aug-02, This document describes the problem space and solution requirements to develop an IP Security Policy configuration and management framework. The IP Security Policy architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentcation, confidentiality, data integrity, and other IP Security properties. This documents highlights such architectural components and presents their functional requirements. "IPSec Policy Information Base", Man Li, David Arneson, Avri Doria, Jamie Jason, Cliff Wang, Markus Stenberg, 19-May-03, This document describes a portion of the Policy Information Base (PIB) for a device implementing the IP Security Architecture. The provisioning classes defined here provide control of IPsec policy. These provisioning classes can be used with other non-IPsec provisioning classes (defined in other PIB modules) to provide for a comprehensive policy controlled mapping of service requirement to device capability and usage. "IPsec Policy Configuration MIB module", Michael Baer, 07-Mar-03, This document defines a Management Information Base (MIB) module for managing the Internet Security Protocol (IPsec) and Internet Key Exchange (IKE) protocols and associated policies. Some of the policy-based packet filtering and the corresponding execution of actions is of a more general nature than for IPsec configuration only. This MIB module is designed with future extensibility in mind. It is thus possible to externally add other packet filters and actions to the policy-based packet filtering system defined in this document. "Requirements for an IPsec API", Bill Sommerfeld, 19-Jun-03, Given the open nature of the Internet today, application protocols require strong security. IPsec's wire protocols appear to meet the requirements of many protocols. The lack of a common model for application-layer interfaces has complicated use of IPsec by upper- layer protocols. This document provides an overview of facilities which a host IPsec implementation should provide to applications to allow them to both observe and influence how IPsec protects their communications. IP Telephony (iptel) -------------------- "CPL: A Language for User Control of Internet Telephony Services", Jonathan Lennox, Henning Schulzrinne, 16-Jan-02, The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. "Management Information Base for Telephony Routing over IP (TRIP)", David Zinman, Dave Walker, James Jiang, 11-Jun-03, This memo defines a portion of the MIB (Management Information Base) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage for TRIP (Telephony Routing over IP) devices "A Telephony Gateway REgistration Protocol (TGREP)", Manjunath Bangalore, 01-Jul-03, This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a TRIP Location Server, which in turn can propogate that routing information within the same, and other internet telephony administrative domains (ITAD). TGREP shares a lot of similarites with the TRIP Protocol. It has similar procedures and Finite State Machine for session establishment. It also shares the same format for messaages and a subset of attributes with TRIP. "Representing trunk groups in sip/tel Uniform Resource Identifiers (URIs)", Vijay Gurbani, 01-Nov-02, This document describes a standardized mechanism to convey trunk group- related information in SIP and TEL URIs. An extension to the 'tel' URI is defined for this purpose. "The tel URI for Telephone Calls", Henning Schulzrinne, Antti Vaha-Sipila, 02-Jul-03, This document specifies the URI (Uniform Resource Identifier) scheme 'tel'. The 'tel' URI describes resources identified by telephone numbers IP Version 6 Working Group (ipv6) --------------------------------- "IPv6 Node Information Queries", Matt Crawford, 27-Jun-03, This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", Alex Conta, Steve Deering, 29-Nov-01, This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). "Well known site local unicast addresses for DNS resolver", Alain Durand, Jun-ichiro Hagino, Dave Thaler, 04-Nov-02, This documents specifies 3 well known addresses to configure stub resolvers on IPv6 nodes to enable them to communicate with recursive DNS server with minimum configuration in the network and without running a discovery protocol on the end nodes. This method may be used when no other information about the addresses of recursive DNS servers is available. Implementation of stub resolvers using this as default configuration must provide a way to override this. "Default Router Preferences, More-Specific Routes and Load Sharing", Richard Draves, Robert Hinden, 10-Jun-02, This document describes two changes to Neighbor Discovery. The first change is an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. The second change is a mandatory modification of the conceptual sending algorithm to support load-sharing among equivalent routers. "An analysis of IPv6 anycast", Jun-ichiro Hagino, K Ettican, 30-Jun-03, The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. "IPv6 Flow Label Specification", Jarno Rajahalme, Alex Conta, Brian Carpenter, Steve Deering, 11-Apr-03, This document specifies the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, the requirements for IPv6 nodes forwarding labeled packets, and the requirements for flow state establishment methods. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. "Link Scoped IPv6 Multicast Addresses", Jung-Soo Park, Myung-Ki Shin, 07-Nov-02, This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in the serverless environments. "IPv6 Node Requirements", John Loughney, 30-Jun-03, This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. "IP Forwarding Table MIB", Margaret Wasserman, Brian Haberman, 30-Jun-03, This document 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 related to the forwarding of Internet Protocol (IP) packets, in an IP version independent manner. "Management Information Base for the Transmission Control Protocol (TCP)", Bill Fenner, 26-Jun-03, 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 implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. "Management Information Base for the Internet Protocol (IP)", Shawn Routhier, 06-Feb-03, 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 implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. "Requirements for IPv6 prefix delegation", Shin Miyakawa, 01-Jul-03, This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). "IPv6 Global Unicast Address Format", Robert Hinden, Steve Deering, 20-Jun-03, RFC2374 'An IPv6 Aggregatable Global Unicast Address Format' defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. "IPv6 Scoped Address Architecture", Steve Deering, 24-Jun-03, This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids using the syntax and usage of unicast site-local addresses. IS-IS for IP Internets (isis) ----------------------------- "Management Information Base for IS-IS", Jeff Parker, 04-Apr-03, This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. 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 an IETF draft by Chris Gunner [1]. 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. "IS-IS Cryptographic Authentication", Tony Li, Richard Atkinson, 06-Jun-03, This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm as found in RFC 2104. IS-IS is specified in ISO 10589, with extensions to support IPv4 described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specificqation only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. "IS-IS extensions for Traffic Engineering", Tony Li, Henk Smit, 18-Dec-02, This document describes extensions to the IS-IS protocol to support Traffic Engineering. This document extends the IS-IS protocol by specifying new information that an Intermediate System [router] can place in Link State Protocol Data Units. This information describes additional details of the state of the network that are useful for traffic engineering computations. "Routing IPv6 with IS-IS", Chris Hopps, 13-Jan-03, This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. "IS-IS Extensions in Support of Generalized MPLS", Kireeti Kompella, Yakov Rekhter, 07-Jan-03, This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. "M-ISIS: Multi Topology (MT)Routing in IS-IS", Tony Przygienda, Naiming Shen, Nischal Sheth, 26-Mar-03, This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. "Extended Ethernet Frame Size Support", Jed Kaplan, 03-Jul-01, This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. "Restart signaling for IS-IS", Mike Shand, 05-Mar-03, The IS-IS routing protocol (RFC 1142 [2], ISO/IEC 10589 [3]) is a link state intra-domain routing protocol. Normally, when an IS-IS router is re-started, the neighboring routers detect the restart event and cycle their adjacencies with the restarting router through the down state. This is necessary in order to invoke the protocol mechanisms to ensure correct re-synchronization of the LSP database. However, the cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios such temporary disruption of the routes is highly undesirable. "Point-to-point operation over LAN in link-state routing protocols", Naiming Shen, 26-Mar-03, The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. "Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit", Amir Hermelin, Stefano Previdi, Mike Shand, 28-Aug-02, This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. "IS-IS Automatic Encapsulation", Philip Christian, 31-Mar-03, RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS- IS can now also be used to route IPv6 [12]. RFC 1195 [1] places certain topological restrictions on networks that are routed using Integrated IS-IS, specifically that every Intermediate System in a level-1 area must be able to forward all network layer protocols that are present in that area, and that every level-2 Intermediate System must be able to forward all network layer protocols present in the routing domain. The mechanism described in this document enables an Intermediate System or a group of Intermediate Systems that do not support a particular network layer protocol to be used in a level-1 area or level-2 subdomain where that network layer protocol is present. Specifically the mechanism provides automatic encapsulation and unencapsulation so that a packet or PDU may pass through an Intermediate System that would not normally be able to forward that type of packet. "TLV for Proprietary Use", Philip Christian, 03-Sep-02, This document defines a TLV that may be used by any individual, company or other organisation for vendor specific or experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. "Recommendations for Interoperable IP Networks using IS-IS", Jeff Parker, 04-Nov-02, The difference between theory and practice is greater in practice than it is in theory. Appologies to Jan L.A. van de Snepscheut This document discusses a number of differences between the IS-IS protocol used to route IP traffic as described in ISO 10589 [1] and in RFC 1195 [2] and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. "Recommendations for Interoperable Networks using IS-IS", Jeff Parker, 04-Nov-02, In theory, there is no difference between theory and practice. But in practice, there is. Jan L.A. van de Snepscheut This document discusses a number of differences between the IS-IS protocol as described in ISO 10589 [1] the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 [3] for routing IP traffic. "TLV for Experimental Use", Philip Christian, 03-Mar-03, This document defines a TLV that may be used by any individual, company or other organisation for experimental extensions to the IS-IS routing protocol, and defines the format of the TLV.         ICMP Traceback (itrace) ----------------------- "ICMP Traceback Messages", Steven Bellovin, Marcus Leech, Tom Taylor, 19-Feb-03, It is often useful to learn the path that packets take through the Internet, especially when dealing with certain denial-of-service attacks. We propose a new ICMP message, emitted randomly by routers along the path and sent randomly to the destination (to provide useful information to the attacked party) or to the origin (to provide information to decipher reflector attacks). Kerberized Internet Negotiation of Keys (kink) ---------------------------------------------- "Kerberized Internet Negotiation of Keys (KINK)", Matt Thomas, J Vilhuber, 31-Jan-03, The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. Kerberos WG (krb-wg) -------------------- "Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB)", Jonathan Trostle, Michael Swift, Bernard Aboba, Glen Zorn, 07-Oct-02, This document defines extensions to the Kerberos protocol specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. Some common scenarios where lack of accessibility would occur are when the client does not have an IP address prior to authenticating to an access point, the client is unable to locate a KDC, or a KDC is behind a firewall. The document specifies two protocols to allow a client to exchange KDC messages (which are GSS encapsulated) with an IAKERB proxy instead of a KDC. "Kerberos Set/Change Password: Version 2", Jonathan Trostle, Michael Swift, John Brezak, Bill Gossman, 31-May-01, This proposal specifies a Kerberos (RFC 1510 [3]) change/set password protocol and a Kerberos change/set key protocol. The protocol consists of a single request and reply message. The request message includes both AP-REQ and KRB-PRIV submessages; the new password is contained in the KRB-PRIV submessage which is encrypted in the subsession key from the AP-REQ. "Passwordless Initial Authentication to Kerberos by Hardware Preauthentication", Matt Crawford, 24-Oct-02, This document specifies an extension to the Kerberos protocol for performing initial authentication of a user without using that user's long-lived password. Any 'hardware preauthentication' method may be employed instead of the password and the key of another principal must be nominated to encrypt the returned credntial. "Encryption and Checksum Specifications for Kerberos 5", Kenneth Raeburn, 11-Jun-03, This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. Several mechanisms are also defined in this document. Some are taken from RFC 1510, modified in form to fit this new framework, and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered 'required to implement'. Comments should be sent to the editor, or to the IETF Kerberos working group (ietf-krb-wg@anl.gov). "The Kerberos Network Authentication Service (V5)", Clifford Neuman, 19-Jun-03, 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. "Preparation of Internationalized Strings Profile for Kerberos UTF-8 Strings", Jeffrey Altman, 28-Feb-03, This document describes how to prepare UTF-8 strings for use with Kerberos protocols in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This is a profile of 'Preparation of Internationalized Strings' [RFC3454] "Integrating Single-use Authentication Mechanisms with Kerberos", Clifford Neuman, 01-Oct-02, 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. "Kerberos Set/Change Password: Version 2", Jonathan Trostle, 06-May-03, This proposal specifies an extensible protocol for setting keys and changing the passwords of Kerberos [RFC1510] principals. The protocol support a single operation per-session when run over UDP, or multiple operations per-session when run over TCP. Clients can change their own principal's password or keys or they can change other principals', provided that they are properly authorized to do so. Additional related features include the ability to determine the known aliases of Kerberos principals. This feature will facilitate the implementation of aliasing of target principal names in KDC requests by allowing principals to know which names are aliases of their canonical principal names. Principal aliasing is needed to properly support the use of aliases and short-form names by users without requiring that clients canonicalize principal names, possibly using insecure name services in the process. This protocol uses IETF language tags [RFC3066] to negotiate proper localization of help messages intended for users. UTF-8 is used throughout for strings, suitably constrained, where necessary, by the minor version of Kerberos V in use by clients and servers. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "L2TP Session Information (``SESINFO'')", William Palter, 28-Feb-02, This document defines additional L2TP AVPs that may be used during session or control connection establishment to provide additional node and port information for accounting and debugging use. "L2TP Header Compression ('L2TPHC')", Andy Valencia, 07-Nov-02, The Layer 2 Tunneling Protocol ('L2TP') [RFC2661] defines a mechanism for tunneling PPP sessions over arbitrary media. There exists a class of specific media 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'. "L2TP Multicast Extension", Gilles Bourdon, 07-Mar-03, The Layer Two Tunneling Protocol (L2TP) provides a standard method for tunneling PPP packets. This document describes an extension to L2TP, in order to have an efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by such tunnels. "L2TP Active Discovery Relay for PPPoE", W. Mark Townsley, Ron da Silva, 07-Mar-03, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP) [2], facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) [3] describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. "Layer Two Tunneling Protocol (Version 3)", Jed Lau, W. Mark Townsley, Ignacio Goyret, 30-Jun-03, This document describes 'version 3' of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple layer 2 connections between two IP connected nodes. Additional documents detail the specifics for each link-type being emulated. "Frame-Relay Pseudo-Wire Extensions for L2TP", W. Mark Townsley, 17-Jun-03, The Layer 2 Tunneling Protocol [L2TPv3] defines an extensible tunneling protocol suitable for Pseudowire Emulation Edge to Edge (PWE3) applications. This document describes the specifics of how to use the L2TP control plane for Frame-Relay Pseudo-Wires, including PVC creation, deletion, and line status change notification. "Fail Over extensions for L2TP", Reinaldo Penno, Keyur Parikh, 05-Nov-02, L2TP is a connection-oriented protocol that has shared state between active endpoints. Some of this shared state is vital for operation but may be rather volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid just for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network and improving a remote system's layer 2 connectivity. "Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)", Ignacio Goyret, 26-Mar-03, The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re- establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. "HDLC Frames Over L2TPv3", W. Mark Townsley, 17-Jun-03, Simple HDLC frame transport over L2TPv3 is described in this document. This mechanism may be used in the creation of pseudowires to transport HDLC PDUs over an IP network. "Layer Two Tunneling Protocol (Version 3) 'L2TPv3' Management Information Base", Evan Caves, Walter Klausberger, Jed Lau, 07-Nov-02, This document describes a portion of the Management Information Base (MIB) to manage the Layer Two Tunneling Protocol, Version 3 (L2TPv3). "Transport of Ethernet Frames over L2TPv3", Rahul Aggarwal, 22-Oct-02, This document describes transport of Ethernet frames over Layer 2 Tunneling Protocol (L2TPv3). This includes the transport of Ethernet port to port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudo Wires to transport Ethernet frames over an IP network. LDAP (v3) Revision (ldapbis) ---------------------------- "LDAP:String Representation of Distinguished Names", Kurt Zeilenga, 01-Jul-03, The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. "LDAP: The Protocol", Jim Sermersheim, 30-Jun-03, This document describes the protocol elements, along with their semantics and encodings, for the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). "LDAP: String Representation of Search Filters", Mark Smith, Tim Howes, 04-Mar-03, LDAP search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs and in other applications "LDAP: Authentication Methods and Connection Level Security Mechanism", Rod Harrison, 06-Mar-03, This document describes LDAPv3 (Lightweight Directory Access Protocol v3) authentication methods and connection level security mechanisms that are required of all conforming LDAPv3 server implementations and makes recommendations for combinations of these mechanisms to be used in various deployment circumstances. Among the mechanisms described are - various forms of authentication including anonymous authentication, password-based authentication, and certificate based authentication - the use of SASL mechanisms with LDAPv3 - the use of TLS (Transport Layer Security) with LDAPv3 - the various authentication and authorization states through which a connection to an LDAP server may pass and the actions that trigger these state changes. "LDAP: Uniform Resource Locator", Mark Smith, Tim Howes, 04-Mar-03, This document describes a format for an LDAP Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAPv3 referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. "LDAP: User Schema", Kathy Dally, 01-May-03, This document is a integral part of the LDAP technical specification [ROADMAP]. It provides an overview of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as, White Pages. Originally specified the ISO/IEC 9594 and X.500 documents, these objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. "LDAP: Syntaxes and Matching Rules", Kathy Dally, Steven Legg, 03-Jun-03, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, and whose values may be transfered in the LDAP protocol, has a defined syntax which constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. "LDAP: Technical Specification Road Map", Kurt Zeilenga, 01-Jul-03, The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document provides a roadmap of the LDAP Technical Specification. "LDAP: Directory Information Models", Kurt Zeilenga, 07-Mar-03, The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models. "LDAP: Internationalized String Preparation", Kurt Zeilenga, 01-Jul-03, The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This lead to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. "IANA Considerations for LDAP", Kurt Zeilenga, 23-Jun-03, This document provides procedures for registering extensible elements of Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. LDAP Duplication/Replication/Update Protocols (ldup) ---------------------------------------------------- "LDUP Update Reconciliation Procedures", Steven Legg, A Payne, 28-Feb-03, This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. "LDAP Replication Architecture", John Merrells, Ed Reed, UPPILI SRINIVASAN, 05-Mar-03, 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. "LDUP Replication Information Model", Richard Huber, John McMeeking, Ryan Moats, 01-Jul-03, [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 LDUP Replication Update Protocol", Ellen Stokes, 04-Mar-03, The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updateable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAPv3 extended operations and controls. LDAPv3 is described in RFC 2251 [LDAPv3]. Some LDAPv3 extended operations and controls described here are LDAPv3 extended operations used to group related operations. The protocol elements used for grouping are described in LDAPv3: Grouping of Related Operations [GROUPING]. Certain terms used in this document are defined in the document 'LDAP Replication Architecture' [ARCHITECTURE]. "General Usage Profile for LDAPv3 Replication", Richard Huber, Gerald Maziarski, Ryan Moats, 30-Jun-03, Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. "LDAP Client Update Protocol", Rich Megginson, Mark Smith, Olga Natkovich, Jeff Parham, 29-Apr-03, This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. "Mandatory LDAP Replica Management", Ryan Moats, Rick Huber, John McMeeking, 06-Mar-03, The goal of standards for LDAP replication is to allow interoperable replication among products from many different vendors. Defining the mechanism to move data among replicas is a necessary part of this work, but management of the replicated environment must also be standardized for replication to be truly interoperable. This document presents the replication management functions that must be performed. Whenever possible, these functions are defined in terms of existing LDAP functionality using existing LDAP operations and existing data definitions. In some cases, changes or additions to the existing model are required, and specifications for these changes are included in this document Enhancements to Internet email to support diverse service environments (lemonade) --------------------------------------------------------------------------------- "IMAP Submit Without Download", Randall Gellens, 19-Jun-03, IMAP clients operating over low-bandwidth or high-latency links, such as cellular telephones, need to be able to submit mail messages containing all or part of previously-received IMAP messages. Clients need to be able to do this without sloshing the bits both ways, that is, without being forced to download IMAP messages solely to be able to upload the content in a submitted message. This document currently identifies the two main approaches to doing this (called 'IMAP push' and 'IMAP pull'), one which adds submission to IMAP, and another which adds the expansion of IMAP references to message submission. This version of the document attempts to lay out the protocol mechanisms along with associated trade-offs and security considerations of each. Once a decision has been made to go with a particular technique, this document will describe the specifics of that choice as a standards-track proposal. "IMAP CHANNEL Protocol and Use Cases", Eric Burger, 24-Jun-03, Environments that extend beyond traditional text-based e-mail use IMAP4 to serve rich media content. One example is a cellular telephone that can retrieve and send MIME-encoded audio data through IMAP4. While IMAP4 can exchange this type of content, some applications will work better if the message content can be manipulated using schemes external to the IMAP4 connection. In our cellular telephone example, it might be preferable for the telephone client to retrieve the audio data using RTSP. This specification defines a mechanism for an IMAP4 client to request message content from a server through an external scheme. "Goals for Internet Messaging to Support Diverse Service Environments", Jeff Wong, 24-Jun-03, The mission of LEMONADE -- Internet Messaging to support diverse service environments -- is to provide a set of enhancements and profiles to Internet email to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. The enhanced mail service must continue to support conventional environments seamlessly. The primary driver for this effort is, by making Internet mail protocols richer and more media and environment-savvy, to allow their use over the mobile Internet. Stressing the needs of wireless handheld devices, a discussion is given of what is required of Internet messaging protocols to enable the support of multimedia messaging on limited capability messaging clients in diverse service environments. Also included is a list of general principles to guide the design of the enhanced messaging protocols. Finally, some issues around providing seamless service between enhanced Internet email and the existing separate mobile messaging infrastructure are briefly listed. Discussion of this and related drafts are on the LEMONADE WG email list. To subscribe, send the message 'subscribe' to lemonade-request@ietf.org. The public archive is in the directory at: ftp://ftp.ietf.org/ietf-mailing-lists/lemonade/ Multicast & Anycast Group Membership (magma) -------------------------------------------- "Socket Interface Extensions for Multicast Source Filters", Dave Thaler, Bill Fenner, Bob Quinn, 01-Jul-03, IGMPv3 for IPv4 and MLDv2 for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. It is expected that in the near future, the same capability will be available in IPv6 as well. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new APIs. These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications. "Using IGMPv3 and MLDv2 For Source-Specific Multicast", Hugh Holbrook, Bradley Cain, Brian Haberman, 05-Mar-03, The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source- Specific Multicast (SSM) is a particular form of multicast in which a network multicast transmission is bound to a specific source. This document describes clarifications of and modifications to the behavior of IGMPv3 and MLDv2 to accomodate source-specific multicast. "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Rolland Vida, Luis Costa, 04-Jun-03, This document specifies Version 2 of the Multicast Listener Discovery Protocol, MLDv2. MLD is 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. MLDv2 is derived from version 3 of IPv4's Internet Group Management Protocol, IGMPv3. Compared to the previous version, MLDv2 adds support for 'source filtering', that is, the ability for a node to report interest in listening to packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. This document obsoletes RFC 2710. "IGMPv3/MLDv2 and Multicast Routing Protocol Interaction", Brian Haberman, Jay Martin, 08-Jan-03, The definitions of IGMPv3 and MLDv2 require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates multicast routing protocols to manage and utilize the information. This document will describe how multicast routing protocols will interact with these source-filtering group management protocols. "Considerations for IGMP and MLD Snooping Switches", Morten Christensen, Karen Kimball, Frank Solensky, 06-May-03, This memo describes the requirements for IGMP- and MLD-snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. Interoperability issues that arise between different versions of IGMP are not the focus of this document. Interested readers are directed to [IGMPv3] for a thorough description of problem areas. "IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", Bill Fenner, 30-Jun-03, In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient to learn and proxy group membership information and simply forward based upon that information. This draft describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. "Multicast Router Discovery SSM Range Option", Isidor Kouvelas, 18-Jun-03, This document defines the Multicast Router Discovery protocol option for advertising the configured IPv4 Source Specific Multicast destination address range. "Multicast Source Notification of Interest Protocol (MSNIP)", Bill Fenner, 20-Jun-03, This document discusses the Multicast Source Interest Notification Protocol (MSNIP). MSNIP is an extension to IGMPv3 and MLDv2 that provides membership notification services for sources of multicast traffic operating within the SSM destination address range. "Source Address Selection for Multicast Listener Discovery Protocol (RFC 2710)", Brian Haberman, 30-Jun-03, It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery messages when a node is performing stateless address autoconfiguration. This memo is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. "Multicast Group Membership Discovery MIB", Julian Chesterfield, 25-Jun-03, 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 the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. Mobile Ad-hoc Networks (manet) ------------------------------ "Ad Hoc On Demand Distance Vector (AODV) Routing", Charles Perkins, Elizabeth Royer, Santanu Das, 27-Feb-03, The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as 'counting to infinity') associated with classical distance vector protocols. "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", Dave Johnson, 16-Apr-03, The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two mechanisms of 'Route Discovery' and 'Route Maintenance', which work together to allow nodes to discover and maintain source routes to arbitrary destinations in the ad hoc network. The use of source routing allows packet routing to be trivially loop-free, avoids the need for up-to-date routing information in the intermediate nodes through which packets are forwarded, and allows nodes forwarding or overhearing packets to cache the routing information in them for their own future use. All aspects of the protocol operate entirely on-demand, allowing the routing packet overhead of DSR to scale automatically to only that needed to react to changes in the routes currently in use. This document specifies the operation of the DSR protocol for routing unicast IP packets in multi-hop wireless ad hoc networks. "Optimized Link State Routing Protocol", Thomas Clausen, Philippe Jacquet, 12-May-03, This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs) [1], [2]. MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used by for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context. "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", Richard Ogier, Mark Lewis, Fred Templin, 26-Jun-03, TBRPF is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using 'differential' HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. MBONE Deployment (mboned) ------------------------- "Source-Specific Protocol Independent Multicast in 232/8", David Meyer, Robert Rockell, Greg Shepherd, 29-May-03, IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast [SSM] destination addresses and are reserved for use by source- specific applications and protocols [IANA]. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. "Multicast Source Discovery Protocol (MSDP) Deployment Scenarios", Mike McBride, 28-May-03, This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM) "IPv4 Multicast Best Current Practice", Bill Nickless, 17-Jun-03, This document describes best current practices for IPv4 multicast deployment, both within and between PIM Domains and Autonomous Systems. Media Gateway Control (megaco) ------------------------------ "Megaco/H.248 R2 Package", Kushanava Laha, Vikram Nair, 27-Feb-03, This document is work in progress and defines the R2 package for the Megaco/H.248 Protocol that can be used to exchange call setup supervisory and control information between a Media Gateway (MG) and a Media Gateway Controller (MGC) to realize Signaling System R2 at a VoIP Gateway. It is intended to satisfy the requirements in section 12 of the Megaco/H.248 protocol [2]. "Megaco MIB", Bala Pitchandi, I Akramovich, C Brown, Matt Holdrege, 29-Apr-03, 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 use by the MEGACO/H.248 protocol operating on Media Gateways and Media Gateway Controllers. These objects can be used to manage the network containing Media Gateways and Media Gateway Controllers. "The Megaco/H.248v2 Gateway Control Protocol, version 2", Christian Groves, Marcello Pantaleo, 03-Apr-03, This document describes the second version of the general-purpose gateway control protocol standardized as Megaco in the IETF and as Recommendation H.248 (now H.248.1) in the ITU-T. It is common text with Recommendation H.248.1 (05/02), published by the ITU-T. Megaco v2 includes the corrections to RFC 3015 which resulted in RFC xxxx [draft-ietf-megaco-3015corr-02.txt], plus the following new capabilities: - ability to audit specific properties, events, signals and statistics - use of serviceChange to indicate that capabilities have changed in the Media Gateway - playing a signal on the Root Termination - limiting the number of repetitions of transaction pending - allowing topology to be set per stream - ability to audit context properties - new Nx64K multiplex type - provision for digit buffering when a digit map completes. In addition, the use of the Modem Descriptor was deprecated. A detailed list of changes from draft-ietf-megaco-3015corr- 02.txt/H.248.1 (03/02) to this document is given in Appendix II at the end of this document. "Megaco/H.248 Call flow examples", Madhubabu Brahmanapally, Prerepa Viswanadham, Krishna Gundamaraju, 02-Jun-03, The Megaco/H.248 call flow examples draft illustrates the usage of Megaco - Version 1 protocol [Ref:3] defined between the Media Gateway Controller and Media Gateway. In light of the vast features presently incorporated and continuously evolving features of the protocol, it serves the purpose of representing typical use case scenarios. There are a lot of possible scenarios for usage of MEGACO protocol. It is not the intent of the draft to represent the inter-working functionality among various protocols, however, an attempt is made to depict its usage in such a case for the purpose of completeness in the larger perspective. An attempt has been made to illustrate the supplementary call services using MEGACO. Middlebox Communication (midcom) -------------------------------- "Middlebox Communications (MIDCOM) Protocol Evaluation", Mary Barnes, 21-Nov-02, This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. "MIDCOM Protocol Semantics", Martin Stiemerling, 17-Jun-03, This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Session Description Protocol (SDP) Source Filters", Bob Quinn, Ross Finlayson, 16-May-03, This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination 'connection' addresses. It defines the syntax and semantics for an SDP 'source-filter' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Charles Perkins, 22-May-03, This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. "Connection-Oriented Media Transport in SDP", David Yon, 07-Mar-03, This document describes how to express media transport over connection-oriented protocols using the Session Description Protocol (SDP). It defines two new protocol identifiers: TCP and TLS. It also defines the syntax and semantics for an SDP 'direction' attribute that describes the connection setup procedure. "Session Description and Capability Negotiation", Dirk Kutscher, Joerg Ott, Carsten Bormann, 07-Mar-03, This document defines a language for describing multimedia sessions with respect to configuration parameters and capabilities of end systems. 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. "RTCP attribute in SDP", Christian Huitema, 02-Jun-03, The session description protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these port have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Jari Arkko, 04-Mar-03, This document defines general extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, its use is meaningful only when it is completed by the key management protocol in use. General guidelines are also given on how the framework should be used together with SIP and RTSP. "SDPng Transition", Joerg Ott, Charles Perkins, 15-May-03, The Session Description Protocol (SDP) is today widely used in the Internet to announce as well as negotiate multimedia sessions and exchange capabilities. Having originally been designed for session announcements only, as opposed to announcements and capabilities negotiation announcements, native SDP lacks numerous features to be applicable in many session scenarios. Numerous extensions have been developed to circumvent SDP's shortcomings -- but they have also repeatedly shown its inherent limitations. A successor protocol -- termed 'SDPng' for the time being -- is developed to address the aforementioned needs of Internet applications in a more structured manner. With the huge installed base of SDP-based applications, a migration path needs to be developed to move from SDP to SDPng over time. This document outlines how this migration can be achieved: in general as well as for the various IETF control protocols that potentially make use of SDP and SDPng. "Real Time Streaming Protocol (RTSP)", Henning Schulzrinne, 07-Mar-03, This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time proper- ties. RTSP provides an extensible framework to enable controlled, on- demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This pro- tocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). "Implementation Status Of SDP", Tom Taylor, 14-Jan-03, This document is written to track implementations of the features of the Session Descritpion Protocol (SDP). Conventions used in this document This document is not intended to be normative, and therefore makes no reference to RFC 2119 conventions. "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", Magnus Westerlund, 26-Jun-03, The existing Session Description Protocol (SDP) bandwidth modifiers and their values include the bandwidth needed also for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP) and the Real-Time Streaming Protocol (RTSP) and when the involved hosts reside in networks running different IP versions, the interpretation of what lower layer bandwidths are included is not clear. This document defines a bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. "How to make Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls", Magnus Westerlund, 24-Feb-03, This document describes four different types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations that exist is given. Further a description on how RTSP relates to firewalls are also given. "SDP Security Descriptions for Media Streams", Mark Baugher, Dan Wing, 28-Feb-03, This Internet Draft gives a cryptographic attribute to Session Description Protocol (SDP) media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This draft also defines the SRTP parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. "Session Description Protocol Offer Answer Examples", Alan Johnston, Robert Sparks, 01-Jul-03, This document gives examples of Session Description Protocol (SDP) offer answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. IP Routing for Wireless/Mobile Hosts (mobileip) ----------------------------------------------- "Mobility Support in IPv6", Dave Johnson, Charles Perkins, Jari Arkko, 19-Jun-03, This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 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 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 a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary can communicate with mobile nodes. "AAA Registration Keys for Mobile IP", Charles Perkins, Pat Calhoun, 02-Jul-03, AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a AAA security association with its home AAA server, however, it is possible to use that security association to create derived mobility security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create mobility security associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, 21-Oct-02, This draft introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 reduces the amount of signalling between the Mobile Node, its Correspondent Nodes and its Home Agent. The Mobility Anchor Point described in this document can also be used to improve the performance of Mobile IPv6 in terms of handoff speed. "Fast Handovers for Mobile IPv6", Rajeev Koodli, 05-Mar-03, Mobile IPv6 describes how a Mobile Node can maintain connectivity to the Internet when it changes its Access Router for another, a process referred to as handover. During this process, there is a time period when the Mobile Node is unable to send or receive IPv6 packets both due to link switching delay and IP protocol operations. This time period is referred to as handover latency. In many instances, the handover latency resulting from standard Mobile IPv6 handover procedures could be greater than what is acceptable to support real-time or delay sensitive traffic. Furthermore, reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. The intent of this document is to describe protocol enhancements to reduce handover latency due to IP protocol operations as small as possible in comparison to the inevitable link switching latency. "Low latency Handoffs in Mobile IPv4", Karim Malki, 23-Jun-03, Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low- latency Mobile IP handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. "Registration Revocation in Mobile IPv4", Steven Glass, M Chandra, 22-May-03, This document defines a Mobile IPv4 Registration Revocation mechanism whereby either mobility agent participating in providing Mobile IP services to the same mobile node can notify the other mobility agent (or co-located mobile node) of the termination of a binding, and for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. "Localized Mobility Management Requirements", Carl Williams, 06-Mar-03, This document describes requirements for Localized Mobility Management (LMM) for Mobile IP and Mobile Ipv6 protocols. These requirements are intended to guide the design of a protocol specification for LMM. Localized Mobility Management, in general, introduces enhancements to Mobile IPv4 and Mobile IPv6 to reduce the amount of latency in binding updates sent to the Home Agent and, for route-optimization, Correspondent Nodes, upon Care of Address change. In addition, LMM seeks to reduce the amount of signaling over the global Internet when a mobile node traverses within a defined local domain. The identified requirements are essential for localized mobility management functionality. They are intended to be used as a guide for analysis on the observed benefits over the identified requirements for architecting and deploying LMM schemes. "Mobile IPv4 Challenge/Response Extensions (revised)", Charles Perkins, Pat Calhoun, Jayshree Bharatia, 27-May-03, Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays, and does not allow for the use of CHAP for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. This document obsoletes RFC 3012. "AAA NAI for Mobile IPv4 Extension", Fredrik Johansson, Tony Johansson, 07-Mar-03, When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. "Problem Statement: Mobile IPv4 Traversal of VPN Gateways", Farid Adrangi, Henrik Levkowetz, 26-Jun-03, Deploying Mobile-IP v4 in networks which are connected to the internet through a VPN (Virtual Private Network) gateway presents some problems which do not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions. "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", Jari Arkko, Vijay Devarapalli, Francis Dupont, 27-May-03, Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This draft discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", Sami Vaarala, 01-Jul-03, This document outlines the proposed solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec are not required Multiprotocol Label Switching (mpls) ------------------------------------ "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", Joan Cucchiara, Hans Sjostrand, James Luciani, 01-Jul-03, 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 for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base", Cheenu Srinivasan, Arun Viswanathan, Thomas Nadeau, 27-Jun-03, 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 for Multiprotocol Label Switching (MPLS) based traffic engineering. "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base", Cheenu Srinivasan, Arun Viswanathan, Thomas Nadeau, 01-Jul-03, This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR). "Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol", Peter Ashwood-Smith, Bilel Jamoussi, Don Fedyk, D Skalecki, 27-Jun-03, One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints, which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. A new mechanism is proposed whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This information is most valuable in failure scenarious but is benificial during other path setup functions as well. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. "LSP Hierarchy with Generalized MPLS TE", Kireeti Kompella, Yakov Rekhter, 11-Sep-02, To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base", Thomas Nadeau, Cheenu Srinivasan, Arun Viswanathan, 26-Jun-03, 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 for defining, configuring and monitoring Forwarding Equivalent Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). "Multi Protocol Label Switching Label Distribution Protocol Query Message Description", Peter Ashwood-Smith, Antonela Paraschiv, David Allan, 30-Jun-03, This document describes the encoding and procedures for three new Label Distribution Protocol (LDP) messages: Query Message, Query- Reply Message and Partial Query-Reply Message. A Label Edge Router (LER) sends a Query message when it needs to find out information about an established Label Switched Path (LSP). The Query message can be used for LDP LSPs as well as for Constraint-Based Label Switched Paths (CR-LSPs). The queried data is encoded into the Query-Reply messages. "Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management", Thomas Nadeau, Joan Cucchiara, 01-Jul-03, This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Mulitprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. "Link Bundling in MPLS Traffic Engineering", Kireeti Kompella, Yakov Rekhter, Lou Berger, 24-Jul-02, For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct which is described in this document. "Multiprotocol Label Switching (MPLS) Management Overview", Thomas Nadeau, Cheenu Srinivasan, Adrian Farrel, 09-Jun-03, A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This memo describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. "Graceful Restart Mechanism for BGP with MPLS", Yakov Rekhter, Rahul Aggarwal, 14-Oct-02, A mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart is described in 'Graceful Restart Mechanism for BGP' (see [1]). This document extends this mechanism to also minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such it works in conjunction with any of the address famililies that could be carried in BGP (e.g., IPv4, IPv6, etc...) The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve their forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the BGP-related state to be preserved across the restart. "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Ping Pan, 02-Jul-03, This document defines extensions to and describes the use of RSVP to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either or both methods and to interoperate in a mixed network. "Detecting MPLS Data Plane Liveness", Kireeti Kompella, 06-Mar-03, This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS 'echo request' and 'echo reply' for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, 06-Nov-02, 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 for Multiprotocol Label Switching (MPLS) based fast rerouting. "MTU Signalling Extensions for LDP", Benjamin Black, Kireeti Kompella, 09-Jun-03, Proper functioning of RFC 1191 path MTU discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent, off-line mechanisms. This document specifies extensions to LDP in support of LSP MTU discovery. "Encapsulating MPLS in IP or GRE", Tom Worster, Yakov Rekhter, Eric Rosen, 14-Jan-03, In various applications of MPLS, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is applicable in some circumstances. "Applicability Statement for Restart Mechanisms for the Label Distribution Protocol", Adrian Farrel, 11-Jun-03, Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to a minimum. Similarly, where MPLS is at the network edges (for example, in Provider Edge routers) system downtime must also be kept as small as possible. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including the switching hardware and the TCP stack are implementation specific. How the software module itself chooses to implement FT for the state created by the Label Distribution Protocol (LDP) is also implementation specific but there are several issues in the LDP specification in RFC 3036 'LDP Specification' that make it difficult to implement an FT LSR using the LDP protocols without some extensions to those protocols. Proposals have been made in 'Fault Tolerance for the Label Distribution Protocol (LDP)' [LDP-FT] and "LDP DoD Graceful Restart", Bob Thomas, Alex Raj, 18-Apr-03, LDP graceful restart is a mechanism that helps reduce the negative effects on MPLS traffic caused by the restart of a Label Switching Router's (LSR's) control plane, specifically by the restart of its Label Distribution Protocol (LDP) component [RFC3036], on LSRs that are capable of preserving MPLS forwarding state across the restart. [RFC3478] defines procedures for LDP graceful restart for downstream unsolicited label distribution but leaves procedures for downstream on demand label distribution a subject for future study. This document defines graceful restart procedures for downstream on demand label distribution. "Definition of an RRO node-id subobject", Jean Vasseur, 19-May-03, In the context of MPLS TE Fast Reroute ([FAST-REROUTE]), the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find an MP address in multi-areas or multi-domain routing networks. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this draft refers to the 'Facility backup' MPLS TE Fast Reroute method. "OAM Requirements for MPLS Networks", Thomas Nadeau, 01-Jul-03, As transport of diverse traffic types such as voice, frame relay, and ATM over MPLS become more common, the ability to detect, handle and diagnose control and data plane defects becomes critical. Detection and specification of how to handle those defects is not only important because such defects may not only affect the fundamental operation of an MPLS network, but also because they may impact SLA commitments for customers of that network. This Internet draft describes requirements for user and data plane operations and management (OAM) for Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks, similarly some of these requirements have appeared in other documents [Y1710]. This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such as pseudowire voice and VPN services. Those interested in specific issues relating to instrumenting MPLS for OAM purposes are directed to [FRAMEWORK] "MPLS Traffic Engineering Soft preemption", Matthew Meyer, 18-Apr-03, This draft documents MPLS TE Soft Preemption, a suite of protocol modifications extending the current concept of preemption with the goal of reducing/eliminating traffic disruption of preempted TE LSPs. Under present RSVP-TE signaling methods, LSPs are immediately displaced upon preemption. The introduction of a new preemption pending flag helps more gracefully mitigate the re-route process of displaced LSPs. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect overbooked until the LSP can be re-routed. For this reason, the feature is primarily interesting in packet oriented MPLS networks with Diffserv and TE capabilities. "Traffic Engineering Link Management Information Base", Martin Dubuc, Sudheer Dharanikota, Thomas Nadeau, Jonathan Lang, 22-May-03, 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 for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering document. Multicast Source Discovery Protocol (msdp) ------------------------------------------ "Multicast Source Discovery protocol MIB", Bill Fenner, Dave Thaler, 29-May-03, 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 Multicast Source Discovery Protocol (MSDP) [2] speakers. "Multicast Source Discovery Protocol (MSDP)", David Meyer, Bill Fenner, 27-May-03, The Multicast Source Discovery Protocol, MSDP, describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) [RFC2362] domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations. Multicast Security (msec) ------------------------- "The Group Domain of Interpretation", Mark Baugher, Thomas Hardjono, Hugh Harney, Brian Weis, 08-May-03, This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. "GSAKMP", Hugh Harney, 01-Jul-03, This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. "Group Key Management Architecture", Lacshminath Dondeti, 06-Mar-03, This document presents a group key-management architecture for MSEC. The purpose of this document is to define the common architecture for MSEC group key-management protocols that support a variety of application, transport, and internetwork security protocols. To address these diverse uses, MSEC may need to standardize two or more group key management protocols that have common requirements, abstractions, overall design, and messages. The framework and guidelines in this document allow for a modular and flexible design of group key management protocols for a variety different settings that are specialized to application needs. Comments on this document should be sent to msec@securemulticast.org. "GSAKMP Light", Hugh Harney, A Schuett, Andrea Colegrove, 30-Jul-02, A protocol specification must balance two often conflicting goals: to produce as general a protocol as possible, and to produce a simple protocol. The Group Secure Association Key Management Protocol (GSAKMP) is a general protocol for creating and managing cryptographic groups on a network. This document describes the GSAKMP-Light (GL) profile, a way to shorten the number of messages exchanged during secure group establishment. The GSAKMP protocol assumed that group members joining a secure group had no information about the specific security mechanisms used by the group (for example, the key length, encryption protocol, etc). GSAKMP-Light provides a profile for the case where group members have been previously notified of these security mechanisms, used for joining a group, during the group announcement or invitation. This simplification removes 2 messages from the group establishment portion of the GSAKMP protocol, eliminates the need for initiating a unicast security association, and removes the need for many of the optional fields of individual messages. The profile does not sacrifice any of the security properties of the full protocol. To facilitate the transmission of security mechanism settings during session invitation or announcement, this document also describes a useful default set of security algorithms and configurations, Security Suite 1. Full specification of this suite allows an entire set of algorithms and settings to be described to prospective group members in a concise manner. Future security suites can be defined as needed. "MIKEY: Multimedia Internet KEYing", Jari Arkko, 30-Jun-03, Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. "TESLA: Multicast Source Authentication Transform Introduction", Adrian Perrig, 30-Oct-02, Data authentication is an important component for many applications, for example audio and video Internet broadcasts, or data distribution by satellite. This document introduces TESLA, a secure source authen­ tication mechanism for multicast or broadcast data streams. This doc­ ument provides an algorithmic description of the scheme for informa­ tional purposes, and in particular, it is intended to assist in writ­ ing standardizable and secure specifications for protocols based on TESLA in different contexts. The main deterrents so far for a data authentication mechanism for multicast were the seemingly conflicting requirements: loss toler­ ance, high efficiency, no per-receiver state at the sender. The prob­ lem is particularly hard in settings with high packet loss rates and where lost packets are not retransmitted, and where the receiver wants to authenticate each packet it receives. TESLA provides authentication of individual data packets, regardless of the packet loss rate. In addition, TESLA features low overhead for "HMAC-authenticated Diffie-Hellman for MIKEY", Martin Euchner, 23-Jan-03, This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC- SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. "MESP: A Multicast Framework for the IPsec ESP", Mark Baugher, Ran Canetti, 21-Mar-03, Multicast ESP (MESP) is a framework for multicast data-origin authentication using the IPsec Encapsulating Security Payload (ESP) protocol. The MESP framework combines group-secrecy, group- authentication, and source-authentication transforms in an ESP packet. MESP uses a message authentication code for group authentication to protect a digital signature, TESLA timed MAC, or other multicast source-authentication transform. "TESLA: Multicast Source Authentication Transform Specification", Ran Canetti, Adrian Perrig, Bram Whillock, 30-Oct-02, Data authentication is an important component for many applications, for example audio and video Internet broadcasts, or data distribution by satellite. This document specifies TESLA, a secure source authen­ tication mechanism for multicast or broadcast data streams. The com­ panion draft draft-msec-tesla-intro-01.txt [1] introduces and describes TESLA in detail, this document specifies the format of the TESLA authentication field as it is used within the MESP header [2]. The main deterrents so far for a data authentication mechanism for multicast were seemingly conflicting requirements: tolerance to packet loss, low per-packet overhead, low computation overhead, scal­ ability, no per-receiver state at the sender. The problem is particu­ larly hard in settings with high packet loss rates and where lost packets are not retransmitted, and where the receiver wants to authenticate each packet it receives. TESLA provides multicast source authentication of individual data packets, regardless of the packet loss rate. In addition, TESLA features low overhead for both sender and receiver, and does not require per-receiver state at the sender. TESLA is secure as long as the sender and receiver are loosely time synchronized. "IP Multicast issues with IPsec", Mark Baugher, Ran Canetti, Thomas Hardjono, Brian Weis, 23-Dec-02, The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, RFC2406] define certain mechanisms for IP multicast traffic. The recent revisions to each of the protocol documents [ESPbis, AHbis] propose changes to those semantics. However, neither the existing nor proposed semantics are sufficiently general such that IPsec can be used to protect the wide variety of IPv4 and IPv6 multicast applications that are expected by the IP multicast community. In particular, they are not compatible with the needs of the protocols developed in the MSEC WG and for Source Specific Multicast [RFC3376, SSM-ARCH]. This document reviews these semantics and proposes some minor changes, which would enable IPsec to be suitable for these uses. "GSAKMP Token Specification", Hugh Harney, 24-Feb-03, This document specifies the Group Secure Association Key Management Protocol (GSAKMP) Policy Token. The Token provides a format to specify a complete group security policy, necessary for formation of a group secure association. The GSAKMP Token maintains procedures for key dissemination, group membership, authorization and rekey. "The Multicast Security (MSEC) Architecture", Thomas Hardjono, Brian Weis, 08-May-03, This document provides a foundation for the protocols developed by the Multicast Security (MSEC) group. The document begins by introducing a Reference Framework, and proceeds to identify functional areas which must be addressed as part of a secure multicast solution. "Tunneled Group Secure Association Key Management Protocol", Hugh Harney, 20-May-03, The Tunneled Group Secure Association Key Management Protocol (T-GSAKMP) provides a security framework for creating cryptographic groups on a network. It is designed to provide key distribution services under the cryptographic protection of a pairwise SA, like IPSec. T-GSAKMP relies on the pairwise SA to provide data confidentiality services for policy, DoS mitigation services, and protection from 'man-in-the-middle' attacks. It provides mechanisms to disseminate group security policy, perform access control based upon PKI certificates, generate group keys, and recover from compromise. This framework addresses group scalability issues by facilitating delegation of process-intensive actions in a secure and controlled manner. "Securing Feedback Messages: Secure and Scalable Many-to-one Communication", Lacshminath Dondeti, Thomas Hardjono, 24-Jun-03, Members in a secure group may need to communicate to the GCKS to Deregister from the group, for SA resynchronization, or to request retransmission of a Rekey message. A simple solution is to keep the registration SA around, but that comes at the expense of O(n) SA maintenance, and storage at the GCKS. Each member is also responsible for maintaining an extra SA. We propose an efficient method for mem- bers to securely send messages to the GCKS, using the Rekey SA. Message Tracking Protocol (msgtrk) ---------------------------------- "Message Tracking Model and Requirements", Tony Hansen, 25-Oct-02, Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. "Message Tracking Query Protocol", Tony Hansen, 25-Oct-02, Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with exten- sions to the ESMTP protocol to provide a complete message tracking solu- tion for the Internet. "SMTP Service Extension for Message Tracking", Eric Allman, Tony Hansen, 01-Apr-03, This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. "An Extensible Message Format for Message Tracking Responses", Eric Allman, 01-Apr-03, Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications [RFC-DSN-SMTP] and Message Disposition Notifications [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME [RFC-MIME] content-type for message tracking status in the same spirit as RFC 1894, 'An Extensible Message Format for Delivery Status Notifications' [RFC-DSN-STAT]. It is to be issued upon a request as described in 'Message Tracking Query Protocol' [DRAFT-MTRK-MTQP]. This memo defines only the format of the status information. An extension to SMTP [RFC-ESMTP] to label messages for further tracking and request tracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. Site Multihoming in IPv6 (multi6) --------------------------------- "Goals for IPv6 Site-Multihoming Architectures", Joe Abley, Benjamin Black, Vijay Gill, 13-Jun-03, Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. Network Mobility (nemo) ----------------------- "Network Mobility Support Goals and Requirements", Thierry Ernst, 15-May-03, Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions. "Network Mobility Support Terminology", Thierry Ernst, Hong Lach, 16-May-03, This document defines a terminology for discussing network mobility problems and solution requirements. Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. "Nemo Basic Support Protocol", Vijay Devarapalli, 25-Jun-03, This document describes a protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The protocol is based on extensions to Mobile IPv6 [1]. The Mobile Router [2] which connects the network to the Internet runs the NEMO protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. Network File System Version 4 (nfsv4) ------------------------------------- "A Server-to-Server Replication/Migration Protocol", Robert Thurlow, 28-May-03, NFS Version 4 [RFC3010] provided support for client/server interactions to support replication and migration, but left unspecified how replication and migration would be done. This document is an initial draft of a protocol which could be used to transfer filesystem data and metadata for use with replication and migration services for NFS Version 4. "Server-to-Server Replication/Migration Protocol Design Principles", Robert Thurlow, 20-Dec-02, NFS Version 4 [RFC3010] provided support for client/server interactions to support replication and migration, but left unspecified how replication and migration would be done. This document discusses the nature of a protocol to be used to transfer filesystem data and metadata for use with replication and migration services for NFS Version 4. "XDR: External Data Representation Standard", Mike Eisler, 07-May-03, This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. "The Channel Conjunction Mechanism (CCM) for GSS", Mike Eisler, Nevin Williams, 19-May-03, This document describes a suite of new mechanisms under the GSS [RFC2743]. Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to authenticate every message transfer, thereby incurring significant overhead due to the costs of cryptographic computation. While hardware-based cryptographic accelerators can mitigate such overhead, it is more likely that acceleration will be available for lower layer protocols, such as IPsec [RFC2401] than for upper layer protocols like RPCSEC_GSS. CCM can be used as a way to allow GSS mechanism- independent upper layer protocols to leverage the data stream protections of lower layer protocols, without the inconvenience of modifying the upper layer protocol to do so. "NFSv4.1: SECINFO Changes", Mike Eisler, 09-May-03, This document proposes some changes to security negotiation in NFS version 4 [RFC3530]. It is hoped that these changes will be part of a new minor version of NFS: NFSv4.1. "RPC Numbering Authority Transfer to IANA", Robert Thurlow, 20-May-03, Network services based on RPC [RFC1831] use program numbers rather than well known transport ports to permit clients to find them, and use authentication flavor numbers to define the format of the authentication data passed. The assignment of RPC program numbers and authentication flavor numbers is still performed by Sun Microsystems, Inc. This is inappropriate for an IETF standard protocol, as such work is done well by the Internet Assigned Numbers Authority (IANA). This document defines how IANA will maintain and assign RPC program numbers and authentication flavor numbers. "RPC: Remote Procedure Call Protocol Specification Version 2", Robert Thurlow, 20-May-03, This document describes the ONC (Open Network Computing) Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. It is meant to supersede [RFC1831]. NNTP Extensions (nntpext) ------------------------- "Network News Transport Protocol", Clive Feather, 25-Apr-03, The Network News Transport Protocol (NNTP) 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. "Using TLS with NNTP", Jeffrey Vinocur, Chris Newman, 28-Feb-03, This memo defines an extension to the Network News Transport Protocol [NNTP] to provide connection-based encryption (via Transport Layer Security [TLS]). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity and (optional) certificate-based peer entity authentication are also described. "NNTP Extension for Streaming Feeds", Jeffrey Vinocur, 03-Jun-03, This memo defines an extension to the Network News Transport Protocol [NNTP] to provide asynchronous transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency. Operation of the IESG/IAB Nominating and Recall Committees (nomcom) ------------------------------------------------------------------- "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", James Galvin, 18-Jun-03, The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. Individual Submissions (none) ----------------------------- "Printer MIB v2", Ron Bergman, Harry Lewis, Ira McDonald, 21-Feb-03, This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. "Securing FTP with TLS", Paul Ford-Hutchinson, Martin Carpenter, Tim Hudson, Eric Murray, Volker Wiegand, 27-Mar-03, 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 [RFC-2246] and the extensions to the FTP protocol defined by [RFC-2228]. 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. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817]. "Definition of an Object Class to Hold LDAP Change Records", Gordon Good, Ludovic Poitou, 04-Mar-03, 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 that 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 that may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object that holds these change records, so that clients and servers have a common rendezvous point for this information. "Originator-Info Message Header", Chris Newman, 28-May-98, 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. "Handle System Overview", Sam Sun, Larry Lannom, 01-Jul-03, This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URN. The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources. "The Java LDAP Application Program Interface", Rob Weltman, Christine Ho, Steven Sonntag, 03-Apr-03, This document defines a Java [JAVA] language application program interface to the Lightweight Directory Access Protocol (LDAP) [LDAPv3], in the form of a class library. "LDAP Proxied Authentication Control", Rob Weltman, 23-Apr-03, This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of as the current authorization identity associated with the connection. "LDAP Extensions for Scrolling View Browsing of Search Result", David Boreham, Jim Sermersheim, Asaf Kashi, 05-Nov-02, This document describes a Virtual List View extension for the Lightweight Directory Access Protocol (LDAP) Search operation. This extension 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 extension 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. "Common Internet Message Header Fields", Jacob Palme, 06-Sep-02, This memo contains tables 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 2156, RFC 1496, RFC 1766, RFC 2183, RFC 1864, RFC 2421 and RFC 2045. 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. The latest, revised version of this document can be found at URL http://www.dsv.su.se/jpalme/ietf/mail-headers/. The version at that URL may be more recent than the version published as an RFC. Another list of headers can be found at URL http://www.cs.tut.fi/~jkorpela/headers.html [28] "Sieve: Vacation Extension", Tim Showalter, 13-May-03, This document describes an extension to the Sieve mail filtering language for an autoresponder similar to that of the Unix 'vacation' command for replying to messages with certain safety features to prevent problems. "Printer Finishing MIB", Ron Bergman, Harry Lewis, Ira McDonald, 21-Feb-03, This document defines a MIB module 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 application/smil and application/smil+xml Media Types", Philipp Hoschka, 13-Sep-02, This document specifies the Media Type for version 1 and version 2 of the Synchronized Multimedia Integration Language (SMIL 1.0 and SMIL 2.0). SMIL allows ntegrating a set of independent multimedia objects into a synchronized multimedia presentation. "The Common Gateway Interface (CGI) Version 1.1", David Robinson, Ken Coar, 16-Apr-03, 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. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. "X.509 Authentication SASL Mechanism", Steve Kille, 24-Feb-00, 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. "Sieve -- IMAP flag Extension", Alexey Melnikov, 30-Jun-03, Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords. "Appropriate Mailing List Behaviour", Jacob Palme, 02-Dec-02, This memo summarizes common ideas on how good mailing lists should behave. Some of this is taken from IETF standards, some is not. This memo is not intended, itself, to become a standard, but might, if accepted by the IETF, be published as informational RFC or as a Best Current Practice (BCP) document. "Per Hop Behaviors Based on Dynamic Packet State", Ion Stoica, Hui Zhang, Fred Baker, Yoram Bernet, 09-Oct-02, This document proposes a family of Per-Hop Behaviors (PHBs) based on Dynamic Packet State (DPS) in the context of the differentiated service architecture. With these PHBs, distributed algorithms can be devised to implement services with flexibility, utilization, and assurance levels similar to those that can be provided with per-flow mechanisms. With Dynamic Packet State, each packet carries in its header, in addition to the PHB codepoint, some PHB-specific state. The state is initialized by the ingress node. Interior nodes process each incoming packet based on the state carried in the packet's header, updating both its internal state and the state in the packet's header before forwarding it to the next hop. By using DPS to coordinate actions of edge and interior nodes along the path traversed by a flow, distributed algorithms can be designed to approximate the behavior of a broad class of 'stateful' networks using networks in which interior nodes do not maintain per-flow state. We give examples of services that can be implemented by PHBs based on DPS. We also discuss several possible solutions for encoding Dynamic Packet State that have the minimum incompatibility with IPv4. "The VND Tree for URL Scheme Names", Ian King, 24-Jul-00, This document describes the vnd scheme namespace, or 'tree,' which provides for vendor-specific URL scheme namespaces with relaxed registration requirements, which can be used with no concern for name collision. The namespace also implicitly provides identification of the originator of the URL scheme, in the event others become interested in the scheme. "Geographic registration of HTML documents", Andrew Daviel, Felix Kaegi, 25-Apr-01, This memo describes a method of registering HTML documents with a specific geographic location through means of embedded META tags. The content of the META tags gives the geographic position of the resource described by the HTML document in terms of Longitude, Latitude and optionally Elevation in a simple, machine-readable manner. This information may be used for automated resource discovery by means of an HTML indexing agent or search engine. "Host Identity Protocol", Robert Moskowitz, Pekka Nikander, Petri Jokela, 19-Jun-03, This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity (HI), Host Identity Tag (HIT), and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS) attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. "SMIng - Next Generation Structure of Management Information", Frank Strauss, Juergen Schoenwaelder, 29-May-03, This memo presents a data definition language for the specification of various kinds of management information. It is independent of management protocols and applications. Protocol mappings are defined as extensions to this language in separate memos. The language builds on experiences gained with the SMIv2 and its derivate SPPI. "Flexible Authentication for DHCP Messages", Vipul Gupta, 05-Mar-03, This memo proposes a new protocol for DHCP authentication within the general framework outlined in RFC 3118 [4]. This protocol uses public-key cryptography, in the form of digital signatures, for authentication. This simplifies key management and supports mutual authentication between clients and servers belonging to different administrative domains. "Handle System Namespace and Service Definition", Sam Sun, Sean Reilly, Larry Lannom, 01-Jul-03, The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the handle system protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the handle system operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the handle system authentication protocol. "IP over MIME", Donald Eastlake 3rd, 07-May-03, The MIME encoding of IP packets is standardized enabling them to be sent via MAIL, HTTP, etc. This may be convenient for transmitting packets for analysis or for creating application level SP tunnels. "LDAP Authorization Identity Request and Response Controls", Rob Weltman, Mark Smith, Mark Wahl, 24-Apr-03, This document extends the Lightweight Directory Access Protocol (LDAP) [RFC3377] bind [LDAPPROT] operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. "Returning Matched Values with LDAPv3", David Chadwick, Sean Mullan, 27-Jun-02, This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry, specifically, only those values that match a 'values return' filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. "Secure Remote Password Authentication Mechanism", Keith Burdis, Raif Naffah, 02-Jun-03, This document describes an authentication mechanism based on the Secure Remote Password protocol (SRP-6) and how to use it with the authentication frameworks Secure Authentication and Security Layer (SASL), Generic Security Services Application Programming Interface (GSS-API) and Extensible Authentication Protocol (EAP). This mechanism performs mutual authentication and can provide a security layer with replay detection, integrity protection and/or confidentiality protection. "A Taxonomoy of Methods for LDAP Clients Finding Servers", Ryan Moats, Roland Hedberg, 03-Jul-01, There are several different methods for a LDAP client to find a LDAP server. This draft discusses these methods and provides pointers for interested parties to learn more about implementing a particular method. "Discovering LDAP Services with DNS", Michael Armijo, Levon Esibov, Paul Leach, RL Bob Morgan, 12-Jun-02, A Lightweight Directory Access Protocol (LDAP) request must be directed to an appropriate server for processing. This document specifies a method for discovering such servers using information in the Domain Name System. "IP Multicast in Differentiated Services Networks", Roland Bless, Klaus Wehrle, 25-Feb-03, This document identifies problems which will arise when IP Multicast is used in Differentiated Services (DS) networks. Although the basic DS forwarding mechanisms work with IP Multicast as well, some facts have to be considered which are related to the provisioning of multicast resources. The presented problems mainly lead to situations in which other service users are affected adversely in their experienced quality. An adequate solution is described in this document. It provides the necessary resource decoupling for protecting reserved resources until admission control is performed. "LDAP Bulk Update/Replication Protocol", Rod Harrison, Jim Sermersheim, Yulin Dong, 06-Mar-01, The LDAP Bulk Update/Replication Protocol (LBURP) described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server. The protocol groups a set of update operations using the LDAP framed protocol requests defined in [FRAMING] to notify the client that the update operations in the framed set are related. The update operations within the framed set are LDAPv3 extended operations each encapsulating a sequence number and one or more LDAPv3 update operations. The sequence number allows the server to process the update operations in the proper order even when they are sent asynchronously by the client, and the update operations can be grouped within the extended request to maximize the efficiency of client-server communication. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally update the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. "Password Policy for LDAP Directories", Prasanta Behera, Ludovic Poitou, Jim Sermersheim, 04-Mar-03, Password policy as described in this document is a set of rules that controls how passwords are used and administered in LDAP directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts. "Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network", Yingchun Xu, 17-May-01, This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminating at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. "Quick Transaction Protocol - QTP", Allan Cornish, Michael Cox, Robert Neill, Ian Palmer, Angus Telfer, Cliff Wignell, Cameron Young, 03-Oct-02, QTP is a simple protocol for multiplexing short-duration connections over an arbitrary transport service such as UDP. QTP is an open standard to allow dial-up Credit Authorization Terminals (CAT) or Point-Of-Sale (POS) terminals to connect into IP hosts. These transactions require fast connection times, efficient concentration of many sessions, fault tolerant operation, and the ability to transfer access network addressing (called and calling numbers) along with transaction data. "Transport of Layer 2 Frames Over MPLS", Luca Martini, Nasser El-Aawar, 28-Apr-03, This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. "Host Identity Protocol Architecture", Robert Moskowitz, 07-May-03, This memo describes the reasoning behind proposing a new namespace, the Host Identity namespace, and a new layer, Host Identity Layer, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, strengths and weaknesses, and how a new namespace will add completeness to them. This new namespace's roles in the protocols are defined. "Cisco Systems' Simple Certificate Enrollment Protocol (SCEP)", Xiaoyi Liu, Cheryl Madson, David McGrew, Andy Nourse, 04-Jun-03, This document specifies the Cisco Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations "A Protocol for Remotely Managing Sieve Scripts", Tim Martin, 22-Jul-02, Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol 'sieve' for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. This an interim measure as it is hoped that eventually Sieve scripts will be stored on ACAP. This document is intended to proceed on the experimental track. "Netnews Administration System (NAS)", Philipp Grau, Vera Heinau, Heiko Schlichting, 18-Jun-03, The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server-protocol. The database is accessible by news servers and news administrators as well as by news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, to provide detailed information about groups and hierarchies to the user. NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server or news reader software, however, some tasks will be better accomplished with NAS compliant software. "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", Hilarie Orman, Paul Hoffman, 04-Jan-02, Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of the length of a symmetric key. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. "Use of IPsec Transport Mode for Dynamic Routing", Joseph Touch, L Eggert, Yu-Shun Wang, 15-Apr-03, This document addresses the use of IPsec to secure the links of a virtual (private) network (VN/VPN). It describes how virtual links established by IPsec tunnel mode conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses. This document proposes a solution, called IIPtran, in which IPIP encapsulation separate from IPsec is used together with transport- mode IPsec. IPIP tunnel encapsulation occurs as a separate initial step, based on a forwarding lookup of the VN packet. After the forwarding lookup, IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture, by establishing a complete virtual topology with IPIP tunnels that supports static and dynamic routing, and then securing it with IPsec transport mode. The document also discusses how IIPtran compares to several alternative mechanisms for VN routing, and their respective impact on IPsec, routing, policy enforcement and interactions with the Internet Key Exchange (IKE), among other issues. This document is a product of the X-Bone and DynaBone projects at USC/ISI [N5][N8]. Comments are solicited and should be addressed to the authors. "AAA for IPv6 Network Access", Charles Perkins, 09-May-03, IPv6 nodes (clients) need a way to offer credentials to the AAA infrastructure in order to be granted access to the local network. For IPv6, it will be more efficient and thus reasonable to expect such access controls to be exerted by IPv6 routers, possibly as part of performing their role as DHCPv6 relays. Routers and DHCPv6 servers are expected to work in conjunction with AAA servers to determine whether or not the client's credentials are valid. Routers can exert such network access control by the device of carefully controlling entries in their packet filter and Neighbor Cache. "RSVP Proxy", Silvano Gai, Sunil Gaitonde, Nitsan Elfassy, Yoram Bernet, 07-Mar-02, RSVP has been extended in several directions [POLICY], [RSVP-APPID], [DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the applicability of RSVP characterizing it as a signaling protocol usable both inside and outside the Integrated Services [INTSERV] model. With the addition of the 'Null Service Type' [NULLSERV], RSVP is also being adopted by mission critical applications that require some form of prioritized service, but cannot quantify their resource requirements. In cases where RSVP cannot travel end-to-end, these applications may still benefit from reservations that are not truly end-to-end, but that are 'proxied' by a network node on the data path between the sender and the receiver(s). RSVP Receiver Proxy is an extension to the RSVP message processing (not to the protocol itself) in which an intermediate network node originates the Resv message on behalf of the receiver(s) identified by the Path message. "Sieve -- Subaddress Extension", Ken Murchison, 31-Mar-03, On email systems that allow for 'subaddressing' or 'detailed addressing' (eg, 'ken+sieve@example.org'), it is sometimes desirable to make comparisons against these sub-parts of addresses. This draft defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. "Sieve -- Regular Expression Extension", Ken Murchison, 03-Jul-02, In some cases, it is desirable to have a string matching mechanism which is more powerful than a simple exact match, a substring match or a glob-style wildcard match. The regular expression matching mechanism defined in this draft should allow users to isolate just about any string or address in a message header or envelope. "Generalized NAI (GNAIE) Extension for Mobile IPv4", M Khalil, Emad Qaddoura, Haseeb Akhtar, Pat Calhoun, 09-Oct-01, The Mobile IP Extensions Rationalization (MIER) specification defines a new extension header format, that is intended to extend the Mobile IP extension address space. This document defines the Generalized Network Access Identifier (NAI) extension, which SHOULD be used by any Mobile IP extension specifying an extension containing an NAI. "The Architecture of End to End Multihoming", Masataka Ohta, 26-Jun-03, This memo describes the architecture of end to end multihoming. End to end multihoming does not burden routing system for multihoming. That is, even extensive use of end to end multihoming does not increase the number of entries in a global routing table. Traditionally with IPv4, multihoming capability is offered by an intelligent routing system, which, as is always the case with violating the end to end principle, lacks scalability on a global routing table size and robustness against link failures. On the other hand, with end to end multihoming, multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network and works as long as there is some connectivity between the end systems. Because end to end multihoming is performed in end systems, the architecture needs no routing protocol changes Instead, APIs and applications must be modified to some extent. "Application/w-xxx-forms Media Type", Dinkar Tiwari, 31-May-01, This document proposes to standardize application/w-xxx-forms, a media type for use in sending requests involving form-input from a browser to a http server. These requests are currently sent via the HyperText Transfer Protocol on the World Wide Web. "SDXP: Structured Data Exchange Protocol", Max Wildgrube, 02-May-03, This specification describes an all-purpose platform independent networking protocol for use to realize client/server (or similar) applications. User and administration messages are transformed into a special network format (see [SDXF]). This format is self-describing and cpu-independent. "IEEE 802.1X RADIUS Usage Guidelines", Paul Congdon, Bernard Aboba, 18-Apr-03, IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although RADIUS support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS clients. This document provides suggestions on RADIUS usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 27-Nov-02, This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other Internet Drafts relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. "SILC Packet Protocol", Pekka Riikonen, 27-Nov-02, This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol specified in the Secure Internet Live Conferencing, Protocol Specification Internet Draft [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 16-Jun-03, This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. SKE use best parts of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY Key Determination protocol [OAKLEY]. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol is transparent to the authentication data which means that it can be used to authenticate the user with, for example, passphrase (pre-shared secret) or public key (and certificate) based on digital signatures. "LDAPv3: Grouping of Related Operations", Kurt Zeilenga, 05-May-03, This document provides a general mechanism for grouping related Lightweight Directory Access Protocol (LDAP) operations. Grouping of operations can be used to support replication, proxies, and transactions. "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)", Kazuaki Tsuchiya, Hidemitsu Higuchi, Sunao Sawada, Shinji Nozaki, 20-Feb-03, In the stage of the transition from IPv4 to IPv6 it is necessary that IPv4 nodes and IPv6 nodes can communicate directly. This memo proposes a mechanism which enables such direct communication for multicast, in addition to that for unicast defined in RFC2765(SIIT) and RFC2766(NAT-PT.) "Extensions to the 'tel' URL to Support Number Portability and Freephone Service", James Yu, 08-Jan-03, This document proposes three extensions to the 'tel' Uniform Resource Locator for supporting number portability (NP) and freephone service. Those proposed extensions allow the Session Initiation Protocol to carry the tel URL or to convert the tel URL to the SIP URL so as to support NP and freephone service. The proposed extensions allow the SIP protocol to be used to derive the routing number for the ported geographical numbers, identify the freephone service provider/carrier or the Plain Old Telephone Service (POTS) number for a freephone number, and carry the NP- and freephone-related information in the SIP messages. "Session Initiation Protocol (SIP)-H.323 Interworking Requirements", Henning Schulzrinne, Charles Agboh, 01-Jul-03, This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Eric Rosen, Peter Psenak, Padma Pillay-Esnault, 06-Feb-03, [VPN] describes a method of providing a VPN service. That method allows a variety of different protocols to be used as the routing protocol between the Customer Edge (CE) router and the Provider Edge (PE) router. However, it does not fully specify the procedures which must be implemented within the Provider's network when OSPF is used as the PE/CE routing protocol. This document provides that specification. "Session Initiation Protocol Private Extension for an OSP Authorization Token", Alan Johnston, Diana Rawlins, 13-Feb-03, This draft proposes a private extension to the Session Initiation Protocol (SIP) for carrying OSP (Open Settlements Protocol) authorization tokens in applications such as clearinghouses. "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", Andrew Malis, 23-Jul-01, This document describes a method for encapsulating SONET/SDH Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. "Providing Quality of Service Indication by the BGP-4 Protocol: the QOS_NLRI attribute", Geoffrey Cristallo, Christian Jacquenet, 27-Jun-03, This draft specifies an additional BGP4 (Border Gateway Protocol, version 4, [2]) attribute, named the 'QOS_NLRI' attribute, which aims at providing QoS (Quality of Service)-related information associated to the NLRI (Network Layer Reachability Information) information conveyed in a BGP UPDATE message. "The LDAP controlError Result Code", Asaf Kashi, 06-Mar-02, This document defines a controlError result code to be used in LDAPv3 [1] control extension specifications. The purpose of this result code is to let the client know that the operation which returned this result code was not successful due to an attached control and that further information is available in one or more controls attached to the response. "Calling Line Identification for Voice Mail Messages", Glenn Parsons, Janusz Maruszak, 05-Jun-03, This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. "6to4 and DNS", Keith Moore, 18-Oct-02, 6to4 [1] defines a mechanism for allowing sites to communicate using IPv6 over the public IPv4 Internet. It does so by assigning a block of IPv6 addresses corresponding to any 'public' (globally-scoped) IPv4 address, and a means of tunneling IPv6 traffic destined for such addresses over the IPv4 Internet. In this way, any site which is connected to the IPv4 Internet and which has at least one global IPv4 address assigned to it, can communicate with IPv6. The advantage of 6to4 is that it decouples deployment of IPv6 by the core of the network (e.g. Internet Service Providers or ISPs) from deployment of IPv6 at the edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 support in its own time frame according to its own priorities. With 6to4, the edges may communicate with one another using IPv6 even if one or more of their ISPs do not yet provide native IPv6 service. In addition, the principal cost of the 6to4 transition mechanism is borne by those who benefit from it. However, the ability to perform so-called 'reverse lookups' (lookups of IP addresses rather than domain names) in DNS requires that there be a delegation path for the IP address being queried, from the DNS root to the servers for the DNA zone which provides the PTR records for that IP address. For ordinary IPv6 addresses, the necessary DNS servers and records for IPv6 reverse lookups would be maintained by the each organization to which an address block is delegated; the delegation path of DNS records reflects the delegation of address blocks themselves. However, for IPv6 addresses beginning with the 6to4 address prefix, the DNS records would need to reflect IPv4 address delegation. Since the entire motivation of 6to4 is to decouple site deployment of IPv6 from infrastructure deployment of IPv6, such records cannot be expected to be present for a site using 6to4 - especially for a site whose ISP did not yet support IPv6 in any form. This memo discusses several potential mechanisms for locating the DNS servers which are assumed to provide 'reverse lookup' of 6to4 addresses. "Exclusion Extension for Service Location Protocol v2", Michael Day, 10-Jan-03, The Service Location Protocol, Version 2 [1] allows the use of multicast and broadcast discovery requests. The SLP exclusion directive is an extension to SLP that optimizes the use of multicasting and broadcasting to find services on an intranet. This document hereafter refers to multicast discovery but all its contents apply to broadcast discovery as well. "Voice Messaging Client Behaviour", Derrick Dunne, Glenn Parsons, 24-Jul-01, This document defines the expected behaviour of a client to various aspects of a VPIM message or any voice or fax message. "LDAPv3 Transactions", Kurt Zeilenga, 05-May-03, Lightweight Directory Access Protocol (LDAP) update operations acting upon entries have atomic, consistency, isolation, durability (ACID) properties. However, it is often desirable to update two or more entries as one unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning and information replication. This document defines an LDAP extension to support transactions. "Base Encodings of Data", Simon Josefsson, 13-May-02, This draft describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. "A Description of the Camellia Encryption Algorithm", Junko Nakajima, Shino Moriai, 20-Jul-01, This document describes a secret-key cryptosystem, Camellia; it is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. "An analysis of IPv6 anycast", Jun-ichiro Hagino, K Ettikan, 01-Mar-01, The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. "Address Prefix Based Outbound Route Filter for BGP-4", Srihari Ramachandra, Srihari Sangli, 16-Dec-02, This document defines a new Outbound Router Filter type for BGP, termed 'Address Prefix Outbound Route Filter', that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. "Universal Service Protocol: USP Version 3", Timur Shemsedinov, 29-Oct-02, This document describes an application-level remote procedure calls protocol called the USP. This protocol is the maximally generalized way of client/server interactions in distributed systems of object- oriented, hierarchical, relational or hybrid data model. USP treats such interaction as remote procedure calls. This document contains specification of calls, responses and events of USP including the complex structures' coding needed for representation of the objects. Also URI schema of USP is considered. "Mapping Between MIME Types, Content-Types and URIs", Donald Eastlake, 08-Nov-02, Multipurpose Internet Mail Extension (MIME) Content-Type headers, the MIME types used therein, and Uniform Resource Identifiers (URIs) are being used, in different contexts, to label entities. A mapping is specified from each kind of label into the other. This makes it possible to express the union of their meaning in either URI or Content-Type syntax. "Enhanced Alerting Packages for Megaco/H.248", Kevin Boyle, 04-Mar-02, This document provides proposed definitions for several supplemental packages for Megaco/H.248 [2][3]. These packages define alternative signalling for ringing, add the capability for distinctive call waiting tones, and address support of functionality for enhanced telephony services, such as CLASS signaling services [4] and ETSI defined display services [5] [6] [7]. "Supplemental Tones Packages for Megaco/H.248", Kevin Boyle, Sarah Cornel, C Brown, 04-Mar-02, This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for basic and enhanced telephony services. "Diversion Indication in SIP", Stuart Levy, Bryan Byerly, John Yang, 07-Jan-03, This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a new general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. "LDAP & X.500 Component Matching Rules", Steven Legg, 27-Jun-03, The syntaxes of attributes in a Lightweight Directory Access Protocol or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. The matching rules defined for the complex syntaxes, if any, usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. "The tel URI for Telephone Calls", Henning Schulzrinne, Antti Vaha-Sipila, 20-Feb-03, This document specifies the URI (Uniform Resource Identifier) scheme 'tel'. The 'tel' URI describes resources identified by telephone numbers. "Handle System Protocol (ver 2.1) Specification", Sam Sun, 01-Jul-03, The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation. "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", Murtaza Chiba, Goral Dommety, Mark Eklund, David Mitton, Bernard Aboba, 16-May-03, This document describes a currently deployed extension to the RADIUS protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing data filters applicable to a user session. "A COPS client-type for IP traffic engineering", Christian Jacquenet, 23-Jan-03, This draft specifies a COPS (Common Open Policy Service) client-type designed for the enforcement of IP Routing and Traffic Engineering (TE) policies. The usage of this IP TE COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes. "SMIng Mappings to SNMP", Frank Strauss, Juergen Schoenwaelder, 29-May-03, This memo presents an SMIng language extension that supports the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications for application in the SNMP management framework. "SMIng Core Modules", Frank Strauss, Juergen Schoenwaelder, 29-May-03, This memo presents an SMIng module that introduces core data types such as counters, date and time related types, and various string types. "ECDSA with XML-Signature Syntax", Simon Blake-Wilson, Gregor Karlinger, Yongge Wang, Tetsutaro Kobayashi, 04-Apr-03, This document specifies how to use ECDSA (Elliptic Curve Digital Signature Algorithm) with XML Signatures [XMLDSIG]. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. "Protocol versus Paper Points of View", Donald Eastlake, 10-Sep-01, Two points of view are contrasted: the 'paper' point of view, where digital objects of interest are like pieces of paper, and the 'protocol' point of view where objects of interest are composite dynamic protocol messages. While each point of view has a place, adherence to a paper point of view is damaging to protocol design. By understanding both of these points of view, conflicts between them may be clarified and reduced. "Multi-area MPLS Traffic Engineering", Kireeti Kompella, Yakov Rekhter, Jean Vasseur, Ting Chung, 27-Jun-03, An ISIS/OSPF routing domain may consists of multiple areas. This document postulates a set of mechanisms, and then outlines how these mechanisms could be used to establish/maintain Traffic Engineering LSPs that span multiple areas. "The MAP Security Domain of Interpretation for Internet Security Association and Key Management Protocol", Jari Arkko, Ronald Blom, 31-May-02, The Mobile Application Part (MAP) protocol is a signaling protocol for cellular networks. The MAP Security (MAPSEC) protocol provides a secure way to transport MAP messages. To use MAPSEC, however, Security Associations (SAs) are needed. This document defines how such SAs can be created automatically. We use the Internet Security Association and Key Management Protocol (ISAKMP) as a framework for managing SAs and establishing keys. The framework can be specialized to a particular task. Such a specialization is called a Domain of Interpretation (DOI), and this document defines the MAPSEC DOI. This specialization is very similar to the Internet Key Exchange protocol and the ISAKMP specialization for IP Security, except that non-IP protocols are being negotiated. "Multicast in MPLS/BGP VPNs", Eric Rosen, 07-Apr-03, [RFC2547bis] describes a method of providing a VPN service. It specifies the protocols and procedures which must be implemented in order for a Service Provider to provide a unicast VPN. This document extends that specification by describing the protocols and procedures which a Service Provider must implement in order to support multicast traffic in a VPN, assuming that PIM [PIMv2] is the multicast routing protocol used within the VPN, and the the SP network can provide PIM as well. "An IETF URN Sub-namespace for Registered Protocol Parameters", Michael Mealling, Larry Masinter, Ted Hardie, Graham Klyne, 20-Mar-03, This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF-defined resources. "AES Encryption for Kerberos 5", Kenneth Raeburn, 23-Jun-03, Recently the US National Institute of Standards and Technology chose a new Advanced Encryption Standard, which is significantly faster and (it is believed) more secure than the old DES algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. Comments should be sent to the author, or to the IETF Kerberos working group (ietf-krb-wg@anl.gov). "The IETF XML Registry", Michael Mealling, 18-Jun-03, This document describes an IANA maintained registry for IETF standards which use Extensivle Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", Luca Martini, 28-Apr-03, This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet for transport across an MPLS network. "Number Portability Administration in the U.S.", Michael Foster, Tom McGarry, James Yu, 08-May-03, This document provides a historical as well as practical overview of the implementation of Number Portability (NP) Administration in the United States (U.S.). There are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. This document describes the NP business model and the architecture for NP administration in the North America. It also briefly discusses the functions performed by the NP administrator and the cost recovery mechanism. "Distributed Denial of Service Incident Handling: Real-Time Inter-Network Defense", Kathleen Moriarty, 11-Feb-03, One of the latest trends attacking Internet security is the increasing prevalence of Denial of Service (DoS) attacks. DoS attacks target system and/or network resources and seek to prevent valid access by consuming resources. Network Providers (NP) need to be equipped and ready to assist in tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across NP boundaries to identify the source(s) of an attack. The various methods implemented to trace attacks must be coordinated both on the NPs network as well as provide a communication mechanism across network borders. It is imperative that NPs have quick communication methods defined to enable neighboring NPs to assist in tracking a security incident across the Internet. This proposal makes use of current tracing practices for traffic and performance management, which could be extended for DoS incident handling. Policy guidelines for handling these incidents are recommended and can be used by NPs and extended to their clients in conjunction with the technical recommendations. "Crankback Signaling Extensions for MPLS Signaling", Adrian Farrel, Atsushi Iwata, 16-Jun-03, Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for use in Multi-Protocol Label Switching (MPLS) signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. "A Configuration Schema for LDAP Based Directory User Agents", M Ansari, Luke Howard, Bob Joslin, 01-May-03, This document describes a mechanism for global configuration of similar directory user agents. This document defines a schema for configuration of these DUAs that may be discovered using the Light- weight Directory Access Protocol in RFC 2251[17]. A set of attri- bute types and an objectclass are proposed, along with specific guidelines for interpreting them. A significant feature of the global configuration policy for DUAs is a mechanism that allows DUAs to re-configure their schema to that of the end user's environment. This configuration is achieved through attribute and objectclass mapping. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. "Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks", Mario Gerla, 07-Nov-02, The Landmark Routing Protocol (LANMAR) utilizes the concept of landmark for scalable routing in large, mobile ad hoc networks. It relies on the notion of group mobility: i.e., a logical group (for example a team of coworkers at a convention) moves in a coordinated fashion. The existence of such logical group can be efficiently reflected in the addressing scheme. It assumes that an IP like address is used consisting of a group ID (or subnet ID) and a host ID, i.e. . A landmark is dynamically elected in each group. The route to a landmark is propagated throughout the network using a Distance Vector mechanism. Separately, each node in the network uses a scoped routing algorithm (e.g., FSR) to learn about routes within a given (max number of hops) scope. To route a packet to a destination outside its scope, a node will direct the packet to the landmark corresponding to the group ID of such destination. Once the packet approaches the landmark, it will typically be routed directly to the destination. A solution to nodes outside of the scope of their landmark (i.e., drifters) is also addressed in the draft. Thus, by summarizing in the corresponding landmarks the routing information of remote groups of nodes and by using the truncated local routing table, LANMAR dramatically reduces routing table size and routing update overhead in large networks. The dynamic election of landmarks enables LANMAR to cope with mobile environments. LANMAR is well suited to provide an efficient and scalable routing solution in large, mobile, ad hoc environments in which group behavior applies and high mobility renders traditional routing schemes inefficient. "Network Data Management Protocol Version 4", Harald Skardal, 31-Mar-03, The Network Data Management Protocol (NDMP) defines a mechanism and protocol for controlling backup, recovery, and other transfers of data between primary and secondary storage. The NDMP architecture separates the network attached Data Management Application (DMA), Data Servers and Tape Servers participating in archival or recovery operations. NDMP also provides low-level control of tape devices and SCSI media changers. The XDR and TCP/IP protocols are foundations for NDMP. The key goals of NDMP include interoperability, contemporary functionality, and extensibility. The XDR and TCP/IP protocols are foundations for NDMP. The key goals of NDMP include interoperability, contemporary functionality, and extensibility. "Domain Name System Uniform Resource Identifiers", Simon Josefsson, 21-May-03, This document define Uniform Resource Identifiers for Domain Name System resources. "Explicit Multicast (Xcast) Basic Specification", Richard Boivie, 17-Jan-03, Multicast has become increasingly important with the emergence of network-based applications such as IP telephony and video conferencing. The Internet community has done a significant amount of work on IP multicast over the last decade [1075, 2201, 2236, DEER, DEE2, FARI, HOLB, MBONE, PERL]. However, while today's multicast schemes are scalable in the sense that they can support very large multicast groups, there are scalability issues when a network needs to support a very large number of distinct multicast groups. "Path Request and Path Reply Message", C.J. Lee, 21-Nov-02, This draft specifies the interface between an entity requesting an explicit route between two end-points (Path Query Entity) and another entity computing the explicit route (Path Computation Entity) "Internationalized Domain Names in URIs", Martin Duerst, 06-Nov-02, This document proposes to upgrade the definition of URIs (RFC 2396) [RFC2396] to work consistently with internationalized domain names. "Basic MGCP Packages", Andrew Dugan, Flemming Andreasen, 28-Feb-03, This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages. "LDAP Cancel Extended Operation", Kurt Zeilenga, 01-Jul-03, This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. "The DISCOVER opcode", Bill Manning, Paul Vixie, Erik Guttman, 26-Oct-01, The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. "Megaco/H.248 Basic CAS Packages", Vikas Bajaj, Kushanava Laha, Bill Foster, Kevin Boyle, Wendy Bothwell, Michael Brown, 04-Mar-02, This document defines Basic Channel Associated Signalling (CAS) and R1 packages and supplemental CAS packages in association with the Megaco/H.248 Protocol that can be used to control a Media Gateway (MG) from an external controller, called a Media Gateway controller (MGC). It is intended to satisfy the requirements in section 12 of the Megaco/H.248 requirement document [1]. "Inverse ARP over Unidirectional Virtual Circuits", Juha Heinanen, 02-Mar-01, This memo describes operation of an Inverse Address Resolution Protocol (InARP) over unidirectional virtual circuits such as MPLS LSPs. "Effects of ICMPv6 on IKE", Jari Arkko, 07-Mar-03, The ICMPv6 protocol provides many functions which in IPv4 were either non-existent or provided by lower layers. IPv6 architecture also makes it possible to secure all IP packets using IPsec, even ICMPv6 messages. IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is hard, particularly with ICMPv6 packets related to Neighbor Discovery. Sound looking policies may easily lead to loops: The establishment of security requires Neighbor Discovery messages which can not be sent since security has not been established yet. The purpose of this draft is to inform system administrators and IPsec implementors in which manner they can handle the ICMPv6 messages. Common understanding of the way that these messages are handled is also necessary for interoperability, in case vendors hardcode such rules in to products. "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", Jari Arkko, 07-Mar-03, This informational document discusses the use of manually configured IPsec security associations to protect IPv6 Neighbor Discovery (ND) messages. IPsec security associations are generally identified by the triple (security parameters index, destination address, protocol). In the case of Neighbor Discovery, configuring these associations requires some effort, however. There are multiple known destination addresses plus a number of addresses that depend on the physical link addresses. This document describes the security implications of protecting or not protecting the Neighbor Discovery messages and lists the security associations that must be configured manually. The presented method is applicable only in small networks, but some approaches for reducing the configuration effort are discussed. "TDM over IP", Jonathan Stein, 07-Mar-03, This document describes methods for transporting time division multiplexed (TDM) digital voice and data signals over Pseudo Wires. It is a revision of the document draft-anavi-tdmoip-02. "SASL in HTTP/1.1", Magnus Nystrom, Alexey Melnikov, 30-Jun-03, This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. "Dynamic Mobile IP (DMI)", Mohammed Kassi-Lahlou, 22-Jan-03, This draft introduces a different mode for the mobility usage in IP networks. This mode does not modify the Mobile IP protocol specifications [2], but makes their use more efficient according to the movements of the mobile node as far as its communications are concerned. The Mobile IP mechanisms will be used only for the ongoing communications while the mobile node is in motion. That is, the Mobile IP mechanisms will be used for the communications established from an IP sub-network and which continue whenever the mobile node moves to another IP sub-network. For all the communications that are opened and closed in the same IP sub-network there is no need to use Mobile IP mechanisms even if the mobile node is away from its home network. "Definitions of Managed Objects for Network Address Translators (NAT)", Rajiv Raghunarayan, Nalinaksh Pai, R Rohit, Cliff Wang, Pyda Srisuresh, 08-Nov-02, This memo defines an SMIv2 Management Information Base (MIB) for a device implementing traditional NAT [17] function. This may be used for configuration as well as monitoring of a device capable of traditional NAT function "Generic Tunnel Tracing Protocol (GTTP) Specification", Ronald Bonica, 04-Mar-03, This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace the path between any two points on an IP network. Enhanced route-tracing applications can trace through a network's forwarding plane, its control plane or both. Furthermore, enhanced route-tracing applications can reveal details concerning tunnels that support the traced path. Tunnel details can be revealed regardless of tunneling technology. For example, enhanced route-tracing applications can trace through an MPLS LSP as well as they can trace through an IP-in-IP tunnel. "Context Relocation for Seamless Header Compression in IP Networks", Rajeev Koodli, 26-Jun-03, In networks with bandwidth constraints, such as wireless cellular networks, compression of IP and transport headers may be employed to obtain better utilization of the available spectrum capacity. When header compression is used along with handovers in such networks, the header compression context needs to be relocated from one IP access point (i.e., a router) to another in order to achieve seamless operation. In this document, we propose a mechanism to achieve this compression context relocation using options for the handover ICMP messages defined for IPv6 and suboptions for the destination options used by mobile nodes to request smooth handovers. "A Framework for Purpose-Built Keys (PBK)", Scott Bradner, Allison Mankin, Jeffrey Schiller, 09-Jun-03, This memo considers the need to authenticate the source of a network communication where the actual identity of the source is not important but it is important and that successive messages in the communication come from the same source. This memo defines the use of specially generated public/private key pairs, known as Purpose- Built Keys (PBKs), to provide this assurance. This memo is not a full specification of a PBK protocol, but rather a model or framework for development of PBK in applications "LIN6: A Solution to Mobility and Multi-Homing in IPv6", Fumio Teraoka, 27-Jun-03, LIN6 is a protocol supporting mobility and multi-homing in IPv6. LIN6 introduces the node id, not the interface id, for each node. Each node can be identified by its node id no matter where the node is connected and no matter how many interfaces the node has. In the IPv6 layer, 64-bit node id called LIN6 ID is used while 128-bit node-id called LIN6 generalized ID is used above the Transport layer. TCP connections and security associations can be preserved even if the node moves to another subnet or the node changes the using interface in a multi-homing environment without modifying TCP or IPsec. In comparison with Mobile IPv6, LIN6 has several advantages in terms of header overhead and fault tolerance. "EAP SIM Authentication", Henry Haverinen, Joseph Salowey, 30-Jun-03, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the GSM Subscriber Identity Module (SIM). The mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support and a re-authentication procedure. "The AES Cipher Algorithm in the SNMP's User-based Security Model", Uri Blumenthal, Fabio Maino, Keith McCloghrie, 27-Jun-03, This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the AES cipher algorithm, used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. "IMAP4 SEARCHM Command for Multiple Mailboxes", Barry Leiba, 25-Mar-03, The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete. This also introduces named searches, allowing a client to pipeline the searches if it chooses. "Analysis of the Security of BGP/MPLS IP VPNs", Michael Behringer, 29-May-03, This document analyses the security of the BGP/MPLS IP VPN architecture as described in [RFC2547bis], especially in comparison with other VPN technologies such as ATM and Frame Relay. The target audience is service providers and VPN users. The document consists of two main parts: First the requirements for security in VPN services are defined, second BGP/MPLS IP VPNs are examined with respect to these requirements. The analysis shows that BGP/MPLS IP VPN networks can be equally secured as traditional layer-2 VPN networks such as ATM and Frame Relay. "Carrying Constraints in RSVP", Kireeti Kompella, 18-Jun-03, Constraint-based routing is the computation of a path through a network that satisfies some constraints. Typically, some device A obtains the constraints (perhaps through configuration), and also knows the network topology and resources, and thereby computes the path. However, in certain cases, the device A that knows the constraints cannot compute the full path. In such cases, it is useful for A to be able to communicate the constraints to some other device B that can carry out or complete the computation, and moreover, to communicate these constraints in an extensible, interoperable fashion, and such that A's semantics are understood by B. This document suggests one such means of constraint communication: use a signalling mechanism (such as RSVP) for carrying the constraints, and carry the constraints as a program. "Secure Session Key Generation. Creating PRF from MAC Function", Uri Blumenthal, 08-Jul-02, This document describes Pseudo Random Function (PRF) based on MAC function (keyed iterated hash function), and offers a ref- erence implementation of PRF based on SHA-1. This PRF can be used to produce cryptographic keys for authen- tication/integrity and encryption. It uses pre-shared secret and publicly known random value (and possibly parties’ identi- ties). The main advantage of this algorithm over other similar ones is that its security is formally tied to the MAC property of the underlying function. "The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers, 06-Mar-03, The ARK (Archival Resource Key) is a scheme intended to facilitate the persistent naming and retrieval of information objects. It comprises an identifier syntax and three services. An ARK has four components: [http://NMAH/]ark:/NAAN/Name an optional and mutable Name Mapping Authority Hostport part (NMAH, where 'hostport' is a hostname followed optionally by a colon and port number), the 'ark:' label, the Name Assigning Authority Number (NAAN), and the assigned Name. The NAAN and Name together form the immutable persistent identifier for the object. ".sex Considered Dangerous", Donald Eastlake, Declan McCullagh, 11-Jun-03, Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag 'adult' or 'unsafe' material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and, particularly, the technical points of view.. "IRML: A Rule Specification Language for Intermediary Services", Andre Beck, Markus Hofmann, 27-Jun-03, The Intermediary Rule Markup Language (IRML) is an XML-based language that can be used to specify rules for the execution of Web services in general and OPES content services in particular. OPES services are a new class of applications running on network intermediaries, such as caches, proxies, gateways, etc. or dedicated (callout) servers. They are invoked through intermediaries acting on behalf of application endpoints. IRML is designed to serve as a simple and efficient, but yet powerful language to express the service execution policies of application endpoints. IRML rules are typically processed by intermediaries that trigger the execution of OPES services according to these rules and policies. "Hebrew Character Encoding for Internet Messages", Hank Nussbacher, Yehavi Bourvine, 23-Sep-02, This document describes the encoding used in electronic mail for transferring Hebrew over the Internet. "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Fred Templin, Tim Gleeson, Mohit Talwar, Dave Thaler, 04-Apr-03, This document specifies an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 hosts and routers within IPv4 sites. ISATAP treats the site's IPv4 infrastructure as a link layer for IPv6 with no requirement for IPv4 multicast. ISATAP enables intra-site automatic IPv6-in-IPv4 tunneling whether globally assigned or private IPv4 addresses are used. "The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message", Roger Harrison, Kurt Zeilenga, 28-Mar-03, The Lightweight Directory Access Protocol (LDAP) version 3 is a client-request/server-response based protocol. With the exception of the search operation, the entire response to an operation request is returned in a single LDAP message. While this single- request/single-response paradigm is sufficient for many operations (including all but one of those currently defined by LDAP), both intuition and practical experience validate the notion that it is insufficient for some operations. When multiple messages are sent in response to a single request, all but the last of these response messages are referred to as 'intermediate responses'. This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple- response operations in LDAP. The IntermediateResponse message is defined in a way that maintains the protocol behavior of existing LDAP operations. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. "Generating One-Time Passwords with SHA-256, SHA-384, and SHA-512", Philip Nesser, 05-May-03, This document describes the use of the new AES hash alogrithms, SHA256, SHA384 and SHA512, for use with the One Time Password (OTP) system, as defined by RFC 2289. RFC 2289 has definitions for the MD4, MD5 and SHA1 hashes, while this document defines techniques for using the AES hashes. "Feature Discovery in LDAP", Kurt Zeilenga, 27-May-03, The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms. "LDAPv3: All Operational Attributes", Kurt Zeilenga, 05-Nov-02, The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but does not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes. "SMB Filesharing URL Scheme", Christopher Hertel, 08-Jan-03, The Server Message Block (SMB) protocol is one of the most widely used network filesystem protocols in existence. This document describes a format for an SMB Uniform Resource Locator (SMB URL). The SMB URL can be used to indicate SMB workgroups, servers, shares, files, inter-process communications pipes, print queues, and devices; the objects in the SMB network filesystem space. "Additional XML Security URIs", Donald Eastlake, 03-Mar-03, A number of algorithm and keying information identifying URIs intended for use with XML Digital Signatures, Encryption, and Canonnicalization are defined. "Resource Management in Diffserv (RMD) Framework", Lars Westberg, 28-May-03, This draft presents the work on the framework for the Resource Management in Diffserv (RMD) designed for edge-to-edge resource reservation in a Differentiated Services (Diffserv) domain. The RMD extends the Diffserv architecture with new resource reservation concepts and features. Moreover, this framework enhances the Load Control protocol described in [WeTu00]. The RMD framework defines two architectural concepts: - the Per Hop Reservation (PHR) - the Per Domain Reservation (PDR) The PHR protocol is used within a Diffserv domain on a per-hop basis to augment the Diffserv Per Hop Behavior (PHB) with resource reservation. It is implemented in all nodes in a Diffserv domain. On the other hand, the PDR protocol manages the resource reservation per Diffserv domain, relying on the PHR resource reservation status in all nodes. The PDR is only implemented at the boundary of the domain (at the edge nodes). The RMD framework presented in this draft describes the new reservation concepts and features. Furthermore it describes the: - relationship between the PHR and PHB - interaction between the PDR and PHR - interoperability between the PDR and external resource reservation schemes This framework is an open framework in the sense that it provides the basis for interoperability with other resource reservation schemes and can be applied in different types of networks as long as they are Diffserv domains. It aims at extreme simplicity and low cost of implementation along with good scaling properties. "Resource Management in Diffserv On DemAnd (RODA) PHR", Lars Westberg, 29-May-03, The purpose of this draft is to present the Resource Management in Diffserv (RMD) On DemAnd (RODA) Per Hop Reservation (PHR) protocol. The RODA PHR protocol is used on a per-hop basis in a Differentiated Services (Diffserv) domain and extends the Diffserv Per Hop Behavior (PHB) with resource provisioning and control. "Megaco/H.248 Enhanced Analog Line Packages", Mark Taylor, C Brown, 04-Mar-02, This document provides proposed definitions for two supplemental packages for Megaco/H.248. These packages address support of functionality for standard and enhanced telephony services delivered over analog line terminations, including line-side answer supervision and the delivery of call metering pulses "LDAPv3: A Collection of User Schema", Kurt Zeilenga, 17-May-02, This document provides a collection of user schema elements for use with LDAP (Lightweight Directory Access Protocol) from both ITU-T Recommendations for the X.500 Directory and COSINE and Internet X.500 pilot projects. "Collective Attributes in LDAP", Kurt Zeilenga, 26-Aug-02, X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP. "SILC Commands", Pekka Riikonen, 27-Jun-03, This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages. "Handle System Overview", Sam Sun, Larry Lannom, 01-Nov-01, The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources. This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URN. "Lightweight Directory Access Protocol over UDP/IP", Leif Johansson, Roland Hedberg, 11-May-01, This memo describes modifications to LDAP version 3[1] to allow transport of a subset of the LDAP protocol over UDP/IP. "EAP AKA Authentication", Jari Arkko, Henry Haverinen, 30-Jun-03, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys, and runs typically in a UMTS Subscriber Identity Module, a smart card like device. EAP AKA includes optional identity privacy support and an optional re-authentication procedure. "A Search-based access model for the DNS", John Klensin, 06-Nov-02, This memo discusses strategies for supporting 'DNS searching' -- finding of names in the DNS, or references that will ultimately point to DNS names, by a mechanism layered above the DNS itself that permits fuzzy matching, selection that uses attributes or facets, and use of descriptive terms. Demand for these facilities appear to be increasing with growth in the Internet (and especially the web) and with requirements to move beyond the restricted subset of ASCII names that have been the traditional contents of DNS 'Class=IN'. This document proposes a three-level system for access to DNS names in which the upper two levels involve search, rather than lookup (exactly known target), functions. It also discusses some of the issues and challenges in completing the design of, and deploying, such a system. "The Hashed URI", Clive Feather, 17-Sep-02, There are situations where it is desirable to determine whether two URIs are identical without revealing the value of one or the other if they are not. For example, the publisher of filtering software may want to provide a set of URLs to be filtered without identifying the actual resources in question. This problem has traditionally been done using cryptographically secure hashes. The two items are both hashed and the resulting values then compared. If they are equal it can be assumed that the two original items were equal as well; if not, the hash does not reveal anything about the original item. This technique is eminently suitable for this situation. This document describes a 'hashed' URI naming scheme for representing the hashed form of a URI [RFC2396] as another URI. "Scalable Connectionless Tunneling Architecture and Protocols for VPNs", Takeshi Kuwahara, 24-Jan-03, This document describes a connectionless tunneling architecture that is applicable to layer 3 PE-based virtual private networks and specifies protocols for implementing it. This tunneling architecture is designed to facilitate scalability and reliability. A prominent feature of it is to provide VPN tunnels over a connectionless network. Since a connectionless network can provide full mesh connectivity without a connection establishment procedure, the architecture enables scalable operation of a VPN more efficiently than connection-oriented tunneling technologies. "Procedural Footnote Language Version 1.0", Daniel Myers, 02-Dec-02, This document sets out the proper syntax and usage of the Procedural Footnote Language (PFL) - a system of adding structured footnote objects to a text file. "Layer 2 VPNs Over Tunnels", Kireeti Kompella, 15-Apr-03, Virtual Private Networks (VPNs) based on Frame Relay or ATM circuits have been around a long time. While these VPNs work well, the costs of maintaining separate networks for Internet traffic and VPNs and the administrative burden of provisioning these VPNs have led Service Providers to look for alternative solutions. In this document, we present a VPN solution where from the customer's point of view, the VPN is based on Layer 2 circuits, but the Service Provider maintains and manages a single network for IP, IP VPNs, and Layer 2 VPNs. "Simple Explicit Multicast (SEM)", Ali Boudani, Bernard Cousin, 25-Jun-03, In this document, we propose a new multicast protocol called SEM (Simple Explicit Multicast) or simple Xcast. This protocol uses an efficient method to construct the multicast tree and deliver multicast packets. In order to construct the multicast tree, this protocol uses the same mechanism as Xcast+. For the delivery of multicast packets it uses the mechanism of branching routers similar to the mechanism used in REUNITE I and REUNITE II. "Traffic Engineering Extensions to OSPF and ISIS for GMPLS Control of G.709 Optical Transport Networks", Germano Gasparini, Gert Grammel, Alberto Bellato, 07-Oct-02, This document introduces the traffic engineering extensions required in existing IGP protocols to support sub-sequent signalling for Label Switched Path (LSP) when using Generalized MPLS signalling as defined in [GMPLS-SIG] and [GMPLS-G709] for G.709 Optical Transport Networks (see [GMPLS-G709]). In particular, using [GMPLS-RTG] as guideline, it specifies the GMPLS routing extensions to OSPF and IS- IS protocols for G.709 Optical Transport Networks (OTN). "A grammar for Policies in a Generic AAA Environment", Arie Taal, 13-Feb-03, In this document the concept of a so-called Driving Policy is pre- sented. A Driving Policy determines the behavior of an AAA server (Authentication, Authorization, Accounting) when it is confronted with a specific message type of the AAA protocol. The first part of this document defines the role of a Driving Policy and how it fits into the AAA concept. According to the model presented, the main task of a Driving Policy is to describe which pre-conditions have to be checked before the corresponding actions, needed to fulfill an incoming AAA request, can be called, and how to deal with the post-conditions of these actions. In the second part a grammar is proposed for these Driving Policies accompanied by the necessary comments about the semantics. "An IPv6 Provider-Independent Global Unicast Address Format", Tony Hain, 17-Apr-03, This document defines an IPv6 Provider-Independent global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [2] and the 'IPv6 Addressing Architecture' [3]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. "Application and Use of the IPv6 Provider Independent Global Unicast Address Format", Tony Hain, 17-Apr-03, This document discusses the expected use of the Provider Independent address format discussed in the companion document [2] in the Internet. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations that should be avoided due to the negative impact on the routing tables. "The 'tag' URI scheme and URN namespace", Tim Kindberg, Sandro Hawke, 16-Sep-02, This document describes the 'tag' Uniform Resource Identifier (URI) scheme and the 'tag' Uniform Resource Name (URN) namespace, for identifiers that are unique across space and time. Tag URIs (also known as 'tags') are distinct from most other URIs in that they are intended for uses that are independent of any particular method for resource location or name resolution. A tag URI may be used purely as an entity identifier. It may also be presented to services for resolution into a web resource or into one or more further URIs, but no particular resolution scheme is implied or preferred by a tag URI itself. Unlike UUIDs or GUIDs such as 'uuid' URIs and 'urn:oid' URIs, which also have some of the above properties, tag URIs are designed to be tractable to humans. Furthermore, they have many of the desirable properties that 'http' URLs have when used as identifiers, but none of the drawbacks. "About Unicode Consortium Procedures, Policies, Stability, and Public Access", Raymond McGowan, 31-Mar-03, This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the consortium work and what their procedures are, as well as information on public access to the character encoding & standardization processes. "The Media Gateway Control Protocol (MGCP) Bulk Audit Package", Bill Foster, David Auerbach, Flemming Andreasen, 10-Jun-03, The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints. "MIME Type Registrations for JPEG 2000", David Singer, 20-Jul-01, This document serves to register and document the standard MIME types associated with JPEG 2000 files, Motion JPEG 2000 files, and Multi- layer JPEG 2000 files "Expanded Simulation Models for IntServ and DiffServ with MPLS", Mark Pullen, 27-Jun-03, This document describes detailed models for analysis of proposed protocols for Quality of Service (QoS) delivery with IPv4 (including multicast). The models have been developed using the OPNET simulation package. They are intended to allow investigation of performance using proposed protocols and should have wide applicability in the Internet QoS community. We are making these models publicly available with the intention that they can be used to provide expanded studies of Qos delivery for both unicast and multicast, using IntServ, DiffServ, and MPLS. This Internet-Draft is intended to form the basis for an Informational RFC that extends the previous RFC2490. "Whois Domain Data using the Lightweight Directory Access Protocol (LDAP)", A Newton, 18-Jun-03, Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes an experimental service using the Lightweight Directory Access Protocol (LDAP) and well-known LDAP types to make available domain administrative data. "Simple Notification and Alarm Protocol (SNAP)", Noam Shapira, 06-Nov-02, This memo suggests a protocol for messaging notification in which a messaging system (e.g. email server, voice mail system, etc.) notifies a notification service, and through it the user, that changes have occurred in a user's mailbox (new message arrived, mailbox is full, etc.). The protocol aims to provide the end-user with unified notification of events occurring on different messaging systems. A mailing list has been established to discuss this draft and promote the issue of Notification to RFC. To subscribe, send email with 'subscribe snap' to majordomo@lists.neystadt.org or using web at http://www.neystadt.org/cgi-bin/majordomo. "Assigning Experimental and Testing Numbers Considered Useful", Thomas Narten, 23-Dec-02, When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified. "Publicly Verifiable Nomcom Random Selection", Donald Eastlake, 02-Jul-03, 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. "Mobile IP Border Gateway (MBG)", Kuniaki Mizuno, Hiroyiki Ohnishi, Yasushi Takagi, 06-Nov-02, This draft introduces the use of Mobile IP border gateways (MBGs) to optimize the Mobile IP packet routing from a correspondent node (CN) to a mobile node (MN) without adding more functions to the CN nodes. "Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions", Ethan Blanton, Mark Allman, 04-Nov-02, TCP and SCTP provide notification of duplicate segment receipt through DSACK and Duplicate TSN notification, respectively. This document presents a conservative method of using this information to identify unnecessary retransmissions. "Opportunistic Encryption using The Internet Key Exchange (IKE)", Michael Richardson, D. Hugh Redelmeier, 13-Jan-03, This document describes opportunistic encryption (OE) using the Internet Key Exchange (IKE) and IPsec. Each system administrator adds new resource records to his or her Domain Name System (DNS) to support opportunistic encryption. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This document is offered up as an Informational RFC. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. There are two large payoffs. First, the administrative overhead is reduced from the square of the number of systems to a linear dependance. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance. This document is offered up as an Informational RFC. "Filters for Mobile IPv4 Bindings (NOMADv4)", Nicholas Fikouras, 25-Apr-03, Filters for Mobile IPv4 bindings enables mobile nodes to associate one or more Filters with mobility bindings during their establishment (registration, binding update). Flows that match a Filter will be processed as defined by the Filter. In this manner, it is possible for a mobile node to distribute flows among its available points of attachment or to request that such flows are dropped before traversing the Internet fabric, with or without notification to their source. Finally, it is possible for a mobile node to select whether it wishes to turn off routing optimization for specific communications in order to avoid giving away its location. "Sender Initiated Multicast (SIM)", Vasaka Visoottiviseth, 05-Mar-03, Sender Initiated Multicast (SIM) is a point-to-multipoint multicast mechanism. SIM will not replace the existing multicast protocol, but will be a subset of entire multicast protocol suite. Its design goals are to gain more simplicity than the traditional IP multicast and to gain less header-processing overhead than the Xcast protocol. It eliminates the cost of allocating global multicast address, by routing packets according to receiver unicast addresses attached to packet headers. Access control can be introduced before, members of a receiving group are explicitly specified by the sender. A group is identified by the combination of sender's unicast address and a multicast group address. The key feature of SIM is in its Preset mode, which can lessen the costs of route lookups and provides cost- efficient packet forwarding by using a SIM Forwarding Information Base (FIB) maintained on routers. Moreover, a SIM tunnel will be automatically created between two routers that act as multicast branching points. Therefore, SIM can gain scalability by maintaining FIB entries only on the branching routers. In this document, we describe SIM including its delivery models, SIM FIB operations, the formats, and security considerations. "A Framework for MPLS User Plane OAM", David Allan, 24-Feb-03, This Internet draft discusses many of the issues associated with user plane OAM for MPLS. The goal being to provide tools to perform 'in service' maintenance of LSPs. Included in this discussion is some of the implications of MPLS architecture on the ability to support fault, diagnostic and performance management OAM applications, potential solutions for distinguishing user plane OAM, and a summary of what the authors believe can be achieved in addressing all aspects of the MPLS architecture. "Performing DNS queries via IP Multicast", Stuart Cheshire, 26-Jun-03, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up host names and similar DNS resource record data types, in the absence of a conventional managed DNS server, is becoming essential. "Emergency Services for Internet Telephony based on the Session Initiation Protocol (SIP)", Henning Schulzrinne, 08-Jan-03, This document describes how Session Initiation Protocol (SIP) user agents and proxies can set up emergency calls and, more generally, reach emergency assistance via SIP requests. For that purpose, it defines a universal emergency SIP URI, sip:sos@domain and sips:sos@domain, that allows SIP user agents to contact the local emergency number. It also defines conventions that increase the high probability of reaching the appropriate emergency call center. The document does not define any SIP protocol extensions. "Finding Remote Directory Agents and Service Agents in the Service Location Protocol via DNS SRV", Weibin Zhao, 20-Jan-03, This document describes how to find Directory Agents (DAs) and Service Agents (SAs) in the Service Location Protocol (SLP) at remote DNS domains via DNS SRV. It defines the SLP service and the DNS SRV Resource Record for the SLP service, describes the usage of Gateway DAs, and gives the steps for a User Agent to discover desired services in remote DNS domains. "Diameter Mobile IPv6 Application", Stefano Faccin, 10-Apr-03, Mobile IPv6 capable mobile nodes can roam between networks that belong to their home service provider as well as others. Roaming in foreign networks is enabled as a result of the service level and roaming agreements that exist between operators. One of the key protocols that allows this kind of a roaming mechanism to be enabled is Diameter. This Internet Draft specifies a new application to Diameter that enables Mobile IPv6 roaming in networks other than its home. "Basic Network Media Services with SIP", Eric Burger, 01-Jul-03, In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well-defined manner. This document describes a mechanism for providing an interoperable protocol interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Eric Rosen, 26-Jun-03, [VPN] describes a method of providing a VPN service. That method allows a variety of different protocols to be used as the routing protocol between the Customer Edge (CE) router and the Provider Edge (PE) router. However, it does not fully specify the procedures which must be implemented within the Provider's network when OSPF is used as the PE/CE routing protocol. This document provides that specification. "Text-based Compression Using Cache and Blank Approach (TCCB)", Ishita Majumdar, 04-Nov-02, This document defines an efficient, robust, and scalable scheme for the compression of text-based protocols. Such protocols (e.g. SIP, SDP) when sent uncompressed over limited bandwidth networks (such as Cellular or the upstream of Hybrid Fiber Coax (HFC)) causes inadvertent delays in call set up. TCCB addresses these problems and proposes a simple mechanism to reduce the size of the messages and hence the recurrent delay "Protected EAP Protocol (PEAP)", Simon Josefsson, Ashwin Palekar, Daniel Simon, Glen Zorn, 25-Mar-03, The Extensible Authentication Protocol (EAP), defined in RFC 2284, provides for support of multiple authentication methods. While EAP was originally created for use with PPP, it has since been adopted for use with IEEE 802.1X 'Network Port Authentication'. Since its deployment, a number of weaknesses in EAP or some EAP protocols have become apparent. These include no per packet confidentiality and integrity protection; which results in lack of protection to user identity, notification messages or EAP negotiation; and sequencing of EAP methods. In addition, there is no standardized mechanism for key exchange; no built-in support for fragmentation and reassembly; no support for acknowledged success/failure indications; and no support for fast reconnect. In addition, some EAP protocols (e.g. like EAP-MD5) are susceptible to dictionary and brute force attacks; do not provide confidentiality; do not support server authentication required to prevent spoofing by rogue servers (gateways), and do not support the generation of key strength required for 802.11i. "Datatypes for WebDAV properties", Julian Reschke, 24-Mar-03, This specification extends the Web Distributed Authoring Protocol (WebDAV) to support both datatyping and some amount of meta information on property values. Protocol elements are defined to let clients and servers specify the datatype and meta information of a property, and to instruct the WebDAV method PROPFIND to return datatype and meta information. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. "The HTTP header for the Platform for Privacy Preferences 1.0 (P3P1.0)", Massimo Marchiori, Ran Lotenberg, 05-Feb-02, The Platform for Privacy Preferences 1.0[4] (P3P1.0) specification describes how to associate a privacy policy with each URI request. Such associations are contained in a so-called policy reference file. This draft describes a new HTTP response header which indicates the location of such policy reference file. This header is intended to be a part of the P3P1.0 framework and should be treated in the full context of the P3P1.0 specification[4]. "Message Disposition Notification", Tony Hansen, Gregory Vaudreuil, 12-May-03, This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary 'LAN-based' systems, and often referred to as 'read receipts,' 'acknowledgements', or 'receipt notifications.' The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary 'LAN-based' systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of 'foreign' addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support 'tunneling' of foreign notifications through Internet Mail. "Locating IP-to-Public Switched Telephone Network (PSTN) Telephony Gateways via SLP", Weibin Zhao, Henning Schulzrinne, 29-Aug-02, This document describes how to use the Service Location Protocol (SLP) to locate Internet telephony gateways. It defines the 'service:iptel-gw:' template for the Internet telephony gateway service, and discusses the different usage scenarios and the applicability of SLP for the Internet telephony gateway location. "Multihoming issues in the Stream Control Transmission Protocol", Lode Coene, 06-Jun-03, This document describes issues of the Stream Control Transmission Protocol (SCTP)[RFC2960] in regard to multihoming on the Internet. It explores cases where through situations in the internet, single points-of-failure can occur even when using multihoming and what the impact is of multihoming on the routing tables of the host. "Using DNS for VPN Discovery", James Luciani, 04-Nov-02, Virtual private networks are becoming a common offering of many service providers. There are many technologies with which to implement a VPN service, ranging from MPLS to GRE to IPSEC. A common requirement of all VPN technologies is the need to discover all of the sites, or at least all the provider equipment associated with the sites, that are in a particular VPN. DNS provides a simple and commonly available mechanism for site discovery that is independent of any signaling or tunneling protocol. This draft proposes the use of DNS as a discovery mechanism for VPN maintenance and control. "Bounding Longest Match Considered", Russ White, Ted Hardie, 07-Nov-02, Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. "IPv6 over Mobile IPv4", Pat Calhoun, Paal Engelstad, Tom Hiller, Peter McCann, 01-Nov-02, This document specifies a Mobile IPv4 extension that may be used by dual stack mobile nodes to obtain IPv6 service with the use of a Mobile IPv4 registration. This extension allows for immediate deployment of IPv6 on dual stack mobile devices, without the need for a full IPv6 infrastructure. It is believed that providing IPv6 services to mobile devices in the short term will spur the growth of IPv6 networks. This extension makes use of the existing Mobile IPv4 security model, including the interface to the AAA infrastructure, but does not provide the route optimization capabilities included in the Mobile IPv6 protocol. Further, this specification requires that the mobile node and Home Agent have dual IPv4 and IPv6 stacks. There are no changes to the FA nor does it need to be dual stack. "Requirements for the Replacement of AppleTalk Name Binding Protocol", Stuart Cheshire, 26-Jun-03, One of the implicitly understood goals amongst the participants working on 'Multicast DNS', 'Link-Local Multicast Name Resolution', 'Zeroconf Name Service', 'Rendezvous' (or whatever you like to call it) is the ability to retire AppleTalk Name Binding Protocol, NetBIOS naming, and the like, and replace them with an all-IP solution. This document outlines the specific properties required of an IP replacement for AppleTalk Name Binding Protocol. "SMQP: Simple Message Queue Protocol", John Tegen, 14-Apr-03, The Simple Message Queue Protocol (SMQP) provides a standard form of sharing data between those that publish data and those that desire to subscribe to data. Publish/subscribe systems decouple the two end points from knowing about one another. SMQP will provide a common protocol to be used for a variety of implementation from simple chat applications to mission critical message flows. "TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Sasha Vainshtein, 06-Jun-03, This document describes a method for encapsulating unstructured (T1, E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for SONET/SDH. Proposed PW encapsulation uses RTP for clock recovery and leverages RTP-based mixing capabilities for application state signaling between Customer Edge (CE) devices. "HTTP Authentication: SPNEGO Access Authentication As implemented in Microsoft Windows 2000", John Brezak, 16-Oct-02, This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The HTTP auth-scheme of 'negotiate' is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and optionally impersonation are performed. This document explains how HTTP authentication utilizes the SPNEGO [7] GSSAPI mechanism. Details of SPNEGO implementation are not provided in this document. "Registration procedures for message header fields", Graham Klyne, Mark Nottingham, Jeffrey Mogul, 20-Jan-03, This specification defines registration procedures for the message header fields used by Internet mail, HTTP, news and other applications. Please send comments to . To subscribe, send a message with body 'subscribe' to . "Computing the CHECKIN URI in WebDAV versioning", Julian Reschke, 06-Feb-03, In many cases, a versioning-aware client might want to display/include the URI of the version it's editing while it's being edited. For instance, an editor might include this as meta information, or the author of a document might want to know the URI of the version before it's checked in. A well-known example is the W3C way of referring to document versions in recommendations: it contains references to 'the current version', to 'this version' and to the 'previous version'. Something like this is currently impossible with WebDAV versioning [RFC3253], as the version URI is determined at the time of CHECKIN. Distribution of this document is unlimited. Please send comments to the WebDAV versioning (delta-V) mailing list at ietf-dav- versioning@w3.org, which may be joined by sending a message with subject 'subscribe' to ietf-dav-versioning-request@w3.org. Discussions of the delta-V mailing list are archived at URL: http://lists.w3.org/Archives/Public/ietf-dav-versioning/. "Including additional properties in WebDAV PROPFIND/allprop requests", Julian Reschke, Stefan Eissing, 12-Jun-03, Recent specifications extending the Web Distributed Authoring Protocol (WebDAV) restrict the set of properties returned automatically upon a PROPFIND/allprop request. This specification defines a method to add specific properties to the set of properties returned upon PROPFIND/allprop. "Security of IPv6 Routing Header and Home Address Options", Pekka Savola, 02-Dec-02, All IPv6 nodes must be able to process Routing Header [IPV6] and Home Address [MIPV6] Options. With these, packet filter access lists can be tricked (among other things) as the destination and source addresses, respectively, are being rewritten as the packet traverses the network. Some of the security considerations of these features are analyzed, and a few possible solutions presented. It will be shown that with the current architecture, the network-based security does not seem to scale to the requirements of Mobile IPv6; it seems possible that unless security is taken seriously when implementing the nodes, the new Mobile IPv6 requirements might not be allowed to be used at all in some circumstances. "Subentries in LDAP", Kurt Zeilenga, 26-Aug-02, In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with Lightweight Directory Access Protocol (LDAP). "The Dublin Core Metadata Element Set", John Kunze, 16-Apr-02, Defines fifteen metadata elements for resource description in a cross-disciplinary information environment: Title Contributor Source Creator Date Language Subject Type Relation Description Format Coverage Publisher Identifier Rights This document contains the same text as ANSI/NISO Z39.85-2001. It differs from that standard only where formatting requirements of the present publishing medium require it. This document supersedes Internet RFC 2413, which was the first published version of the Dublin Core. "Diameter Credit Control Application", Harri Hakala, 04-Mar-03, This document specifies a Diameter application that is used for real- time cost and credit control between a service element and a credit control server in service environment. Diameter accounting messages with additional AVPs are used to transfer service and credit control information between the service element and the Credit Control Server. "MGCP R2 CAS Package", Kushanava Laha, Vikram Nair, Bill Foster, 24-Oct-02, This document describes an MGCP package for R2 CAS signaling "Decoupled Virtual Private LAN Services", Kireeti Kompella, 07-Nov-02, Virtual Private LAN Service (VPLS, also known as Transparent LAN Service) is a useful Service Provider offering. A common scenario where this offering is made is in the metro area, where several Multi-Tenant buildings are connected to an Office, and several Offices are connected by a metro area network. The Service Provider places a simple, low-cost box (MTU) in each building; these MTUs have uplinks to some box (PE) in one or more Offices. In such a scenario, it is useful to decouple the functions needed to offer VPLS across the MTU and PE; this document proposes one way of accomplishing that. "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", Eric Rosen, 06-May-03, [PWE3-CONTROL] specifies a 'signaling protocol' which uses extensions of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-FR, PWE3- ARCH]. Like any protocol which sets up connections, the signaling protocol provides a method by which each endpoint can identify the other. [L2VPN-FW] describes a number of different ways in which sets of pseudowires may be combined together into 'Provider Provisioned Layer 2 VPNs' (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. Different kinds of L2VPN may have different 'provisioning models', i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a 'discovery process', and once the information is discovered, the signaling protocol is automatically invoked to set up the required pseudowires. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of PPVPN provisioning models, and specifies the semantic structure of the endpoint identifiers required. It further specifies how the endpoint identifiers are carried in the 'Generalized Identifier FEC' of [PWE3-CONTROL]. It is believed that the specified identifiers can also be carried within the L2TP signaling protocol, though this is currently not specified. "The application/rss+xml Media Type", Mark Nottingham, 24-Oct-01, This document specifies the Media Type for the RSS format. RSS allows lists of information to be exchanged in an XML-based format. "The W7 Stream Cipher Algorithm", Stephen Thomas, 21-Oct-02, This document specifies the W7 cipher algorithm. The W7 algorithm is a byte-wide, synchronous stream cipher optimized for efficient hardware implementation at very high data rates. It is a symmetric key algorithm supporting key lengths of 128 bits. In addition to the algorithm specification, this document contains test vectors and a representative software implementation in the C language. "SIP Extensions for QoS support", Luca Veltri, Stefano Salsano, Donald Papalilo, 03-Oct-02, This work describes an enhancement to SIP protocol for the interworking with QoS enabled IP networks. The proposed mechanism is simple and it fully preserves backward compatibility and interoperability with current SIP applications. The draft describes also, as an example, the application of this mechanism to a particular QoS enabled IP network, which implements Diffserv as transport mechanisms and COPS as protocol for QoS requests and for admission control. "Time Efficient context Transfer (TEXT)", Madjid Nakhjiri, 04-Mar-03, This document presents a context transfer proposal that allows completion of context transfer outside timing critical message sequence for handover. The context transfer process is initiated at a moment of MN’s choice (in regard to layer 2 and 3 handover and MN’s traffic) and is completed without a disruption in the flow of MN’s real time traffic. This proposal is in line with the current fast handover framework within Mobile IP WG [3]. Although this document provides a specific recommendation, the framework proposed here, along with multiple alternatives that are mentioned, provides a great amount of flexibility in detailed design of context transfer. A minimum reliability mechanism for ensuring quality of transferred context is added to provide context updates that cannot be achieved by any transport protocol. "Offline Traffic Engineering in a Large ISP Setting", Chris Liljenstolpe, 11-Dec-02, This document is in response to a request made by the Traffic Engineering Working Group for a set of traffic engineering practices from a sample of the ISP engineering community. It reflects the current traffic engineering principles and practices that Cable & Wireless uses for its global 'packet' networks (including IP and MPLS) at the time of publication. It will also identify some of the history that has lead to the specific principles and practices as well as some of the trade-offs between these methods and other possible approaches. It is not intended to be a detailed engineering guide or 'how-to' document. "Definitions of Managed Objects for Service Location Protocol (SLP MIB)", Mark Bakke, Ira McDonald, 04-Mar-03, 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 as set of managed objects that support monitoring (but not configuration) of Service Location Protocol Version 2 (SLPv2, RFC 2608, RFC 3111, RFC 3224) directory agents (DAs), service agents (SAs), and user agents (UAs). "IPv6 Hostname auto-registration Procedure", Sira Rao, K Ettikan, 03-Dec-02, This document describes a new method, which will automatically acquire the host name of active IPv6 nodes and register it to the local Domain Name System (DNS) server. Active IPv6 nodes are nodes that are connected to a network. Our proposed new method [6] will automatically learn some useful information from all the IPv6 nodes, such as the host name and the IP address. The Agent using a new method will keep all the information that is send by the nodes. The Resolver will add the host name together with the IPv6 address to the DNS. This will be implemented without the need for any changes at the clients' site. The objective of this document is to specify a new procedure and also the algorithm used in the procedure. "Requirements for dynamic tunnel configuration", Christian Jacquenet, 18-Oct-02, In today's Internet, tunnels are established and activated to provide a facility for conveying a specific traffic from one point to another, or from one point to several others. This draft aims at describing the requirements for the specification and the standardization of the configuration information that will be used to define, establish, activate and maintain such facilities. "FTP/TLS Friendly Firewalls", Paul Ford-Hutchinson, 08-Jan-03, This document discusses some of the issues with running FTP, secured with TLS as defined in [FTP-TLS], through firewalls. FTP is known to be a bit of a problem for firewalls (see [RFC-1579] for a discussion of normal FTP and firewalls). Some of the problems have been fixed by adding intelligence into the firewall. With secured FTP, where the control connection is encrypted, some of these techniques fail. Whilst this document confines itself to issues of FTP over TLS, the issues will probably be relevant for most secured FTP protocols that conform to [RFC-2228]. Some of the discussions will also be relevant to any protocol that firewalls do clever things with. "EAP-SKE authentication and key exchange protocol", L. Salgarelli, 30-Jun-03, This note describes EAP Shared Key Exchange (SKE), a method for authentication of Mobile Nodes (MN) and generation of a per session, per node EAP Master Secret. The method applies to scenarios where a Mobile Node (MN) is in a foreign network such as a public 802.11 or 802.3 network that uses Home-AAA and Foreign-AAA services. The method requires presence of a pre-deployed cryptographically secure shared key on the MN and its Home-AAA server, and use of the 802.1x standard [1], Extensible Authentication Protocol (EAP) [2] messages, and RADIUS [3] authentication servers. The protocol can easily be extended to support the migration from RADIUS to DIAMETER [4]. "Explicit Multicast over Mobile IP (XMIP)", Jiwoong Lee, 17-Jan-03, As a special kind of Internet multicast, Explicit multicast(Xcast)[1] encodes destination addresses of all the receivers into the packet. Not requiring membership management and routing information exchange in the intermediate routers in contrast to the legacy Internet multicast or Deering multicast, Xcast can effectively provide multicast service to Internet without those overheads. A node mobility supporting protocol, Mobile IP[2,3], requires to be modified to appropriately intercept, route and forward Xcast packets. This document specifies the protocol operations for the mobile agent, the mobile node and the correspondent node to support transmission and reception of Xcast datagram over Mobile IPv4 and Mobile IPv6. "IPv4 Address Conflict Detection", Stuart Cheshire, 11-Dec-02, When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination) problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect after-the-fact that it has happened, so that the host may respond to rectify the problem. "Common Elements of GSER Encodings", Steven Legg, 04-Jun-03, The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types commonly occuring in Lightweight Directory Access Protocol (LDAP) syntaxes. "EAP Keying Framework", Bernard Aboba, Daniel Simon, 06-Mar-03, This document describes the framework for EAP key derivation, and provides guidelines for generation and usage of EAP keys by EAP methods and AAA protocols. Algorithms for key derivation or mechanisms for key transport are not specified in this document. Rather, this document provides a framework within which derivation algorithms and transport mechanisms can be discussed and evaluated. "An Effective Solution for Multicast Scalability:The MPLS Multicast Tree (MMT)", Ali Boudani, Bernard Cousin, Jean-Marie Bonnin, 24-Jun-03, A multicast router should keep forwarding state for every multicast tree passing through it. The number of forwarding states grows with the number of groups. In this paper, we present a new approach, the MPLS multicast Tree (MMT), which utilizes MPLS LSPs between multicast tree branching node routers in order to reduce forwarding states and enhance scalability. In our approach only routers that are acting as multicast tree branching node routers for a group need to keep forwarding state for that group. All other non- branching node routers simply forward data packets by traffic engineered unicast routing using MPLS LSPs. We can deduce that our approach can be largely deployed because it uses for multicast traffic the same unicast MPLS forwarding scheme. We will briefly discuss the multicast scalability problem, related works and different techniques for forwarding state reduction. We discuss also the advantages of our approach, and conclude that it is feasible and promising. Finally, we analytically evaluate our approach. "Capsulated Network Address Translation with Sub-Address(C-NATS)", Kuniaki Kondo, 16-Jun-03, Many home user networks or enterprise networks are using the address translation technology (NAT[1]) at the boundary of their end-networks for various reasons. One disadvantage of the use of the address translation technology is that it might disable two-way transparent communication. This document specifies the enhancement of the address translation technology, which it adds 'sub-address' to current IP address space to enable NAT inside/outside hosts to setup transparent communication in both direction through enhanced NAT routers. This enhancement is called 'C-NATS' (Capsulated Network Address Translation with Sub-Address) and the word 'NATS' used in this document implies 'C-NATS'. "A Two-Level Architecture for Internet Signaling", Robert Braden, Bob Lindell, 06-Nov-02, This memo defines an architectural framework for a wide variety of Internet signaling protocols. This framework has a two-level organization: a common lower layer 'transport' protocol together with a suite of upper-level signaling protocols. The common lower level protocol CSTP (Common Signaling Transport Protocol) provides a transport-like service that may include reliable delivery and soft state management. The upper layer protocols, which implement algorithms and data structures specific to particular signaling applications, are generically called ULSPs (Upper-layer Signaling Protocols). This memo motivates the two-level design and describes the service model, API, and operation of the lower level CSTP. "Text string notation for Dial Sequences and GSTN / E.164 addresses", Claudio Allocchio, 30-Apr-03, This memo describes the full set of notations needed to represent in a text string a Dial Sequence. A Dial Sequence is normally composed by Dual Tone Multi Frequency (DTMF) elements [1] plus separators and the additional 'actions' (such as 'wait for dialtone', 'pause for N secs', etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply. This notation is a fully compatible compendium of existing notations, and should be used in all specifications needing a text string representation of a Dial Sequence. Although the commonly called 'telephone numbers' are normally used to generate a Dial Sequence when establishing a connection, the full abstract E.164 addresses [2], i.e. the universal addressing on the Global Switched Telephone Network (GSTN), have further elements which cannot be dialled. Thus abstract E.164 addresses cannot be fully converted into a Dial Sequence or fully represented using this notation. "Language Tags and Ranges in LDAP", Kurt Zeilenga, 11-Dec-02, It is often desirable to to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). "LDAP 'Who am I?' Operation", Kurt Zeilenga, 04-Nov-02, This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity which the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP 'Who am I?' operation "A Framework for Service Personalization", A Barbir, 04-Mar-03, This document discusses a Framework for Service Personalization (FSP) defined within the bounds of the Open Pluggable Edge Services (OPES) Framework. The work described here aims to provide a Framework and Protocols for the delivery of the optimal content variant for a given requestor based on subscriber profile and policies, content profile and its associated policies. This document provides a general outline of FSP that could be used as a vehicle for performing personalization services in edge and intermediary devices or at Content origins. "Requirements for an OPES Service Personalization Callout Server", A Barbir, 04-Mar-03, This document provides the requirements for implementing a Framework for Service Personalization (FSP) in OPES intermediaries. This document provides a summary of modifications and required protocols that need to be supported by OPES intermediaries in order to allow for the development, deployment, and execution of a Service Personalization (SP) call-out server. "IP Header Compression over PPP", Mathias Engan, 03-Mar-03, 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 [RFC2507], [RFC2508] and [RFCYYYY]. "A Media Resource Control Protocol Developed by Cisco, Nuance, and Speechworks.", Saravanan Shanmugham, 01-May-03, This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks Inc. It is published as an RFC as input for further IETF development in this area. MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers etc. over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP(Session Initiation Protocol) which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol) "SIP Communications Resource Priority Header", James Polk, Henning Schulzrinne, 06-Mar-03, This document defines a new SIP header field for communications resource priority, called 'Resource-Priority'. This header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not influence the forwarding behavior of IP routers. "Using SIP to Support NP and Freephone Service", James Yu, 08-Jan-03, This document describes how Session Initiation Protocol (SIP) [2] can be used to retrieve information related to NP, freephone service and/or other information, and how the retrieved routing information is used in call processing and SIP signaling. "Generalized MPLS (GMPLS) LSP Bandwidth Modification (LBM) for SONET/SDH Networks", Eric Mannie, Dimitri Papadimitriou, Lyndon Ong, 24-Feb-03, This document defines how Generalized MPLS (GMPLS) can be used to dynamically modify the bandwidth of a Time Division Multiplexing (TDM) Label Switched Path (LSP). It focuses first on Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) and intends to cover other switching technologies in a further release. This document also defines how to use multiple differently routed LSPs to build a single SONET/SDH virtually concatenated circuit where each component LSP can be subsequently recovered (i.e. protected or restored) individually. "Analysis of Existing QoS Solutions", Hermann De Meer, 04-Nov-02, This memo provides a brief analysis of existing IP quality of service (QoS) solutions and the implied signalling issues. This analysis is intended to point out open issues in QoS signalling. Moreover, this analysis is done in order to understand whether the strict QoS requirements imposed by future fixed and mobile applications are satisfied by the existing IP QoS solutions. The existing IP QoS solutions can be categorized as follows: * End-to-end per-flow resource reservation protocols * Integrated Services over Differentiated Services * Statically assigned trunk reservations based on Differentiated Services * Dynamic trunk reservations with Aggregated RSVP "Extended RTP Profile for RTCP-based Feedback - Results of the Timing Rule Simulations", Carsten Burmeister, 04-Jun-03, This document describes the results we achieved when simulating the timing rules of the Extended RTP Profile for RTCP-based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well accepted RTP rules regarding allowed bit rates for control traffic. "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 06-Nov-02, This document defines a simple challenge-response [SASL] authenti- cation mechanism, using a [KEYED-MD5] digest. "Global Connectivity for IPv6 Mobile Ad Hoc Networks", Ryuji Wakikawa, 06-Nov-02, This document describes how to provide Internet connectivity with mobile ad-hoc networks. It describes how to obtain a globally routable address and internet-gateway operation. Once a manet node obtains a global address from an internet-gateway, it may exchange data with nodes on the Internet. Data goes through the internet-gateway with a routing header specifying the gateway. This connectivity method is not dependent on a particular manet protocol. Further, use of global connectivity with Mobile IPv6 is specified. "Virtual Private LAN Service", Kireeti Kompella, Yakov Rekhter, 15-May-03, Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 VPN; however, in the case of VPLS, the customers in the VPN are connected by a multipoint network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, and proposes a mechanism for signaling a VPLS, as well as for forwarding VPLS frames across a packet switched network. "Mobile Router Tunneling Protocol", TJ Kniveton, 08-Nov-02, This document describes how to support mobile networks with Mobile IP or Mobile IPv6 using reverse tunneling. It provides this support capability with no modifications to Mobile IP or routing protocol signaling, but also defines new extensions to ease in the implementation of network mobility. There are two described scenarios of mobile router support, consumer mode, and fully enabled mode. In the former, the mobile router is not allowed to use routing protocol signaling with the home agent, but performs routing for subnet(s) assigned to it. In the latter mode, both the home agent and the mobile router use a routing protocol in the same manner as fixed routers. "Considerations for LDAP Extensions", Kurt Zeilenga, 07-Mar-03, The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding system schema. This document discusses considerations for designers of LDAP extensions. "Traversal Using Relay NAT (TURN)", Jonathan Rosenberg, 10-Mar-03, Traversal Using Relay NAT (TURN) is a protocol that allows for an element behind a NAT or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to run servers on well known ports if they are behind a nat; it supports the connection of a user behind a nat to only a single peer. In that regard, its role is to provide the same security functions provided by symmetric NATs firewalls, but to ``turn'' the tables so that the element on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client. "Virtual Private LAN Services over MPLS", Marc Lasserre, 07-Mar-03, This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling demultiplexor labels, extending [PWE3-CTRL] and rudimentary support for availability (multi-homing). It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3- ETHERNET]. "LDAP: Dynamic Groups for LDAPV3", S Haripriya, 07-Mar-03, This draft describes the requirements, semantics, schema elements, and operations needed for a dynamic group feature in LDAP. A dynamic group is defined here as a group object with a membership list of distinguished names that is dynamically generated using LDAP search criteria. The dynamic membership list may then be interrogated by LDAP search and compare operations, and be used to identify a group of access control subjects. This feature eliminates a huge amount of the administrative effort required today for maintaining group memberships and role-based operations in large enterprises. "Extensions to Generalized MPLS in support of Waveband Switching", Richard Douville, 21-Feb-03, Generalized MPLS (GMPLS) extends the MPLS control plane to encompass layer 2, time-division, wavelength and spatial switching. A functional description of the extensions to MPLS signaling needed to support the new types of switching is provided in [RFC-3471]. On the other hand, along with the current development on IP over optical switching, considerable advances in optical transport systems based on the multiple optical switching granularities have been developed. [RFC-3471] currently defines two layers of optical granularity using wavelengths and fibers. By introducing an extended definition of waveband switching, this document specifies the corresponding GMPLS extensions, to further integrate optical multi-granularity and benefit from the features of the corresponding switching layers. "RTP Payload Format for AC-3 Streams", Jason Flaks, Todd Hager, 30-Jan-03, This document describes an RTP payload format for transporting AC-3 encoded audio data. AC-3 is a high quality multichannel audio coding system used in ATSC HDTV, DVD, film, and other media. The RTP payload format presented in this document provides mechanisms for interleaving redundant data, which can increase packet loss resilience. An intelligent method for fragmenting AC-3 frames that exceed the maximum transfer unit (MTU) is also described. "SIM Authentication over IPv6 (SIM6)", TJ Kniveton, Jari Malinen, 05-Mar-03, Providing an existing scalable authorization infrastructure for mobile nodes is needed for IPv6-based mobility. SIM Authentication provides a protocol for authenticating and authorizing services. It uses an authorizing home domain defined by the Subscriber Identity Module (SIM). The protocol is an Internet Control Message Protocol for IPv6 (ICMPv6) [17] extension. It can leverage the existing SIM authorization infrastructure for automatic bootstrapping of security association between the mobile node and a service, where the service can be e.g. authorized last-hop VPN setup for network access or Mobile IPv6 mobile-home security association setup. "The Managed Object Aggregation MIB", Glenn Keeni, 01-Jul-03, This memo defines a portion of the Management Information Base (MIB), the AggrMIB, for use with network management protocols in the Internet community. The AggrMIB is used to configure an agent to aggregate the values of a (user) specified set of MO instances and to service queries related to the aggregated MO instances. "A URN Namespace for MPEG", Jay Smith, 23-Sep-02, This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG. "URI Scheme for the TFTP Protocol", Eliot Lear, 09-Jun-03, TFTP is a very simple TRIVIAL file transfer protocol that has been in use on the Internet for quite a long time. While this document discourages it continued use, largely due to security concerns, we do define a URI scheme, as well as discuss the protocol's applicability. "Test Specification for MTP3 User Adaptation", Anshoo Sharma, 14-May-03, This document presents the test specification for M3UA (MTP3 User Adaptation) protocol (RFC 3332), which can be used to test M3UA implementations for conformance to the protocol definition. The list of test is exhaustive and covers almost all the categories of test. This draft can also be used in conjunction with M3UA specification by implementers of protocol as implementers guide, as the pictorial representation of various scenarios help easy understanding of the protocol. Next revision of the draft will cover the additions done to the protocol revision and any subsequent RFC published by IETF. "Definition of IP Packet Reordering Metric", Stanislav Shalunov, 06-Mar-03, Various pieces of network testing equipment currently often report a characteristic that is referred to as a 'degree (or percentage) of packet reordering'. The way this metric is computed is often undocumented and it differs between vendors. Having a useful numeric measure of the degree of packet reordering is important for applications such as TCP and VoIP on different ends of the spectrum. However, the metric that makes sense for one application may have no or little applicability to another. This document introduces a definition of reordering metric that is hoped to be applicable to a number of different applications by parametrizing the metric. "SS7 MTP2-User Peer-to-Peer Adaptation Layer Test Specifications M2PA-TEST", Brian Bidulock, 07-Oct-02, This Internet Draft provides information for the Internet community on test cases for testing the SS7 M2P2-User Peer-to-Peer Adaptation Layer [M2PA06] based on the conformance test specifications for SS7 MTP Level 2 [Q.781]. "What's In A Name:Thoughts from the NSRG", Eliot Lear, Ralph Droms, 27-Mar-03, Over the last few years, the use of IP addresses for Internet connectivity has changed dramatically. The Name Space Research Group (NSRG) has been chartered by the IRTF to review these changes, and make recommendations on whether or not remediation within the protocol stack is necessary. This document reports the outcome of some of the discussions within the research group. One of the questiones addressed by the NSRG is: Does the TCP/IP protocol suite need an additional level of naming above layer 3 but below the application layer? This document reviews the motivation for an additional naming mechanism, reviews related work, proposes a straw man 'stack name' and discusses the structure and use of stack names. "Registration of GSTN SMS Service Qualifier", Erik Wilde, 15-May-03, This memo describes the registration of the Short Message Service (SMS) as a registered IANA service selector for Global Switched Telephone Network (GSTN) numbers. SMS is not available for all GSTN subscribers, but it has proven very popular with users of the Global System for Mobile Communications (GSM), and has also been adapted to other telephone network technologies such as the Integrated Services Digital Network (ISDN). "Application Server Process (ASP) Extension (ASPEXT) Framework for Signalling User Adaptation Layers", Brian Bidulock, 10-Jan-03, This Internet-Draft describes ASP Extensions (ASPEXT) for Signalling User Adaptation Protocols [IUA...TUA], which permits cooperating Signalling Peer Processes (SPPs) to indicate to each other the specific protocol extensions that each supports. "Signalling Gateway (SG) Information (SGINFO) Support for Signalling User Adaptation Layers", Brian Bidulock, 10-Jan-03, This Internet-Draft describes Signalling Gateway (SG) Information (SGINFO) for Signalling User Adaptation Protocols [M2UA...TUA], which permits supporting Signalling Gateways (SG) to convey additional Application Server (AS) support information to Application Server Processes (ASPs) activating for AS on the SG. This additional AS support information consists of information pertaining to the underlying SS7 Signalling Provider that otherwise would have to be statically configured at the Application Server Process (ASP) or exchanged between SG and ASP using a non-IETF defined protocol. "Load Selection for Signalling User Adaptation Layers", Brian Bidulock, 10-Jan-03, This Internet-Draft describes Load Selection for Signalling User Adaptation Protocols [M3UA, SUA, TUA], which permits an Application Server Processes (ASP) to indicate its placement within an Application Server and permits an Signalling Gateway (SG) to distribute traffic over ASPs in Application Servers under Application Server Process (ASP) control. "Load Grouping Extension for Signalling User Adaptation Layers", Brian Bidulock, 10-Jan-03, This Internet-Draft describes an extension parameter and procedure to the Signalling User Adaptation Protocols [IUA...TUA], based on the Stream Transmission Control Protocol (SCTP) [RFC 2960] which permits an Application Server Processes (ASP) to indicate its placement within a Load Group and permits an Signalling Gateway (SG) to distribute traffic over Load Groups under Application Server Process (ASP) control. The described procedure provides for Override, Load-share and Broadcast traffic mode operation within a Load Group consisting of one or more Application Server Processes (ASPs) resulting in a mixture of traffic modes within an Application Server (AS). The parameters and procedures described here supplement the UA Load Selection [LOADSEL] extension parameters and procedures for improved distribution of traffic over ASPs and Signalling Gateway Processes (SGPs). "Correlation Id and Hearbeat Procedures (CORID) Supporting Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Layers", Brian Bidulock, 10-Jan-03, This Internet-Draft describes Correlation Id and Heartbeat procedures to support lossless fail-over between SCTP [RFC 2960] associations for SS7 [Q.700] Signalling User Adaptation Protocols [M2UA...TUA] supporting the concept of a Routing Context or Interface Identifier. These procedures permit lossless fail-over between Application Server Processes (ASPs) at a Signalling Gateway (SG) and fail-over between Signalling Gateway Processes (SGPs) and Signalling Gateways (SGs) at an Application Server Process (ASP). Lossless fail- over permits these fail-overs to occur without loss or duplication of UA-User messages. "SS7 TCAP-User Adaptation Layer TUA", Brian Bidulock, 10-Jan-03, This document defines a protocol for the transport of any SS7 TCAP- User signalling (e.g, INAP, MAP, etc.) over IP using the Stream Control Transport Protocol [RFC 2960]. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway and IP Signalling End-point architecture. Protocol elements are added to allow seamless operation between peers in the SS7 and IP domains. "A URN Namespace for SWIFT's Financial Messaging", Jean-Marc Gustin, Andre Goyens, 12-Apr-02, This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT s.c.r.l. (societe coopérative a responsabilites limitees) for usage within messages standardized by SWIFT. "The 'application/soap+xml' media type", Mark Baker, Mark Nottingham, 18-Jun-03, This document defines the 'application/soap+xml' media type which can be used to describe SOAP 1.2 messages serialized as XML. "Lightweight Directory Access Protocol (LDAP):Schema for Printer Services", Pat Fleming, Ira McDonald, 02-Jul-02, This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). "Diameter Multimedia Application", Tony Johansson, Maria-Carmen Belinchon, 07-Nov-02, This document specifies a Diameter application that allows a Diameter server to authenticate, authorize, and collect accounting information for Session Initiation Protocol (SIP) services rendered to a client node. This application, combined with the base Diameter protocol and appropriate SIP extensions, allows SIP User Agents (UAs) to obtain services from SIP servers that are connected to a Diameter infrastructure. When combined with the Inter-Domain capability of the base protocol, service may even be obtained from SIP servers that belong to foreign domains, as would be encountered by roaming mobile nodes. Note that the specification defined here may be used independently of the authentication technique used for authenticating a node's link layer or network-layer access. In particular, we do not require that the client node was authenticated for access with the use of either the Mobile IP [4] or NASREQ [3] Diameter application. "Requirements for transmission of IP datagrams over MPEG-2 networks", Gorry Fairhurst, 06-Jun-03, This document contains requirements for a framework for transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. Examples include the Digital Video Broadcast (DVB), specified by standards published by the European Telecommunications Standards Institute (ETSI) and the ATSC Digital Television Standard specified by the Advanced Television Systems Committee (ATSC). It identifies the need for the definition of a set of network protocols to standardise the interface between the MPEG-2 Transport Stream and an IP subnetwork. It also suggests an optimised encapsulation method for IP datagrams. The requirements for these functions are described, and a framework proposed for their implementation. "URI scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 15-May-03, This memo specifies a URI (Universal Resource Identifier) scheme 'sms' for specifying a recipient (and optionally a gateway) for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped computer "VeriSign Registry Registrar Protocol (RRP) Version 2.0.0", Scott Hollenbeck, Srikanth Veeramachaneni, Suresh Yalamanchilli, 18-Sep-02, This document updates version 1.1.0 of the NSI Registry Registrar Protocol specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol. "OSPF Area 0 PE/CE Links in BGP/MPLS VPNs", Eric Rosen, 06-Feb-03, [VPN] describes a method of providing a VPN service. That method allows a variety of different protocols to be used as the routing protocol between the Customer Edge (CE) router and the Provider Edge (PE) router. [OSPF-VPN} specifies the procedures which must be implemented within the Provider's network when the PE/CE routing protocol is OSPF [OSPF], and the PE/CE link is not an area 0 link. This document specifies the additional, optional, procedures that must be implemented to support the case in which the PE/CE link is an area 0 link. "Simple Middlebox Configuration (SIMCO) Protocol Version 2.0", Martin Stiemerling, Juergen Quittek, 04-Mar-03, This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used. The protocol meets all requirements defined by the MIDCOM working group (see [4]) and it implements the MIDCOM semantics [3]. "Use of /127 Prefix Length Between Routers Considered Harmful", Pekka Savola, 28-Jun-02, In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This draft discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers. "MGCP Fax Package", Flemming Andreasen, 13-Jan-03, This document defines an MGCP package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method as well as handle the details of the fax call without Call Agent involvement. "IMEI-based universal IPv6 interface IDs", Francis Dupont, Loutfi Nuaymi, 20-Jan-03, The IPv6 addressing architecture [1] defines a modified EUI-64 format for interface identifiers. These interface identifiers may have global scope when a global token is available (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers). Such a global token, the IMEI (International Mobile station Equipment Identity), is defined for GSM and UMTS terminals [2, 3, 4] and has the same properties than identifiers based on IEEE standards. This document explains the construction of a global IPv6 interface identifier from an IMEI. "Global Unique Identifiers (GID)", Hamid Ould-Brahim, 18-Dec-02, The existing VPN solutions [VR, 2547, L2VPN-Kompella] use in their control plane globally unique identifiers. This document describes the format of these identifiers (called GIDs). If any future VPN solutions require globally unique identifiers, they can re-use the format described in this document. "LDAPv3: Requesting Attributes by Object Class", Kurt Zeilenga, 23-Dec-02, The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, or attributes selected by their description. This document extends LDAP to provide a mechanism for LDAP clients to request the return of all attributes of an object class. "LDAP Absolute True and False Filters", Kurt Zeilenga, 05-May-03, This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. "Backtrace Messages for Label Switched Paths", HariKishan Desineni, Kameswara Avasarala, 10-Oct-02, Label switched path (LSP) backtrace is a method to backtrack the paths followed by packets in a particular multi protocol label switching (MPLS) forwarding equivalence class (FEC). This document describes encoding and procedures for new label distribution protocol (LDP) messages, backtrace message and backtrace reply message used for performing LSP backtrace. Backtrace message is sent upstream for an established LSP. Backtrace message can be used for LDP LSPs as well as for constraint based label switched paths (CR-LSPs). Data requested through backtrace message is encoded into backtrace reply message. Backtrace reply message is sent in downstream direction. It always travels towards the tail end of an LSP. Backtrace mechanism described in this document can also be used for obtaining additional attributes of LSPs. "EAP IANA Considerations", Bernard Aboba, 14-Oct-02, This document describes the IANA considerations for Extensible Authentication Protocol (EAP). "ARP Mediation for IP interworking of Layer 2 VPN", Himanshu Shah, 01-Jul-03, The VPWS service [L2VPN Framework] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a Pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both ethernet, both ATM), and the Pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the Pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as 'ARP Mediation'. This document specifies the ARP Mediation function, and specifies the encapsulation used to carry the IP datagrams on the Pseudowires when ARP mediation is used. "An API for Service Location", James Kempf, Erik Guttman, 13-Jan-03, The Service Location Protocol (SLP) provides a way for clients to dynamically discovery network services. This document describes a standardized API for SLP in the C language. In addition, standardized file formats for configuration and serialized registrations are defined. This document defines a new API for SLP that supercedes the definition in RFC 2614. "Zero-Configuration Subnet Prefix Allocation Using UIAP", Andrew White, Aidan Williams, 04-Nov-02, The ability of a multiple segment network to zero configure has advantages. This is especially the case when the network designer/builder has few IP networking skills, as can be expected in the home environment. This document describes a method for the zero- configuration of unique subnet prefixes in a network. The method proposed is based on the existence of the Unique Identifier Allocation Protocol (UIAP) but can be modified to use another protocol providing the same service. "Unique Identifier Allocation Protocol", Andrew White, Aidan Williams, 04-Nov-02, This memo specifies a distributed mechanism for testing the uniqueness of identifiers within a connected collection of devices. The mechanism supports multiple identifier domains, and uses only link-local communication and flooding. "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources", John Brezak, 16-Oct-02, Microsoft Windows 2000 includes operating system specific data in the Kerberos V5 [2] authorization data field that is used for access control. This data is used to create an NT access token. The access token is used by the system to enforce access checking when attempting to access objects. This document describes the structure of the Windows 2000 specific authorization data that is carried in that field for use by servers in performing access control. "IPv4 Multicast Unusable Group And Source Addresses", Bill Nickless, 17-Jun-03, Some IPv4 multicast datagrams should not be routed, either within an administrative domain or between administrative domains. A list of those restrictions is supplied here. These restrictions SHOULD be respected by IPv4 multicast applications, and included in network device access control lists. "Limited Private Address Support for Mobile IPv4", Samita Chakrabarti, 04-Nov-02, Reverse Tunneling for Mobile IP describes Limited Private Address Scenario for mobile nodes and mobile agents. This document specifies the requirements of Mobile IP components for Limited Private Address Support and discusses implementation issues and options. It also specifies two new Mobile IP skippable extensions for the interoperability of deployment in Limited Private Address Scenarios. Solutions involving Network Address Translation are out of scope of this document. "PPVPN Terminology", Loa Andersson, Tove Madsen, 30-Apr-03, The provider provisioned VPN solutions has attracted a great deal of interest. Memos proposing different and overlapping solution have been discussed on the PPVPN mailing list and in the Working Group meetings. This has lead to a development of a partly new set of concepts used to describe the set of VPN services. To a certain extent there are more than one term covering the same concept and sometimes the same term covers more than on concept. The terminology needs to be made clearer and more intuitive. This document seeks to fill at least part of that need. "RFC 3041 Considered Harmful", Francis Dupont, Pekka Savola, 19-Feb-03, The purpose of the privacy extensions for stateless address autoconfiguration [1] is to change the interface identifier (and the global-scope addresses generated from it) over time in order to make it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Current Distributed Denial of Service (DDoS) [2] attacks employ forged source addresses which can also be in the same prefixes than the real addresses of the compromised nodes used for attacks. Indeed, network ingress filtering defeats DDoS using 'random' forged source addresses. "Problem Scope and Requirements for Mobile Networks Working Group", TJ Kniveton, Alper Yegin, 08-Nov-02, This document suggests problem scope definitions and possible domain requirements for proposed solutions which describe how to connect mobile routers within the scope of the Network Mobility working group. The recommendations made in this draft result from the discussions of the Mobile IP mailing list, the NEMO mailing list, and past meetings of MONET and NEMO BOF sessions "Mobile IP API", Alper Yegin, 26-Jun-03, The Mobile IP API provides an interface between the mobility management module and the application layer. Using Mobile IP API, applications can extract the mobility information that is already maintained by the mobility management module. This API provides mobility awareness for applications. This document describes application scenarios followed by requirements and definition of Mobile IP API. Application scenarios are example applications that can take advantage of awareness of the mobility information. "Access Control Administration in LDAP", Steven Legg, 28-Feb-03, This document adapts the X.500 directory administrative model, as it pertains to access control administration, for use by the Lightweight Directory Access Protocol. The administrative model partitions the Directory Information Tree for various aspects of directory data administration, e.g. subschema, access control and collective attributes. This document provides the particular definitions that support access control administration, but does not define a particular access control scheme "Basic and Simplified Access Control in LDAP", Steven Legg, 28-Feb-03, An access control scheme describes the means by which access to directory information and potentially to access rights themselves may be controlled. This document adapts the X.500 directory Basic Access Control and Simplied Access Control schemes for use by the Lightweight Directory Access Protocol. "Instructions to Request for Comments (RFC) Authors", Joyce Reynolds, Robert Braden, 19-Jun-03, This memo provides information for authors of Request for Comments (RFC) documents. It summarizes RFC editorial policies and formatting requirements, addresses frequently-asked questions, and serves as a model for constructing a properly formatted RFC. "IP Measurement Protocol (IPMP)", Anthony McGregor, Matthew Luckie, 05-Jun-03, The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. IPMP is tightly constrained and easy to implement. "Backup Record Route for Fast Reroute Techniques in RSVP-TE", Stefaan De Cnodder, 05-Nov-02, MPLS fast reroute [3] is considered as a possible solution to protect traffic against link and node failures by re-directing the traffic locally to a backup LSP. A backup LSP can be either a detour LSP or a bypass tunnel. This document describes two methods to optimize the routing of detour LSPs such that they merge faster, a distributed method and a centralized method. The distributed method uses the Backup Record Route Object (BRRO) and the centralized method uses the Backup Explicit Route Object (BERO). The latter can also be used for bypass tunnels. "Mobile SCTP", Maximilian Riegel, Michael Tuexen, 05-Feb-03, Transport layer mobility management is presented in addition to Mobile IP for providing seamless mobility in the Internet. By use of SCTP (Stream Control Transmission Protocol) and some of its currently proposed extensions a seamless handover can be fully accomplished in the mobile client without any provisions in the network, only assisted by functions embedded in Mobile SCTP enabled servers. Client mobility management based on Mobile SCTP seems not to require any new protocol development. It is a particular application of SCTP eventually solving the requirements of transport layer mobility in the Internet. "Hierarchical LSP", Heinrich Hummel, Jochen Grimminger, 22-Oct-02, This draft pursues the standardization of the 'Hierarchical LSP' being a label-switched sequence of other LSPs (and interfaces), i.e. of hierarchically next-lower LSPs, which eventually, after some recursive cycles, consist of label-switched sequences of physical interfaces, i.e. of LSPs as of today. Hierarchically stacked LSPs will eliminate the notorious N-square problem when virtual networks (or even virtual networks on top of virtual networks) are to be built. Version 03 is based on RSVP-TE (not on CR-LDP anymore). "RObust Header Compression (ROHC):Profiles for UDP Lite", Ghyslain Pelletier, 31-Jan-03, This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in [RFC-3095] for UDP [RFC-768]. Although both transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because it does not share protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field and as a consequence cannot always be inferred anymore. "(FA-)LSP Initiation and Bundling using Link Management Protocol (LMP)", Dimitri Papadimitriou, Jim Jones, 05-Mar-03, This memo is a companion document to Link Management Protocol (LMP), for which it details the Forwarding Adjacency LSP (FA-LSP) Initiation and Bundling process. [LMP] protocol is being developed as part of the Generalized MPLS (GMPLS) protocol suite to control and manage Traffic Engineering (TE) Links. The current document extends the LMP capabilities to FA-LSPs enabling among other to dynamically configure TE Links (in particular the LSP it can serve) between non-adjacent LSRs. "SCTP Profile for EPIC", Mark West, Abigail Surtees, 27-Jun-03, This draft describes a profile for compressing SCTP/IP using the Robust Header Compression Formal Notation. The RObust Header Compression [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. This profile describes a new profile for ROHC which will allow SCTP/ IP headers to be compressed. "Provider Provisioned GMPLS-based Virtual Private Cross-Connect Service", Hamid Ould-Brahim, 18-Dec-02, This document describes an Optical Virtual Private Network service (OVPN) called Virtual Private Optical Cross-Connect (VPOXC). A VPOXC is a provider provisioned VPN service part of the customer private network but administered and under the control of the service provider. A VPOXC operates similarly to a physical optical cross-connect except that it allows a wide spectrum of port topology such as hub and spoke, full mesh, and arbitrary topologies. To the VPOXC customer, the service provider network appears as a virtual private optical cross- connect where customer sites are attached to. The VPOXC port topology is defined by the customer, and enforced by the service provider. Customers can signal any optical connectivity according to the port topology implemented by the VPOXC. Client devices operate within the VPOXC space independently from the service provider network operations. "Mobile IPv6 Authentication, Authorization, and Accounting Requirements", Stefano Faccin, 10-Apr-03, This document describes the motivation why Diameter support for Mobile IPv6 is required and needs to be developped. It analyses the requirements expressed in RFC 2977 which was written both for MIPv4 and MIPv6; and it finally updates the IPv6 requirements for the AAA support for Mobile IPv6 to reflect the latest modifications and evolution of the Mobile IP, AAA and other relevant working groups. "IMAP ANNOTATEMORE Extension", Cyrus Daboo, 20-May-03, The ANNOTATEMORE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' on IMAP4 servers. This document describes two 'profiles' for mailbox and server metadata. "Use of Session Initiation Protocol (SIP) and Simple Object Access Protocol (SOAP) for Conference Floor Control Protocol (SOAP) for Conference Floor Control", Xiaotao Wu, 06-Mar-03, During a conference, floor control coordinates simultaneous access to shared resource in multimedia conferences. Floor control allows applications and users to gain safe and mutually exclusive or non- exclusive access to the shared resources. This document defines an approach of using Session Initiation Protocol (SIP) event notification mechanism and Simple Object Access Protocol (SOAP) to perform floor control. "Geopriv Scenarios and Use Cases", Jorge Cuellar, 05-Mar-03, This document describes location-based service scenarios for Geopriv. It complements the Geopriv Requirements document by providing a set of examples in which the Geopriv Location Object (LO) may be used. Thus this documents serves as a basis to discuss and analyze the security (authentication, authorization, integrity and confidentiality) and privacy issues and requirements associated with location-based services. To be useful, these scenarios include details of location computation, which helps to identify the entities involved on an abstract level and where privacy issues like control, consent, access, and security arise. "The 'doi' URI Scheme for Digital Object Identifier (DOI)", Norman Paskin, 01-Jul-03, This document defines the 'doi' Uniform Resource Identifier (URI) scheme for the Digital Object Identifier (DOI). DOIs are identifiers for entities of significance to the content industries. The 'doi' URI scheme allows a resource associated with an entity identified by a DOI to be referenced by a URI for Internet applications. A 'doi' URI is dereferenced to a set of service descriptions through discoverable resolution mechanisms. "How to make IPsec more mobile IPv6 friendly", Francis Dupont, Wassim Haddad, 07-Mar-03, IPsec specifications [1-6] do not work well with any mobility device based on addresses [7]. Mobile IPv6 interaction with IPsec is still far from being well achieved. This is mainly due to bad interpretations of IPsec specifications. HIP (Host Identity Payload) [9] should change this regrettable situation. This document specifies some points where improvements can be made in many current implementations, on the way of making IPsec more suitable for Mobile IPv6. "Advancement of Application Programming Interface specifications on the IETF Standards Track", Brian Pawlowski, 06-Nov-02, The Internet Standards Process [RFC2026] requires that all IETF Standards Track specifications must have 'multiple, independent, and interoperable implementations' before they can be advanced beyond Proposed Standard status. This document specifies the test which the IESG will use to determine if an Application Programming Interface (API) specification document meets these requirements. It also discusses the rationale for this process. "Domain-based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", Leslie Daigle, A Newton, 09-Jun-03, This memo defines a Dynamic Delegation Discovery System (DDDS) [3] Application for domain name based discovery of application services. Essentially, this uses DNS NAPTR resource records [4] to provide one more layer of redirection for service lookup than is feasible with SRV ([2]) records. It is proposed because real-life use is demonstrating a need for something slightly more substantial than SRV, and alternatively SRV usage may become twisted out of its intended shape. "A Method to Provide Dynamic Routing in IPsec VPNs", Paul Knight, Bryan Gleeson, 06-Mar-03, Exchange of routing information between IPsec security gateways, using standard routing protocols across IPsec tunnels, can be a straightforward operation. Using the routing information to choose the proper path is also straightforward, when routing is functionally separated from the IPsec gateway operation. One of the most significant obstacles to widespread implementation of dynamic routing in IPsec VPNs has been agreement on a way to exchange and use the routing information. This document describes a simple and secure method of exchanging dynamic routing information between IPsec security gateways, using standard IPsec messages. This method is currently in use in a large number of installations, and has been demonstrated to be interoperable across several IPsec implementations from different vendors. "VPLS solutions: Commonalities and Differences", Michael Chen, Vasile Radoaca, 08-Nov-02, The scope of this draft is regarding the VPLS solutions - it describes commonalities and differences among different VPLS solutions in terms of distributed and non-distributed access topologies. The metrics used for comparison are derived from [L2VPN- METRICS] and [L2VPN-FRMK]. The current VPLS solutions that are taken in consideration are: GVPLS [GVPLS], DTLS [DTLS], and VPLS/HVPLS [VPLS-MPLS]. This list of solutions is not exhaustive; other solutions may be taken into account in future versions of this draft. "BGP Security Vulnerabilities Analysis", Sandra Murphy, 05-Mar-03, BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to the BGP protocol to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination. This internet draft does not discuss security issues with forwarding of packets. "GMPLS Extensions to OSPF and IS-IS for SONET/SDH Network Control", Eric Mannie, Dimitri Papadimitriou, 07-Oct-02, This document introduces some of the extensions required in existing IGP routing protocols to support sub-sequent signalling for dynamically established SONET/SDH circuits using GMPLS-based control plane architecture [GMPLS-ARCH]. In particular, it specifies the GMPLS routing extensions to OSPF and IS-IS routing protocols for SONET/SDH networks using [GMPLS-RTG] as guideline. The current document is based on the Traffic Engineering (TE) extensions defined in [OSPF-TE] and [ISIS-TE]. It supports link bundling (aka TE Links) as defined in [MPLS-BDL]. This document proposes several new sub-TLVs for SONET/SDH network control which complement those proposed in [GMPLS-OSPF] and [GMPLS-ISIS]. The proposed encoding does not preclude any further integration in these documents that the current one intends to complement. "ForwArding and Control ElemenT protocol (FACT)", Alex Audu, Ram Gopal, 01-Jul-03, This document defines a FACT protocol that is suitable for communicating between Forwarding Element and Control Elements inside a network element. This protocol addresses all the requirements described in Forces [3] requirements document. This document also describes the architecture that FACT may leverage during the protocol operation "CE Auto-configuration", C.J. Lee, 07-Nov-02, This draft describes the protocols required to automatically configure a Customer Equipment (CE) to support a VPN service offered by the provider (aka as Provider Provisioned CE-based VPN). "IMAP CHANNEL Use Cases", Eric Burger, 06-Nov-02, This document describes different use cases for using the IMAP CHANNEL facility. "OSPF Extensions to Support Multi-Area Traffic Engineering", Dean Cheng, 21-Feb-03, The [MULTI-AREA] introduces a set of mechanisms that could be used to construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all the way to the ABR in the tail-end area. This document proposes some new OSPF extensions that can be used in supporting that scenario, i.e., by leaking some of the useful information from individual areas to others, the constraint-based routing at the head-end LSR of LSPs in OSPF networks with multiple areas can be optimized. "The 'application/srgs' Media Type", Brad Porter, Steph Tryphonas, 21-Nov-02, This document defines the 'application/srgs' media type for the augmented BNF version of the Speech Recognition Grammar Specification. "The 'application/srgs+xml' Media Type", Brad Porter, Steph Tryphonas, 21-Nov-02, This document defines the 'application/srgs+xml' media type for the XML version of the Speech Recognition Grammar Specification. "The 'application/ssml+xml' Media Type", Steph Tryphonas, Brad Porter, 21-Nov-02, This document defines the 'application/ssml+xml' media type for the Speech Synthesis based markup language. "The 'application/voicexml+xml' Media Type", Steph Tryphonas, Brad Porter, 21-Nov-02, This document defines the 'application/voicexml+xml' media type for the VoiceXML based markup language. "OSPF Link-local Signaling", Alex Zinin, Barry Friedman, Abhay Roy, Liem Nguyen, Derek Yeung, 20-Jun-03, OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. "OSPF Out-of-band LSDB resynchronization", Alex Zinin, Abhay Roy, Liem Nguyen, 20-Jun-03, OSPF is a link-state intra-domain routing protocol used in IP networks. LSDB synchronization in OSPF is achieved via two methods-- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network. This memo describes a vendor specific mechanism to perform such form of out-of-band LSDB synchronization. "OSPF Restart Signaling", Alex Zinin, Abhay Roy, Liem Nguyen, 20-Jun-03, OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions. This memo describes a vendor specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. "Terminal Independent Mobile IP (TIMIP)", Pedro Estrela, 17-Jan-03, All IP mobility protocols currently proposed on the IETF assume that the mobile nodes always have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including the laptops and PDAs which most would benefit of the mobility support, still use legacy IP stacks, limiting their use to layer-2 mobility within a single IP subnet. This document presents Terminal Independent Mobile IP (TIMIP), which supports IP micro-mobility of all possible existing legacy IP terminals, while fully interoperating with Mobile IP to provide macromobility across IP subnets for all terminals. "WebDAV SEARCH", Julian Reschke, 13-Jun-03, This document specifies a set of methods, headers, properties and content-types composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) DASL mailing list at www-webdav-dasl@w3.org, which may be joined by sending a message with subject 'subscribe' to www-webdav-dasl-request@w3.org. Discussions of the WebDAV DASL mailing list are archived at URL: http://www.w3.org/pub/WWW/Archives/Public/www-webdav-dasl/. "The MUPDATE Distributed Mailbox Database Protocol", Robert Siemborski, 15-May-03, As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of IMAP (or POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol. Please note that this specification is provided to give information to the internet community; it is anticipated that it would need to be revised before widespread adaption. "Session Initiation Protocol Based Application Interaction Requirements", Bert Culpepper, Robert Fairlie-Cuninghame, 06-Mar-03, This document defines the high level requirements for a framework and/or one or more mechanisms that support user interaction, via SIP-based user agents, with applications residing on remote network servers. The requirements in this document address the overall features of such a system, without regard to its architecture. SIP currently supports media-based application interactions using methods such as speech, video and end-to-end telephony-related tones; however, it is desired that more general application interaction models are defined, especially those that are not restricted to the media plane. In addition, it is desired that an application be able to present the user with application-specific user interfaces and information. The user agent should also be able to generate activity indications back to an application to communicate actions on physical or logical user interfaces. The document also defines a number of topic-related terms to assist in disambiguating discussions of the issues. "Developing High Quality SNMP Agents", Aleksey Romanov, 04-Nov-02, SNMP is a ubiquitous protocol. Many software developers working in the embedded space develop or interface with MIB handlers and SNMP agents one way or another. Often these developers are unfamiliar with SNMP standards and overlook a number of subtle points. This document will provide a list of steps and rules to avoid common problems in order to develop a high quality SNMP agent. "Enabling Global Service Attributes in the Service Location Protocol", Weibin Zhao, Henning Schulzrinne, 28-Apr-03, This document describes enabling global service attributes in the Service Location Protocol (SLP). A global service attribute describes a service property common to all service types. Its name begins with the 'service-' prefix. It is defined via an attribute template, and can be imported into any service template. A single Service Request (SrvRqst) message can use global service attributes to search services across multiple service types. Global service attributes can be associated with certain special characteristics so as to support advanced discovery scenarios, such as URL changes, multi-access-point services, multi-function devices and replicated services. "Generic String Encoding Rules for ASN.1 Types", Steven Legg, 04-Jun-03, This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules, that produce a human readable text encoding for values of any given ASN.1 data type "Toward a Quantitative Analysis of IETF Productivity", M. Richard Rose, Dave Crocker, 06-Nov-02, This memo presents an initial quantitative analysis of the IETF's working groups using RFC publication as the primary metric. "Analysis of Generalized MPLS-based Recovery Mechanisms (including Protection and Restoration)", Dimitri Papadimitriou, Eric Mannie, 07-Nov-02, This document provides an analysis grid that can be used to evaluate, compare and contrast the numerous Generalized MPLS (GMPLS)-based recovery mechanisms currently proposed at the CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in [CCAMP-TERM]. Also, this document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. "An LDAPv3 Schema for X.509 Certificates", Norbert Klasen, Peter Gietz, 07-Mar-03, This document describes an LDAP schema which can be used to implement a certificate store for X.509 certificates. Specifically, a structural object class for a X.509 certificate is defined. Key fields of a certificate are stored in LDAP attributes so that applications can easily retrieve the certificates needed by using basic LDAP search filters. Multiple certificates for a single entity can be stored and retrieved. "RADIUS Support For Extensible Authentication Protocol (EAP)", Bernard Aboba, Pat Calhoun, 16-May-03, This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This document updates RFC 2869. "application/rdf+xml Media Type Registration", Aaaron Swartz, 13-Feb-03, This document describes a media type (application/rdf+xml) for use with the XML serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. "Fast Reroute Extensions to Constraint based Routed Label Distribution Protocol", C Vijayanand, 06-Dec-02, This document proposes extensions to existing CR-LDP for setting up MPLS backup tunnels. These tunnels can protect Label Switched Paths on an exclusive bandwidth basis or shared bandwidth on the back up paths, as desired by the initiator of the tunnel at the head end node. Several backup segments are maintained for a single LSP and they are meant to provide link and node failure protection along various segments of the LSP. Sharing of backup segments across multiple LSPs is also facilitated to achieve scalability "BGP/MPLS VPN Policy Information Base", Yacine Mghazli, 07-Mar-03, This document describes a Policy Information Base (PIB) for a device implementing the BGP/MPLS VPN [2547bis] Architecture. The Provisioning Classes defined here provide policy control of resources implementing the BGP/MPLS VPN Architecture. These Provisioning Classes can be used with other non BGP/MPLS VPN Provisioning Classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirements to device resource capability and usage. The COPS-PR protocol offers significant advantages when dealing with dynamic configuration and when compared to traditional management solutions. Moreover, dynamic VPN resource assignment is crucial to cope with the frequent changes requests from customer's (e.g., sites joining or leaving a VPN), as well as to achieve scalability. The PEs should be able to dynamically assign the VPN resources. This capability is especially important for dial and wireless VPN services. "UTF-8, a transformation format of ISO 10646", Francois Yergeau, 10-Jun-03, ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2279. "Interworking SIP and Intelligent Network (IN) Applications", Vijay Gurbani, F Haerens, Vidhi Rastogi, 21-Jun-02, Public Switched Telephone Network (PSTN) services such as 800 number routing (freephone), time-and-day routing, credit-card calling, virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This draft addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this draft describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). "Simple Encapsulation for transmission of IP datagrams over MPEG-2/DVB networks", Horst Clausen, 20-May-03, This document contains the Simple Encapsulation, a simple and lean encapsulation mechanism for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. One example is the Digital Video Broadcast (DVB), specified by standards published by the European Telecommunications Standards Institute (ETSI). "PPP V.44 Compression Protocol", Jeff Heath, John Border, 16-Sep-02, The Point-to-Point Protocol [PPP] provides a standard means for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [CCP] provides a means to negotiate and utilize compression protocols over PPP encapsulated links. This memo describes a means for compressing PPP encapsulated datagrams by utilizing the data compression algorithm that is described in International Telecommunication Union (ITU-T) Recommendation V.44 [V44]. Recommendation V.44 is a modem standard but Annex B of the recommendation describes the implementation of V.44 in packet networks. This memo defines the application of V.44, with single or multiple compression dictionaries,to the PPP Compression Control Protocol (RFC 1962). "An IPv4 Flowlabel Option", Thomas Dreibholz, 02-Dec-02, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "Internationalized Resource Identifiers (IRI)", Martin Duerst, Michel Suignard, 01-Jul-03, This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the URI [RFC2396]. An IRI is a sequence of characters from the Universal Character Set [ISO10646]. A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs where appropriate to identify resources. The approach of defining a new protocol element was chosen, instead of extending or changing the definition of URIs, to allow a clear distinction and to avoid incompatibilities with existing software. "Media Gateway Control Protocol (MGCP) Return Code Usage", Bill Foster, C Sivachelvan, 11-Apr-03, This document provides implementation guidelines for the use of return codes in the Media Gateway Control Protocol MGCP 1.0 (RFC 3435). Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency. "GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit", Hamid Ould-Brahim, 06-Mar-03, This draft describes a suite of port-based Provider-provisioned VPN services called Generalized VPNs (GVPNs) that uses BGP as a VPN auto-discovery and GMPLS as a signaling mechanism. GVPN services are 'generalized' as the interfaces on the customer's and provider ports could be any of the interfaces supported by Generalized MPLS (GMPLS). GVPN services outlined in this document are: (1) a port-based Generalized Virtual Private Wire (GVPW) where the basic unit of service is a Label Switched Path (LSP) between a pair of customer's ports within a given VPN port-topology. (2) A Generalized Virtual Private Cross-connect (GVPXC) service where the service provider network appears to the client network as a GMPLS-enabled Virtual Private node. A GVPXC service provides flexible traffic engineering on the client network and eliminates the need for n square routing peering between CEs. Since GVPNs uses GMPLS as the signaling mechanism, and since GMPLS applies to both TDM and Lambda Switching capable interfaces, it results that GVPN services include Optical/TDM VPNs (though they need not be restricted to). "IP Version 6 over MAPOS", Tsuyoshi Ogura, Mitsuru Maruyama, Toshiaki Yoshida, 25-Apr-03, Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over SONET/SDH. This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 neighbor discovery messages. "Interworking between SIP and QSIG", John Elwell, 24-Oct-02, This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. "IPv6 Fast Router Advertisement", James Kempf, M Khalil, Brett Pentland, 11-Feb-03, This document specifies an amendment to the router solicitation handling procedures in RFC 2461 that allow for improved default router aquisition performance when an active IP host moves from one subnet to another. "Carrying ISUP in SIP Messages (SIP-ISUP-ANNEX)", Frank Miller, 20-Mar-03, SIP-ISUP-ANNEX is a mechanism by which an XML representation of certain ISUP messages can be transported in the body of SIP INFO messages. This mechanism can be used to allow PSTN elements to control trunk interfaces that are terminated by SIP-controlled access equipment without having to implement the binary ISUP protocol. "High Level Requirements for Tightly Coupled SIP Conferencing", Orit Levin, Roni Even, 06-Mar-03, This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. "SMTP Submission Service Extension for Future Delivery", Gregory White, Gregory Vaudreuil, 01-Jul-03, This memo defines an extension to the SMTP submission protocol for client indication of a future-delivery time. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. "Architecture for Event Notification Filters", Tim Moran, Sreenivas Addagatla, 24-Oct-02, This document defines an extendible architecture whereby an event subscriber (client) may specify the rules for SIP event notification from the notifier (server). Potential solutions meeting the architecture specification are also provided in the annexes. Requirements for event filtering were previously described in [1]. "M3UA SG-SG communication", Brian Bidulock, Tolga Asveren, 24-Apr-03, This Internet-Draft describes a protocol to support communication of M3UA[1] based SGs in IP domain. The additional functionality needed by SGs to act as relay points between SS7 nodes is also addressed. "Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean", James Seng, 17-Jun-03, Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design--such as how names are represented on the network, compared, and converted to appropriate forms--but also with issues and options for deployment, transition, registration, and administration. The IETF Internationalized Domain Name (IDN) Working Group focused its efforts on the development of a standards-track specification for access to domain names in a range of scripts that is broader in scope than the original ASCII. During its efforts, it became clear that the appearance of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition, and that those issues could best be addressed administratively rather than through restrictions embedded in the protocols. This document is an effort of the Joint Engineering Team (JET), a group composed of members of CNNIC, TWNIC, KRNIC, and JPNIC as well as other individual experts. It offers guidelines for zone administrators -- including but not limited to registry operators and registrars -- and information for all domain names holders on the administration of domain names that contain characters drawn from Chinese, Japanese, and Korean scripts. Other language groups are encouraged to develop their own guidelines as needed, based on these guidelines if that is helpful. "RFC Editor Guidelines on Author Lists", Joyce Reynolds, Robert Braden, 09-May-02, This memo presents a new set of guidelines to govern lists of authors on RFC documents. It is intended to counteract a recent tendency towards author list inflation. "Extensible Authentication Protocol State Machine", Bryan Payne, 07-Nov-02, The specification for the Extensible Authentication Protocol (EAP) [2] omits a state machine description. This omission has led to ambiguity in the specification and potential security problems in EAP implementations. This document outlines a state machine to be integrated into the next revision of the EAP RFC. "A URN Namespace for MACE", RL Bob Morgan, Keith Hazelton, 21-Nov-02, This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by the Internet2 Middleware Architecture Committee for Education (MACE) for naming persistent resources defined by MACE, its working groups and other designated subordinates. "Localized RSVP", Jukka Manner, 14-Jan-03, Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. Even if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources at the access network, especially wireless link resources. Additionally, for mobile nodes the continuity of QoS is disturbed due to end-to-end signalling or slow re-reservations of resources after each handover. This draft proposes a simple enhancement to RSVP, so that initial resource reservations and re-reservations due to host mobility can be done locally in an access network. "A Guide to Implementing Stateless DHCPv6 Service", Ralph Droms, 25-Oct-02, Stateless DHCPv6 service is used by hosts to obtain configuration information such as the addresses of DNS servers that does not require the maintenance of any dynamic state for individual clients. A host that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. "SILC Message Flag Payloads", Pekka Riikonen, 16-Jun-03, This memo describes the data payloads associated with the SILC Message Flags, as defined in the SILC Packet Protocol specification [SILC2]. The purpose of the Message Flags is to augment the function of the Message Payload used to send both private and channel messages, by allowing the sender to tell the receiver what type of data the payload includes, and how the data should be processed. Some of the Message Flags may define additional payloads to be associated with the flag, and this memo describes these payloads. "User Online Presence and Information Attributes", Pekka Riikonen, 26-Nov-02, This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network. "Stream Control Transmission Protocol (SCTP) Bakeoff Scoring", Randall Stewart, Michael Tuexen, 06-May-03, This memo describes some of the scoring to be used in the testing of Stream Control Transmission Protocol (SCTP) at upcoming bakeoffs. "Chinese Name String in Search-based access model for the DNS", XiaoDong Lee, YanFeng WANG, 25-Nov-02, There are many requirements of developing internationalized and human-readable Internet identifiers/names now, thereby there are many systems based on DNS technology to meet such requirements. John C. Klensin has proposed a three-layer search-based access model for the DNS [DNSSEARCH]; this paper is only to explain some related problems mentioned in John C. Klensin's proposal. Especially it focuses on Traditional and Simplified Chinese problems and some other special Chinese requirements. The ultimate goal for any kinds of search-based access system is to help users to access network resources in more natural ways, which have different meaning for different user groups. On the premise of respecting Chinese user's language convention, it is very important for a valuable and human-friendly system to deal with traditional and simplified Chinese equivalence problems. "Advertisement of Multiple Paths in BGP", Daniel Walton, David Cook, Alvaro Retana, John Scudder, 07-Nov-02, The BGP specification [1,2] defines an 'Update-Send Process' to advertise the routes chosen by the Decision Process to other BGP speakers. No provisions are made to facilitate the advertisement of multiple paths to the same destination. In fact, a route with the same NLRI as a previously advertised route implicitly replaces the original advertisement. This document proposes a mechanism that will allow the advertisement of multiple paths for the same prefix without the new paths implicitly replacing any previous ones. The essence of the mechanism is that each path is identified by an arbitrary identifier in addition to its prefix. "Exclude Routes - Extension to RSVP-TE", C.J. Lee, Adrian Farrel, Stefaan De Cnodder, 06-Mar-03, The current RSVP-TE specification, 'RSVP-TE: Extensions to RSVP for LSP Tunnels' (RFC 3209) and GMPLS extensions to RSVP-TE, 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions' (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some systems where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole of a path, or to parts of a path between two abstract nodes specified in an explicit route. Shared Risk Link Groups (SRLGs) allow the definition of resources or groups of resources that share the same risk of failure. The knowledge of SRLGs may be used to compute diverse paths that can be used for protection. In systems where it is useful to signal exclusions, it may be useful to signal SRLGs to indicate groups of resources that should be excluded on the whole of a path or between two abstract nodes specified in an explicit path. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. "Applying WebDAV (Web Distributed Authoring and Versioning)to Network Configuration Management Problems", Randy Presuhn, 07-Jan-03, This memo examines the potential of using WWW Distributed Authoring and Versioning (WebDAV) technologies to address the problems of network configuration management. It reviews requirements and issues that have been identified in IETF network configuration management and operator requirements discussions, matching these requirements and issues with various WebDAV facilities. It concludes by identifying areas for further exploration. Comments are welcomed, both from the Operations and Management Area in general, and from participants in the webdav and deltav working groups in particular. Please send comments to the author at randy_presuhn@bmc.com. "Shared Risk Link Groups Encoding and Processing", Dimitri Papadimitriou, 05-Nov-02, The Shared Risk Link Group (SRLG) concept introduced in [IPO-Frame] and extended in [CCAMP-SRG] is considered as one of the most important criteria concerning the constraint-based path computation of optical channel routes. By applying the SRLG disjointness criteria to the constraint-based path computation, one can select a route taking into account both resource and logical structure disjointness. That implies a lower probability of simultaneous optical channel failure. This document describes the various physical and logical resource types considered in the SRLG concept. The proposed method focuses on the inference of SRLG information between the network physical and logical layers and the logical structures representing geographical locations. The main applications of the proposed model are related to the Constraint-based Shortest Path First (CSPF) algorithm for optical channel route computation and the aggregation of the SRLG information flooded throughout traffic engineering extensions of the IGP routing protocols (such as OSPF and IS-IS). "SIP server IPCP configuration option for PPP", Junhyuk Song, 22-Apr-03, This document defines a new configuration option for the PPP IPCP (PPP Internet Protocol Control Protocol), to return a list of the IPv4 addresses of SIP proxy servers. This option provides one mechanism that a system may use to locate a SIP proxy server. This approach is applicable for a system that is using PPP for the link layer protocol and IP address allocation. "Data Transfer Protocol for Distributed Information Acquisition (DTP/DIA)", Alexei Soloviev, 20-Mar-03, The described in this memo protocol was developed for the application in distributed information measurement systems (IMS) at any stage of communication. It was designed for transmission of measured data from measuring devices to processing and storing equipment. Also it does support common device identification in distributed IMS. Due to its simplicity it can be easily implemented in firmware of any digital measuring device. "SMTP Service Extension for message Media Size declaration", Vladimir Shveidel, Ari Erev, 13-Feb-03, This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the general message size and sizes of media parts the message contains. [9] lists a number of issues and requirements for the use of internet messaging in the context of Unified Messaging and Telephone User Interface. This memo elaborates and suggests an implementation for chapter 3.2 of [9]. This memo extends facilities of 'SMTP Service Extension for Message Size Declaration' [3]. As such, the authors of this memo used portions of the text in [3] as a basis for this memo. "Cisco Systems NetFlow Services Export Version 9", Benoit Claise, 11-Jun-03, This document discusses the Cisco Systems NetFlow services that provide network administrators with access to IP flows information. The NetFlow services create flow records that are exported to a NetFlow collector. The exported flow records can be used for a variety of purposes, including network management and planning, accounting, departmental chargebacks, Internet Service Provider (ISP) billing, data warehousing, and data mining for marketing purposes. This document focuses on the most recent evolution of the NetFlow flow record export format, which is known as version 9. The distinguishing feature of the NetFlow version 9 export format, compared with previous formats, is that it is template based. The templates (collections of fields with the corresponding description of their structures and their semantics) provide a flexible and extensible design to the flow record export format. This facilitates future enhancements to NetFlow services without requiring changes to the basic flow record export format. Another advantage is that only the required fields are exported within the flow record, which minimizes the consumed export bandwidth. "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing Session Initiation Protocol SIP-based Distributed Call Control Mechanisms", Warren Marshall, Matt Osman, Flemming Andreasen, David Evans, 16-Jan-03, This document provides an overview of a SIP-based Distributed Call Signaling (DCS) architecture to support carrier class packet-based voice, video, and other real time multimedia services. Companion documents address a specific set of SIP 2.0 protocol extensions and usage rules that are necessary to implement the DCS architecture in an interoperable fashion. The DCS architecture takes advantage of endpoint intelligence in supporting telephony services without sacrificing the network's ability to provide value through mechanisms such as resource management, lookup of directory information and translation databases, routing services, security, and privacy enforcement. At the same time, the architecture provides flexibility to allow evolution in the services that may be provided by endpoints and the network. DCS also takes into account the need to manage access to network resources and account for resource usage. The SIP usage rules defined in the accompanying IDs specifically address the coordination between Distributed Call Signaling and dynamic quality of service control mechanisms for managing resources over the access network. In addition, the DCS architecture defines the interaction needed between network provided call controllers, known as a 'DCS- proxy' for supporting these services. "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", Warren Marshall, Flemming Andreasen, 06-Mar-03, In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the architecture described in 'Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms' (RFCXXXX) (Note: replace with RFC number of draft- dcsgroup-sipping-arch). The use of the extensions is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. "application/xenc+xml Media Type Registration", Joseph Reagle, 17-Sep-02, This document describes a media type (application/xenc+xml) for use with the XML Encryption specification. "Control Channel Bootstrap for Link Management Protocol", Jonathan Lang, John Drake, Dimitri Papadimitriou, 05-Mar-03, The Link Management Protocol (LMP) requires that a bi-directional control channel is established to form an LMP adjacency. The control channel may be transmitted either in-band with the data links or out-of-band over a separate wavelength, fiber, or IP network. This draft specifies a simple procedure to dynamically bootstrap LMP control channels and exchange interface mappings using a new LMP message that is transmitted in-band over the data links. This memo also details how this mechanism is used in implementing Layer Adjacency Discovery as described in [G.7714.1]. "Japanese characters in Internationalized Domain Name labels", Yoshiro Yoneya, 06-Nov-02, Internationalized Domain Name (IDN) makes expression of domain name rich. The demand for such enrichment is to use native language characters in a domain name. IDN itself has no locale dependency as a protocol, but to utilize IDN in the real world, language and/or regional aspects should be taken into account. This document explains a guideline to any IDN zone administrator who accepts Japanese as an IDN label. "HighSpeed TCP for Large Congestion Windows", Sally Floyd, 20-Feb-03, This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packet (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community "Dynamic Hostname Exchange Mechanism for OSPF", Venkata Naidu, Sanjay Harwani, 06-Feb-03, Currently, there does not exist a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like ISIS. This document defines a new Area Scope and AS Scope Opaque LSAs which allows the OSPF routers to flood their name to Router ID mapping information across the OSPF network. "Fault Notification Protocol for GMPLS-Based Recovery", Richard Rabbat, 20-Jun-03, This draft presents a fault notification protocol that is implementation-agnostic to be used in a GMPLS-based failure recovery scheme. The protocol achieves bounded recovery path activation times in the event of single resource failures. This is done by allowing for the computation of constrained recovery paths that take into account the physical capabilities of the nodes as well as the delay characteristics of the control plane. We propose using a flooding protocol for fault notification to allow for per-failure notification and to speed up the recovery process, and justify choices made for the notification method and for the extensions required to current protocols. "Registration of HTTP header fields", Mark Nottingham, 13-Jun-02, This document defines the initial IANA registration for some HTTP message header fields. Discussion of this document Please send comments to . To subscribe to this list, send a message with the subject'subscribe' to . "The 'enum:' URI scheme", Rudolf Brandner, Lawrence Conroy, Richard Stastny, 21-Feb-03, This document specifies the enum: URI scheme. This URI is intended for use where a resource address can be returned by evaluating the URI value using the ENUM DDDS application. Syntactically, it uses a subset of the format defined for the tel: URI scheme. "Applicability of LMP (and LMP-WDM)", Dimitri Papadimitriou, 05-Nov-02, Integration of Generalized MPLS-capable SONET/SDH networks in existing backbone environments has generated the need to determine inter-working capabilities between nodes interconnected by both SONET/SDH and non-SONET/SDH overhead terminating networks. This is particularly the case for critical functions and applications such as the ones provided by the Link Management Protocol [LMP] and its WDM extensions [LMP-WDM]. In this context, this document describes the applicability of their respective functions and illustrates them through several inter-connection architectures. "A Structural Object Class for Arbitrary Auxiliary Object Classes", Luke Howard, 02-Jun-03, The Lightweight Directory Access Protocol (LDAP) supports auxiliary object classes for adding additional attributes to a directory entry. This document defines a structural object class that may be used when no other structural object class is available. "Optimized Packet Structure for HIP", Petri Jokela, 04-Nov-02, This memo describes alternative, optimized packet structures for the Host Identity Payload and Host Layer Protocol (HIP). The packet structures presented in this memo are intended replace original packets in HIP. In addition, this memo describes a new packet, CER, to transmit certificates. The main objective in redefining HIP packet structures is to make the packet structures simpler and more distinct, which makes the implementation work easier, hopefully leading to more secure protocol implementation. The new structures reduce the average packet size and take advantage of other existing IPv6 protocols formats, including alignments concerns, like the newly suggested Mobility header format for Mobile IPv6. "Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)", Maximilian Riegel, 18-Dec-02, This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits. "IPv6 Reverse Routing Header and its application to Mobile Networks", Pascal Thubert, Marco Molteni, 27-Jun-03, Already existing proposals enable Mobile Networks by extending Mobile IP to support Mobile Routers. In order to enable nested Mobile Networks, some involve the overhead of nested tunnels between the Mobile Routers and their Home Agents. This proposal allows the building of a nested Mobile Network avoiding the nested tunnel overhead. This is accomplished by using a new routing header, called the reverse routing header, and by overlaying a layer 3 tree topology on the evolving Mobile Network. "Guidelines for Mobile IP and IPSec VPN Usage", Serge Tessier, 02-Dec-02, This document highlights some of the issues that should be considered when IPSec [2] and Mobile IP [3] inter-work with each other. This work finds some applications in the following fields: VPN traversal requirement [4], IPSec Remote access client co-located with a Mobile Node, IPSec security Gateway running in parallel with a Home Agent or a MIP Proxy [5]. The purpose of this document is informational. Rather that strictly indicating how both protocol should take advantages of each other (IPSec running on top of Mobile IP or the other way around), which is a subjective task left to the user and implementation developers of both protocol, it rather proposes some usage guidelines and general considerations regarding the preference of one solution over the other one. "IPv6 Transition Solutions for 3GPP Networks", Juha Wiljakka, 04-Nov-02, This document describes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. "Protocol Actions for RFC2547bis", Eric Rosen, 06-Feb-03, The purpose of this document is to list all the protocol changes specified in [rfc2547bis] and related drafts which might be regaded to require approval or other action by IETF WGs other than the PPVPN WG. This document is for temporary administrative purposes only, and does not itself specify a protocol or an architecture. "An IP Traffic Engineering PIB for Accounting purposes", Mohammed Boucadair, 17-Jun-03, This document defines a set of IP Traffic Engineering Policy Provisioning Classes (PRCs) for accounting usage within the context of a COPS-based policy enforcement scheme. The purpose of those PRCs is to provide information exploitable by the IP Traffic Engineering decision-making process. Those PRCs are intended for use by the reporting process of the IP TE Client-Type [2]. "Synchronization operations for disconnected IMAP4 clients", Alexey Melnikov, 16-Oct-02, This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the 'driver' portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy. This note describes different strategies that can be used by disconnected clients as well as shows how to use IMAP protocol in order to minimize the time of synchronization process. "Hop-by-Hop Local Mobility Agents Probing for Mobile IPv6", Vrizlynn Thing, 09-Oct-02, This document introduces an extension to Mobile IPv6 to provide support for Localized Mobility Management. This proposed Hop-by-Hop Local Mobility Agents Probing scheme specifies the Local Mobility Agents Discovery, Selection and Failure Detection architecture and procedures for deploying the localized mobility management, whereby the Local Mobility Agents are distributed. It reduces the amount of signalling to the home agent and correspondent nodes when mobile node moves among the subnets of the visited domain "Signaling Reverse-directional LSP in Generalized MPLS", Nobuaki Matsuura, Eiji Oki, 03-Mar-03, This document defines an extension to Generalized MPLS signaling procedure to support the establishment of reverse-directional LSPs. Reverse-directional LSPs can be signaled by 'one-way' signaling. "Relialeble Serverpool applicability statement", Lode Coene, 07-Mar-03, This document describes the applicability of the reliable server pool architecture and protocols to applications which want to have High avialebility services. This is accomplished by using redundant servers and failover between servers of the same pool in case of server failure. Processing load in a pool may de distributed/shared between the members of the pool according to a certain policy. Also some guidance is given on the choice of underlying transport protocol (and corresponding transport protocol mapping) for transporting application data and Rserpool specific control data. "Registration of common IMAP keywords", Alexey Melnikov, John Neystadt, 30-Jun-03, The aim of this document is to document some common [IMAP4] keywords for the purpose of improving interoperability between different IMAP mail clients. The document both documents some keywords already in use, as well as introduces several new ones. "IPPM measurement signature", Emile Stephan, 04-Nov-02, Despite the growing availability of good measurement platforms, it is still impossible to generalize IPPM metrics measurement among heterogeneous points of measure. To do so, the extra information inserted in the IP packets to perform the measurement has to be standardized. This document defines an IPPM measurement signature suitable for performing the measure of the current IPPM metrics, for integrating those used by manufacturers and for allowing the IPPM WG to define other measurement signature in the future. "JXTA v1.0 Protocols Specification", Michael Duigou, 04-Mar-03, The JXTA protocols defines a suite of six XML-based protocols that standardize the manner in which peers self-organize into peergroups, publish and discover peer resources, communicate, and monitor each other. The Endpoint Routing Protocol (ERP) is the protocol by which a peer can discover a route (sequence of hops) to send a message to another peer potentially traversing firewalls and NATs. The Rendezvous Protocol (RVP) is used for propagating a message within a peergroup. The Peer Resolver Protocol (PRP) is the protocol used to send a generic query to one or more peers, and receive a response (or multiple responses) to the query. The Peer Discovery Protocol (PDP) is used to publish and discover resource advertisements. The Peer Information Protocol (PIP) is the protocol by a which a peer may obtain status information about another peers. The Pipe Binding Protocol (PBP) is the protocol by which a peer can establish a virtual communication channel or pipe between one or more peers. The JXTA protocols permit the establishment a virtual network overlay on top of physical networks allowing peers to directly interact and organize independently of their network location and connectivity. The JXTA protocols have been designed to be easily implemented on unidirectional links and asymmetric transports. "SIP endpoint service charging requirements", Wolfgang Beck, 20-Dec-02, Today, a SIP user wanting to charge for a service needs to establish an agreement with all prospective callers. This administrative overhead can be avoided if caller and callee can prove the duration and existence of a call in case of a dispute. The draft describes requirements for protocols and SIP extension that can be used to implement such functionality. "A Survey of Authentication Mechanisms", Eric Rescorla, 06-Mar-03, Authentication is perhaps the most basic security problem for design- ers of network protocols. Even the early Internet protocols such as TELNET and FTP, which provided no other security services, made pro- vision for user authentication. Unfortunately, these early authenti- cation systems were wholly inadequate for the Internet Threat Model [REF] and a vast array of other authentication mechanisms have been introduced in an attempt to close these holes. The most striking thing about these security mechanisms is how many of them are essentially similar. There are only 7 basic classes of authentication protocol but there are a large number of slightly dif- ferent protocols with essentially the same security properties. This memo surveys the space of authentication mechanisms, describes the basic classes and provides examples of protocols which fit into each class. "Address Allocation for PE-CE links within an RFC2547bis Network", Jim Guichard, 10-Apr-03, This document proposes to allocate a block of globally unique IPv4 addresses for the exclusive use of Service Providers that provide [L3VPN] based Services. The Service Provider may use these addresses for the provisioning of IP addresses to the links that connect Customer Edge (CE) routers with Provider Edge (PE) routers (PE-CE links), and/or for the IP addressing of attached CE routers. The main motivation for this proposal is to simplify the Service Providers' operations in the scenario where they monitor PE-CE links, and/or CE-routers, while at the same time conserving IPv4 address space. This addressing scheme is not intended for use by VPNs that span more than one Service Provider, unless co-operation of addressing structure is maintained to ensure uniqueness of addresses between providers. Furthermore, although the main reference within this draft is related to services provided by [L3VPN], the recommendations formulated herein may also apply to other Layer-2 or Layer-3 VPN architectures. "ForCES Forwarding Element Functional Model", Lily Yang, 05-Nov-02, This document defines a functional model for forwarding elements (FEs) used in the Forwarding and Control Plane Separation (ForCES) protocol. This model is used to describe the capabilities and state of ForCES forwarding elements within the context of the ForCES protocol, so that ForCES control elements (CEs) can control the FEs accordingly. The model is to specify what logical functions are present in the FEs, what capabilities these functions support, and in what order these functions are or can be performed. The forwarding element model defined herein is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. Using this model, predefined or vendor specific logical functions can be expressed and configured. However, the definition of these individual functions are not described and defined in this document. "Service Requirements for Optical Virtual Private Networks", Hamid Ould-Brahim, 18-Dec-02, This document addresses service requirements for provider provisioned optical virtual private network The intent of this document is to include the OVPN work as part of PPVPN charter. A VPN service model based on optical connectivity has a lot of functional elements in common with other models already chartered in PPVPN. Inclusion of this topic in the charter will facilitate convergence and maximize reusability of common techniques to provide VPN service functions independently of the VPN connectivity level. That is also a global objective of the PPVPN standardization effort. "Link-layer Triggers Protocol", Alper Yegin, 10-Jun-03, Wireless and mobile hosts are subject to changing their point of attachment from one access network to another. These changes result in link-layer events such as link up and link down. Information on these events can be conveyed to interested parties in the form of link-layer triggers. Primary consumers of this information are the modules implementing mobility related network-layer protocols. When provider and consumer of this information are co-located on the same IP node, required communication can take place via internal mechanisms. But when they are separate, as in the case of networks using wired-to-wireless bridges, a transport mechanism is needed to convey link-layer triggers. This draft defines a UDP based client- server protocol for transporting link-layer triggers between two IP nodes. "Enhanced Forwarding From Previous Care-of Address For Fast Mobile IPv6 Handovers (eFWD)", Youngjune Gwon, Alper Yegin, 21-Jan-03, This memo introduces a low latency and low loss handover protocol that enhances the performance of forwarding from previous care-of address for Mobile IPv6, namely eFWD. The eFWD allows a mobile node to control and initiate creation of a bi-directional tunnel between the old and the new access routers subsequent to link layer handover. The eFWD handover reduces IP handover latency by eliminating new care-of address acquisition time and by identifying new access router information in advance utilizing Candidate Access Router Information Discovery (CARID) process detailed in this memo. The eFWD protocol removes extra burden on link layer by eliminating any requirement on pre-triggers. "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Waldemar Augustyn, Yetik Serbest, 19-Feb-03, This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint to multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. "L2TP Call Information Messages", Thomas Mistretta, 05-Nov-02, This document defines additional L2TP AVPs to communicate informational ASCII text messages between the tunnel endpoints during call establishment. The message contents are not interpreted by the receiving endpoint in any way but can be used for logging or debugging purposes. "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", Francis Dupont, Jean-Jacques Bernard, 06-Jan-03, When a 'NAT traversal' capability is added to a class of signaling protocols which can control some traffic aggregation points, an attack based on a temporary access to the path followed by messages exists. Mobile IP [1] with NAT traversal [5] or IKE [2] with NAT traversal [6], including the IKEv2 [7] proposal, are potentially affected by this kind of attacks. This document claims this vulnerability is an intrinsic property of the NAT traversal capability, so is another point where the usage of NATs is very damaging. "Transition Scenarios for ISP Networks", Cleveland Mickles, 06-Mar-03, This document describes the different types of Internet Service Provider (ISP) networks in existence today. It will provide design and operational considerations in delivering network services to customers for five specific areas in an effort to better identify specific issues which may arise during a transition to IPv6. "Testing Hierarchical Virtual Private LAN Services", Olen Stokes, 20-Dec-02, This document describes a methodology for testing the operation, administration and maintenance (OA&M) of a general VPN service, that is applied here to Hierarchical Virtual Private LAN Services (HVPLS) as described in [VPLS]. As part of this methodology, the MPLS ping concepts described in [LSP- PING] are extended to enable HVPLS spoke-to-spoke connectivity testing. A method to provide the information necessary for this spoke-to-spoke OA&M is also proposed. These are the goals of this draft: - checking connectivity between 'service-aware' nodes of a network, - verifying data plane and control plane integrity, - verifying service membership There are two specific requirements to which we call attention because of their seemingly contradictory nature: - the checking of connectivity MUST involve the ability to use packets that look like customer packets - the OAM packets MUST not propagate beyond the boundary of the provider network "Network Management for GSMP Interface", Younguk Cha, 07-Nov-02, General switch management protocol (GSMP) is an open interface between a label switch and a controller, and it provides connection, configuration, event, performance management and synchronization. The managed objects of RFC 3295 are only defined to configure, monitor and maintain the protocol entity. Traditionally, network management services are classified into five categories: those are configuration, performance, fault, accounting, and security management. These services are provided by the network management functions, which can be located either in the controller or in the label switch. In the GSMP interface, there are no managed objects for the network management services and the location of network management functions is not clearly defined. We discussed the complexity of switch implementation and the efficiency of resource usage according to the location of network management functions. "Internet Unified Messaging Requirements to Support Diverse Clients", J Wong, Glenn Parsons, 06-Mar-03, The goal of Internet Unified Messaging is to provide, over the Internet, a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of his or her messages from a collection of clients with varying capabilities, no matter what the media or source is. Towards this goal, this document considers what is required of Internet messaging protocols to enable the support of Unified Messaging on two new classes of limited capability messaging clients: those limited to having a telephone user interface (TUI) and those that can be supported by small hand-held wireless devices with simple displays such as cell phones with data features and wireless-enabled PDAs (WUI). Included in the discussion is also a list of general principles to guide the design of Unified Messaging protocols. Discussion of this and related drafts are on the UM list. To subscribe, send the message 'subscribe um' to majordomo@snowshore.com. The public archive is at http://flyingfox.snowshore.com/um_archive/maillist.html. "Anonymous SASL Mechanism", Kurt Zeilenga, 06-Nov-02, It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. "Securing MIPv6 Binding Updates Using Address Based Keys (ABKs)", Satomi Okazaki, 04-Oct-02, This document outlines a method for authenticating and authorizing Mobile IPv6 [MIPv6] Binding Updates between a Correspondent Node and a Mobile Node where there exists no pre-established direct or indirect security relationship between those two entities. The method uses a new security technique called Address Based Keys. Address Based Keys are an alternative to other cryptographic address mechanisms for optimizing Binding Update security to avoid the need for Return Routability checks on each binding update. Address Based Keys use some mathematical results in identity based cryptosystems that have been known to cryptographers for some time, but have not been widely discussed in the network security community. "Extensions to IS-IS and OSPF for Advertising Optinal Router Capabilities", Acee Lindem, 05-Nov-02, It is useful for routers in a domain to know of the capabilities of their IGP neighbors, and/or of other routers in the domain. This draft proposes extensions to IS-IS and OSPF for advertising optional router capabilities. We define an optional Router Capability TLV for IS-IS, while for OSPF we define an optional Router Information Opaque LSA. "SIMPLE Presence Publication Mechanism", Ben Campbell, 03-Mar-03, This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. "Sieve -- 'body' extension", Jutta Degener, 03-Feb-03, This document defines a new primitive for the 'sieve' language that tests for the occurrence of one or more strings in the body of an e-mail message. "Plain SASL Mechanism", Kurt Zeilenga, 06-Nov-02, This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. "Requirements for Presence Service in 3GPP Wireless Systems", Krisztian Kiss, 07-Mar-03, This Internet-Draft defines requirements for Presence Service in 3GPP wireless systems. "Framework for QoS in Provider-Provisioned VPNs", Fabio Chiussi, 06-Mar-03, This document defines the QoS framework for Layer 2 and Layer 3 provider-provisioned VPNs. The scope of this document includes MPLS, IPSec, GRE, and L2TP VPNs. This document focuses on the QoS aspects that are specific of PPVPNs, and discusses issues pertaining to Service Level Agreements, provisioning, resource allocation, signaling, and protection/restoration. Both non-hierarchical and hierarchical VPN’s are addressed "A NAT package for MGCP NAT traversal", Cedric Aoun, Martin Wakley, Tania Sassenberg, 04-Mar-03, Network Address translators impact several application protocols in the internet; this document discusses how the MGCP protocol could work through NATs. Only the signaling protocol message traversal is discussed in this version of the document. The VoIP streams NAT traversal are already documented and researched within the MIDCOM WG. "Analysis on RSVP Regarding Multicast", Xiaoming Fu, Cornelia Kappler, Hannes Tschofenig, 25-Oct-02, RSVP version 1 has been designed for optimum support multicast. However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported in the generic RSVP signaling protocol and adapt related functionalities accordingly - we call the resulting feature set 'RSVP Lite', a potentially more light-weight version of RSVP. "Extended RSVP-TE for Multicast LSP Tunnels", Seisho Yasukawa, 04-Nov-02, Multicast technology will become increasingly important with the dissemination of new applications such as contents delivery services and video conferences, which require much more bandwidth and stricter QoS than conventional applications. From the service providers' perspective, traffic engineering (TE) functions will be needed to handle the large amount of multicast traffic. This document defines some protocol extensions to the existing RSVP- TE[1] in order to establish a multicast label switched path (LSP). The use of label switching routers (LSRs) with these protocol extensions defined in this document allows service providers to offer unicast and multicast multiprotocol label switching (MPLS) services in the same service network. This protocol assumes a variable LSP topology, e.g., point-to- multipoint, multipoint-to-multipoint, topologies. This document describes how to establish point-to-multipoint and multipoint-to- multipoint LSPs as the most basic multicast topology. It defines two ways of constructing a point-to-multipoint LSP: sender-initiated LSP setup and leaf-initiated LSP setup. Each method has an LSP modification function in order to adapt to dynamic changes in the LSP tree topology. This MPLS architecture[10] is very flexible and can be expanded to carry protocols other than IP multicasting, e.g., Ethernet, PPP, and SONET/SDH, but this document only defines IP multicasting (IPv4 and IPv6) as a forwarding equivalence class object (FEC). "Pseudowires and L2TPv3", W. Mark Townsley, 17-Jun-03, This document provides an overview of the Layer 2 Tunneling Protocol (L2TPv3), presented in a manner which highlights its applicability for Pseudo Wire Emulation Edge to Edge (PWE3). It is intended as a guide for architects, new implementers, and those adding functionality to L2TPv3 in support of new pseudowire types. "ISATAP Transition Scenario for Enterprise/Managed Networks", Fred Templin, 05-Nov-02, This document discusses application of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) as a transition tool for enterprise/managed networks. The enterprise/manged network problem space is described, and the ISATAP transition scenario for enterprise/managed network environments is presented. "MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection", Jean Vasseur, 05-Mar-03, This draft proposes an efficient model called ''Facility based computation model'' for computing bypass tunnels paths in the context of the MPLS TE Fast Reroute, while allowing bandwidth sharing between backup tunnel protecting independent resources. Both a centralized and a distributed path computation scenarios are described. The required signaling extensions are also addressed in the draft. "Framework for PPVPN Operation and Management", Yacine Mghazli, Arnaud Gonguet, Thomas Nadeau, 16-Jun-03, This document provides a framework for Provider Provisioned Virtual Private Networks (PPVPNs) operation and management. This framework intends to produce a coherent description of the significant technical issues which are important in the design of PPVPN management solution. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. "CE-based Virtual Private LAN", C.J. Lee, Mitsuru Higashiyama, 07-Mar-03, This draft describes how a Virtual Private LAN (VPL) can be realized by setting up point-to-point tunnels from CE (Customer Edge) or CLE (Customer Located Equipment) to CE/CLE over a PSN, and bridging Ethernet traffic at the CE/CLE. Regardless of the access technology used (e.g. DSL or Ethernet) or the geographic distribution of CEs/CLEs, an end customer may use an emulated LAN service via an Ethernet interface, as long as the CEs/CLEs of the emulated LAN are reachable over the PSN. When used in conjunction with IPSec, the proposal allows secure transmission of Ethernet traffic, from one site to another site of a VPL, over the PSN. "Mobile IPv6 VPN using Gateway Home Agent", Hiroyiki Ohnishi, Katsunori Suzuki, Yasushi Takagi, 06-Nov-02, Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. It can also be used for public mobility services. One of the most important services is the VPN service enabling users to access their Intranets from outside. Mobile IP does not work well with VPN, however, and this issue is being discussed in the Mobile IP WG [VPN problem]. This document proposes a simple mechanism that combines VPN and Mobile IP functions. This mechanism uses a hierarchical HA architecture and includes an HA with GW functions, called a Gateway Home Agent (GHA). "Path-coupled and Path-decoupled Signaling for NSIS", Alban Couturier, Olov Schelen, 07-Nov-02, The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches for a signaling model have been discussed: path-coupled and path-decoupled (previously denoted as on-path and off-path). This draft provides a conceptual comparison between path-coupled and path-decoupled signaling together with reasons for why an NSIS protocol should be designed to support both cases. The collection of data objects to be carried by the protocol should basically be the same in both cases and will evolve over time as new usages for NSIS protocol are identified. The differences between the two flavors of this NSIS protocol are then explained. "A Lower Effort Per-Domain Behavior for Differentiated Services", Roland Bless, 21-Nov-02, This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be 'starved' (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's 'best-effort' or 'normal Internet traffic' model where prolonged starvation indicates network problems. In this sense the proposed PDB's traffic is forwarded with a 'lower' priority than the normal 'best-effort' Internet traffic, thus the PDB is called 'Lower Effort' (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on 'best- effort'/'normal' or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. "A Requirement of the Network State Information Database for Traffic Engineering Over GMPLS", Dae Young Kim, 04-Nov-02, This document presents a set of requirements of the Network State Information Database (NSID) for Traffic Engineering over Generalized Multiprotocol Label Switching (GMPLS) in the view of service providers. The Network State Information Database is required to implement the network architecture for network models that introduce the control element of IP and to optimize the utilization of network resources. And this document includes discussion about the considerations and necessity of the several attributes to construct NSID for Traffic Engineering over GMPLS that are extended from the requirement for Traffic Engineering over MPLS [4]. These attributes can be used to maximize the utilization of network resources and to enhance resource oriented Traffic Engineering techniques. "Considerations for Intellectual Property Rights in IETF Standards", Maximilian Riegel, 07-Mar-03, Intellectual Property Rights (IPR), in particular patents are important for standards development organizations (SDOs). A patent grants a monopoly to the owner to control the usage of the covered technology. If such a technology is becoming part of a standard the patent owner can arbitrarily restrict the usage of the standard. Therefore all SDOs are concerned about patents in their standards. This memo focuses on practices the IETF may apply to cope with patent rights in its standards. The proposal is based on the idea of open standards and is fully aligned to the current IPR rules of the IETF. The intention is to retain the mind of the IETF while enabling the consideration of IPR covered proposals in a defined way. "Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation", Wai Lai, 27-Jun-03, The Diffserv-aware MPLS Traffic Engineering Requirements RFCxxxx specifies the requirements and selection criteria for bandwidth constraints models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFCxxxx by describing in more details some of the selection criteria and their implications. Results of a performance evaluation of the two models are also included. "HMAC SHA TSIG Algorithm Identifiers", Donald Eastlake 3rd, 08-Jan-03, Currently only the HMAC-MD5 and GSS TSIG Algorithm identifiers are specified. This document specifies identifiers for additional HMAC SHA TSIG algorithms. "Securing IPv6 Neighbor Discovery", Gabriel Montenegro, 07-Mar-03, The known security vulnerabilities in Neighbor Discovery have not been properly dealt with. This note suggests some techniques based on cryptographically generated addresses and probes that may be applied even in the absence of a pre-established security relationship between the parties involved. "SigComp User Guide", Richard Price, Abigail Surtees, Mark West, 15-May-03, This document provides an informational guide for users of the SigComp protocol. The aim of the document is to assist users when making SigComp implementation decisions; for example the choice of compression algorithm and the level of robustness against lost or misordered packets. "MIME Type Registration for MPEG-4", Yuen Lim, David Singer, 06-Nov-02, This document defines the standard MIME types associated with MP4 files and various MPEG-4 streams. This also document recommended use of registered MIME types. according to the type of contents. "Network Measurement and Monitoring : A Sprint Perspective", Supratik Bhattacharyya, 06-Mar-03, This document provides an overview of network measurements and monitoring from the perspective of Sprint Advanced Technology Labs. It starts with a detailed discussion of the benefits of monitoring for an ISP's backbone and the type of measurements required for various tasks. It describes the tools and techniques currently in use, and then outlines what else is needed to meet the challenges of monitoring an operational network. "Quick-Start for TCP and IP", Amit Jain, Sally Floyd, 06-Nov-02, This draft outlines an optional Quick-Start mechanism for transport protocols to determine an optional allowed initial congestion window or initial sending rate at the start of a data transfer. This mechanism is designed to be used by a range of transport protocols; however, in this document we only describe its use with TCP and IPv4. By using Quick-Start, a TCP host, say, host A, would indicate its desired initial sending rate in packets per second in a Quick Start Request option in the IP header of the initial TCP SYN or SYN/ACK packet. Each router in turn could either approve the specified initial rate, reduce the specified initial rate, or indicate that nothing above the default initial rate for that protocol would be allowed. The Quick-Start mechanism also can determine if there are routers along the path that do not understand the Quick Start Request option, or have not agreed to the initial rate described in the option. TCP host B communicates the final initial rate to TCP host A in a transport-level Quick-Start Response in the answering SYN/ACK or ACK packet. Quick-Start is designed to allow TCP connections to use high initial windows in circumstances when there is significant unused bandwidth along the path, and all of the routers along the path support the Quick-Start Request. This proposal is a request for feedback from the community. "Unmanaged Networks Transition Scope", Christian Huitema, 07-Nov-02, In order to evaluate the suitability of transition mechanisms, we need to define the environment or scope in which these mechanisms have to be used. One specific scope is the 'unmanaged networks', which typically correspond to home networks or small office networks. "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Pasi Sarolahti, Markku Kojo, 03-Jun-03, Spurious retransmission timeouts (RTOs) cause suboptimal TCP performance, because they often result in unnecessary retransmission of the last window of data. This document describes the 'Forward RTO Recovery' (F-RTO) algorithm for detecting spurious TCP RTOs. F-RTO is a TCP sender only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by an RTO, the F-RTO algorithm at a TCP sender monitors the incoming acknowledgements to determine whether the timeout was spurious and to decide whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in case of a spurious timeout. "MIB Table Modifications Tracking MIB", Niraj Gopal, 23-Dec-02, 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 management objects used for tracking the modifications in MIB tables on a system. "Configuring BGP to Block Denial-of-Service Attacks", Doughan Turk, 20-Jan-03, This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black- holing can be applied on a selection of routers rather than all BGP- speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. "URI Fragment Identifiers for the text/plain Media Type", Erik Wilde, 07-Apr-03, This memo defines URI fragment identifiers for text/plain resources. These fragment identifiers make it possible to refer to parts of a text resource, identified by character count or range, line count or range, or a regular expression. These identification methods can be combined to identify more than one sub-resource of a text/plain resource. "SIEVE Spamtest and Virustest Extensions", Cyrus Daboo, 10-Apr-03, The SIEVE [SIEVE] 'spamtest' and 'virustest' extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. "Basic Transition Mechanisms for IPv6 Hosts and Routers", Erik Nordmark, Robert Gilligan, 07-Nov-02, This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. "IFAX service of ENUM", Kiyoshi Toyoda, Dave Crocker, 24-Jul-02, This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is 'Facsimile using Internet Mail'. For this use, the DNS returns the email address of the referenced IFax system. "Congestion safety and Content Indirection", Hisham Khartabil, 07-Mar-03, The Content-Indirection service has many uses. This document describes this service by combining congestion safely and Content- Indirection Mechanism into the one document and presents scenarios where the 2 could be combined. It also introduces extensions to SIP that allows end points to specify their maximum acceptable message size. "A Proposal for ICMP 'Authentication Required' Messages", Avinash Lakhiani, Shawn Ostermann, 08-Oct-02, The current ICMP 'Destination Unreachable - Communication Administratively Prohibited' message conveys one bit of information: the gateway is administratively filtering your packets. This memo proposes the addition of an ICMP 'Authentication Required' response to provide the more specific message that packets are being administratively prohibited until successful authentication. "Counter with CBC-MAC (CCM)", Doug Whiting, Russell Housley, Nicky Ferguson, 21-Feb-03, Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as AES. "Architecture, Model and Requirements for Operations and Maintenance (Testability) of Virtual Private Networks AND Application Level VPN Testability Solution", Tissa Senevirathne, Lior Shabtay, 29-Oct-02, In this document we present Architecture, Model, and Requirements for Operation and Maintenance of Virtual Private Networks (VPN). Operation and Maintenance of VPN is divided into Application Level VPN testability, Technology dependent VPN testability, and Technology specific VPN testability. This document presents a solution for Application level VPN Operation and Maintenance (Testability). "Guidelines for MPLS Load Balancing", David Allan, 15-Apr-03, RFC 3031 permits MPLS load balancing while making no specific representations as to implementation requirements. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorithms may separate path test probes from the path of interest. This document proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. "IANA Charset MIB", Ira McDonald, 11-Feb-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is [intended to become] an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (work-in-progress). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are in accordance with the IANA Charset Registration Procedures (RFC 2978). "Internationalized String Matching Rules for X.500", Kurt Zeilenga, 07-Mar-03, The existing X.500 Directory Service technical specifications do not precisely define how string matching is to be performed. This has lead to a number of interoperability problems. This document provides string preparation profiles for standard syntaxes and matching rules defined in X.520. "Generalized MPLS Recovery Functional Specification", Jonathan Lang, Bala Rajagopalan, Jonathan Lang, 07-Nov-02, This document presents a functional description of the protocol extensions needed to support GMPLS-based recovery. Protocol specific formats and mechanisms will be described in companion documents. "Requirements for Floor Control", Petri Koskelainen, Henning Schulzrinne, Joerg Ott, 04-Nov-02, This document defines the requirements for floor control. "Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking Tool", Marcus Leech, 13-Feb-03, This document revisits the so-called Chinese Lottery massively- parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences. "A method for storing IPsec keying material in DNS", Michael Richardson, 25-Feb-03, This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been proposed to be obsoleted by [1]. "IANA Registration of MIME types and SDP parameters in proposed ITU Recommendation V.150.1", Rajesh Kumar, 04-Nov-02, This document defines a framework for the IANA registration of MIME types and SDP parameters defined in the ITU V.150.1 recommendation. For SDP parameters,it does not repeat the details of syntax and semantics found in the ITU recommendation. For the MIME types, it provides RFC 2048-compliant MIME definitions which refer to the ITU V.150.1 recommendation for detailed format description. Until the ITU V.150.1 recommendation is ratified, this document should be considered work in progress. "IANA Registration of parameters and MIME types in proposed ITU Recommendation V.150", Rajesh Kumar, 26-Aug-02, This document defines a framework and basis for the IANA registration of parameters defined in the ITU V.150 recommendation, which addresses the transmission of modem signals over IP. This includes both modem passthrough and modem relay operation. As a framework document, this internet draft leaves the details of the modem-over-IP (MoIP) protocols and formats to the ITU V.150 recommendation. Since the V.150 recommendation is work in progress by ITU SG16/Q11, registration of these parameters is contingent upon its impending ratification. Although these parameters are meant for use in text-based control protocols such as SDP, equivalent reformulations are planned for non-text protocols such as ITU H.245. "Measures to prevent security attacks in TCP/IP", M Dattathrani, 21-Feb-03, The security problems in the internet are due to inherent problems in the TCP/IP stack. The purpose of this draft is to brief on some of the measures to prevent security attacks in TCP/IP network, by changing some of the ways in which the TCP/IP protocol stack works. The security attacks which are addressed in this draft are: 1) ARP(Address Resolution Protocol) spoofing and MAC address cloning 2) TCP Initial sequence number prediction This version offers backward compatibility with cards that do not support the security features mentioned in this draft. In view of this, changes have been made to section 2.3 and a new section (Section 2.4) has been added. "BGP Sessions Protection via MD5 Authentication", Hu Chunzhe, 27-Aug-02, This draft describes a BGP Extension to protect the route information on the basis of authentication on the BGP message between BGP speakers,In this mechanism,an addtional Capabilty option(Authentication Code) and random number used for authentication are added to OPEN message,and the Authentication Capability is negotiated between BGP speakers,when they pass the negotiation and setup the Established relationship, all the successive message will be authenticated using MD5 algorithm,with the Marker field in the BGP message substituted with the MD5 digest of the combination including message body.This mechanism can guard against that the BGP message be intercepted and tampered by the attacker. "SNMP Extended Capability Negotiation", David Shield, 27-Aug-02, This draft discusses mechanisms for supporting future changes to the functionality and behaviour of SNMP, without needing to introduce new versions of the protocol, or completely new protocol operations. It defines a Management Information Base (MIB) for advertising support for various extensions to traditional SNMP protocol capabilities, and proposes a mechanism for negotiating the use of such extensions on a per-request basis. "Reliable Streaming Internet Protocol Detail Records", Jeff Meyer, 27-Aug-02, This memo defines a mechanism to deliver streams of network usage information which follow the Internet Protocol Detail Records (IPDR) format. This format provides an extensible means to exchange usage information between systems. The model of extension is based on the use of a subset of the XML Schema specification language, in conjunction with a well defined mapping to a binary format based on the eXtensible Data Record (XDR). "IMAP4rev1 QUOTA Extension", Dave Cridland, Alexey Melnikov, 27-Aug-02, The QUOTA extension of the Internet Message Access Protocol IMAP4 [2] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo replaces RFC2087 [4], but attempts to remain backwards compatible whenever possible. "Requirement for Analysis of SIP Paths", Arjun Roychowdhury, 27-Aug-02, There is no defined mechanism today by which SIP proxies can insert path related information in a SIP message that is being routed across a network. As an example, a network administrator may want to trace the path as a SIP message traverses across her network to detect failure points. As another example, a user may want to discover capabilities of servers in the path of a call. Although there is an informal mention of using the OPTIONS method to achieve the latter example [1], there is no defined way to achieve the same today. "The Geographic Position Option for DHCP", Sam Critchley, 27-Aug-02, This document describes a DHCP option in which the geographic position of the DHCP server is passed to the DHCP client in order to allow the client to make use of Location-Based Services. "Sampling Techniques for Packet Selection", Tanja Zseby, 28-Aug-02, This document describes the deployment of sampling techniques for packet selection. It suggests some terminology and shows different sampling methods for selecting a subset of packets in a flow. Furthermore it describes which parameters can be varied for the different sampling methods. "IPv4-Mapped Addresses on the Wire Considered Harmful", Christopher Metz, Jun-ichiro Hagino, 30-Oct-02, The IPv6 Addressing Architecture [Hinden, 1998] defines the 'IPv4-mapped IPv6 address.' These addresses are used in the IPv6 basic API [Gilligan, 1999] to denote IPv4 addresses using AF_INET6 sockets. These addresses are used in protocol proposals such as SIIT [Nordmark, 2000] to denote IPv6 communication using AF_INET6 sockets. Therefore, IPv4-mapped addresses have two different meanings, and they are not distinguishable from the user-land applications. This draft discusses security threats due to this ambiguity of IPv4-mapped address. It also discusses threats due to the additional complexities introduced by IPv4-mapped addresses. Finally, it proposes to resolve these problems by forbidding protocols from using IPv4-mapped addresses for IPv6 communications. "Standardized caching of dynamic web content", Brent Baccala, 28-Aug-02, Summarizes the present state of web caching technology. Points out the need for caching dynamic web sites, and the inadequacy of present caching technology for anything but static sites. Proposes the adoption of Java servlets, cryptographically signed Web Application Archives (WARs), and LDAP as standards for dynamic web caching, using an expanded interpretation of existing DNS standards to locate and authenticate cached information. "Data-oriented networking", Brent Baccala, 28-Aug-02, Differentiates between connection-oriented and data-oriented networking, identifies the advantages of data-oriented networks, argues that Internet web architecture is becoming more data-oriented, and suggests ways of encouraging and accelerating this trend. "Transport of AAL1 frames over PSN", Davari Shahram, 04-Mar-03, This document describes methods for transporting AAL1 over IP/MPLS network, using the existing ATM transport over IP/MPLS methods described in [ATM-encap]. "Internationalisation of Email Addresses,Newsgroup Names and similar Identifiers", Claus Andre Faerber, 29-Aug-02, This document describes a possible architecture for the implementation of internationalised email addresses, newsgroup names, and similar identifiers on top of the standards set by the Internationalised Domain Names [IDN] working group. "Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery", Greg Daley, Richard Nelson, 03-Feb-03, This draft describes a possible optimization to Duplicate Address Detection (DAD) which can be used to successfully terminate DAD early, based on the presence of listeners on the link-scope solicited nodes multicast address. "A Proposal for RSVPv2", Lars Westberg, 01-Nov-02, The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the desire of many to deploy technology to deliver services with different levels of quality of service (QoS) to their customers. The reasons for this are arguably well-understood and documented and are not the focus of this memo. This memo seeks to initiate a dialog about the design of a new version of RSVPv1, which we call RSVPv2. The RSVPv2 framework could use the combination of two concepts. The concept of ALSP (Application Layer Signaling Protocol) and the concept of Common Signaling Transport Protocol (CSTP). This memo outlines the motivation for doing this work and provides design guidelines and specifications for the development of the RSVPv2 ALSP. RSVPv2 ALSP is an ALSP type that can be a part of the RSVPv2 framework. "Reject Message Extension for ICMP", Hani Jamjoom, 29-Aug-02, This document specifies the incorporation of a Reject message to ICMP to improve a server’s ability for controlling TCP connection requests during periods of overload beyond dropping them. The Reject message serves two purposes: (1) it can inform a connecting host (the client) to completely abort the connection attempt as if a connection timeout has expired, and (2) modify the retransmission timeout interval to reduce the client’s wait times and also to break the re-synchronization of connection requests when multiple SYN packets are dropped. Introducing an additional ICMP message, as opposed to modifying the behavior of TCP, was motivated by the need for backward compatibility (i.e., a host can ignore the ICMP Reject message without affecting the behavior of TCP) and incremental deployment. "Use of Multiple Instance of OSPF for the PE/CE protocol in BGP/MPLS VPNs", Kunihiro Ishiguro, Ville Hallivuori, 07-Mar-03, This document describes a simple way to use OSPF for Provider Edge (PE) router and Customer Edge (CE) router communication in BGP/MPLS VPNs [RFC2547BIS]. [VPN-BGP-OSPF] proposes a complicated way to achieve VPN route propagation as Type-3 LSAs. This document describes the use of multiple instances of OSPF in conjunction with standard BGP/OSPF route redistribution mechanisms to maintain reachability information throughout VPNs. With this mechanism, VPN routes are propagated as Type-5 LSAs. "Evaluation of the CRANE Protocol Against IPFIX Requirements", Kevin Zhang, 03-Sep-02, This document provides an evaluation of the applicability of the CRANE protocol developed by XACCT Technologies as an IPFIX protocol. It compares the properties and capabilities of the CRANE protocol with the IPFIX requirements [IPFIX-REQ]. "Evaluation Of NetFlow Version 9 Against IPFIX Requirements", Benoit Claise, 03-Mar-03, This document provides an evaluation of the applicability of the NetFlow flow record export protocol version 9 as an IPFIX protocol. It compares the properties and capabilities of the NetFlow flow record export protocol version 9 to the IPFIX requirements [IPFIX- REQ]. "Evaluation of Diameter Protocol against IPFIX Requirements", Sebastian Zander, 03-Sep-02, This document provides an evaluation of the applicability of the Diameter protocol [DIAMETER] as an IPFIX protocol. It compares the properties and capabilities of the Diameter protocol to the IPFIX requirements [IPFIX-REQ] "Evaluation Of Streaming IPDR Against IPFIX Requirements", Jeff Meyer, 03-Sep-02, This document provides an evaluation of the applicability of the Streaming IPDR protocol as an IPFIX protocol. It compares the properties and capabilities of Streaming IPDR to the IPFIX requirements. Streaming IPDR is a mechanism to deliver streams of network usage information which follow the Internet Protocol Detail Records (IPDR) format over a reliable transport connection. "Evaluation Of Protocol LFAP Against IPFIX Requirements", Paul Calato, 03-Sep-02, This document provides an evaluation of the applicability of the LFAP protocol as an IPFIX protocol. It compares the properties and capabilities of the LFAP protocol to the IPFIX requirements version 05 [IPFIX- REQ]. "SPAN Discussion Issues", Peter Cordell, 04-Sep-02, This document collects points of discussion surrounding the pre-midcom SPAN deliverable (SPAN = Simple Protocol for Augmenting NATs). As far as possible it is intended to act as a collation point for facts surrounding the SPAN deliverable. Where a discussion item is not black and white it attempts to collate opinion from all angles as far as the author is able to without bias. It does not draw conclusions of any sort. "Request to Move RFC 954 to Historic Status", Eric Brunner-Williams, 04-Sep-02, This memo requests a change of the status of RFC 954, "COPS usage for Path Computation Servers (COPS-PCS)", Marcus Brunner, 05-Sep-02, This memo proposes to use COPS for the communication between a Label Switching Router (LSR) and a Path Computation Server (PCS). Path computation is in much regard a complex function and might be out- sourced. For this reason a protocol between an LSR and a Path Computation Server is needed. This memo proposes to use COPS as a base protocol for that task. "IPv6 Addressing Architecture Support for mobile ad hoc networks", Guillaume Chelius, E Fleury, 05-Sep-02, The concept of node identifier, in practical terms an IP address, is crucial in ad hoc networks. Its use allows the setup of IP routing for ad hoc connectivity and the identification of several wireless devices as part of a unique ad hoc node. In this document, a new addressable object is defined: the ad hoc connector. It virtualizes several ad hoc network interfaces into a single addressable object. To locally address ad hoc connectors, a third IPv6 local-use unicast address (adhoc-local address) and the correlated use of the subnet multicast scope are defined. "SNMP Extended Error Reporting", David Shield, 06-Sep-02, This draft discusses a mechanism for reporting on failures to fulfil an SNMP request, in somewhat more detail than is currently possible. This includes both providing a textual description of the error, and reporting on more than one problem with an individual request. "An Architecture for IP Packet Tracing", Gargi Keeni, Yoshitaka Kuwata, 09-Sep-02, This document presents an architecture for use in packet tracing. "The Aggregation MIB for time based samples of a Managed Object", Glenn Keeni, 16-Dec-02, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it is used to configure an agent to aggregate values of a (user) specified MO instance sampled at (user) specified intervals for a (user) specified number of times and to service queries related to the aggregated MOs. "Simultaneous Handoff of Mobile-IPv4 and 802.11", Subrata Goswami, 05-Feb-03, This document describes a way to perform simultaneous Mobile-IPv4 handoff and 802.11 Access Point Association/Reassociation. Mobile-IPv4 Registration messages are carried as Information Elements in 802.11 frames. This way Mobile-IPv4 can perform handoff at the same time as 802.11 handoffs. The Foreign Agent can be a part of the Access Point or may serve a number of Access Points. The implications to existing mobility entities such as Access Point, Mobile Node, and Foreign Agent are disccussed. Also pointed out are potential issues with 802.1x and the emerging 802.11i standards. "SIP Header Language Information Extension", Shingo Fujimoto, 10-Sep-02, This draft explains the problem when we use the UTF-8 character set to represent the language text other than English. This draft also describes the requirements to solve the problems, and proposes the extended syntax to SIP protocol message syntax specification. "Mapping Between NFSv4 and Posix Draft ACLs", Marius Eriksen, 02-Jun-03, The NFS (Network File System) version 4[rfc3530] (NFSv4) specifies a flavor of Access Control Lists (ACLs) that apply to file system objects. ACLs specify an access level for a number of entities. The NFSv4 ACLs model resembles that of Windows NT. A POSIX draft[posixacl] proposes another, more restrictive ACL model. Many systems implement this proposed standard. Differing in syntax, semantics and extensiveness, it is only feasible to create a correct representation for POSIX ACLs with NFSv4 ACLs. This does not hold for an attempt to represent arbitrary NFSv4 ACLs with POSIX ACLs. "DHCP Option for SNMP Notifications", Mark Bakke, 06-Nov-02, The Dynamic Host Configuration Protocol [RFC1531] provides a method for a host to retrieve common configuration parameters at boot time. These include the host's IP address, default gateway, subnet mask, DNS server, and other useful things. When a host is booted from the network, it does not have access to these configuration parameters from its local or network disk right away; it relies instead on DHCP to provide them. One such parameter that is not yet provided is a list of IP hosts to which to send SNMP notifications [RFC1448] during the boot process, particularly if the boot fails. As the host is already gleaning similar information from DHCP, a new option to specify these SNMP 'trap' hosts appears to be the simplest method to gain this information. Hosts not booting from the network benefit as well, since SNMP notification hosts can now be configured centrally through DHCP. This document describes a proposed DHCP option that specifies a list of SNMP notification hosts to which SNMP notifications should be sent. "ISATAP interactions with TSP", Fred Templin, 11-Sep-02, This document discusses possible interactions between the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) and the Tunnel Setup Protocol (TSP) "Light-weight Flow Accounting Protocol MIB", Paul Calato, Mike MacFaden, 11-Sep-02, This document provides a description of MIB module that accompanies the LFAP Specifications [1][2]. "An enhancement for limiting the length of tunnel in the fast handover method using bi-directional edge tunnel (BET)", Hans Jung, J. Minas, 11-Sep-02, To support real-time services such as VoIP in Mobile IPv4/v6, several fast handover methods have been proposed. The fast handover method using BET is one of them and was chosen as an alternate protocol to FMIPv6 version 4. BET has advantage in reducing the handover latency because it does not perform the layer 3 registration. However, the long BET in certain situation could be not acceptable. In that case, a mechanism is needed to limit the tunnel length of BET. In this draft, we propose to group the ARs by predefined value to limit the tunnel length of BET. An anchor router is changed whenever a MN changes its associated group. "Mobile IPv4 Extension for Configuration Options Exchange", Jayshree Bharatia, Kuntal Chowdhury, 05-Jun-03, IP Mobility support for IPv4 [RFC3344] defines a short and skippable extension header format intended to extend the Mobile IP extension address space. Based on the format presented in [RFC3344], this draft defines a Mobile IP extension for configuration options, which SHOULD be used by any Mobile IP entity to exchange information of the network entities like DNS server address, previous Foreign Agent (FA) address, address of a session manager etc. "Robust Header Compression (ROHC) over Wireless Ethernet Media ROHCoWEM", Kristoffer Fleming, 01-Nov-02, This document describes a protocol which supports the use of robust header compression (ROHC) [2] on IP datagrams transmitted over Ethernet and other 'Ethernet-Like' wireless media such as IEEE 802.11, Bluetooth and other future wireless media based IEEE 802.3. This draft defines a simple protocol to support ROHC over Wireless Ethernet Media (ROHCoWEM). "IRC Command Prefix Capability", Edward Brocklesby, 09-Dec-02, This memo presents a method for a client to prefix commands sent to an IRC (Internet Relay Chat) server with a label, in order to match server replies against commands previously sent, without having to keep excessive state on the server connection. It is a primary goal to implement this in a way which is completely backwards- compatible with existing IRC servers. This documents describes an extention to the Internet Relay Chat protocol as described in RFC 1459 [1]. "Evaluation of Transition Mechanisms for Unmanaged Networks", Christian Huitema, 07-Nov-02, In a companion paper we defined the 'unmanaged networks' scope, which typically correspond to home networks or small office networks, and the requirements for IPv6 transition mechanism in that scope. We start from this analysis and evaluate here the suitability of mechanisms defined in the NGTRANS working group. "Spatial metrics for IPPM", Emile Stephan, 20-Jun-03, The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end-to-end performance. This memo defines spatial metrics both for measuring end-to-end network performance using aggregation of sequence of network measures and for measuring the performance of segments of an IP path trajectory. It distinguishes clearly the decomposition of one end-to-end measure result in a sequence of per hop results from the aggregation of a sequence of per hop measure results in an end-to-end result. "Transcoding Services Invocation in the Session Initiation Protocol", Gonzalo Camarillo, 19-Feb-03, This document describes how to discover the need of transcoding services in a session established with SIP and how to invoke those transcoding services. Two models for transcoding services invocation are introduced; the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "The source and sink attributes for the Session Description Protocol", Gonzalo Camarillo, Henning Schulzrinne, Eric Burger, 13-Sep-02, This document defines two media level SDP attributes, namely source and sink. They are intended to be used to invoke services that involve media manipulation, such as transcoding services. "A Simple Analysis of Mobile IP v4", Subrata Goswami, 16-Sep-02, This document analyzes Mobile IP v4 from a deployment point of view. With the popularity of wireless LAN technologies subnet roaming has become a prominent issue. Some critical scalabilty issues for Home Agent and Foreign Agents are pointed out. "IRC RPL_ISUPPORT Numeric Definition", Edward Brocklesby, 13-May-03, This memo presents a way for the server to unobtrusively advertise the ways in which it differs from the IRC (Internet Relay Chat) specification defined in RFC 1459 [6]. It is a primary goal to implement this in a way which is completely backwards-compatible with the original protocol, and also with current non-standard implementations of the ISUPPORT numeric. "'A compendium of enumservice registrations'", Rudolf Brandner, 16-Sep-02, This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. "Subscription Data Format (DRAFT)", John Ramsdell, 16-Sep-02, This memo specifies the CPIM Subscription Data Format (SDF) as a common subscription data format for CPIM-compliant IM/Presence protocols. "CASP - Cross-Application Signaling Protocol", Henning Schulzrinne, 07-Mar-03, CASP is a modular potocol for establishing network control state along a data path between two nodes communicating on the Internet. The signalling problem addressed by CASP is the same as the overall problem being addressed by the NSIS activities. The CASP framework is defined as a modular protocol, which includes a general purpose messaging layer (M-layer), which supports a number of client layers for particular signalling applications (e.g. QoS, MIDCOM). In addition there is distinct, special purpose client component for next-peer discovery. "A Quality-of-Service Resource Allocation Client for CASP", Henning Schulzrinne, 07-Mar-03, Signaling resource reservations is one of the possible applications of the Cross-Application Signaling Protocol (CASP). This document describes a client protocol that supports per-flow resource reservation in both sender- and receiver-directed modes operation. "Marker PDU Aligned Framing for TCP Specification", Paul Culley, 30-Jun-03, A framing protocol is defined for TCP that is fully compliant with applicable TCP RFCs and fully interoperable with existing TCP implementations. The framing mechanism is designed to work as an 'adaptation layer' between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. "Open Network Handles Implemented in DNS", Michael O'Donnell, 17-Sep-02, An Open Network Handle System (ONHS) provides an intermediate level of service between IP numbers and domain names. A handle adheres permanently to an owner, who may assign and reassign it to dif- ferent addresses at will. But a handle is a number, carrying no significance in natural language. Any user desiring a handle may generate one from a public key. This memo describes a simple imple- mentation of an Open Network Handle System using the security extensions to the Domain Name System (DNSSEC). "An RDMA Protocol Specification", Renato Recio, 04-Nov-02, This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into ULP Buffers without intermediate data copies. It also enables a kernel bypass implementation. "General Requirements for Emergency Telecommunication Service", Ken Carlberg, Randall Atkinson, 06-Dec-02, This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). "IP Telephony Requirements for Emergency Telecommunication Service", Ken Carlberg, Randall Atkinson, 06-Dec-02, This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. Solutions to these requirements are not presented in this document. "Direct Data Placement over Reliable Transports", Himanshu Shah, Paul Culley, 04-Nov-02, The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol’s receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. "Experience of the BRAIN and MIND Projects in the Development of IP Mobility Solutions", Andrej Mihailovic, 18-Sep-02, This draft gives an overview of the design of IP mobility protocols conducted in BRAIN and MIND IST projects. "Customer Managed Gateway Selection for RFC2547 VPN(s)", James Uttaro, 18-Sep-02, This document presents an application of the BGP community attribute in simplifying the implementation and configuration of routing policies between two or more VPN service providers. It is assumed that RFC2547 has been implemented to provide the VPN service although this is not a requirement of this application It shows how use of the community attribute along with the setting of a BGP metric can be used by customers to select the best gateway between one or more VPN service providers. This technique simplifies configuration and management at the provider level, and gives the customer the ability to control its own routing policy with respect to the selection of gateways between service providers. "General Considerations For MIDCOM Semantics", Tom Taylor, 18-Sep-02, This document is written to aid the process of selecting and completing the definition of the MIDCOM protocol, which will operate between MIDCOM agents and middleboxes such as firewalls and NATs. It describes the semantics which the protocol must support. These semantics are derived from the MIDCOM requirements and the MIDCOM usage scenarios which helped to inspire the requirements. This document was derived from draft-taylor-midcom-semantics-00.txt. The present version incorporates tentative conclusions reached in discussion at the IETF 54 meeting of the MIDCOM WG. It removes the concrete expression of the MIDCOM requests, responses, and notifications in favour of those presented in draft-stiemerling- midcom-semantics-xx.txt. "A Base-85 Encoding Suitable for XML", Paul Kwiatkowski, 18-Sep-02, This memo proposes a base85 text encoding for arbitrary binary data that is suitable for use in XML documents. This encoding requires approximately 15/16 of the space of the MIME Base64 encoding that is currently supported as a primitive datatype in the XML Schema definition language. In a UTF-8 encoded XML entity, Base85 therefore has 3/4 of the overhead of Base64. "SDP attribute for qualifying Media Formats with Generic Parameters", Rajesh Kumar, Flemming Andreasen, 20-May-03, This document defines a new SDP attribute called general-purpose media descriptor (gpmd). The gpmd attribute allows the use of new informative parameters, gpmd parameters, to qualify existing media formats. These gpmd parameters are not part of the standard (e.g., MIME) definition of the media format and support for them with a given media format can not be assumed. Their use is therefore limited to cases where they provide information that may be of use to the other party in a session but is not critical to the use of the particular media format. This document also defines a specific gpmd parameter, voice-band data, which can be used to describe a media format as carrying voice-band data. This enables the receiver to optimize its handling of the media received. "Directory Administrative Model in LDAP", Steven Legg, 28-Feb-03, This document adapts the X.500 directory administrative model for use by the Lightweight Directory Access Protocol. The administrative model partitions the Directory Information Tree for various aspects of directory data administration, e.g. subschema, access control and collective attributes. The generic framework that applies to every aspect of administration is described in this document. The definitions that apply for a specific aspect of administration, e.g. access control administration, are described in other documents. "SIP PSTN Number Association", Mick O'Doherty, Mark Ashworth, 18-Sep-02, This document describes a specific requirement for associating SIP endpoints with PSTN (Public switched telephony Network) endpoints, not for the SIP endpoint to replace the PSTN endpoint, but to allow them to be used together. It outlines some potential ways of addressing this requirement and proposes one of the options as the best case approach. Additionally, it describes a general requirement that fell out from this scenario and that might be a good candidate for further study. "Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno, 29-May-03, This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11. "SIP Specific Data Publication Framework", Aki Niemi, 20-Sep-02, This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework for publication of SIP specific data. This extension derives from the recent Internet Draft defining the PUBLISH method, but instead of using the SIP events framework, it introduces a specific publication framework for the publish mechanism. The main motivations for decoupling publications from events are that the event framework is not overloaded, and the applicability of the PUBLISH method to problem sets similar to those surfacing in the publication of event state is improved. The SIP publication framework is neither intended for general data manipulation, nor is it intended to foster any discussion on the issue of using SIP for everything. "DNSSEC Wildcard Optimization", Olaf Kolkman, 08-Jan-03, Secure denial of the existence of wildcards may lead to a large number of NXT Resource Records and associated SIG Resource Records in DNS responses, even in the common case when wildcards are not present in the zone. This optimization uses one bit from the NXT type array to signal that there is no closer wildcard in the zone for a given query name. This reduces the packet size and the need for executing slow, and complicated, code paths in the case when queries are made to zones which have the bit set at zone signing time. In cases where there are no wildcard RRs in the zone (e.g. the root zone) only one NXT RR and corresponding SIG is needed for denial of existence of both a full match and any possible wildcard matches. "A UUID URN Namespace", Michael Mealling, 23-Sep-02, This specification defines a Uniform Resource Name namespace for 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. The original version of this document was written by Paul Leach and Rich Salz but was unpublished for several years. This is an updated version incorporated as part of the URN registration document. "Mobile IPv6 Fast Handovers for 802.11 Networks", Pete McCann, 04-Nov-02, This document describes how a Mobile IPv6 Fast Handover [2] can be implemented on a wireless LAN conforming to the 802.11 suite of specifications [3]. "Enhanced Internet Protocol Specification", Yunqing Zeng, 24-Sep-02, This document describes aspects of 'multi-tier' architecture, 'Grid-net', addressing architecture, 'address plane', 'address swapping','address option', and revises aspects of the security, precedence of the Standard Internet Protocol to suit newly development trend of Internet, Municipal Area Network, and 'Home-net'. This addressing architecture provides much more capacious address space by attached 32-bit 'Grid' IP address for transmitting datagram from sources to destinations, where hosts identified by twin 32-bit IP addresses, i.e. to provide 'non-private' 32-bit IP address for transmission in adding 'Grid' tier, and scalable service for data, voice, signaling, and multimedia. The proposed protocol provides of seamless integration with existing Internet, tier border address swapping for transmission throughout public Internet tier, IP address planes inside Grid-net for data, IP phone, mobile phone, wireless PAD, video and other multimedia applications, and IP address personality for personal computer, IP phone, mobile phone, wireless PAD, home control, monitoring, and multimedia equipments. The goal of this document is to implement a compatible protocol, to create new Internet Multimedia Environment, and to protect worldwide investment on network resources. "Generic Requirements for Provider Provisioned VPN", Ananth Nagarajan, 04-Nov-02, This document described generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. "IPv6 Enterprise Networks Scenarios", Yanick Pouffary, Jim Bound, 20-Jun-03, This document describes the scenarios for IPv6 deployment within Enterprise networks. It will focus upon an Enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of Enterprise solutions in a later document. "Firewalling Considerations for IPv6", Pekka Savola, 05-Mar-03, There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. "URN Namespace for NewsML Resources", Danny Allen, 21-May-03, This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems and NewsML related XML Schemas. A NewsItem is an information resource that is expressible as a NewsML element within a NewsML document conforming to the NewsML Document Type Declaration (DTD) as defined by the International Press Tele- communications Council (IPTC). "Extensible Provisioning Protocol Over SOAP", Hong Liu, 26-Sep-02, This memo documents a proposal for exchanging EPP (Extensible Provisioning Protocol) messages as XML documents between a client and a server via SOAP (Simple Object Access Protocol), using the SOAP request/response communication model. An EPP message is encapsulated in the SOAP Body, while the EPP session information is encoded in the SOAP header, enabling EPP session-oriented messaging over the SOAP protocol. It is designed to work on top of any transport bindings defined for SOAP, taking advantage of the variety of SOAP software tools and environments available for web services. "Select PDU for SNMPv3", Carl Kalbfleisch, 27-Sep-02, Traditionally data retrieval from SNMP entities has been done using GET, GETNEXT and the GETBULK PDU's. These mechanisms have worked well for some instances. However, there are many cases where they are inefficient in retrieving data that the management application needs to access. The EOS (Evolution of SNMP) Working Group is investigating new PDU's to be used to gather information from SNMP entities. This memo proposes a select PDU that will operate in much the same way as SQL Select. "A Multicast Extension to MAPOS NSP (Node Switch Protocol) - NSP+", Tsuyoshi Ogura, 06-Jun-03, This document describes NSP+, an extension of the MAPOS NSP (Node Switch Protocol). MAPOS is a multiple access protocol for transmitting of network-protocol datagrams, encapsulated in High- Level Data Link Control (HDLC) frames, over SONET/SDH. NSP is a protocol for automatically assigning MAPOS node addresses. The NSP+ extension enables the nodes to provide their directly connected switch with information about the multicast groups to which they belong, so the switch forwards only required multicast frames to the nodes. "DIAMETER Application for Mobile-IPv4 and 802.11 Authentication", Subrata Goswami, 14-Oct-02, This document describes a single way to perform both Mobile-IPv4 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consummate message sequences for both 802.11 and Mobile IPv4. It is possible to replace the currently proposed 802.1x Authentication/key-exchange with Diameter Mobile-IPv4 Application. "ISP requirements for IPv6 unmanaged networks", Yoann Noisette, 27-Sep-02, This document proposes to identify the elementary network functions required to automatically deploy an IPv6 home network, i.e. with the minimum (and ideally not a single) intervention from any administrator or any user. The next generation Internet Protocol, IPv6, is expected to being deployed in environments such as homes and SOHOs. However, most of the people making use of the Internet at home don't have enough knowledge to set up on their own the network and services. Therefore, this document exposes the requirements necessary to ease such a deployment, from an ISP point of view. "Guidelines for Integrating Mobile IP with NAPT", Cheng-chi Huang, 27-Sep-02, As the number of mobile terminals increases, Mobile IP[1] potentially could make users roam around the world while also keep their connection to the Internet uninterruptedly. In the mean time, many organizations are using NAPT[2] (Network Address Port Translator) to isolate private network from public realms. The integration of NAPT with Mobile IP, however, introduces technical issues that must be resolved before they can function together. Although techniques such as UDP tunneling[3] and reverse tunneling[4] can be utilized to solve part of the problem, there are still some scenarios which need more discussion. This document reviews these mechanisms and presents a guideline for the integration of Mobile IP and NAPT in various scenarios. "DNS look-up for services related to a URI", Soren Nyckelgard, 30-Sep-02, This memo is an extension to ENUM RFC 2916 [3]. RFC 2916 describes how to utilize DNS as a look-up mechanism for services related to a telephone number. This memo describes how to utilize the same look- up mechanism for personal URIs (user@domain). Specifically, it defines how to translate personal URIs to DNS names. "Applicability Statement for Restart Mechanisms for the Label Distribution Protocol", Adrian Farrel, 14-Oct-02, Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to a minimum. Similarly, where MPLS is at the network edges (for example, in Provider Edge routers) system downtime must also be kept as small as possible. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including the switching hardware and the TCP stack are implementation specific. How the software module itself chooses to implement FT for the state created by the Label Distribution Protocol (LDP) is also implementation specific but there are several issues in the LDP specification in RFC 3036 'LDP Specification' that make it difficult to implement an FT LSR using the LDP protocols without some extensions to those protocols. Proposals have been made in 'Fault Tolerance for the Label Distribution Protocol (LDP)' [LDP-FT] and 'Graceful Restart Mechanism for LDP' [LDP-RESTART] to address these issues. This document gives guidance on when it is advisable to implement some form of LDP restart mechanism and which approach might be more suitable. The issues and extensions described here are equally applicable to RFC 3212, 'Constraint-Based LSP Setup Using LDP' (CR-LDP). "Architecture and Protocol framework for Dormant Mode Host Alerting", Marco Liebsch, Yoshihiro Ohba, Tao Zhang, 30-Sep-02, This document discusses and describes an architecture and protocol framework for the design and specification of a generic IP based architecture and protocol for Dormant Mode Host Alerting, aka IP paging. It focuses on the location and operation related interworking of the different functional entities as required to allow for a flexible and scalable deployment of the protocol. Furthermore, protocol transport and security mechanisms are evaluated and proposed to meet respective requirements on a DMHA protocol. This document intends to be a comprehensive guideline for the design of a generic IP paging architecture and protocol. "PANA over TLS", Yoshihiro Ohba, S Baba, S Das, 30-Oct-02, This draft specifies a method to carry authentication information over TLS between PANA Client (PaC) and PANA Authentication Agent (PAA). PANA over TLS uses existing TLS protocol over a reliable transport in order to perform authentication information exchange in a secure and reliable manner. The purpose of this document is not only to provide a mechanism for carrying the authentication parameters but also to address some outstanding issues such as, multiple access routers, reauthentication, security threats, etc. "SDP Security Descriptions for Media Streams", Mark Baugher, Dan Wing, 01-Oct-02, This Internet Draft gives a generic cryptographic attribute to Session Description Protocol (SDP) media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This draft also defines the SRTP parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. "LSP Subobject for RSVP-TE", C Vijayanand, 04-Jun-03, This document describes the use of RSVP-TE to establish hierarchical tunnels using a LSP sub-object in the ERO. This document proposes extensions to existing RSVP-TE for establishing hierarchical tunnels in RSVP-TE using a LSP subobject in the Explicit route object of RSVP-TE path message. LSP subobject can be used to uniquely identify the outer tunnel to be used for tunneling. This is useful in situations where the outer tunnel is not an FA-LSP and the knowledge of outer tunnel is available to the administrator. "IPv6 Router Advertisement DNS resolver Option", Luc Beloeil, 17-Jan-03, This document defines the DNS resolver (DNSR) option used to advertise on a link IPv6 addresses of DNS resolvers. The DNSR option, which lists the IPv6 addresses of DNS resolvers that all nodes of the link may use to resolve name or address, is attached to IPv6 Neighbor Discovery Router Advertisement messages that are sent across a link. This document specifies the process used by a host to decide how to configure the IPv6 addresses of DNS resolvers that the host could use in IPv6 networks. This document defines the mechanism by which a node processes the DNSR option and updates valid IPv6 addresses of DNS resolvers. "A Negative Acknowledgement Mechanism for Signalling Compression", Adam Roach, 06-Mar-03, This document describes a mechanism that allows Signalling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine- grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. "PWE3 Common Terminology", Stewart Bryant, 06-Nov-02, This document defines the terminology common to PWE3 drafts. "SIP Combined Registration and Subscription", Ajaykumar Idnani, Thomas Hallin, Steven Upp, 02-Oct-02, This memo proposes that the headers of REGISTER and SUBSCRIBE be combined, so that a REGISTER message can also be treated as an implicit subscription for events. This memo identifies the need for doing this, and then explains how combining the Registration and Subscription solves the problem. It also presents an example flow demonstrating the use of this combined registration and subscription. The headers being combined will be made optional in the REGISTER and SUBSCRIBE messages - depending on where they do not appear as of today - so that backward compatibility is maintained. "LDAP (Alternative) Virtual List View Operation", Kurt Zeilenga, 02-Oct-02, This document describes an LDAP (Lightweight Directory Access Protocol) Virtual List View (VLV) operation. The operation allows the client to obtain portion (the view) of an ordered set (the list) of entries visible through a virtual window. The client can reissue the operation with different criteria to obtain a different view of the list. Clients may use this operation to page, scroll, or browse directory content. The VLV operation is defined as a set of LDAP controls which extend the Search operation. The VLV controls may be used in conjunction with a number of other search controls, such as the Server Side Sorting of Search Results (RFC 2891) control. "New Parameter for Contact Header", Ajaykumar Idnani, 02-Oct-02, This memo proposes a new parameter for the SIP Contact header This memo identifies the need for the new parameter, and then goes ahead and defines the new parameter, and the algorithm for using the new parameter. It also presents an example flow demonstrating the use of the new parameter. The new parameter being defined is an optional parameter, and is not required to be supported by the SIP servers and UAs to be interoperational. "Diameter C++ API", Yoshihiro Ohba, Victor Fajardo, Dilip Patel, 03-Oct-02, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C++ language. The intent of the API is to foster source code portability across multiple programming platforms, leveraging the object-oriented nature of C++ and reusing what is already defined in the Diameter C API as much as possible. The C++ API can also be used as a basis to define more platform-independent API such as Java-based API. "Secure Network Access Authentication (SeNAA)", Dan Forsberg, Jarno Rajahalme, 31-Oct-02, This draft describes how reliable Secure Network Access Authentication (SeNAA) protocol over UDP carries Transport Layer Security (TLS) protocol. SeNAA messages are formatted like Diameter messages and contain Attribute Value Pairs (AVPs) that are protected with TLS Record Layer. SeNAA provides secure transport for Extended Authentication Protocol (EAP) between PANA Client (PaC) and PANA Authentication Agent (PAA). PANA stands for Protocol for carrying Authentication for Network Access. "Service Discovery in On-Demand Ad Hoc Networks", Rajeev Koodli, Charles Perkins, 03-Oct-02, In this document, we describe extensions to suitable ad hoc network routing protocols in order to provide support for service discovery. Typical Internet applications require information such as name resolution, a web proxy IP address, access to print services etc. While [manet] protocols have focussed on providing basic routing support for communication, this document addresses the problem of discovering services along with routes to those services. "Guidelines for Working Groups on Intellectual Property Issues", Scott Brim, 04-Oct-02, This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with IPR issues. It documents specific examples of how IPR issues have been dealt with in the IETF. "XML Schema for Media Control", Orit Levin, Sean Olson, Roni Even, 07-Apr-03, This document defines an XML Schema for Media Control in a tightly controlled environment. The current version includes commands for managing of video streams only. Implementation of this schema for interactive video applications in SIP environments significantly improves user experience. "Media Gateway Control Protocol (MGCP) Redirect and Reset Package", Bill Foster, Flemming Andreasen, 27-Jun-03, The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be re-directed one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately re-direct endpoints by allowing a list of Call Agents to be specified in a preferred order. "IPv6 Anycast Binding using Return Routability", Brian Haberman, Erik Nordmark, 04-Oct-02, Today, the use of IPv6 anycast is limited. This document proposes a mechanism by which TCP/SCTP and stateful protocols using UDP can securely discover the mapping from an anycast address to a unicast address that can be used until a failure is detected. The mechanism reuses the Mobile IPv6 Return Routability and Binding Update mechanism. "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", Magnus Westerlund, 23-Oct-02, The existing Session Description Protocol (SDP) bandwidth modifiers and their values include the bandwidth needed also for the transport and IP layers. When using SDP in protocols like SAP, SIP and RTSP and the involved hosts reside in networks running different IP versions, the interpretation of what type of lower layers that is included is not clear. This documents defines a bandwidth modifier that does not include transport overhead, instead additional packet rate attributes are defined. The transport independent bitrate value together with the packet rate can then be used to calculate the real bitrate over the actually used transport. "IPv6 Multicast Deployment Issues", Pekka Savola, 04-Nov-02, There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted. "An Extensible Markup Language Schema for Call Processing Language (CPL)", Xiaotao Wu, Henning Schulzrinne, Jonathan Lennox, 06-Mar-03, This document provides an Extensible Markup Language (XML) Schema for the Call Processing Language (CPL). The original CPL specification only provides a Document Type Declaration (DTD) to describe the structure of the language. Compared with XML DTDs, XML schemas have many advantages such as performing stricter type checking, providing pre-defined data types and being able to derive new data types from existing ones. We further split the CPL schema into two parts, one contains elements common to all the telecommunication entities, such as user agents or presence agents. The other contains elements, such as 'proxy', specifically for network servers. "Virtual Hierarchical LAN Services", Arnold Sodder, 29-Apr-03, This draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching architecture. The model is based on a hierarchical MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. "Voiceband Data Transport Services in Megaco/H.248 Networks", Annette Schwarz, 12-May-03, This document describes the terminology and gives a network model for different strategies concerning Voiceband Data (VBD) transport services. The purpose of this effort is to set the reference space for describing and evaluating Megaco/H.248 signaling procedures. Primary scope are voiceband data services, typically inherent part in voice-over-packet networks (e.g., like Internet Telephony). Motivation: VBD calls typically start out as a voice call. The modems on the VBD devices at the Termination detect the switch to VBD (like facsimile) and fax modem or data modem transmission begins. With the development of Voice over IP, many CODECs have been developed which are optimized for the transmission and reception of voice. In creating these CODECs, VBD transport may not reliably be used over the same transmission channel. In an effort to optimize the transmission of VBD, specialized protocols (e.g., T.38, or V.150) have been developed to provide a more reliable transport, minimize bandwidth usage, etc. "Localized Key Management for AAA in Mobile IPv6", Miyoung Kim, Y. Mun, 16-Dec-02, This document describes a way to distribute secure key for optimizing AAA authentication procedure while a mobile node is away from it's home. The AAA infrastrucrue is used as an underlying framework which enables a Mobile-IPv6 node to get an global authentication by identifying it with an unique identifier NAI. The Diameter messages are exchanged to transfer information of mobile node between home and foreign AAA servers. The steps to complete an authentication procedure for mobile node in the visited link may be reduced by delegating the role for generating and synchronizing keys to AAA server in the visited domain. The implications to existing entities supporting mobility such as attendant, AAA server in home and visited domain are discussed. The delegation is introduced and the related security issues are pointed out. "Optimal Detecting Increases in PMTU", Ho John Lee, 08-Oct-02, This document presents a new method for the detection of increases in PMTU using the newly defined Hop-by-Hop option header. To detect increases in a path's PMTU, a node does not increase its assumed PMTU unconditionally without considering network status, but measures its real PMTU, and then replaces the previous PMTU with new one. To measure node's real PMTU, the node sends the IP packet with the newly defined Hop-by-Hop option header to the destination node right before a timer expires. This can eliminate the chance of occurrence of packets being discarded and Packet Too Big messages being generated. "The BGP TTL Security Hack (BTSH)", Vijay Gill, John Heasley, David Meyer, 29-May-03, The BGP TTL Security Hack (BTSH) is designed to protect the BGP [RFC1771] infrastructure from CPU-utilization based attacks. While BTSH is most effective in protecting directly connected BGP peers, it can also provide a lower level of protection to multi-hop sessions. "OSPFv2 Opaque LSAs in OSPFv3", Kireeti Kompella, 08-Oct-02, This memo specifies how OSPF version 2 Opaque Link State Advertisements can be carried in OSPF version 3. "Layer 2 Handoff for Mobile-IPv4 with 802.11", Yong-Jin Park, Y. Mun, 08-Oct-02, Mobile-IPv4 describes how a Mobile Node can perform layer 3 handoff between subnets served by different Foreign Agents. Sometimes the delay during handoffs can exceed the threshold of delay sensitive applications. So low delay must be considered. This document describes a method to perform fast handoff on the Layer 2 for Mobile-IPv4 with 802.11's Access Point. Mobile-IPv4 Registration messages are carried in the Information Elements of 802.11 frames. According to this method, Mobile-IPv4 can perform handoff at the same time as 802.11 handoff. But some modifications bust be adopted in the existing Mobile-IPv4 and 802.11's entities such as Mobile Node and Access Point. "Megaco Ringing MIB", Bala Pitchandi, 08-Oct-02, 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 use by the MEGACO/H.248 Ringing Packages operating on Media Gateways. These objects can be used to manage the network containing Media Gateway(s). This is the initial version of this draft. This draft defines a MIB that contains the elements for defining ringing patterns [21]. Rules have been defined below which MUST be adhered to ensure a properly defined set of ringing patterns. "Traffic Engineering Extensions to OSPF version 3", Kunihiro Ishiguro, Toshiaki Takada, 07-Mar-03, This document describes extensions to the OSPF version 3 to support intra-area Traffic Engineering [RFC2702]. The OSPFv3 protocol is specified in [RFC2740]. This document expands [OSPFV2-TE] to make both IPv4 and IPv6 network applicable. New sub-TLVs are defined to support IPv6 network. Use of these new sub-TLVs are not limited in OSPF version 3. They can be used in OSPF version 2. "Towards RSVP Version 2", Marcus Brunner, Rosella Greco, 09-Oct-02, This memo is a first step towards the design of RSVP Version 2. We take RSVP Version 1 as a basis of this work. RSVP has been criticized mainly because of its complexity and poor scalability among others. We present the first steps towards the definition of a new version of RSVP. The goal is to provide a more 'light' approach that can help improve handling reservations in the network by means of a simplified behavior. This proposal for RSVP Version 2 is not meant as a complete replacement of RSVP Version 1 but is meant to coexist with Version 1. For some scenarios such as receiver orientation and multicasting we assume that RSVP version 1 works fine. "Alternative Solutions for a SPAN Deliverable", Peter Cordell, 10-Oct-02, This document presents and discusses alternatives to developing a custom solution for the pre-midcom SPAN deliverable (SPAN = Simple Protocol for Augmenting NATs). Such alternatives consist of protocols or techniques that have already been standardised or will soon be standardised. "Grace LSA in OSPFv3", Padma Pillay-Esnault, 24-Oct-02, This memo describes the OSPF version 3 specific Grace Link State Advertisement. "iWARP Framing for TCP", Jim Williams, 18-Feb-03, A framing protocol is defined for DDP over TCP that is fully compliant with applicable TCP RFCs and fully interoperable with existing TCP implementations. This protocol is being offered as an alternative to to the proposal offered in [MPA]. The protocol offers to two things, definition of the DDP record boundaries within the TCP stream, and added data integrity by means of added CRC protection. "Media Gateway Control Protocol (MGCP) MoveConnection Package", Flemming Andreasen, Bill Foster, 10-Oct-02, This document defines a Media Gateway Control Protocol (MGCP) package containing the MoveConnection command which was originally proposed in RFC 2705 [4]. The MoveConnection command can move an MGCP connection from one endpoint in a media gateway to another endpoint in the same gateway. This can be very useful in order to support redirection of media streams across endpoints in a media gateway. "Fast Handoff L2 Trigger API", Ajoy Singh, 10-Oct-02, To enable seamless L3 handover of a MN from one subnet to other, the MN or the AR is required to anticipate the identity of the target AR prior to initiation of the L3 handoff. To anticipate the identity of target AR, the L3 is required to receive a notification from L2 about the appropriate identity of target AP as soon as the L2 handoff is detected. To further optimize the L3 handoff, L3 is also required to receive indications about Link Up and Link Down events as soon as such events are detected by L2. The Link Down event is detected by L2 as soon as the MN loses connection with current AP. Similarly, the Link Up event is detected as soon as the MN re-connects with new AP. Depending upon the nature of access technologies, some of the various triggers can be available at MN, AR or both. "Embedding the Address of RP in IPv6 Multicast Address", Pekka Savola, Brian Haberman, 22-May-03, As has been noticed, there is exists a huge deployment problem with global, interdomain IPv6 multicast: Protocol Independent Multicast - Sparse Mode (PIM-SM) Rendezvous Points (RPs) have no way of communicating the information about multicast sources to other multicast domains, as there is no Multicast Source Discovery Protocol (MSDP), and the whole interdomain Any Source Multicast model is rendered unusable; SSM avoids these problems. This memo outlines a way to embed the address of the RP in the multicast address, solving the interdomain multicast problem. The problem is three-fold: specify an address format, adjust the operational procedures and configuration if necessary, and modify PIM-SM implementations of those who want to join or send to a group (Designated Routers) or provide one (Rendezvous Points). In consequence, there would be no need for interdomain MSDP, and even intra-domain RP configuration could be simplified. This memo updatres RFC 3306. "Secure Ad hoc On-Demand Distance Vector (SAODV) Routing", Manel Zapata, 10-Oct-02, The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension of the AODV routing protocol that can be used to protect the route discovery mechanism providing security features like integrity, authentication and non-repudiation. "Taxonomy of Route Optimization models in the Nemo Context", Pascal Thubert, Marco Molteni, Chan Ng, 05-Jun-03, Nemo enables Mobile Networks by extending Mobile IP to support Mobile Routers. This paper documents how the MIPv6 concept of Route Optimization can to be adapted for Nemo to optimize: 1) the nested tunnels of the nested Nemo configuration 2) router-to-router within the infrastructure as opposed to end-to- end. "IPv6 for Large Access Providers", Kenneth Allen, Weijing Chen, 11-Oct-02, This document discusses how Large Access Providers (LAP) could use IPv6 to solve current technical challenges. In particular, IPv6’s large address space and optional header mechanism can be used to provide scalable and manageable broadband Internet access and Virtual Private Network (VPN) services. A new optional header to support forwarding-plane based VPNs is proposed. "Usage Scenario and Requirements for AAA in Network Mobility Support", Chan Ng, Takashi Tanaka, 14-Oct-02, This memo set out the basic Authentication, Authorization, and Accounting (AAA) model for Network Mobility Support (NEMO), and described various usage scenarios. From the scenarios, a set of AAA requirements in NEMO is drawn. "Optimistic Duplicate Address Detection", Nick Moore, 06-Feb-03, Optimistic DAD is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case. "CALL ESTABLISHMENT PROCEDURES FOR T.38 H.248/MEGACO MEDIA GATEWAYS CAPABLE OF AUTONOMOUS TRANSITION BETWEEN VoIP AND T.38 FoIP", Dominic Walker, 15-Oct-02, This document describes MEGACO/H.248 [6,2] call-setup set up procedures that enable T.38 [4] capable media gateways to transition between a Voice over IP (VoIP) call and a Facsimile over IP (FoIP) (using ITU-T Rec. T.38) call either: a) with the real-time intervention of a Media Gateway Controller (MGC) using one of the existing mechanisms in Rec. T.38 Annex B/H.323, Rec. T.38 Annex D/SIP-SDP and Rec. T.38 Annex E/H.248, and Rec. H.323 Annex D. b) without the real-time intervention of a Media Gateway Controller (MGC). The only involvement of the MGC will be during initial connection capabilities negotiation between the media gateways. At this stage, both the MGs and the MGCs are unaware of the type of connection, (i.e. Voice, Fax, Modem, etc.). This contribution also describes how these call set-up procedures can be used in conjunction with the existing procedures of ITU-T Rec. H.323 Annex D to set-up two parallel channels, one for voice and the other for T.38, without any modifications of the procedures. "Automatic Router Configuration Protocol", Jeb Linton, 15-Oct-02, Automatic Router Configuration Protocol is a method by which Routers may be automatically configured according to a predefined or default scheme of behavior and address allocation. It is routing protocol independent and is based on on a Client-Server model, working in conjunction with DHCP [2] and using a system of IP messages for communication between participating Router Clients and Servers. It is easy to use as a labor-saving device in less secure environments and will work even in conjunction with unmodified DHCP Server implementations. However, it also has inherent security features and is capable of highly secure implementation. "Requirements for SIP Capabilities in PIDF", Paul Kyzivat, 16-Oct-02, This document sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF), as well as for guidelines on how to use these new elements with PIDF to represent the capabilities of a SIP User Agent Server. "IMAP UNSELECT command", Alexey Melnikov, 04-Jun-03, Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While [IMAP4] provides this functionality (via a SELECT command with an invalid argument), a more clean solution is desirable. [IMAP4] defines the CLOSE command that closes the selected mailbox as well as permanently removes all messages with the Deleted flag set. However [IMAP4] lacks a command that simply closes the mailbox without expunging it. This document defines the UNSELECT command for this purpose. A server which supports this extension indicates this with a capability name of 'UNSELECT'. "Max Allocation with Reservation BW Constraint Model for MPLS/DiffServ TE", Jerry Ash, 06-Mar-03, This document complements the DiffServ-aware MPLS TE (DSTE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) bandwidth constraint model. Examples of the operation of the MAR bandwidth constraint model are presented. MAR performance is analyzed relative to the criteria for selecting a bandwidth constraint model, in order to provide guidance to user implementation of the model in their networks. "OSPF extensions for flexible CSPF algorithm support", Satish Jamadagni, 18-Oct-02, The fundamental problem of Constrained Shortest Path First (CSPF) computation which is typical of quality of service routing, is that the problem is NP-hard. While standard approximation methods exist, their complexity may often be prohibitive in terms of scalability. Recently pre-computation and caching techniques have been suggested [3] [4] to achieve better on-demand computation costs. The motivation for pre- computation and path caching is to reduce as much of the on-demand computational overhead as possible. To fully utilize Pre-computation and caching of QoS paths at a source, mechanisms should be available to verify the validity of either the full or a partial subset of the pre-computed paths. The mechanisms should preferably support verification of the consistency of either partial or the full pre-computed path cache. In an IP control plane, CSPF is expected to work in conjunction with OSPF-TE [1] and RSVP-TE [2] protocols. To support CSPF algorithms that might want to use pre-computation and caching techniques rooted at a source or an identified core in the network, we propose mechanisms to dynamically setup OSPF 'virtual links' and describe setting up of 'virtual areas' to enable OSPF based selective network monitoring and updation. Such an extension will help deploy flexible CSPF algorithms that might be distributed, partially distributed or utilize pre-computation or caching techniques. "End-to-End VoIP over MPLS Header Compression", Jerry Ash, Bur Goode, 06-Mar-03, VoIP over MPLS typically uses the encapsulation voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP over MPLS header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). In this draft we propose to use RSVP extensions to signal the header compression context and other control messages between the ingress and egress LSR. We provide two approaches to determining the header compression context: a) re-use the methods in cRTP to determine the context, and b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the context. "End-to-End VoIP Header Compression Using cRTP", J.Ivan Ash, Bur Goode, Jim Hand, 06-Mar-03, VoIP typically uses the encapsulation voice/RTP/UDP/IP, wherein the packet header is at least 40 bytes, while the voice payload is typically no more than 30 bytes. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). In this draft we propose to re-use the methods in cRTP to determine the header compression context and to use the cRTP session context ID to route a compressed packet between the ingress and egress routers. "Secure Shell Public-Key Subsystem", Joseph Galbraith, Jeff Van Dyke, Charles McClure, 26-Jun-03, SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting a Shell or a Command''. The subsystem name used with this protocol is The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with a mandatory command. "IP over LAN Service (IPLS)", Himanshu Shah, 01-Jul-03, A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear to those systems as if they are interconnected on a private LAN. The systems which are interconnected in this way may themselves be LAN switches. If, however, the interconnected systems are NOT LAN switches, but rather are IP hosts or IP routers, certain simplifications are possible. We call this simplified type of virtual private LAN service an 'IP over LAN Service' (IPLS). In IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their MAC Destination Addresses. However, the maintenance of the MAC forwarded tables is done via signaling, rather than via the 'MAC Address Learning' procedures of IEEE 802.1D. Further, Address Resolution Protocol (ARP) messages are proxied, rather than being carried transparently. This draft specifies the protocols and procedures for support of the IPLS service. "IPv6 over Fibre Channel", Claudio Desanti, 20-Jun-03, Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and IPv4, as specified in [IP-FC]. The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network. "The XPointer xpath1() Scheme", Simon St.Laurent, 04-Nov-02, This document specifies an xpath1() scheme for use in XPointer-based fragment identifiers. This scheme, like other XPointer Framework [11] schemes, is designed primarily for use with the XML Media Types defined in RFC 3023 [5], to identify locations within a given XML representation of a resource. The xpath1() scheme uses XPath 1.0 syntax "National and Local Characters in DNS TLD Names", John Klensin, 21-Oct-02, In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about 'multilingual' or 'internationalized "PWE3 ATM Transparent Cell Transport Service", Andrew Malis, 21-Oct-02, The document describes a transparent cell transport service that makes use of the 'N-to-one' cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. "EAP support in smartcards", Pascal Urien, 01-Jul-03, This document will describe the interface to the EAP protocol in smartcards, which could store multiple identities associated to Network Access Identifiers. "Framework for IPsec Protected Virtual Links for PPVPNs", Mark Duffy, 21-Oct-02, This memo explores some choices that arise when IPsec is to be used to implement secure 'virtual links' interconnecting customer premises VPN devices and/or network based virtual routers. The main focus is on the network based cases. Requirements are proposed and some relevant aspects of the IPsec protocol suite are discussed. A number of different protocol architectures for virtual links are then evaluated. This memo is informational in nature; it is intended that it will focus discussion toward a standard in this area. "On reducing the number of TimeOuts for short-lived TCP connections", Urtzi Ayesta, Konstantin Avrachenkov, 21-Oct-02, This document shows that short TCP sessions are prone to timeout. In particular, one single segment loss will provoke TCP to timeout if the document size is below certain threshold. This document analyzes the benefit of TCP modifications such as Limited Transmit Algorithm [RFC3042] and Increasing Initial Window [RFC2414] in the context of short-lived TCP transfers. However TCP remains vulnerable to the losses at the very end of the transmission. Therefore we suggest complementary modifications to Limited Transmit Algorithm to recover effectively from losses at the end of the TCP transfer. "Resource Management in Diffserv Measurement-based Admission Control PHR", Lars Westberg, 22-Oct-02, The purpose of this draft is to present the Resource Management in Diffserv (RMD) Measurement-Based Admission Control (RIMA) Per Hop Reservation (PHR) protocol. The RIMA PHR protocol is used on a per- hop basis in a Differentiated Services (Diffserv) domain and extends the Diffserv Per Hop Behavior (PHB) with Measurement-based Admission Control features. "DHCP Option for Geographic Location", James Polk, 22-Oct-02, This document specifies a Dynamic Host Configuration Protocol option for the geographic location of the client. The location includes latitude, longitude, and altitude, with resolution indicators for each. "A Recovery Mechanism for Signaling Compression", Zhigang Liu, 05-Nov-02, This document defines a recovery mechanism for signaling compression (SigComp). It allows a decompressor to signal to its peer compressor in case it has lost synchronization with the compressor. The compressor can thereafter take appropriate recovery actions. The signals are carried using the state announcement mechanism as defined in SigComp. "Diameter Command Codes for 3GPP Release 5", John Loughney, 04-Dec-02, This document authorizes IANA to allocate a block of Diameter command codes for the Third Generation Partnership Project Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. "EPP transport mapping for SMTP", Eric Brunner-Williams, 22-Oct-02, This document describes how to exchange EPP content using SMTP transport. The data is packaged using standard MIME content-types. Authentication and data security are obtained by using OpenPGP security body parts or Cryptographic Message Syntax (S/MIME). Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message. "IANA Allocation Guidelines for Values in IPv6 and Related Headers", Thomas Narten, 22-Oct-02, This document provides guidelines to IANA on the procedures for assigning values for various IPv6-related fields. This document updates and replaces the IPv6-related guidelines in RFC 2780. "Link Management Protocol Extensions for Link discovery Using Loss of Light", Richard Bradford, Dimitri Papadimitriou, Dan Tappan, 11-Apr-03, This document proposes an enhanced mechanism for Link Management Protocol’s Link Verification procedure that is independent of the data encoding type. It can be used for any point-to-point link, including both Optical Links and SONET/SDH Links. The general proposal is to use the transmission of light by the sender and recognition of the presence or absence of light by the receiver to identify port mapping. The proposal includes minor extensions to the existing messages to implement this extension to the link verification procedure. "The PWE3 Control Word", Jonathan Stein, 22-Oct-02, Control words are used by PWE3 service emulations to carry information needed by the PWE3 Encapsulation Layer and the PSN Convergence Layer. The generic PWE3 documents do not specify the format of this control word and hence contradictory control word formats have proliferated in the various service encapsulation documents. We present an analysis of these control words and a suggestion for a single unified control word family. "Security Considerations for 6to4", Pekka Savola, 08-Jan-03, The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes Relay Routers and Routers, which accept and decapsulate IPv4 traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. "Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU)", Anwar Siddiqui, 23-Oct-02, This memo defines a common protocol data unit (PDU) used between RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report a QOS statistics using RTCP and SNMP as Transport Protocol. The original RAQMON draft [SIDDIQUI3] was split into 3 parts to identify the RAQMON Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined RAQMON QOS Protocol Data Unit (PDU). This memo also outlines mechanisms to use Real Time Transport Control Protocol (RTCP) and Simple Network Management Protocol (SNMP) to transport these PDUs between RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) as outlined in RAQMON Charter of the RMON Workgroup. The memo [SIDDIQUI2] defines a Real-Time Application QOS Monitoring (RAQMON) Framework that extends the RMON Framework to allow Real-time Application QoS information as outlined by RAQMON Charter of the RMON Workgroup. The memo [SIDDIQUI1] defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solution. Distribution of this memo is unlimited. "Link Bundling support for Diff-Serv aware Traffic Engineering", Siva Sivabalan, Francois Le Faucheur, Raymond Zhang, 23-Jun-03, This document describes how bandwidth-related MPLS Traffic Engineering parameters need to be advertised for a bundled link in order to support Diff-Serv aware Traffic Engineering. "Terminology for Benchmarking Core Router Software Accelerated Life Testing", Scott Poretsky, Ray Piatt, Sira Rao, 05-Mar-03, This terminology document provides the terms to be used for benchmarking router software under accelerated stress conditions. A framework is defined to configure routing protocols, security policies, traffic forwarding, and management. Conditions to produce instability and accelerate operational conditions are also defined. Benchmarks for evaluating a router subjected to the accelerated life test are introduced. The DUT configuration and accelerated stress conditions emulate those of Internet Core routers. "Draft of agreement between ISOC/IETF and SO/IEC JTC1/SC6 on IS-IS protocol development", Alex Zinin, 23-Dec-02, This document contains a proposed text of the agreement between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. Please send any comments on this document to the IESG (iesg@ietf.org) "Caching Mechanisms in Layered DNS Search Services", Xiaohong Shi, Karen LIU, 24-Oct-02, John Klensin proposed a multi-layered search-based access model for the DNS to address more human-friendly naming and navigation need of the modern Internet [DNSSEARCH]. When deploying the DNS search system in the global Internet, stability and scalability are two most important factors no matter what protocol we finally use. This draft demonstrates that caching is a significant objective for a stable and scalable DNS search system. Particularly, this document analyzes statistical operational data collected from our Keyword service. The collected data clearly demonstrates the potential high impact of caching in the resolution process. Based on deployment experience, the document describes alternative caching methods. From there, basic caching requirements for DNS Search systems are discussed. The goal of this document is not to propose some standard caching mechanisms or methods but to emphasize the necessity of caching for DNS Search systems. Furthermore, the authors believe that the proven high efficiency of caching should be an important consideration when designing the future lookup protocol for such systems. "Integrating layered DNS search services within user agents", Xiaohong Shi, Karen LIU, 24-Oct-02, This document presents a user perspective to the notion of DNS search layers as defined by John Klensin's DNS search model [DNS_SEARCH]. In particular, the authors look at the integration of name lookup results from layer 2, 3 and 4 services to discuss the presentation of these results across popular desktop applications such as Web browsing and email clients. The goal of this document is not to propose a standard UI to the DNS search problem (clearly something out of the scope of any IETF work). Instead, the document seeks to demonstrate that layered search services can be easily integrated within traditional desktop applications; hence that deployment of DNS search services is realistic and could rapidly be achieved. It is important to understand that the proposed form of integration and choice of user interfaces are not fundamental. In fact, the authors expect many competing systems to pursue different alternative solutions. However, in order to achieve critical deployment mass, it is crucial to demonstrate that the architectural model proposed by DNS search lends itself to simple user interfaces where different and possibly competing services can complete each other to provide a more precise and complete navigation experience for the end-user. This draft attempts to fulfill that goal by looking at possible solutions for popular navigation use cases. "Moving from 6bone to IPv6 Internet", Pekka Savola, 07-Nov-02, Currently, IPv6 Internet is, globally considered, inseparable from the 6bone network. The 6bone has been built as a tighly meshed tunneled topology. As the number of participants has grown, it has become an untangible mess, hindering the real deployment of IPv6 due to low quality of connections. This memo discusses the nature and the state of 6bone/IPv6 Internet, points out problems and outlines a few ways to start fixing them; also, some rough operational guidelines for different-sized organizations are presented. The most important issues are: not offering transit to everyone and real transit operators being needed to take a more active role. "Requirements for Diagnostics Support in SIP", J Kuthan, 24-Oct-02, Session Initiation Protocol (SIP) provides only limited space for communicating diagnostic information when errors occur. To facilitate troubleshooting, automated error detection, and reporting we propose to create new protocol extensions. The extensions will be used for richer reporting on request processing status. Particularly, we suggest that User Agent Servers (UAS) include additional information about error reasons in negative replies, and proxy servers indicate in relayed requests the routing logic they used. "Requirements for Instant Messaging in 3GPP Wireless Systems", Aki Niemi, 04-Mar-03, This document lists the requirements specific to 3GPP wireless Instant Messaging systems. "NSIS Network Address Translator implications", Cedric Aoun, 07-Mar-03, This Internet draft discusses Network Address Translators impacts on in path directed signaling. The purpose of this memo is to provide inputs to the NSIS WG on Middlebox specific considerations. "Advice on Writing an Internet Draft Amenable to Security Analysis", Carol Meadows, 24-Oct-02, In this document we give guidelines for writing Internet Drafts in order to facilitate their security analysis. By 'security analysis' we mean, not only informal analyses, but formal analyses using automated tools, and mathematical analysis of the cryptographic protocols used in an Internet Draft. "Unstructured TDM Circuit Emulation Service over Packet Switched Network (UCESoPSN)", Sasha Vainshtein, 24-Oct-02, This document describes a method for encapsulating unstructured TDM digital signals as pseudo-wires (PWs) over various packet-switched networks (PSN). In this regard it complements similar work for SONET/SDH circuits. "CLI-based Mediation Mechanism using XML for Configuration Management", Byung-Joon Lee, Taesang Choi, 25-Oct-02, Currently, there is an ongoing activity in the IETF to define a standard, XML-based protocol to manage the configuration of networks and networking equipments. Defining initial requirements are underway and one important requirement among them is co-existence with the CLI. This document suggests a possible mechanism for this requirement. It identifies some characteristics of CLI commands, and provides the syntax of XML template which models such characteristics of CLI commands. X-CLI is an API to manipulate XML templates in an easy and robust way. "Network Discovery Protocol (NETDIS)", Guillaume Bichot, 21-Mar-03, This document describes the Network Discovery Protocol (NETDIS), a protocol that provides a way to broadcast information about the network service accessible through the access network where the information is broadcasted. This allows several service providers to share the same access network. The public WLAN access network is particularly targeted by this protocol. As a result a mobile terminal listening NETDIS announcements discovers the list of Service providers (Virtual WLAN operator) supported by the WLAN it is currently attached. "Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers", Ralph Droms, 25-Oct-02, 'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP messages exchanged between relay agents and servers are not subject to attack. This document describes how IPsec can be used to protect messages exchanged between relay agents and servers. "GR-303 extensions to the IUA protocol", R Mukundan, Ken Morneault, 25-Oct-02, This document defines a mechanism for backhauling of GR-303 [2] messages over IP by extending the ISDN User Adaptation Layer Protocol [3] and to be the base for a GR-303 User Adaptation (GR- 303UA) implementation. "Extended IEEE802.1x Support Authentication of users sharing a Single Ethernet Port", Runtong Zhang, 25-Oct-02, IEEE802.1x standard provides a method to authenticate users based on port and does not support authentication of multi-user sharing a single port.This document extended IEEE802.1x to support authentication of users sharing a single ethernet port.Also this document makes modification to the EAP(The Extensible Authentication Protocol, defined in [RFC2284])message. "Path Quality Verification over an All-Optical Network", Shoichiro Seno, Kazunori Konishi, 25-Oct-02, This draft proposes a framework for path quality verification over an all-optical network. Because it will be difficult to ensure quality of a dynamically established path over an all-optical network, it may be useful for network providers to have means to verify quality of a path before it is served to the subscribers. This draft proposes a framework for such means, including requirements behind them and a path continuity check mechanism to verify optical-level path quality upon a path's establishment by the GMPLS signaling. "SIMPLE PIDF presence capabilities extension", Mikko Lonnfors, Krisztian Kiss, 27-Jun-03, Interoperation of Instant Messaging and Presence systems has been defined in IMPP Working Group. IMPP WG has come up with baseline interoperable operations and formats for Presence and Instant Messaging systems. However, these base formats might need standardized extensions in order to enable building rational applications using Presence and Instant Messaging. This memo proposes an extension to PIDF presence document format to be used in SIMPLE based Presence systems [1] but may also be applied to other protocols as well. "Multihomed Loadsharing", Jay Kumarasamy, Lode Coene, 25-Oct-02, This document describes a way to loadshare the different paths of a multihomed SCTP association at the same moment while keeping congestion control per path. "Provider-Internal Aggregation based on Geography to Support Multihoming in IPv6", Iljitsch van Beijnum, 25-Oct-02, Current 6bone backbone routing guidelines prohibit traditional multihoming in IPv6, because current IPv4-style multihoming doesn't scale. This stands in the way of successful adoption of IPv6. The solution outlined in this memo proposes aggregating the routing information for multihomed destinations inside service provider networks based on geography to accomplish scalable multihoming in IPv6 using current protocols and implementations. This solution does not require network operators to increase the density of interconnection; nor does it require significant cooperation or simultaneous adoption. "AVT Tones (RFC 2833) Interoperability Statement", Robert Sparks, 25-Oct-02, It is required to demonstrate interoperability of AVT Tones implementations in order to move that specification to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. "A Proposal to Improve IETF Productivity", Geoff Huston, Marshall T. Rose, 25-Oct-02, The IETF standards process must exhibit four qualities (Predictability, Accountability, Competency, and Timeliness), which we term 'the IETF Pact'. Growth in the IETF's size and diversity challenges its ability to make progress in producing useful specifications. This proposal puts forward procedural changes that will improve the IETF PACT, without altering the IETF's philosophy or structure, and without requiring changes to the formal IETF standards process (cf., RFC 2026 [1]). "Network Mobility Support Terminology", Ted Ernst, Hong Lach, 05-Nov-02, This document proposes a terminology for defining network mobility problems and solution requirements. Network mobility occurs when an entire network changes its point of attachment to the Internet and thus its reachability in the topology, which is referred to as a mobile network "Semantics for DHC Location Object within GEOPRIV", James Polk, 28-Oct-02, This document describes the semantic intent of the proposed Location Object (LO) within DHC ID [1] for use by the GEOPRIV Protocol. Reasons are provided for the choice of representation of location resolution, and examples illustrate the use of this choice. "Simple Authentication and Security Layer C API", Chris Newman, Alexey Melnikov, 18-Feb-03, Almost every protocol needs authentication. However, there does not exist an authentication mechanism suitable for all organizations, nor is it likely that a small fixed set of authentication mechanisms will remain suitable. SASL [SASL] provides the on-the-wire framework for authentication (and a security layer) which separates the design of authentication mechanisms from the protocols in which they're used. The SASL protocol model suggests a software architecture where application protocols call a generic API to authenticate which in turn calls a generic plug-in interface for extensible authentication modules. This memo documents the API used in one implementation of this architecture in the hope that it will be useful to others. An associated memo documenting the plug-in interface is forthcoming. "OSPF Traffic Engineering capability TLVs", Jean Vasseur, Peter Psenak, 28-Oct-02, This draft proposes OSPF traffic engineering capability TLVs. Two capability TLVs are defined in the current draft: the Path Computation Server Discovery (PCSD) TLV that allows a router to announce its Path Computation Server capability to other LSRs within an OSPF area or a routing domain and the Mesh-group TLV used by an LSR to indicate its desire to participate to a mesh of Traffic Engineering Label Switched Path (this mesh of TE LSPs is identified by a mesh-group number). They are both used in the context of MPLS Traffic Engineering. Additional OSPF TE capability TLVs may be added in further revision of this draft. Those OSPF TE capability TLVs will be carried within the OSPF router information LSA (opaque type of 4, opaque ID of 0) defined in [18]. "Distinguish a link from a node failure using RSVP Hellos extensions", Anna Charny, Jean Vasseur, 28-Oct-02, The aim of this draft is to provide a method to distinguish a link from a node failure using RSVP hello extensions. In a network making use of MPLS Traffic Engineering Fast Reroute as specified in [FAST-REROUTE], efficient use can be made of the network links when protecting against link/node failures. As described in [FACILITY], excess capacity used for bypass tunnels can be shared between bypass tunnels providing protection for mutually exclusive failures of different links or nodes. This results in significant bandwidth savings under the single failure assumption. Making use of the single failure assumption implies the need to distinguish a link from a node failure. However, the mechanisms currently available for failures detection do not always allow to distinguishing a link from a node failure. "ROHC-TCP Early Compression", Yousuf Saifullah, 28-Oct-02, This document specifies Early Compression Enabler for ROHC-TCP to increase compression gain. The enabler provides a generic platform to implement an early compression mechanism. An early compression mechanism is an out-of-band mechanism that populates the ROHC-TCP decompression context with some of the header fields before the ROHC- TCP initialization step. ROHC-TCP does not need to carry those fields, thus early compression provides compression from the very first TCP packet and increases the compression gain. It is especially useful for short-lived TCP connections. The document describes the working of Early Compression Enabler as part of ROHC-TCP. It also specifies protocol changes for the ROHC-TCP protocol. It does not specify any particular early compression mechanism. "ROHC-TCP Early Compression in GPRS Networks", Yousuf Saifullah, 28-Oct-02, This information document gives an example of early compression mechanism from the GPRS networks. It shows a utilization of the early compression enabler enhancements proposed for ROHC-TCP. It does not show an exhaustive use of all the options of the enabler, but rather shows a use of the basic enabler function. "Available Bandwidth Measurement in IP Networks", Tricha Anjali, 28-Oct-02, Available bandwidth along a path is an important metric that can be useful to provide insight into the state and performance of the network. Some methods have been proposed in literature for measurement of available bandwidth but they face the problems of scalability and high intrusiveness. In this draft, we propose a method to measure path available bandwidth using an active approach that probes the path. The probing mechanism used is based on TCP New Reno. Once the samples for the available bandwidth measurement are obtained, more accurate results are calculated using a prediction filter. "Instant Message Transport Sessions using the CPIM Message Format", Ben Campbell, 28-Oct-02, Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. Each message can be sent independently using the SIP MESSAGE method, or messages can be associated into sessions that are initiated using SIP. The first approach is often referred to as pager-mode messaging, due to its similarity to the behavior of two way pager devices. The second approach is often called session-mode messaging, or simply message sessions. This document describes a message session mechanism based on the Common Presence and Instant Messaging message format. "Instant Message Sessions in SIMPLE", Ben Campbell, Jonathan Rosenberg, 06-Mar-03, The SIP MESSAGE method is used to send instant messages, where each message is independent of any other message. This is often called pager-mode messaging, due to the fact that this model is similar to that of most two-way pager devices. Another model is called session-mode. In session-mode, the instant messages are part of a media session that provides ordering, a security context, and other functions. This media session is established using a SIP INVITE, just as an audio or video session would be established. This document describes a The Message Session Relay Protocol (MSRP), a mechanism for transmitting session-mode messages with minimal relay support. Additionally, this document describes using the SDP offer/ answer model to initiate such sessions. "The Use of RSA Signatures within ESP and AH", Brian Weis, 28-Oct-02, This memo describes the use of the RSA Signature algorithm [RSA] as an authentication algorithm within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. The use of a digital signature algorithm such as RSA provides origin authentication, even when ESP and AH are used to secure group data flows. Further information on the other components necessary for ESP and AH implementations is provided by [ROADMAP]. "MPLS-TE Shared Mesh Protection", Akber Qureshi, 28-Oct-02, This document discusses the shared mesh protection concept. Its aim is to provide fast, guaranteed recovery of service at significantly less cost of protection capacity compared to other schemes. In companion documents [1,2], extensions to RSVP-TE and OSPF-TE protocols are proposed that enable shared mesh protection. Those extensions, together with this document, first address global repair with path-based protection switching, as opposed to local repair of LSP failures and reroute. However, the concept can be extended straightforwardly to the local repair techniques being considered in the MPLS working group. "OSPF-TE Extensions for Shared Mesh Protection", Ajay Sathyanath, 28-Oct-02, This document describes extensions to the OSPF[1]/OSPF-TE[2] protocol to support Sharing/Restoration information, using opaque LSAs. The extension presented here enables the source router to obtain a backup route to a destination such that minimal amount of protection bandwidth reservation is needed. In other words, we provide a method by which one may easily increase sharing of backup links significantly, without having to go through each and every possible backup route. "RSVP-TE Extension for Shared Mesh Protection", Hong Liu, 28-Oct-02, This document describes the use of RSVP [RSVP, RSVP-TE] to establish shared protection LSP tunnels. The method presented enables the set up and reservation of resources of protection LSPs while sharing the network protection bandwidth. The described use of RSVP allows the protection LSP to be established without changes to a pre-existing OSPF-TE protocol. Of course, A 'TE' routing protocol is not required, but would be desirable as it would reduce the number of crank-backs. In the companion draft [Shared- OSPF-TE], extensions to OSPF/OSPF-TE are presented that enable further optimized operations to support efficient sharing of protection bandwidth. "Definition of an NAA naming format for iSCSI Node Names", Marjorie Krueger, 28-Oct-02, iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP [iSCSI]. This document defines an additional iSCSI node name type format to enable use of the NAA world wide naming format used by ANSI T11 Fibre Channel protocols. It is hoped that this definition would enable storage devices containing both iSCSI and FC ports to use the same NAA-based SCSI device name. "Signaling Requirements for LCAS based Applications", Krishna Pattabhiraman, 28-Oct-02, With LCAS and VCAT, the transport layer is capable of not only providing right-sized data pipes, but also elastic pipes. Fluid transport pipes spur services like frame-relay transport (CIR, EIR) and intelligent COS-aware protection. The popular protocol used to convey control information in SONET networks is GMPLS. There are two aspects of control mechanisms for a connection: call-control and connection-control. Call-control is used to establish a signaling association between two end-points, whereas connection-control is used to setup and modify the attributes (e.g., bandwidth) of an transport connection. This draft deals with signaling requirements for connection-control of elastic pipes. "GAPI: A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv6", M Py, Iljitsch van Beijnum, 28-Oct-02, This document establishes an address allocation framework for Geographically Aggregatable Provider Independent (GAPI) IPv6 addresses for the purpose of multihoming. A /16 is divided in a hierarchical manner over geographical entities such as parts of continents, countries, states, provinces and metropolitan areas, with each receiving one or more /32 allocations from which end-user assignments can be made. The number of /32 allocations for a geographical entity depends on the current population. This address allocation framework in itself does not present a scalable multihoming solution, it merely provides a necessary building block for such solutions. "DHCP Server-ID Override Suboption", Richard Johnson, 28-Oct-02, This memo defines a new suboption of the DHCP relay information option [6] which allows the DHCP relay to specify a new value for the Server-ID option, which is inserted by the DHCP Server. In some cases it is convenient for the DHCP relay to act as the actual DHCP server such that DHCP RENEWAL requests will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on RENEWAL messages. This new relay agent suboption allows the relay to tell the DHCP server what value to use in the Server-ID option [3]. If this suboption is not present, the server should build the Server-ID option in the normal fashion. "DHCP Subscriber ID Suboption for the DHCP Relay Agent Option", Richard Johnson, Ralph Droms, 28-Oct-02, This memo defines a new DHCP Relay Suboption for passing an arbitrary number of bytes defining what will be called the 'Subscriber ID'. This value is simply defined as an array of bytes and can be interpreted in any form by the DHCP server. Its intended purpose is to give additional information which the DHCP server can use in address allocation. "Subnet Allocation using DHCP", Richard Johnson, 28-Oct-02, This document defines a new DHCP option which is passed between the DHCP Client to the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. "Session Initiation Protocol Call Control - Conferencing for User Agents", Alan Johnston, Orit Levin, 11-Feb-03, This document defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. "OSPF-TE Extensions in Support of Shared Mesh Restoration", Hong Liu, 29-Oct-02, This document describes extensions to the OSPF-TE routing protocol in support of path computation for shared mesh restoration. New optional sub-TLVs are added to the link TLV of the Traffic Engineering (TE) LSA so that the sharing information of the restoration resource on the TE link reserved for shared mesh restoration is disseminated. The extensions supports both SRLG-disjoint and node-disjoint paths. "Guidelines for Mandating the Use of IPsec", Steven Bellovin, 29-Oct-02, The Security Considerations sections of many Internet Drafts say, in effect, 'just use IPsec'. While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec should and should not be specified. "Microsoft's PEAP version 0 (Implementation in Windows XP SP1)", Vivek Kamath, Ashwin Palekar, Mark Wodrich, 29-Oct-02, This specification documents the implementation of PEAP supported in Windows XP SP1. This implementation utilizes a version number of zero (0) and supports acknowledged and protected success and failure indications, using the EAP Extensions method, Type 33. "MPLS Inter-AS Traffic Engineering requirements", Runtong Zhang, Raymond Zhang, Jean Vasseur, JP Vasseur, 14-May-03, This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). The main objective of this document is to present a set of requirements which would result in a set of general guidelines in the definition, selection and specification development for any technical solution(s) meeting these requirements. "An Extension to the Session Initiation Protocol for Request History Information", Mary Barnes, 11-Feb-03, This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, HistInfo, to be included in the Supported header is defined to allow UAs to indicate whether the HistInfo should be returned in responses to a request which has captured the history information. "Entity State MIB", Sharon Chisholm, David Perkins, 29-Oct-02, 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 extensions to the entity MIB to that provide information about the state of the entity. "GMPLS RSVP Support for the Overlay Model", George Swallow, 29-Oct-02, Generalized MPLS defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. "Protocol Liveness Protocol", Kireeti Kompella, 29-Oct-02, This document describes a protocol to determine the liveness of routing protocols such as OSPF and BGP. The basic idea is to have a single simple mechanism for liveness for all protocols, and thereby to allow fast detection of failures. "enumservice registration for SIP Addresses-of-Record", Jon Peterson, 29-Oct-02, This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. "GVPLS/LPE - Generic VPLS Solution based on LPE Framework", Vasile Radoaca, 01-Jul-03, This document describes distributed virtual private LAN service (VPLS) solution over MPLS using LDP signaling. For VPLS solutions, the VPLS Reference Model [VPLS-L2-FRW] introduces two types of models: distributed and non-distributed. While [VPLS] solution presents a non-distributed model, it is recognized that both models may co-exist in the same SP network. This implies a need of signaling mechanisms to support these new classes of solutions. The current draft presents the GVPLS solution that addresses such issues. The term 'Generalized' in this document is used to reflect the unified aspect of the two models. "Framework for GMPLS Label Encoding", Jin Choi, 06-Mar-03, Generalized Multiprotocol Label Switching (GMPLS) extends the MPLS control plane to encompass packet switching, time-division, lambda and fiber switching. The new forms of label which used in GMPLS to deal with the widening scope of MPLS into the optical and time domain are collectively referred to as a 'Generalized Label'. In this draft for extending MPLS label specification [5], we describe the concept and characteristics of Generalized Label for GMPLS. We also discuss the format and considerations for label encoding. Particularly we present the necessity of mapping rule at ingress and egress switching interface where data flows with label of a different granularity are merged into the aggregated data flow of large bandwidth. "Signaling Interworking for IPv6 Network", Jin Choi, 29-Oct-02, In this draft, we describe the features and requirements of QoS signaling in IPv6 network to explain the needs of end-to-end QoS signaling. We discuss the signaling interworking between IPv6 network and other network. The delivering methods of signaling messages in IPv6 network are also presented in Appendix. "A Firewall/NAT Traversal Client for CASP", Hannes Tschofenig, Henning Schulzrinne, Cedric Aoun, 07-Mar-03, This document describes a CASP client protocol that allows nodes to signal information to firewalls both in an in-path and off-path fashion. The protocol furthermore allows to establish a NAT binding and to provide the signaling initiator with the NAT information. This is information can then be used within other protocols such as SIP. "Autoconfiguration of routers using a link state routing protocol", Arthur Dimitrelis, Aidan Williams, 29-Oct-02, This memo documents our thinking to date regarding the use of version 3 of the Open Shortest Path First (OSPF) protocol as a mechanism for the autoconfiguration of IP routers within an OSPF area. Specifically, a method for the allocation and distribution of IPv4 and IPv6 subnet addresses without explicit configuration is described. Such a mechanism would be useful in an environment where routing is desirable, but the network administration skills necessary to configure IP routers are not available. This draft presents zOSPF (zeroconfigutaion OSPF), a protocol based on OSFPv3 that will allow routers to self configure and forward IPv4 and IPv6 traffic. "Routing Architecture Building Blocks: an Informational Taxonomy", Howard Berkowitz, 29-Oct-02, This document identifies and categorizes the components of routing, switching, forwarding, and addressing that may be used in routing architectures. The intention is to support the development of a new routing architecture for the Internet. The addressing architecture, address allocation and assignment principles, and possibilities for renumbering are important aspects when designing a routing architecture. How routing information is learned and methods for distributing it are other issues discussed in this document. A number of methods for data traffic forwarding are also described and evaluated "DCLOR: De-correlated Loss Recovery using SACK option for spurious timeouts", V Swaminathan, Khiem Le, 01-Apr-03, A spurious timeout in TCP forces the sender to unnecessarily retransmit one complete congestion window of data into the network. In addition, TCP uses the rate of arrival of ACKs as the basic criterion for congestion control. TCP makes the assumption that the rate at which ACKs are received reflects the end-to-end state of the network in terms of congestion. But after a spurious-timeout, the ACKs don't reflect the end-to-end congestion state of the network, but only a part of it. In these cases, the slow-start behavior after a timeout can further add to network congestion instead of relieving it. In this draft we propose changes to the TCP sender (no change is needed for TCP receiver) that can be used to solve the problems of both redundant-retransmission and network congestion after a spurious timeout. These changes preserve the sanctity of congestion control principles and are conservative in nature. The proposed algorithm--called DCLOR--separates congestion control from loss recovery, and uses the TCP SACK option to achieve this. DCLOR can be used as a congestion control algorithm (after a spurious timeout) only, and it can work with other spurious timeout detection mechanisms such as the Eifel detection scheme. "Protocol Actions for Virtual Router VPNs", Paul Knight, 29-Oct-02, This document identifies elements of the protocols used by the 'Virtual Router' Provider Provisioned VPN architecture which may need to be coordinated with IETF Working Groups other than the PPVPN WG. The primary focus of coordination identified in this document is with the IPSEC WG. This document is for temporary administrative purposes. "Requirements for Assured Service Capabilities in Voice over IP", Michael Pierce, Don Choi, 26-Jun-03, Assured Service refers to the set of capabilities used to ensure that critical communications are setup and remain connected. This memo describes the requirements for such capabilities in support of specific networks such as those used by government agencies, but they could also be applied in commercial environments. "Architecture for Assured Service Capabilities in Voice over IP", Michael Pierce, Don Choi, 26-Jun-03, Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. This memo describes the architecture required to meet the requirements detailed in [Pierce1]. "Examples for Provision of Preferential Treatment in Voice over IP", Michael Pierce, Don Choi, 26-Jun-03, Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. [Pierce1] describes the requirements, one of which is to provide preferential treatment to higher priority calls. IEPS refers to a set of capabilities used to provide a higher probability of call completion to emergency calls made by authorized personnel, usually from ordinary telephones. This also requires some form of preferential treatment. This memo describes some of the methods which may be applied to provide that preferential treatment. "Generalized MPLS Architecture for Multi-Region Networks", Martin Vigoureux, 01-Jul-03, Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments of single switching capability devices e.g. one data plane layer, as such, the complexity raised by such control planes is similar to the one expected in classical IP/MPLS networks. The fundamental reason being that an IP-based control plane protocol suite for Label Switch Routers (LSR) or Optical Cross-Connects (OXC) has exactly the same Level (i.e. single data plane layer) complexity. The present document analyses the various GMPLS signaling and routing aspects when considering network environments consisting of multiple switching data layers e.g. supporting combined Packet/Layer-2 Switching - OXC devices. The examples provide an overview of the tradeoffs in using a GMPLS control plane for combined Ethernet MAC - opaque, service transparent, and/or fully transparent data planes. The intent of this memo is also to demonstrate that these aspects may not be as straightforward as they may first appear. "BGP Custom Decision Process", Alvaro Retana, Richard White, 29-Oct-02, The BGP specification [RFC1771] defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community [EXT_COMM], called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. "MultiAccess Reachability Protocol (MARP)", Alvaro Retana, Richard White, 06-Mar-03, This document defines a protocol to quickly determine the existence or aliveness of devices attached to a shared media (broadcast) subnet. While the examples used are narrowly defined for simplicity, the protocol could be applied to other situations as well. "Selectively Reliable Multicast Protocol (SRMP)", Mark Pullen, 19-Jun-03, The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can be used to carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer that combines short messages, peforms NAK suppression, and incorporates the TCP-Friendly Multicast Congestion Control of Widmer and Handley, dropping best- effort traffic in order to achieve congestion control; and a selectively reliable transport (SRT) sublayer that formats best- effort and reliable transmissions and also creates negative acknowledgements when loss of reliable messages is detected. In SRMP, selection between reliable and best-effort messages is performed by the application. The protocol bundles messages within a configured time interval, attempting to achieve a configured bundle size which typically is set to the expected smallest MTU in the delivery path. The bundle header carries the latest sequence number for each reliable transmission. Rate reduction is achieved when necessary by dropping best-effort messages at random. "Sender and Receiver Orientation Issues in NSIS", Robert Hancock, 29-Oct-02, The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2] and a framework in [3]. It is clear from existing work that there are many interrelated issues with NSIS signaling, concerning the respective roles of the two ends of the communication path. These issues include route finding, authorisation, state management requirements, localization of negotiation, and so on. The wide variety of problems involved hinders progress in deciding what approach NSIS should adopt. This Internet Draft attempts to provide a summary of these issues and suggests a way of structuring further analysis. It is not expected that this document should have a long term existence. "Regional Mobile IPv6 mobility management", Kyungjoo Suh, 29-Oct-02, This document defines a new protocol, namely, Regional Mobile IPv6 mobility management (RMM/RMIPv6). RMM mechanism satisfies the LMM requirements while it is more flexible mobility management scheme than existing solution, for example HMIPv6. This document therefore describes methods to be used to reduce the amount of signaling to the Home Agent and Correspondent Nodes. In addition, this scheme is flexible enough to adapt to any network topology assumed by IPv6. The network that using RMM/RMIPv6 is robust against the failure or the performance degradation. The mechanism is intended to reuse the Care of Address. Moreover, the forwarding tunnel length from an anchor point to a Mobile Node can be a controllable or configurable. "Problem Statement for Triggers for Transport(TRIGTRAN)", Spencer Dawkins, 06-Mar-03, When transport protocols are deployed over a path including a wireless sub-network, a wireless access device now has significantly better knowledge of the wireless portion of the connection path characteristics than one or both endpoints. End-to-end mechanisms continue to work (see [PILC] and related specifications), but must rely on communication over a sub- network link that experiences outages and degradation. This document will set the framework for investigation of whether this special knowledge from wireless access devices can be useful to endpoint transports. While the initial focus is on wireless links, other links will also be taken into account. "An Implementation Guide for RTP MIDI", John Lazzaro, John Wawrzynek, 02-Jun-03, This memo offers non-normative implementation guidance for the RTP MIDI payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. "Extensions to BGP to Support Secure Origin BGP (soBGP)", James Ng, 23-Jun-03, There is a great deal of concern over the security of routing systems within the Internet, particularly in relation to the Border Gateway Protocol [BGP], which is used to provide routing information between autonomous systems. This document proposes a system where the origin of any advertisement within BGP can be verified and authenticated, preventing the advertisement of prefix blocks by unauthorized networks, and verifying that the final destination in the path is actually within the autonomous system to which the packets are being routed. "Deployment Considerations for Secure Origin BGP (soBGP)", Russ White, 25-Jun-03, There is a great deal of concern over the security of routing systems within the Internet, particularly in relation to the Border Gateway Protocol [BGP], which is used to provide routing information between autonomous systems. This draft addresses various deployment scenarios and options using the extensions to BGP outlined in [SOBGP-BGP] in conjunction with [SOBGP-KEY] (which is not yet completed or published) and [SOBGP-RADIUS]. Each section of this draft discusses a different deployment situation or deployment option. The final section discusses how private key rollovers can be accomplished with no loss of routing information within soBGP deployments. "Indicating Resolver Support for AAAA Records", John Reid, Suzanne Woolf, 30-Oct-02, In order to simplify the deployment of AAAA records in the DNS, name servers should only perform automatic inclusion of these RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. "Generic Threats to Routing Protocols", Bob Beard, 04-Mar-03, Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. The lack of a common set of security requirements has led to the use in existing routing protocol of a variety of different security solutions, which provide various levels of security coverage. The RPSEC working group intends to deliver in a separate document a set of security requirements for consideration of routing protocol designers. The first step in developing the security requirements is to analyze the threats that face routing protocols. This document describes the threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. "Privacy and Security Considerations in ENUM", Richard Shockey, 30-Oct-02, Many individuals and groups have expressed concerns about the privacy and security of personal information to be established in implementations of RFC 2916. This document discusses some of the technical as well as security and privacy considerations national implementations of ENUM should consider. This is a work in progress. Input from security and privacy experts is welcome. "Split Multi-link Trunking (SMLT)", Roger Lapuh, Dinesh Mohan, 21-Feb-03, This document describes SMLT. When building redundant bridging networks, IEEE 802.3ad offers link redundancy as a measure against the link failures. SMLT additionally offers node redundancy by allowing IEEE 802.3ad links of a link-aggregated group to be dual homed across two aggregation bridges. SMLT provides data plane and control plane to avoid inherent loops and makes full usage of all links in a link-aggregated group. The dual homing remains transparent to a device connecting to the two aggregation bridges. "Requirements for Protecting Control Channels in GMPLS", Yong-Hwon Kim, 30-Jun-03, This document describes base requirements for protecting control channels(CCs) for GMPLS. It provides guidelines needed in order to switchover an active CC to one of standby CCs when a failure occurs about the active CC. It defines terminology, base concepts, necessities, and considerations that should be noted primarily in order to complete the mechanism of CC protection. This document describes requirements for providing resilience capabilities of control plane in GMPLS whose control channel can be separated from the data channel. This contribution, as a document that proposes the necessity about resilience of control plane like that of transport plane, handles related terminologies, base concepts, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP. "IPv4-Mapped Address API Considered Harmful", Christopher Metz, Jun-ichiro Hagino, 30-Oct-02, The IPv6 Addressing Architecture [Hinden, 1998] defines the 'IPv4-mapped IPv6 address.' This representation is used in the IPv6 basic API [Gilligan, 1999] to denote IPv4 addresses using AF_INET6 sockets. The use of IPv4-mapped addresses on AF_INET6 sockets degrades portability, complicates IPv6 systems, and is likely to create security problems. This document discusses each issue in turn. Finally, it proposes to resolve these problems by recommending deprecation of this mechanism. "Core Privacy Protections for Geopriv Location Object", James Morris, 06-Mar-03, The working group has generally agreed that the Geopriv Location Object MUST be able to contain a limited set of Privacy Rules. This Internet-Draft suggests the set of Privacy Rules that the authors believe should be includable in the Location Object. "Session Description Protocol Offer Answer Examples", Alan Johnston, Robert Sparks, 06-Mar-03, This document gives examples of Session Description Protocol (SDP) offer answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. "Establishing jabber Messaging Sessions with the Session Initiation Protocol", Robert Sparks, 30-Oct-02, This document explores modeling jabber message streams as media sessions, and how they can be initiated with the Session Initiation Protocol. It also explores how these sessions can be integrated into existing session-based multimedia communication applications. "Integer Counter Mode", David McGrew, 30-Oct-02, This document specifies Integer Counter Mode (ICM), a mode of operation of a block cipher which defines an indexed keystream generator (which generates a keystream segment given an index). This mode is efficient, parallelizable, and has been proven secure given realistic assumptions about the block cipher. Test vectors are provided for AES. Counter Mode admits many variations. The variant specified in this document is secure and flexible, yet it enables a single implementation of a keystream generator to suffice in different application domains. "The Truncated Multi-Modular Hash Function (TMMH), Version Two", David McGrew, 30-Oct-02, TMMH is a 'universal' hash function suitable for message authentication in the Wegman-Carter paradigm. It is simple, quick, and especially appropriate for Digital Signal Processors and other processors with a fast multiply operation. This document specifies version two of TMMH, which eliminates the large storage requirement for hashing large messages that was present in version one. "The Universal Security Transform", David McGrew, 30-Oct-02, This document describes a cryptographic transform which uses an indexed keystream generator (that generates a keystream segment given an index value) and a universal hash function to provide confidentiality, message authentication, and replay protection. This transform is efficient, provably secure, and is appropriate for network security. "Issues Concerning DHCP in IPv6 Specifications", Ralph Droms, 30-Oct-02, There are several issues related to DHCPv6 in various IPv6 documents that require clarification or resolution. The v6ops working group discussed these issues at an interim meeting in August, 2002. This document presents those issues and summarizes the v6ops working group discussion. "IP Encapsulating Security Variable Payload (ESVP)", Sneha Kasera, 30-Oct-02, This note describes a new IPsec option called Encapsulating Security Variable Payload (ESVP) that allows a variable but contiguous portion of the payload received from upper protocol layers to be encrypted/authenticated between the two end-points of a security association. The remaining portion of the payload is left in the clear. The upper layer payload contains the upper layer protocol headers and data. The decision about which portions of the payload should be available as cleartext is taken only by the end-points of the security association. By leaving a certain portion of the payload as cleartext, ESVP provides the option of encrypting and decrypting an IPsec ESVP datagram at other protocol layers to allow limited and secure access to the cleartext data at these protocol layers. These layers could be terminated inside the network for providing network-based value added services and performance optimizations. These network-based value added services and performance optimizations include policy implementation and QoS based on packet classification, TCP performance enhancement in the case of wireless networks and firewall services. "RADIUS Attributes for soBGP Support", Chris Lonvick, 23-Jan-03, This document defines a set of RADIUS attributes designed to support the provisioning of the soBGP protocol. A router will encapsulate the components of an AuthCert or PolicyCert into TLVs and transport them to a centralized server capable of verifying the associated signature. This draft goes along with other IDs submitted for Secure Origin BGP (soBGP) both of which are edited by James Ng and Russ White. draft- white-sobgp-bgp-deployment-00.txt [1], draft-ng-sobgp-bgp-extensions- 00.txt [2] Mostly this work relates to 'Extensions to BGP to Support Secure Origin BGP (soBGP)' and is explained in additional detail in 'Deployment Considerations for Secure Origin BGP (soBGP)'. The purpose of this draft is to explain the concept of offloading the Authcert validation steps, and the Entitycert storage, from the router. RADIUS may not be the best way to do this but it's the best that I know of at this moment. Once the concepts of soBGP are discussed, the transport to support offload should be reviewed and a proper mechanism should be chosen. "Internet Group membership Authentication Protocol (IGAP)", Takeshi Hayashi, 29-May-03, This memo documents the Internet Group membership Authentication Protocol (IGAP), a protocol developed by NTT, Nortel Networks and Panasonic. IGAP provides not only the group membership communication functionality between hosts and their first hop routers as IGMP does, but also user authentication and accounting functionalities. IGAP is designed to be used in a controlled or managed IPv4 multicast environment. It provides with a viable alternative to IGMP in IP multicast networks when authentication and accounting are required. The user authentication information in IGAP can enable a provider to control the distribution of the multicast traffic as well as collecting real time user accounting information in an environment where the last hop access networks are not shared. "Requirements for Plug and Play IPsec for IPv6 applications", Tomoaki Kobayakawa, Shin Miyakawa, 30-Oct-02, This document describes requirements about how IPsec is supplemented for IPv6 Plug and Play applications. "Use of the DDDS System for Cryptographic Key Discovery and Retrieval", Richard Shockey, Christopher Davis, 30-Oct-02, This document discusses the use of the Dynamic Delegation Discovery System [RFC 3401-6] for the discovery and retrieval of application specific cryptographic objects. "An Approach for Using LDAP as a Network Information Service", Luke Howard, M Ansari, 30-Oct-02, This document describes a mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. A set of attribute types and object classes are pro- posed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organiza- tional nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, lead- ing eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. "Benchmarking Terminology for Protection Performance", Shigeru Kimura, Jerry Perser, 25-Apr-03, This document addresses common terminology and metrics for the performance benchmarking of sub-IP layer protection technologies: Automatic Protection Switching (APS) for SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for Multi-Protocol Label Switching (MPLS). The benchmarks describe the performance based on the effects in the IP-layer, to avoid dependence on a specific sub-IP layer protection technology. "Discussion of suitability: S/MIME instead of Digest Authentication in the Session Initiation Protocol (SIP)", Rohan Mahy, 01-Jul-03, Digest authentication (as defined in RFC2617) is used in SIP (RFC3261) for user authentication, and less frequently for message integrity of MIME bodies carried in SIP. Various members of the IETF security community have periodically suggested that Digest should be deprecated in favor of the SIP use of S/MIME (RFC2633), support for which was recently introduced in RFC3261. The author seeks clarity from the IETF security community on behalf of the SIP community about the feasibility and possible benefits of using S/MIME instead of Digest in one or both of these applications. "Active Traceback Protocol", Tatsuya Yamada, 30-Oct-02, General traceback protocols (e.g. itrace) only consider to send traceback information from Generator to Tracer. But they are not helpful when victims and/or Tracer want to know who attacks them because of conventional traceback mechanisms have not been reflected in Tracer intention. Therefore this draft proposes an additional protocol for conventional traceback protocols, especially itrace, to reflect in Tracer intention and be able to control generation of traceback information by Generator. "Application Aspects of IPv6 Transition", Myung-Ki Shin, 26-Jun-03, The document specifies application aspects of IPv6 transition. As IPv6 is deployed, the application developers and the administrators will face several problems. This draft clarifies the problems and considerations occurring in transition period between IPv4 applications and IPv6 applications. It also proposes guidelines that help application developers understand how to develop IP version-independent applications during the transition period. "The Compound Authentication Binding Problem", Jose Puthenkulam, 01-Jul-03, There are several motivations for using compound authentication methods using tunnels, but man-in-the-middle attacks are possible in certain circumstances when they are used, without cryptographically binding the methods together. At the time of writing this document, several protocols being proposed within the IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP. This document studies the problems and suggests potential solutions to mitigate them "Unique DNS Name Generation", Jae-Hoon Jeong, 07-Mar-03, This document describes a mechanism of generating a unique DNS name automatically. This mechanism is useful when a node wants to configure a unique domain name in its network interface automatically in the environment where there is no dedicated DNS name server, such as the unmanaged home-network and ad-hoc network. "Referential Integrity Considerations in Management Information Base (MIB) Design", Randy Presuhn, 30-Oct-02, This memo identifies some of referential integrity considerations of which management information base (MIB) designers should be aware. It is intended to promote discussion and the identification of additional related issues. Comments are welcomed, from the Operations and Management Area in general, from MIB writers, and from participants in the sming and eos working groups and the xmlconf BOF in particular. Please send comments to the mibs@ops.ietf.org mailing list. "A Framework for Internet Program Guides", Yuji Nomura, Henning Schulzrinne, 30-Oct-02, This memo provides a framework for Internet program guides (IPG). An IPG is a set of meta-data describing the features of multimedia content in order to subscribe to, manage and exchange multimedia content. We present an architecture, a protocol model and program guide data model for several scenarios. "Suppressing Refer Implicit Subscription", Sriram Parameswar, 30-Oct-02, The recipient of the REFER method [1] creates an implicit subscription to the 'refer' event. This subscription causes the REFER recipient to send NOTIFY messages to the sender informing him of the progress of the REFER. This memo provides for the requirements and one potential mechanism to suppress the creation of this implicit subscription, via an option tag - 'norefersub'. This gives the agent sending the REFER control over the creation of the subscription, while being backwards compatible with [1]. "LDAP Content Synchronization Operation", Kurt Zeilenga, Jin Choi, 19-Jun-03, This specification describes the LDAP (Lightweight Directory Access Protocol) Content Synchronization operation. The operation allows a client to maintain a shadow copy of a fragment of directory information tree. It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search operation. "MPLS VPN Import/Export Verification", Michael Behringer, Jim Guichard, Pedro Marques, 10-Apr-03, Configuration errors on Provider Edge (PE) routers in Layer-3 VPN networks based on [RFC2547] can lead to security breaches of the connected VPNs. For example, the PE router could be mistakenly configured such that a connected Customer Edge (CE) router belongs to an incorrect VPN. Here we propose a scheme that verifies local and remote routing information received by the PE router before it installs new VPN routes into the Virtual Routing & Forwarding Instance (VRF). The proposed changes affect only the PE routers. "Ethernet Pseudo-wire over L2TPv3 (multipoint support)", C.J. Lee, 31-Oct-02, This draft describes the emulation of an Ethernet segment or broadcast domain over an IP network and the use of L2TPv3 to transport Ethernet frames. "RSVP-TE extensions for interdomain LSPs", Cristel Pelsser, Olivier Bonaventure, 31-Oct-02, We propose extensions to RSVP-TE to allow the establishment of traffic engineered LSPs with fast restoration requirements. We first discuss the problem of establishing explicitly routed interdomain LSPs and show that the current subobjects found in RSVP-TE are not sufficient to establish interdomain LSPs because they do not take into account the policy constraints of the interdomain environment. We then show how to extend the fast-reroute and detour objects to protect interdomain links and ASBRs on interdomain LSPs. We also discuss the establishment of disjoint interdomain LSPs for restoration and load balancing purposes in the appendix. Finally, we describe the necessary RSVP objects and flags and discuss the impact of the proposed solution on the syntax of existing RSVP-TE objects and the syntax of new required objects are presented. "A Container Type for the Extensible Authentication Protocol (EAP)", Tom Hiller, Ashwin Palekar, Glen Zorn, 29-May-03, The Extensible Authentication Protocol (EAP), defined in RFC 2284, provides for support of multiple authentication methods. While EAP was originally created for use with PPP, it has since been adopted for use with IEEE 802.1X 'Network Port Authentication'. Since its deployment, a number of weaknesses in EAP have become apparent. These include the lack of protection for, and acknowledgement of Success and Failure messages. "SIP Support for Application Initiation", Cullen Jennings, 01-Jul-03, This document describes SIP extensions to allow network elements to request a UA to initiate a scripted application that is associated with a dialog. It provides a mechanism for the network elements to find out a UA's ability to fetch and execute scripts. "Xcast+ Extension for Few-to-Few Mulitcast Communication", Kevin Kim, 31-Oct-02, Xcast+[2] is newly proposed multicast scheme to support IGMPv2/MLDv3 in Explicit Multicast(Xcast)[1]. Xcast+ is suitable for one-to-few multicast applications. In order to support few-to- few communication naturally, the control plane of existing Xcast+ should be extended. In this document, a new control plane for few- to-few communication for Xcast+ is specified. In order to acheive this, the concept of logical core (LC) is newly introduced. "iCalendar SIP-Based Interoperability Protocol", Pekka Pessi, Martti Mela, 30-Jun-03, This document proposes a binding from the abstract iCalendar Transport-independent Interoperability Protocol (iTIP) using Session Initiation Protocol (SIP) as transport and SIP/SIPS URIs as addresses. The iTIP objects are used as a MIME payload format with SIP. iTIP is an abstract transport protocol for exchanging calendaring information between calendar systems using the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC-2445. SIP is a application-layer signaling protocol for creating, modifying, and terminating multimedia sessions, retrieving user presence and sending instant messages. "INCH Requirements", Glenn Keeni, Hiroyuki Ohno, 31-Oct-02, The purpose of the Incident Report Format is to facilitate the exchange of incident information and statistics among involved parties and responsible Computer Security Incident Response Teams (CSIRTs) for reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. A common and well defined format will help in retrieving, archiving and exchanging Incident Reports across organizations, regions and countries. This document describes the requirements for an Incident Report format. "EPP Data Considerations", Eric Brunner-Williams, 31-Oct-02, This memo discusses data collection considerations and EPP. It is far from complete, but deadlines press. Distribution of this document is unlimited. "G.709 Encoding for Link Management Protocol (LMP) Test messages", Dimitri Papadimitriou, Jonathan Lang, 31-Oct-02, This document detail the G.709 Optical Transport Network technology specific information needed when sending Link Management Protocol (LMP) test messages. "Network Mobility Support Requirements", Ted Ernst, 31-Oct-02, The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts only (host mobility support). In contrast, network mobility support (NEMO support) deals with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. In this situation, mobility support is to provide continuous Internet sessions not only to the router connecting the mobile network to the global Internet, but also to nodes behind the mobile router. This document tries to identify what constraints limit the implementation and the deployment of a potentially and ideally good solution, and what requirements solutions must comply with. Our main aim is to raise the discussion on the mailing list. "The set of Emergency Features provided in Public Switched Telephone Networks", Joerg Ottensmeyer, 06-Mar-03, This document describes the set of emergency call services that are provided in Public Switched Telephone Networks (PSTN) today and will be in the near future. It discusses related features which are needed to provide these services. "RTP payload format for ATRAC-X", Norihiro Matsumoto, 07-Mar-03, This document describes an RTP payload format for efficient and flexible transporting of ATRAC-X encoded audio data. ATRAC-X is a high quality audio coding technology that supports multiple channels. The RTP payload format as presented in this document includes support for metadata, data fragmentation, and continuous decoding even during packet losses. "Specifying Security Claims for EAP Authentication Types", Glen Zorn, 31-Oct-02, This document describes a method that may be used to enumerate the claimed security qualities of EAP authentication types in terms of well-defined objective qualities. These claims may then be used to evaluate the claims against both the actual operation of the authentication types themselves and the security requirements of users (including other standards development organizations). "XML Configuration Architecture", Rei Atarashi, 31-Oct-02, For the new network configuration concept discussed at XMLCONF, we mention the importance of building new network architecture. We can not develop and discuss the concept using XML because it is only tools but the concept is confusable. The consensus of architecture is required to clarify the items and technologies that should be discussed and standardized at IETF. " Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)", Simon Leinen, 01-Jul-03, This draft contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. "On the Relationship between PSAMP and IPFIX", Juergen Quittek, Benoit Claise, 04-Mar-03, This memo discusses the relationship between the packet sampling (PSAMP) Working Group and the IP flow information export (IPFIX) Working Group. The goals of writing this memo are: avoiding duplication of work, increase mutual benefits between the groups, and harmonize the documents and standards developed by the groups. Therefore, potential overlap of both group's activities is analyzed, activities in both groups that potentially complement each other are pointed out, and common issues are listed that should be harmonized between the groups. "Connecting IPv6 Islands across IPv4 Clouds with BGP", Jeremy De Clercq, 31-Oct-02, This document explains how to interconnect IPv6 islands over an IPv4 cloud, including the exchange of IPv6 reachability information using BGP. Two approaches will be explained, both requiring a Dual Stack MP-BGP-speaking edge router per IPv6 island. The hosts in the IPv6 islands can use native IPv6 addresses. The first approach uses MP-BGP over IPv4, relies on identification of the MP-BGP-speaking edge routers by their IPv4 address and uses a trivial tunneling mechanism without any explicit tunnel configuration. The second approach uses MP-BGP over IPv6 and relies on existing ngtrans tunneling mechanisms to tunnel packets. "Cable Gateway Addressing Management Information Base for CableHome compliant Residential Gateways", Douglas Jones, Eduardo Cardona, 06-Mar-03, 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 a basic set of managed objects for SNMP- based management of Network Address Translation and transparent bridging functionality within a CableHome compliant residential gateway. 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. "Multi-protocol encapsulation over MPLS", Johan Moreels, Jeremy De Clercq, 30-Jun-03, This document describes an encapsulation method for transporting Service Data Units (SDUs) of different protocols over a single Label Switched Path (LSP). The different protocols are identified by pre- pending an LLC / SNAP header to the SDU. The method allows interconnecting networks with a different layer 2 protocol via an intermediate MPLS network. The proposed encapsulation method is complementary to PWE3. "LateClearance Content Encoding", Martin Stecher, 01-Nov-02, This document introduces a new content encoding that can be used in HTTP/1.1. Its purpose is to solve the download progress indication problem that some proxy gateway filters like virus scanners have. "Analysis of Mobile IP and RSVP Interactions", Michael Thomas, 01-Nov-02, IP Mobility along with RSVP makes my head hurt. Trying to guess the benefits (if any) of a proposed context transfer protocol is even more difficult to judge. This draft tries to make sense of some subset of the possible permutations in a possibly vain attempt have an overview of the problem space. "Securing Nested Tunnels Optimization with Access Router Option", Chan Ng, Takashi Tanaka, 01-Nov-02, Through the establishment of bi-directional tunnels between a mobile router and home agent, global connectivity can be extended to nodes within a network in motion. However, the multiple levels of bi- directional tunnels in nested mobile networks lead to undesirable effects. This memo proposes using a new mobility header option called the Access Router Option to allow a mobile router to inform its home agent the home-address of the access router it is currently attached to. From there, this memo lays out a mechanism that allows mobile routers to securely achieve nested tunnels optimization. "Some Problems with Perimeter Firewalls", Angelos Keromytis, 01-Nov-02, This document discusses some of the shortcomings of perimeter firewalls and the reasons for employing end-point (or distributed) firewall functionality in the network, either as an alternative or coexisting with traditional network access controls. "A Framework for Conferencing with the Session Initiation Protocol", Jonathan Rosenberg, 12-Feb-03, The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. "A Framework and Requirements for Application Interaction in SIP", Jonathan Rosenberg, 01-Nov-02, This document describes a framework and requirements for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. "Cable Gateway Address Mapping Management Information Base for CableHome compliant Residential Gateways", Douglas Jones, 01-Nov-02, 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 a basic set of managed objects for SNMP- based management of Network Address Translation and transparent bridging functionality within CableHome 1.0 and 1.1 compliant residential gateways. 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. "Cable Gateway Configuration Management Information Base for CableHome compliant Residential Gateways", Eduardo Cardona, Douglas Jones, 06-Mar-03, 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 a basic set of managed objects for SNMP- based management of DHCP [22] functionality within a CableHome compliant [21] residential gateway. 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. "Cable Gateway Device Management Information Base for CableHome compliant Residential Gateways", Douglas Jones, 06-Mar-03, 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 a basic set of managed objects for SNMP- based management of CableHome compliant WAN Gateway Devices and home routers. 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@ietf.org and/or the editor. "Uniform Resource Identifier (URI): Generic Syntax", Tim Berners-Lee, 09-Jun-03, A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. "Cable Gateway Security Management Information Base for CableHome compliant Residential Gateways", Douglas Jones, 06-Mar-03, 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 a basic set of managed objects for SNMP- based security management of CableHome 1.0 compliant residential gateway devices. 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. "Cable Gateway Tools Management Information Base for CableHome compliant Residential Gateways", Douglas Jones, 06-Mar-03, 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 a basic set of managed objects for SNMP- based management of CableHome compliant WAN Gateway Devices and home routers. Specifically, this MIB defines managed objects for both a connection speed tool and an ICMP 'ping' tool between the Gateway and devices on the LAN. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. "Requirements for message adaptation in the context of SIP Instant Messaging and Presence applications", Jose Costa-Requena, Stephane Coulombe, 01-Nov-02, Some SIP instant messages (IM) and presence notifications may be too large for a receiving user agent or may contain media types or extensions not supported by the receiving User-Agents. This may create serious interoperability problems in the future. This document defines requirements for a SIP message adaptation framework providing means to express the User-Agent capabilities and User preferences to enable adaptation of SIP messages to meet the recipient's needs. "A framework for message adaptation in the context of SIP Instant Messaging and Presence applications", Stephane Coulombe, Jose Costa-Requena, 01-Nov-02, This Internet-Draft presents a message adaptation framework that addresses the requirements presented in the document draft-coulombe- message-adaptation-requirements-00. This document focuses mostly on the issue of terminal capability exchange and the overall message adaptation and delivery process. "An architecture for a gradual deployment of end-to-end QoS on an Internet-wide scale (Virtual Service-aware Network)", Jeremy De Clercq, 10-Jun-03, This document introduces Virtual Service-aware Networks (VSNs) as a solution for inter-domain resource reservation with Quality-of- Service (QoS) on an Internet-wide scale. A VSN is a single-domain overlay network that consists of guaranteed QoS pipes. VSNs of neighboring domains that offer the same level of QoS establish peering relationships. As such, they form a network of QoS-enabled networks with a specific (QoS) routing context. In this network, admission control for traffic flows is performed in two phases. The two-phase approach allows for the use of an off-path signaling protocol, which enables the gradual introduction of this architecture without changing the existing routers. "ENUM Service Registration for H.323 URL", Orit Levin, 01-Nov-02, The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. "SigComp Torture Tests", Richard Price, Abigail Surtees, 16-May-03, This document provides a set of 'torture tests' for implementers of the SigComp protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. "L2VPN Interworking", Ali Sajassi, 07-Mar-03, The need to support L2VPN services with disparate Attachment Circuits (heterogeneous transport) is becoming as important as the support of L2VPN services with the same type of Attachment Circuits (homogenous transport). To support L2VPN services with heterogeneous transport, some means of interworking is needed. The requirement to support L2VPN interworking is stated in [PPVPN-L2FRWK]. This document describes different approaches and mechanisms that can be used to provide L2VPN interworking among disparate interfaces. "VPLS based on IP Multicast", Ali Sajassi, Hussein Salama, 01-Nov-02, Virtual Private LAN Service (VPLS) is a type of Layer-2 Provider Provisioned Virtual Private Network (L2 PPVPN) offered service, which has been described in [PPVPN-FRWK]. If the Service Provider network provides IP multicast functionality, then this network capability can be leveraged in providing very efficient VPLS service and yet simplifying the implementation of such service. This document describes a solution for providing VPLS service based on IP multicast feature referred to as Multicast Virtual Private LAN Service (MVPLS). "A Dynamic Protocol for Candidate Access-Router Discovery", Dirk Trossen, 01-Apr-03, Many protocols currently being developed for seamless IP-level handovers, such as fast handovers and context transfers, possess an inherent requirement that the mobile node and/or it's current access router have a priori knowledge concerning the target of the handover. In particular, the target access router (TAR) should be known to have the appropriate set of capabilities necessary to meet the requirements of the mobile node. Although the TAR selection process occurs at or near the time of handover, applicable candidate access routers (CARs) can be identified in advance. In this draft, we propose a dynamic, distributed protocol, dyCARD, which allows geographically adjacent routers to exchange capability information, thus providing critical information to the target selection process. "Keypad Markup Language (KPML)", Eric Burger, 01-Jul-03, Keypad Markup Language (KPML) is a markup language used in conjunction with SIP and HTTP to provide instructions to SIP User Agents for the reporting of user key presses. "Media Server Control Markup Language (MSCML) and Protocol", Jeff Van Dyke, Eric Burger, Andy Spitzer, 01-Jul-03, Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and IVR functions. This protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. "Semantic Description of SIMPLE List Manipulation Operations", Markus Isomaki, 01-Nov-02, In SIMPLE based presence and messaging applications, it is necessary for the user to be able to configure a number of pieces of information. One of the most common types of information is a list of URIs. List management is useful outside the scope of SIMPLE as well, for instance in conferencing. There are many reasons why it would be beneficial to manage the lists in a similar fashion regardless of the application. Before the selection of the actual protocol(s) to manage the lists there is a need to describe their semantics on an abstract level. This document proposes the semantics for SIMPLE list manipulation protocol. "The Use of Bi-Directional RSVP in the Wireless Internet", Kamel Shaheen, Sharif Shahrier, 01-Nov-02, With the current evolution toward wireless data, wireless internet, and wireless multimedia applications such as Voice over IP (VoIP), video conferencing, and Video telephony, similar performance requirements to those of existing circuit switched or voice based wireless systems are essential to the success of this evolution. Among these performance requirements are the call setup time, delay, reliability, and Quality of Service (QoS). To ensure QoS, provide faster call setup time, and reduce the number of RSVP messaging across the network; this note introduces the concept and describes the use of bi-directional RSVP (B- RSVP) resource reservation protocol with both Controlled-Load and Guaranteed QoS control services. While RSVP allows for uni-directional resource reservations only in the 'send' direction, B-RSVP protocol generalizes the process by allowing simultaneous bi-directional (send and receive) resource reservations on each hop. B-RSVP also allows for a reverse route (receive only) uni-directional resource reservation. B- RSVP is most suitable for applications in which the originator of a service is solely responsible for making the necessary reservations and their cost. This note defines several data objects that carry resource reservation information required for both send and receive traffic. The proposed message formats are extensions to existing RSVP messages and totally backward compatible. The usage and data format of those objects are described herein. "Requirements for NEtwork MObility Support", Christophe Janneteau, 01-Nov-02, This draft introduces some scenarios for mobile networks, i.e. IP networks that change their points of attachment to the Internet, and proposes requirements for network mobility support in the context of the NEMO working group. "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Alexandru Petrescu, 07-Mar-03, This document describes several issues relevant to the design of a network mobility support solution that relies on the bi-directional tunnel between Mobile Router and Home Agent, with Mobile IP. Examples of issues are: conflicting Mobile IP and RIPng/OSPF requirements on link-local addresses, HA/BR co-location, and 'cross-over' tunnels. "RADIUS & L2TP Extended NAS-Port AVPs", Neil McGill, 01-Nov-02, This document defines additional Layer 2 Transfer Protocol (L2TP) and Remote Authentication Dial In User Service (RADIUS) Attribute-Value Pairs (AVPs) to communicate Network Access Server (NAS) port usage information between L2TP peers during call establishment to facilitate authorization and accounting. "Improving the Architectural Alignment for FMIPv6", James Kempf, Jonathan Wood, 01-Nov-02, The FMIPv6 draft proposes a number of changes in the local link and routing information exchange architecture for wireless networks that are not quite aligned with standard IETF protocols, including the base MIPv6 protocol itself. This draft proposes modifications of FMIPv6 to tighten the semantics of anticipated care-of address configuration around the prehandover signaling as a logical extension of Router Discovery, and around the HI/HAck exchange as a logical extension of routing information propagation. It also proposes some extensions to Router Discovery for reactive handover to piggyback signaling for quickly establishing a tunnel to the Previous Access Router on top of standard RFC 2461 Router Discovery signaling. "Architectural Requirements for Base Network Mobility Using Bidirectional Tunneling", Behcet Sarikaya, 01-Nov-02, While traditional mobility support deals with providing continuous Internet connectivity to mobile hosts (host mobility support), network mobility support means dealing with situations where an entire network changes its point of attachment to the Internet. Such a network is called a mobile network. This document identifies architectural entities of network mobility and nested network mobility. "The XPointer xinclude1() Scheme", Simon St.Laurent, 01-Nov-02, This document specifies an xinclude1() scheme for use in XPointer- based fragment identifiers. This scheme, like other XPointer Framework [12] schemes, is designed primarily for use with the XML Media Types defined in RFC 3023 [5], to identify locations within a given XML representation of a resource. The xinclude() scheme notifies an XPointer processor whether the creator of the XPointer intended for XInclude 1.0 [9] processing to take place. "RADIUS Client Kickstart", Robert Moskowitz, 01-Nov-02, RADIUS servers [2] require foreknowledge of the IP address of the RADIUS clients, as the shared secret is bound to the address. This has been a manageable situation when the clients were just NASs (Network Access Servers). With the advent of IEEE 802.1x [3], there is a significant increase in RADIUS clients in organizations not prepared to have the clients use fixed IP addresses and manage the shared secret. To address the concerns of the IEEE 802.1 and 802.11 Task Groups a level of indirection is added; a Master secret bound to the name of the RADIUS client. This Master secret is created by a Diffie-Hellman exchange. It is used in an initial RADIUS exchange to create a session secret that is used as the normal RADIUS client shared secret. "A URN Namespace for FIPA", Fabio Bellifemine, 04-Nov-02, This is an application for assignment of the URN NID 'FIPA' to be used for identification of standard components published by the Foundation for Intelligent Physical Agents standards body [1] in the area of Agent technology. "Limited Flooding as a scalability improvement to OSPF", Dan Dovolsky, 04-Nov-02, This draft describes a limited flooding approach to address the problem of routing scalability in link state IGPs. The solution is based on decomposition of a routing area into 'zones' and the restriction of the exchange of routing information between zones. This approach introduces an extra level in the isolation of knowledge within a routing domain. The advantage of this solution is that it considerably decreases the amount of information flooded in link state advertisements and reduces the size of the link-state database (and traffic engineering entries) on network elements utilizing link state protocols. The technique presented in this document has been particularized to OSPF in order to make the discussion practical and concrete. However, the underlying concepts are very general and similar modifications can be easily applied to other IGPs, such as ISIS. "Requirements for Event Notification Filters", Tim Moran, Sreenivas Addagatla, 04-Nov-02, This document defines a set of structured requirements whereby an event subscriber (client) may specify when notifications are sent to it and what the contents should be. "The XPointer content-type() Scheme", Simon St.Laurent, 04-Nov-02, This document specifies a content-type() scheme for use in XPointer- based fragment identifiers. This scheme, like other XPointer Framework [12] schemes, is designed primarily for use with the XML Media Types defined in RFC 3023 [5], to identify locations within a given XML representation of a resource, though it may potentially be used to mix schemes for XML and non-XML representations. The content-type() scheme notifies an XPointer processor whether the creator of the XPointer intended for a particular pointer part to apply to a resource representation which uses a particular MIME content type identifier. "The XPointer xmlns-local() Scheme", Simon St.Laurent, 04-Nov-02, This document specifies an xmlns-local() scheme for use in XPointer- based fragment identifiers. This scheme, like other XPointer Framework [13] schemes, is designed primarily for use with the XML Media Types defined in RFC 3023 [5], to identify locations within a given XML representation of a resource. The xmlns-local() scheme notifies an XPointer processor that it should include all of the namespace binding context defined for the element containing the XPointer in the namespace binding context for the XPointer. "Transition cases and their implementations for 3GPP Networks", Amit Thakur, 04-Nov-02, This document describes the implementation of various transition cases in Third GenerationPartnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition.The cases considered here have already been described in [TRANS-SCENE]. "An Architecture of Overlay Multicast Control Protocol", Seok Koh, 04-Nov-02, This document describes Overlay Multicast Control Protocol (OMCP) used for realizing and managing Overlay Multicast, as also known as Application Layer Multicast. Overlay Multicast is a data delivery scheme for multicast applications, in which one or more intermediate relay agents are employed for relaying application data from a sender to many receivers along a pre-configured or automatically configured tree hierarchy. In OMCP, a special- purpose entity, called Session Manager, is used to manage and control the tree configuration and session monitoring. OMCP is designed to ensure that the multicast applications and services can be provided over current Internet environments in which IP multicast has not completely been deployed. "Mandatory MIME Security Considered Harmful", Dave Crocker, 04-Nov-02, MIME is the preferred Internet mechanism for labeling and aggregating bulk data objects, such as for email and the web, and it is essential to have useful, MIME-based mechanisms. Indeed, two standards have existed for some years: OpenPGP and S/MIME. A current IESG policy for new application protocols requires that they mandate conforming implementations to support a single security mechanism. For applications using MIME security, this means that the specification is required to choose between S/MIME and OpenPGP. Although well-intentioned, the policy is at least useless and at worst counter-productive. This note discusses the problem and suggests returning to the previously acceptable policy that better reflects the lack of market resolve for MIME security. "Extension Header for Site-Multi-homing support", Marcelo Bagnulo, Alberto Garcia-Martinez, 04-Nov-02, This note describes an IPv6 multi-homing solution that achieves equivalent fault tolerance benefits to those provided by current IPv4 multi-homing solution while preserving the route aggregation capabilities of the Provider-based Aggregation scheme. The solution lies on the inclusion, in every packet flowing to a multi-homed site, of an extension header containing multiple alternative route information to the destination, so that if the original destination address becomes unreachable, alternative route is used for reaching the destination. "MGCP, MEGACO, and SIP VoIP Signaling Protocol Security Requirements", Sharon Jacobs, Henrik Nielsen, 04-Nov-02, This document specifies the requirements that the MGCP, MEGACO, and SIP VoIP Signaling Protocols must satisfy in order to meet the needs for VoIP deployment in carrier class and large geographically distributed organization networks. These requirements were developed with a specific focus on network address translation (NAT), network through application layer packet filtering, signaling across multiple trust domains, and redundancy of call/controllers, media gateways, proxies and registrars. "IP Measurement Protocol (IPMP)", Jon Bennett, 05-Mar-03, The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. "LSA Flooding Optimization Algorithms and Their Simulation Study", G Choudhury, Vishwas Manral, 05-Nov-02, The full flooding of LSAs in OSPF may cause large CPU and memory consumption at node processors of a network with large number of nodes, links, adjacencies per node and LSDB size. An LSA storm, defined as the near-simultaneous update of a large number of LSAs, in such networks may cause network instability and outage. We do a simulation study of four alternative algorithms to full flooding to determine their ability to handle large LSA storms. Algorithm 2 does full flooding but in case two neighbors are connected by multiple interfaces, flooding is done over only one such interface. The other algorithms are based on Algorithm 2 and employ further flooding restrictions. In Algorithm 3 each node asks only a subset of its one-hop neighbors, known as multipoint relays, to flood further. In Algorithm 4 flooding is done only over a minimum spanning tree. Algorithm 5 uses full flooding (as in Algorithm 2) for LSAs carrying intra-area topology information and restricted flooding over a minimum spanning tree (as in Algorithm 4) for other LSAs. "Definitions of Managed Objects for Network Management Services in General Switch Management Protocol (GSMP) Interface", Younguk Cha, 05-Nov-02, General switch management protocol (GSMP) is an open interface protocol between a label switch and a controller, and it provides connection, configuration, event, performance management and synchronization. Traditionally, network management services are classified into five categories: those are configuration, performance, fault, accounting, and security management. The companion draft document discussed the implementation complexity of a label switch and the efficiency of resource usage according to the location of network management functions. This document defines managed objects to support network management services in the GSMP interface. "TRACK PROTOCOL INSTANTION OVER UDP:TREE ACKNWOLEGEMENT BASED RELIABLE MULTICAST", Brian Whetten, 05-Nov-02, One of the protocol instantiations the RMT WG is chartered to create is a TRee-based ACKnowledgement protocol (TRACK). Rather than create a set of monolithic protocol specifications, the RMT WG has chosen to break the reliable multicast protocols into Building Blocks (BB) and Protocol Instantiations (PI). A Building Block is a specification of the algorithms of a single component, with an abstract interface to other BBs and PIs. A PI combines a set of BBs, adds in the additional required functionality not specified in any BB, and specifies the specific instantiation of the protocol. "User Cases of Network Operation of Large Access Providers", Weijing Chen, Kenneth Allen, 25-Nov-02, This document discusses the typical network operation use cases of Large Access Providers (LAP). Since a LAP has hundreds of locations, thousands of nodes, millions of subscribers, where the law of large number affects the bottom line of network operation, a LAP has been always strives to streamline network operation functions. The use cases presented in this document are generic with respect to the type of network technology and can be augmented with technology-specific details. They are intended to be the baseline for other network operation streamlining requirements. "Procedures for Megaco/H.248 controlled Voice Media Gateways for Autonomous Switchover to Fax Relay Service", An Leurs, Carsten Waitzmann, Annette Schwarz, 07-Nov-02, This document describes the handling of realtime fax calls in Megaco/H.248 controlled MGs. The call setup and capability negotiation is done with support of the control domain with Megaco commands. The switch over to fax or modem, upon detection of the relevant tones, is done in an autonomous way, without intervention of the control domain. In the Appendix, the Megaco messages for a call setup scenario with capability negotiation are shown, to point out the structure of the to the transmitting MG. Switching to T.38 is done after reception of V.21 flags. In the other flows, T.38 is not enabled, both MGs switch to the fallback case, fax pass-through mode. This document is based on the superior framework (reference [2]). The reader should be familiar with [2]. SDP sessions in the local and remote descriptors. Call flow diagrams are given as example: In the first flow, a T.30 CNG tone is generated by the transmitting terminal, the transmitting MG signals the detection towards the receiving MG. Switching to T.38 is done by both MGs as soon as possible. In the second example, a T.30 CED tone is sent by the receiving terminal. As this tone is no clear indication that a FAX will be sent, the receiving MG will switch to VBD after signaling this event "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of G.709 Networks", Germano Gasparini, Dimitri Papadimitriou, 08-Nov-02, This document introduces the traffic engineering extensions required in existing IGP protocols to support sub-sequent signalling for Label Switched Path (LSP) when using Generalized MPLS (GMPLS) signalling as defined in [GMPLS-SIG] and [GMPLS-G709] for G.709 Optical Transport Networks. In particular, using [GMPLS-RTG] as guideline, it specifies the GMPLS routing extensions to OSPF and IS- IS protocols for G.709 Optical Transport Networks (OTN). "Traffic Engineering Extensions to OSPF for Generalized MPLS control of Sonet/SDH Networks", Eric Mannie, Dimitri Papadimitriou, 18-Feb-03, This document introduces the Sonet/SDH traffic engineering extensions required for existing IGP protocols in support of Generalized MPLS (GMPLS) signalling as defined in [RFC-3471] and [GMPLS-SONET-SDH]. Using [GMPLS-RTG] as guideline, this memo specifies the GMPLS routing traffic engineering extensions to OSPF for Sonet/SDH networks. Based on the Traffic Engineering (TE) extensions defined in [OSPF- TE], the proposed approach is aligned with link bundling as defined in [MPLS-BDL] and extends the set of Link sub-TLVs proposed in [GMPLS-OSPF] to Sonet/SDH networks. The proposed extensions do not preclude any further integration with the Interface Switching Capability Descriptor specified in [GMPLS-OSPF]. "A Taxonomy of Directories Best Practice Topics and Concepts", Christine Yoon, 21-Nov-02, There are several different topics and concepts appropriate for an LDAP-based Directories Best Practice Guide (DBPG). This document discusses these topics and concepts for interested user communities to learn more about implementing them. "Hierarchy of Provider Edge Device in BGP/MPLS VPN", Li Bin, Dong Weisi, 27-May-03, In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.When there are many VPNs converged by a PE,and the capacity of PE is relevant limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a 'Plane Modle' where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is 'Core-Convergence-Access(Edge)' model,and the performance of the device is superior in Core Layer and inferior in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current 'Plane Modle',when PE device push to the edge layer,it has to maintain more VPN routes,this makes it difficult to extend the PE device to edge layer.This document defines an model of Hierarchy of Provider Edge Device in BGP/MPLS VPN,where Hierarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model 'Hierarchy Model',In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too. "IRC client capabilities negotiation", Petr Baudis, Aaaron Wiebe, 21-Nov-02, This memo presents a way for IRC servers and clients to negotiate optional features of the IRC protocol, mainly those which need to be explicitly supported by the client and are either backwards incompatible with the original IRC protocol or involve the format of data sent by the client. "Local Key Exchange for Mobile IPv6 Local Binding Security Association", Changwen Liu, 05-Mar-03, This document describes a key management protocol for a mobile computer to securely obtain keying material with an access router in a visited link for use as the local binding security association with the router. The protocol enables an IPv6 node to utilize the access router as its temporary home agent and continue to receive packets destined to its care-of address with the temporary home agent as well as to send packets from this care-of address when the nodes change its access router. To support this operation, two new types of mobility headers and one Neighbor Discovery option are defined. All IPv6 nodes MAY support this protocol. "Session control through RTCP an extension to RTCP", Debashis Haldar, 22-Nov-02, The main focus of this draft is to incorporate certain level of session control mechanism within a RTP session. One of the high demands of current IP network is to provide high performance for instant messaging, push to talk and other applications along those lines. For all of these kinds of services, it is better not to go through the out-of-band session control path and control the session within RTP session. Here the suggestion is to define an extension of RTCP. "Security Framework for the Access Control of MIPv6 Mobile Nodes", John Floroiu, 22-Nov-02, This draft proposes a few alterations to the Internet Key Exchange protocol (IKE) aimed at shortening the security associations and key management signaling. The resulting "Access Control Prefix Router Advertisement Option for IPv6", Steven Bellovin, 28-Feb-03, Some very low-end devices are expected to rely on address-based authentication, even though that is not a high-security mechanism. In particular, they may wish to permit access by 'local' peers only, for some value of 'local'. This memo proposes a new Router Advertisement option to supply a list of privileged prefixes. "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for DiffServ", Riza Cetin, 25-Nov-02, 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 for diffServ based Multiprotocol Label Switching (MPLS) Traffic Engineering. "An extension of RTP and RTCP protocols For Video-on-Demand systems", Rahul Banerjee, 26-Nov-02, This memorandum specifies an extension to RTP and RTCP as specified in RFC 1889 [1] specifically designed to extend support to Video-on-Demand systems in particular and unicast systems in general. It is presented through an experimental Video-on-Demand Architecture that supports dynamic changes in the distribution pattern and load balancing to optimize the service quality provided to the user. "Suggestions to Streamline the IETF Process", Marc Blanchet, 27-Nov-02, The intent is to document problems in the IETF process and to suggest simple solutions that can be easily implemented and do not require major changes in the IETF organisation, following the value of 'running code'. "L2VPN Signaling Using L2TPv3", Wei Luo, 03-Jun-03, The Layer 2 Tunneling Protocol (L2TPv3) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TPv3 describes the use of an L2TP session to cross-connect two Layer 2 circuits attached to a pair of peering LACs. A cross-connect is a basic form of Layer 2 Virtual Private Networks (L2VPNs). This document describes mechanisms which utilize the building blocks that L2TP provides to construct different types of L2VPNs. "Development of an Algorithm to Reduce Internet Data Traffic Congestion", Syed Misbahuddin, 01-Jul-03, In recent era of Information Technology the data traffic over the Internet is increasing uncontrollably. This proliferation of data traffic is due to general shift towards e-business and other application of Information Technology. The businesses relying on Internet lose billions of dollars each year due to slow or failed web services. Therefore, in Internet research, the most conspicuous issue is to develop methodologies to reduce net traffic over the Internet. In this paper, an algorithm is proposed to reduce net data traffic, which works at Internet layer in TCP/IP reference model. The algorithm monitors data repetitions in IP datagram and prepares a compression code in response of this repetition. If no IP datagrams are repeated, no compression code is sent. Therefore, the algorithm does not put any overhead on the system. Furthermore, as the proposed algorithm works at IP datagrams only, therefore, it remains transparent from all client-server applications. "Security Audit and Access Accountability Message Data Definitions for Healthcare Applications", Glen Marshall, 14-Apr-03, To help assure healthcare privacy and security in automated systems, usage data need to be collected. These data will be reviewed by administrative staff to verify that healthcare data is being used in accordance with the healthcare provider's data security requirements and to establish accountability for data use. This review process is called security auditing. This document defines security auditing data to be collected by healthcare application systems for subsequent use by an automation- assisted review application. The data includes records of who accessed healthcare data, when, for what purpose, from where, and which patients' records were involved. The data definition is an XML schema to be used as a reference by healthcare standards developers and application designers. "Signaling MPLS in IP or MPLS in GRE Encapsulation Capability", Rahul Aggarwal, Robert Raszuk, 02-Dec-02, This document proposes a lightweight mechanism for signaling a PE router's capability to encapsulate MPLS using dynamic GRE and/or IP. This is applicable when a MPLS packet is tunnelled using a dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. For instance the MPLS packet may be a 2547 based MPLS VPN packet [2547bis] or a layer 2 packet transported using MPLS [MARTINI]. Adding such a mechanism has several benefits. It helps in blackhole avoidance and eases transitioning from MPLS tunneling based Layer 3/Layer 2 VPNs to GRE/IP tunneling based Layer 3/Layer 2 VPNs (and vice versa). Such a mechanism is needed where a network may be using MPLS and GRE (or IP) for tunneling, at the same time, in 2547 based or Layer 2 VPNs. It can help in encapsulation selection when multiple tunneling technologies are supported. It can also be used to enhance the security of the network backbone. "RObust Header Compression (ROHC): A Compression Profile for Mobile IPv6", Hui Wang, 02-Dec-02, The original RObust Header Compression (ROHC) RFC, RFC 3095, defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed packet streams. And another draft [IPPROFILE] posted by Jonsson deals with the IP only profile. However, no profile was defined for compression of IP extension headers. But in the coming wireless applications, mobile IP will play an important role. In mobile IPv4, there is no difference to the packet's IP header, so we don't have to make a profile for mobile IPv4; while as to mobile IPv6[MIPV6], there is difference, since some specific IPv6 extension headers will be included in almost every packet in the mobile IPv6 packets. The extension headers will also cost a lot of bandwidth, and we should do compression over them. This document addresses this issue and defines a ROHC compression profile for mobile IPv6, which may work as a complementarity to the profiles defined by RFC3095. "Early Media and Ringback Tone Generation in the Session Initiation Protocol", Gonzalo Camarillo, Henning Schulzrinne, 01-Jul-03, This document describes how to manage early media in SIP using two models; the gateway model and the application server model. It also describes which inputs need to be taken into consideration to define local policies for ringback tone generation. "MGCP Lockstep State Reporting Mechanism", Bill Foster, Flemming Andreasen, 02-Dec-02, An MGCP endpoint that encountered some adverse failure condition such as being involved in a transient call when a Call Agent failover occurred could be left in a lockstep state such that events are quarantined but not notified. The MGCP LCK package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. "MultiGRIP: Quality of Service Aware Multicasting over DiffServ", Giuseppe Bianchi, 02-Dec-02, Efficient delivery of real-time multicast traffic imposes on the underlying network infrastructure the burden of supporting Quality of Service (QoS). This can be quite a complex issue in a Differentiated Services (DiffServ) IP network, especially if multicast users are allowed to dynamically join and leave the multicast tree. In fact, since DiffServ lacks of explicit reservation states, i) a replicating node cannot test whether a corresponding reservation exists on an output link, and ii) upon a dynamic join of a QoS multicast user, the DiffServ network lacks of control functions to verify whether resources are available along the new path. In this document, we present a solution to support dynamic multicast with QoS over a DiffServ network. Our solution combines two ideas. First, resource availability along a new QoS path is verified via a probe-based approach. Second, QoS is maintained by marking replicated packets with a special DSCP value, before forwarding them on the QoS path. We are fully aware that the possible application of the principles described in this draft in the Internet raises many issues, which we do not address. Our aim, then, is not proposing a fully-fledged solution, but contributing to the on-going discussions in the international arena on these matters, by means of what we may see also as a problem statement document. "Enhanced PPP link re-establishment using context transfer", Madjid Nakhjiri, Shreesha Ramanna, 02-Dec-02, Many of today’s networks use PPP as a means of providing access links to remote users. In case a PPP user is mobile and performs a subnet handover, it needs to tear down and re-establish of its PPP link with the network. PPP link re-establishment is an elaborate procedure (as explained in a later section of this document) involving multiple messages. This will lead in an extended service disruption as due to the round trip time involved in the messaging as well extensive radio bandwidth usage. Of this reason, we consider PPP to be a prime candidate for context transfer [1-3]. The proposal in this document can reduce the number of PPP establishment messages by 50%-100. Furthermore, it will save significant amount of time in PPP state machine transitions, due to the multiphase nature of PPP. Reliability and timing issues of PPP context transfer are also discussed. "SIP Telephony Device Requirements, Configuration and Data", Ian Butcher, Steven Lass, Dan Petrie, Henry Sinnreich, Christian Stredicke, 18-Jun-03, This informational I-D describes the requirements for SIP Telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations. The document reviews the generic requirements for SIP telephony devices, the automatic device configuration process, the device configuration data and examples for XML configuration data formats. SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have text, audio and visual interfaces, various input modes, and require functionality targeted at several constituencies: (1) End users, (2) service providers and network administrators and (3) manufacturers and system integrators. The objectives of the requirements are a minimum set of interoperability and multi-vendor supported core features, so as to enable similar ease of purchase, installation and operation as found for standard PCs, analog feature phones or mobile phones. "A DNS RR for simple SMTP sender authentication", Hadmut Danisch, 02-Jun-03, This memo suggests a new DNS RR type to provide a very simple light-weight authentication scheme for the domain part of the sender address for SMTP mail transport. It is designed to be a simple and robust protection against e-mail fraud and especially spam. It is easy to implement and administer, compatible with all legislations known by the author, and cheap. It also focuses on security and privacy problems and requirements in context of spam defense, and touches non-technical problems of defense against spam. "Conformance Test Specification for IUA", Vikas Bhola, Gayatri Singla, 18-Dec-02, This Internet Draft presents a test specification for RFC 3057 which defines the ISDN Q.921-User Adaptation protocol along with IUA Outstanding Issues . This test specification can be used to test IUA implementations for conformance to the IUA protocol definition. Next revision of the draft will cover the additions done to the protocol revision and any subsequent RFC published by IETF. "DHCP Option for Civil Location", Henning Schulzrinne, 20-Feb-03, This document specifies a Dynamic Host Configuration Protocol option for the civil (country, street and community) location of the client. "IPv6 Globally Unique Site-Local Addresses", Robert Hinden, 06-Dec-02, This internet draft describes a proposal for IPv6 Globally Unique Site-Local Addresses. "RGL Codec Description Document", Michael Ramalho, 04-Mar-03, This document describes the operation of the RGL codec which obtains significant lossless compression of speech/audio packet payloads encoded with ITU-T Recommendation G.711 PCM (mu-law or A-law, IETF RTP payload types PCMA or PCMU) with trivial complexity and virtually no delay. Full documentation can be found at www.vovida.org [14]. The RTP payload format proposed for this codec is described in draft- ramalho-rgl-rtpformat-00.txt [4]. "RTP Payload Format for RGL Codec", Michael Ramalho, 04-Mar-03, This document describes the RTP payload format for the RGL Codec (Version 1.0.0) described in draft-ramalho-rgl-desc-01.txt [4] and documented fully at www.vovida.org [10]. The necessary details for the use of the RGL codec with SDP are included in this document. "The Concatenation of IP Packets", Jung Moon, Heon-Young Yeom, 09-Dec-02, This draft defines method to concatenate and separate IP packets to improve throughput in environments configured to use IPsec tunnel mode. "Logically Succinct Basic Policy Rule Components", Larry Bartz, 09-Dec-02, Logically Succinct Basic Policy Rule Components (LSBPRC) provides model extensions to the Policy Core Information Model (PCIM) and implementable extensions to the Policy Core LDAP Schema (PCLS) in which the logic of conditions and actions can be succinctly expressed and explicitly interpreted. LSBPRC offers a direct and invariant connection between the rule designer's intention and the rule interpreter's evaluation of the rulebase. "Automatic Globally Unique Site Local Subnet Allocation", Andrew White, Aidan Williams, 09-Dec-02, This memo specifies an automatically generated globally unique site local address format based on IEEE EUI-48 identifiers. "Legal Intercept Package for Megaco/H.248", Rohit Gupta, Vivek Bansal, 11-Dec-02, This document proposes a mechanism for MEGACO controlled legal intercept without the use of topology descriptor. Only call content duplication is addressed in this draft. The generation of call data information is outside the scope of this draft. "The Secure Routing Protocol (SRP) for Ad Hoc Networks", Panagiotis Papadimitratos, 11-Dec-02, This document describes the Secure Routing Protocol (SRP), a route discovery protocol for ad hoc networks that mitigates the detrimental effects of maliciously behaving nodes that disrupt the route discovery in order to obstruct or disable the network operation. Our protocol provides correct routing information; i.e., factual, up-to-date and authentic connectivity information regarding a pair of nodes that wish to communicate in a secure manner. The sole requirement is that any two such end nodes have a security association. Accordingly, SRP does not require that any of the intermediate nodes perform cryptographic operations or have a prior association with the end nodes. The end-to-end operation of SRP allows for efficient cryptographic mechanisms, such as message authentication codes. More importantly, SRP can be used in a wide range of MANET instances, without restrictive assumptions on the underlying trust, network size and membership. "IESG Overload and Quantity of WGs", John Klensin, 11-Dec-02, One of the key proposals in the PACT [PACT] draft is a limit on the duration of Working Groups. The authors believe that limitations of that type are too constraining on IESG ability to manage working groups and areas and that they will not be effective in practice. We propose an alternate restriction -- on the total number of working groups in an Area -- that we believe will have a number of desirable effects (a superset of those suggested with the PACT model) and that it is more likely to operate as intended. "RTP Payload Format for ETSI ES 202 050 Distributed Speech Recognition Encoding", Qiaobing Xie, David Pearce, 12-Dec-02, This document specifies an RTP payload format for encapsulating ETSI Standard ES 202 050 advanced front-end signal processing feature streams for distributed speech recognition (DSR) systems. "NSIS Transport Layer Protocol (NTLP) Functionality", Marcus Brunner, 16-Dec-02, This memo is a first step towards the design of a NSIS Transport Layer Protocol (NTLP). It lists protocol requirements, protocol design principles, and functional issues on the protocol level coming out of the NSIS requirements document[NSIS-REQ], the NSIS framework document [NSIS-FW], and several analysis documents. This list might be very near to implementation or solution already. The draft has been motivated by recommendations to list protocol requirements instead of higher level NSIS requirements as done in the NSIS requirements draft [NSIS-REQ]. "Zerouter Protocol Requirements", Jeb Linton, Guillaume Chelius, 16-Dec-02, This document provides requirements for protocols addressing Zero-configuration routing, known as 'Zerouter' protocols. It identifies requirements applicable to any of various approaches that may be proposed to this problem space, and is provided with the aim of ensuring complete and secure protocol definition. Scope is defined to ensure operation compatible with existing protocols while minimizing overlap with other ongoing work. "Dynamic Binding Update using AAA", Miyoung Kim, Y. Mun, 16-Dec-02, This document describes the procedure of how dose the Mobile Node(MN) exchange the messages with it's Corresponeant Node(CN) by using the secure communication platform, the AAA infrastructure that consists of the many AAA servers in different domains when the MN is about to enter the visited link. The MIPv6 node (MN, CN or both) has the unique identifier, NAI (Network Access Identifier) to distinguish itself from others and by parsing the NAI[5], we can get the information on which domain the MN belongs. "Diff-Serv-aware MPLS Traffic Engineering Network Management Information Base Using SMIv2", Thomas Nadeau, Sanjaya Choudhury, 05-Mar-03, 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 for modeling and managing Diff-Serv-aware MPLS Traffic Engineering [DSTE-REQ][DSTE-PROTO]. "DNS RR type for Multiple Unicast", Mukesh Bhatla, 16-Dec-02, To date, the scenario of multiple IP addresses for same domain name arises for the case where either we have multihomed IP hosts or we have multiple servers having the same domain name and application on the client needs to approach only one of those IP hosts. However, the penetration of mobile hosts and personal devices identified, on the internet, by the user's Network Access Identifier (NAI) may create a scenario where multiple devices may have same domain name but different IP addresses and all of those devices may need to get the service or data from the application which only identifies them by their host name. This document proposes to add a new Resource Record called the Multiple Unicast Resource Record (MURR) to the DNS system. This resource record is added for a domain name where the applications retrieving the IP address for the domain name have to provide the service (like PUSH data) to all the IP addresses retrieved in the multiple MURRs for the domain name. "BIP: Billing Information Protocol", R Prasanna, 16-Dec-02, Billing information protocol is a simple protocol that can be used by servers to indicate the charging information incurred due to a specific operation with a client. In many situations a client, like a SIP user agent may need to know the charging information about a specific interaction with the server. This document defines the BIP (Billing Information Protocol) that can be used as a standard way to share this charging information. BIP supports simple indication of charging information. The protocol defines a generic representation on the number of units charged, the charge incurred per unit etc. This will be useful for implementing services like advice of charge. The protocol is targeted for VoIP usages, however any generic client-server interaction can use this protocol. "Configuration payload", Darren Dukes, 18-Dec-02, This document proposes changes to IKEv2 [IKEv2] to allow configuration data to be securely distributed to IPsec Remote Access Clients (IRACs) by IPsec Remote Access Servers (IRASs). It is assumed this draft will be merged with the IKEv2 draft [IKEv2] and refers to sections in that draft, preceded by '****'. This draft, on its own, is not intended to progress to any RFC status. Comments regarding this draft should be sent to ddukes@cisco.com or ipsec@lists.tislabs.com "Extreme Networks'Ethernet Automatic Protection Switching (EAPS), Version 1", S Shah, M Yip, 16-May-03, This document describes the Ethernet Automatic Protection Switching (EAPS) (TM) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at lower cost and without some of the constraints (e.g. ring size) of SONET. "IPv6 Deployment using Device ID", Steve Park, 18-Dec-02, This document presents a new configuration of EUI-64 format through defined Device ID for identification and characteristic of all Devices in unmanaged network especially 'Home network'. Because of configured Device ID, all Devices in network must be classified and communicated each other. The main purpose of this document is to deploy IPv6 easily and widely. "Secure Legacy Authentication (SLA) for IKEv2", Paul Hoffman, 18-Dec-02, SLA is a new IKEv2 exchange that reuses most of the features of the IKEv2 Initial (Phase 1) exchange but allows for legacy authentication that is not susceptible to man-in-the-middle attacks. It has a flexible number of messages based on the type of authentication being used, and is extensible for new authentication mechanisms. SLA will work with remote access configuration in the same way as IKEv2's Initial exchange. "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 18-Dec-02, This specification defines a set of requirements for new capabilities for instant messaging and presence in SIP-based systems. "Shared Secret Provisioning Protocol", Robert Moskowitz, 31-Jan-03, Shared secrets are common in IETF protocols. Setting these shared secrets is typically defined as out of scope of those protocols. The upshot of this approach is poor security practices in setting these secrets and, through the life of the implementation, changing these secrets. The Shared Secret Provisioning Protocol (SSPP) provides a mechanism for both setting and changing shared secrets that are provably strong. "The Impact of Site-Local Addressing in Internet Protocol, Version 6 (IPv6)", Margaret Wasserman, 06-Mar-03, Internet Protocol, Version 6 (IPv6) introduces a scoped unicast addressing architecture, including the concept of site-local addressing. Although site-local addresses were originally defined for use in networks that were not yet connected to the Internet, there has been work underway for several years to expand the use of site-local addresses to globally connected IPv6 networks and nodes. The use of site-local addresses on globally connected networks and nodes raises complex technical issues for many parts of the TCP/IP protocol suite. Many of these issues are caused by the fact that IPv6 sites are private address spaces, and site-local addresses are unreachable or ambiguous outside the borders of their originating site. Site-local addresses also add significant complexity at the IP layer and at other layers of the protocol stack. In addition, many of the benefits of site-local addressing can be achieved using mechanisms that are significantly less complex and that cause fewer problems than IPv6 site-local addressing. This document makes a recommendation to limit the use of site-local addresses to isolated, single-site networks, and offers suggestions for less complicated mechanisms to achieve many of the benefits currently attributed to IPv6 site-local addressing. "Session Initiation Protocol Extension for Response Integrity Check using Validation Cookie", Sachin Shenoy, 18-Dec-02, This document defines an extension to the Session Initiation Protocol (SIP). This extension allows detection of stale responses and responses whose Via header (SIP [1]) have been modified. This memo suggests new processing rules at the proxy servers while forwarding requests and responses. The extension works by defining a new parameter which would be used to run an integrity check on received responses. "Policy Core Extension LDAP Schema (PCELS)", Angelica Reyes, 01-Jul-03, This document defines a number of changes and extensions to the Policy Core LDAP Schema [PCLS] based on the specifications of the Policy Core Information Model Extensions [PCIM_EXT]. The changes include additional object classes previously not covered, deprecation of some object classes and changes to the object class hierarchy defined in PCLS. "Using Radius for PE-Based VPN Discovery", Juha Heinanen, 09-Jun-03, This document describes how in PE-based VPNs a PE of a VPN can use Radius to authenticate its CEs and discover the other PEs of the VPN. "RPSLng", Joao Luis Damas, Larry Blunk, Florent Parent, Andrei Robachevski, 18-Dec-02, This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. "The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol", Gonzalo Camarillo, 19-Jun-03, This document creates an IANA registry for SIP header field parameters. It also lists the already existing parameters to be used as initial values for that registry. . "Netlink2 as ForCES protocol", Jamal Hadi Salim, 20-Dec-02, This document describes Netlink2, which is an extension of Linux Netlink [Netlink]. This document is intended as a proposal for the ForCES IETF working group protocol. ForCES attempts to define a clear separation between the two enti- ties of the NE in order to have them evolve separetely as opposed to the current monolithic evolution. "MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport", Juha-Pekka Luoma, 05-Mar-03, This document defines MUPPET, a point-to-multipoint transport protocol for the delivery of Internet Media Guides over unidirectional access networks. This protocol is intended to be used with the Internet Media Guide framework, and in addition may be useful with other applications. "A Registry of Assignments using Ubiquitous Technologies and Careful Policies", Daniel Connolly, Mark Baker, 23-Dec-02, Registries are a critical part of many of the systems which inhabit the Internet today. Unfortunately, not a lot of the assignments within those registries are as accessible as they could be. This document outlines a best current practice approach to improving the accessibility of assignments within registries using ubiquitous technologies and low cost supporting policies. "DNS-Based Service Discovery", Stuart Cheshire, 26-Jun-03, This document describes a convention for naming and structuring DNS resource records. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of a that desired service, using only standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD. "Requirements for Session Policy for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 06-Jan-03, The proxy server plays a central role as an intermediary in the establishment of sessions in the Session Initiation Protocol (SIP). In that role, they can define and impact policies on call routing, rendezvous, and other call features. However, there is no standard means by which proxies can have any influence on session policies, such as the codecs that are to be used. As such, ad-hoc and non-conformant techniques have been deployed to allow for such policy mechanisms. There is a need for a standards-based and complete mechanism for session policies. This document defines a set of requirements for such a mechanism. "The EAP GPRS Protocol (EAP-GPRS)", Apostolis Salkintzis, 06-Jan-03, This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. "Proposed Changes to Connection Oriented Media Handling in the Session Description Protocol (SDP)", Jonathan Rosenberg, 06-Jan-03, This document describes changes that are proposed to draft-ietf-mmusic-sdp-comedia-04, which describes the handling of connection oriented media in the Session Description Protocol (SDP). These changes are motivated by problems encountered in using comedia to support instant messaging sessions in the SIMPLE working group. "The Session Initiation Protocol (SIP) INFO Method Considered Harmful", Jonathan Rosenberg, 06-Jan-03, The Session Initiation Protocol (SIP) INFO method defines a means for transporting mid-dialog application layer data between user agents. Its initial use was to support the transport of ISUP mid-call messages which could not be mapped to any other SIP request method. However, since its initial usage for that purpose, INFO has seen widespread abuse as a means for introducing non-standard and non-interoperable extensions to SIP. For this reason, we now believe INFO should be considered harmful, and therefore, deprecated in its current form. "Efficient and Fast Discovery of Slave Home Agent's Address", Pyungsoo Kim, 06-Jan-03, This document proposes a new mechanism in Mobile IPv6, which allows a mobile node to discover promptly a suitable slave home agent's address on its home link when the mobile node may not know a master home agent's address due to some reasons. To implement the proposed mechanism, new Binding Update/Acknowledgement messages are defined. The proposed mechanism might be more efficient and general, and faster than the existing Home Agent Address Discovery in [1]. "Service Centric Management (SCM)", Sharon Barkai, G Stupp, 07-Jan-03, With the proliferation of IP based internetworking services to mass business and consumer markets carriers are faced with operational challenges in an extent never before experienced in previous LAN MAN or WAN environments. To accommodate these new internetworking envi- ronments, carrier workflow management applications for service Ful- fillment, Assurance, and Billing (FAB) need to undergo major a tran- sition. In essence applications need to transition from being per technology centric to being service centric, as historic correspon- dence between technology and service is no longer true. Applications do not need to change in nature, since they still need to support inventory, CRM, order and other workflows. However, applications need to include a service centric aspect as basis for these work- flows. Service Centric solutions can be shared by a wide range of management and workflow applications, rather than be re-invented by each one. Service Centric Management solutions must be distributed in order to cope with the massive scale and complexity challenges of the underly- ing networks. Service Centric Management Protocol (SCMP) and distri- bution should be standardized to facilitate multi-vendor interoper- ability in this emerging space, allow for potential future embedding within NE, and to allow for Service Centric Management primitives to extend across Inter Carrier Interfaces (ICI) and inner carrier regu- latory bounds. "Moderate Use Case for IPv6 Site-Local Addresses", Robert Hinden, 04-Mar-03, This internet draft describes the moderate use case for IPv6 Site- Local Addresses. "LDAP Partial Entry Control", S Haripriya, G Vithalprasad, 07-Jan-03, This document defines a mechanism to augment the LDAPv3 [RFC2251]search operation through an LDAP search control for sending a partial search entry to an LDAP client as result of a search operation in the SearchResultEntry LDAP PDU. This mechanism lets the LDAP client specify size and time limits to be applied to the server-side processing of a single SearchResultEntry. This document defines two LDAP controls required to support the above requirement. "MIME media types for DPNSS Objects", R Mukundan, 01-Jul-03, This document describes Multipart Internet Mail Extensions (MIME) type for application/Digital Private Network Signaling System (DPNSS) objects for use in Session Initiation Protocol (SIP) applications, according to the rules defined in RFC 2048. These types can be used to identify Digital Private Network Signaling System 1 (DPNSS 1) objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a similar need for Integrated Service Digital Network User Part (ISUP) and Q Signaling (QSIG). "An Attack Tree for the Border Gateway Protocol", Sean Convery, 07-Jan-03, This I-D presents all known attack vectors into or using BGP. The data is presented in 'Attack Tree' format as published by Schneier [1] and detailed by the CERT in 'Attack Modeling for Information Security and Survivability' [2]. Future security improvements to BGP (whether best practices or enhancements to the protocol) should consider the attacks outlined here when determining the relative security improvements such changes provide. "RTP Payload Format for Vorbis Encoded Audio", Phil Kerr, 10-Jun-03, This document describes a RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and details the delivery mechanisms for the decoder probability model, referred to as a codebook, metadata and other setup information. "The audio/rtp-vorbis MIME Type", Barry Short, 08-Jan-03, This document explains the need for a MIME subtype which identifies a Vorbis audio payload to be used within a Realtime Transport Protocol (RTP) bitstream. This document also provides the necessary information to register audio/rtp-vorbis as a MIME type. "Carrying TCAP in SIP Messages (SIP-TCAP)", Frank Miller, 08-Jan-03, SIP-TCAP is a mechanism by which an XML representation of TCAP messages can be transported in the body of SIP INFO messages. This mechanism can be used to allow SIP elements to access features implemented by PSTN equipment without having to implement the binary TCAP protocol. "A Kerberos 5 SASL Mechanism", Simon Josefsson, 03-Feb-03, This document specifies a Simple Authentication and Security Layer (SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1], with optional initial Authentication Service (AS) and/or Ticket-Granting-Service (TGS) exchanges. "6bone (IPv6 Testing Address Allocation) Phaseout", Robert Fink, Robert Hinden, 12-Jun-03, The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This note establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document is intended to obsolete RFC 2471, 'IPv6 Testing Address Allocation', December, 1998. RFC 2471 will become historic. "SS7 ISUP-User Adaptation Layer ISUA", Brian Bidulock, 10-Jan-03, This document defines a protocol for the transport of any SS7 ISUP- User signalling (e.g, Call Control) over IP using the Stream Control Transport Protocol [RFC 2960]. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway and IP Signalling End-point architecture. Protocol elements are added to allow seamless operation between peers in the SS7 and IP domains. "PANA Framework Issues", Hannes Tschofenig, 10-Jan-03, This document discusses framework assumptions relevant to activities in the PANA working group. It is tentative in nature and raises issues regarding some assumptions made in the group. The aim of this draft is therefore not to propose solutions instead issues are highlighted which might require further consideration "Online Certificate Status Protocol Core", Michael Myers, 10-Jan-03, This document expands the core syntax of [RFC2560] in support of additional means to identify a certificate in the Online Certificate Status Protocol (OCSP). It improves the integration of OCSP with other IETF protocols that involve X.509-based public key and attribute certificates while preserving interoperability with existing OCSP implementations. "Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205", Lars Westberg, 28-Feb-03, The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the desire of many to deploy technology to deliver services with different levels of quality of service (QoS) to their customers. The reasons for this are arguably well-understood and documented and are not the focus of this memo. This memo is proposing a (NSIS Transport Layer Protocol) NTLP, that is a modified version of RSVPv1 specified in RFC2205. Furthermore, it provides design guidelines and specifications for the development of the NLTP that is based on a modified version of RSVPv1. "Multihoming in IPv6 by multiple announcements of longer prefixes", Kurt Lindqvist, 10-Jan-03, In the current IP version 4 Internet, many organizations that are not Internet Service Providers are still getting their Internet connectivity through multiple providers by having address space that are announced via multiple paths. This is commonly referred to as multihoming. For the IP version 6 Internet, there have long been a debate as to how to achieve the same effect. This document addresses these issues by highlighting some of the current policies and how these can be used to achive multihoming for IP version 6 connected networks. "Registration Extensions (REGEXT)for Signalling User Adaptation Layers", Brian Bidulock, 10-Jan-03, This memo describes Registration Extensions (REGEXT) that provides the ability for an Application Server Process (ASP) to modify existing Routing (Link) Keys with a Signalling Gateway (SG). Current procedures in the SS7 Signalling User Adaptation Layers (UAs) [M2UA..TUA] do not provide for the modification of Routing (Link) Keys without deactivation of the Application Server (AS). This causes problems in making changes to live systems. The extensions described in this memo permit modification of Signalling Link membership in Application Servers for SS7 MTP2-User Adaptation Layer [M2UA], modification of Circuit Identification Code (CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA], modification of Circuit Identification Code (CIC) rnages for the SS7 ISUP-User Adaptation Layer [ISUA], modificiation of Destination Local Reference (DLR) ranges for SS7 SCCP-User Adaptation Layer [SUA], and modification of Transaction Identifier (TID) ranges for SS7 TCAP-User Adaptation Layer [TUA]. "Inactive Path Advertisement in BGP-4", Justin Fletcher, 13-Jan-03, This document defines BGP capabilities and a path attribute to permit advertisement of routes other than those selected during the BGP decision process. These extensions would provide additional routing information for research, monitoring and policy decisions. "Internet X.509 Public Key Infrastructure Plug-and-Play PKI for Web Services", Anders Rundgren, 13-Jan-03, 'Web Services' [2, 3] is the collective name of a set of emerging technologies targeted for ultimately supporting Plug-and-Play (PnP) integration of business- and information-systems, within and between organizations. This specification covers an X.509 certificate extension, designed to enable PnP-support for the Public Key Infrastructure (PKI) part of a Web Service. In addition to supporting Web Services, the extension is also intended to be useable for general-purpose PKI-enabled applications. A PowerPoint presentation highlighting the core of this specification is also available [4] "State Machines for EAP Peer and Authenticator", John Vollbrecht, 17-Jun-03, This document describes a set of state machines for EAP Peer, EAP Authenticator (supporting local, passthrough and backend), for EAP Passthrough method, and for 'backend adapter' that adapts EAP traffic carried by an AAA protocol such as RADIUS or Diameter to a Backend Authenticator. This set of state machines shows how EAP can be implemented to support deployment in either a Peer/AP or Peer/AP/AAA Server environmnet. The Peer and Authenticator machines are illustrative of how the EAP protocol defined in [I-D.ietf-eap-rfc2284bis] may be implemented. The Passtrhough method and 'backend adapter' illustrate how EAP protocol support defined in [I-D.aboba-radius-rfc2869bis] may be implemented. Where there are differences [I-D.ietf-eap-rfc2284bis]/ [I-D.aboba-radius-rfc2869bis] are authoritative. This document describes a state machine based on an EAP 'Switch' model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. A brief description of the EAP 'Switch' model is given in the Introduction section. This document is still a work in progress. The authors believe it corresponds to the current state of revisions to the defining [I-D.ietf-eap-rfc2284bis]/[I-D.aboba-radius-rfc2869bis] documents, but it has not been vetted by the EAP working group as a whole. An appendix to this document points out issues the authors believe still need to be resolved between the documents. The intent is to synchronize this document with [I-D.ietf-eap-rfc2284bis] and [I-D.aboba-radius-rfc2869bis] revisions when they are released and then submit it as an RFC. "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol (SIP)", Dean Willis, 14-Jan-03, The SIP INFO method (RFC 2976) establishes a method by which applications may transfer application-specific information within a SIP dialog. However, RFC 2976 does not provide a mechanism for describing and documenting an application of INFO, nor does it provide a mechanism by which applications may negotiate such uses. This document provides a framework for documenting and naming specific uses of INFO (called INFO packages), for registering those package names with IANA, and for negotiating the support for various INFO packages between applications using SIP. "M3UA Congestion procedures", Kamesh Kaul, 15-Jan-03, This Internet-Draft describes congestion procedures applicable for both M3UA [2] ASP and SG nodes. Draft explains all the procedures needed by M3UA [2] ASP and SG to handle local and network congestion communicated between M3UA [2] SG and ASP through SSNM messages. Congestion procedures proposed are in line with MTP3 Q.704 with some alteration to suit sigtran architecture. "Considerations for IEPREP Related Protocol Packet Flow Models", James Polk, 16-May-03, This document diagrams the packet flows - both signaling and data - of Internet Emergency Preparedness (IEPREP) related protocols. This document serves as a point of reference for the WG when discussing which QoS mechanisms can be employed for each individual (application) protocol packet flow to function properly during congestion events from IP source to IP destination, as well as a potentially different QOS mechanism for a related but separate data flow (if present). "Reoptimization of MPLS Traffic Engineering loosely routed explicit LSP paths", Jean Vasseur, Yuichi Ikejiri, 27-Jun-03, The aim of this document is to propose a mechanism for the reoptimization of MPLS Traffic Engineering loosely routed explicit LSP paths. A loosely routed explicit LSP path is a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and zero or more strict hop(s). The path calculation (which implies ERO expansion) to reach a loose hop is made on the previous hop defined in the TE LSP path. This draft proposes a mechanism that allows: - The TE LSP Head-end LSR to trigger a new ERO expansion on every hop having a next hop defined as a loose hop, - An LSR to signal to the TE LSP head-end that a better path exists to reach a loose hop (than the current path in use). A better path is defined as a path with a lower cost, where the cost is determined by the metric used to compute the path. This primarily applies to inter-area TE LSPs and inter-AS TE LSPs when the path is defined as a list of loose hops (generally the loose hops are the ABRs/ASBRs) but the following mechanism is also applicable to any loosely routed explicit path within a single routing domain. "EAP over CDMA2000 (EAPoCDMA2000)", Parag Agashe, Frank Quick, 16-Jan-03, This document specifies the Extensible Authentication Protocol over CDMA2000 (EAPoCDMA2000) to be used for service access authentication. Before a CDMA2000 access terminal is granted access to a service provided by a service provider in a CDMA2000 access network, the service provider may use EAPoCDMA2000 to authenticate the access terminal. EAPoCDMA2000 is a variation of the Extensible Authentication Protocol (PPP EAP) [2]. EAPoCDMA2000 allows authentication over CDMA2000 link layer technology. EAPoCDMA2000 uses UDP as its transport protocol. "Architecture for Zerouter", Oliver Marce, Damien Galand, 16-Jan-03, This document proposes an architecture for the self-configuration mechanisms to be used in an IP network. It identifies the entity and the relation between them. It also looks at the existing self-configuration solutions and proposals, with regards to the proposed architecture. "IPv6 Domain Name Auto-Registration (6DNAR)", Soohong Park, 07-Mar-03, This document proposes automatic configuration of IPv6 network using Domain Name Auto-Registration(called 6DNAR). 6DNAR allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAR function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAR don't change any existing DNS system. "Framing RTP and RTCP Packets over Connection-Oriented Transport", John Lazzaro, 27-May-03, This memo defines a method for framing Real Time Protocol (RTP) and Real Time Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP and TLS). The memo also defines how to specify the framing method in a session description. "Protected EAP TLV", Joseph Salowey, 07-Mar-03, EAP type-length-value (TLV) message types provide a mechanism for encapsulating additional information in an EAP conversation. In some cases it is useful to cryptographically protect this information to maintain the integrity and/or privacy of the communication. This document defines a TLV type that uses message authentication to maintain the integrity of the data, encryption to protect the privacy of the data and sequence numbers to protect replays or re-sequencing of the data. Although protected TLVs must be chained after an authentication mechanism that generates key material the protection mechanism is independent of any particular authentication mechanism. "EAP Authorization", Mark Grayson, Joseph Salowey, 07-Mar-03, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authorization information exchange. EAP TLV is a Container type for EAP messages. This mechanism describes an EAP TLV for exchange of authorization related information which can take place within the EAP framework and allows an authentic user to provide the network with additional information in order to determine which Internet Service is being requested. This mechanism may be chained after any EAP-Authentication mechanism. "Distributed End-Point Firewall Control (DEFCon) Applicability Scenarios", Reinaldo Penno, 20-Jan-03, This document discusses the use of a distributed end-point firewall control (DEFCon) in various network deployment scenarios. "Extended RSVP-TE for Point-to-Multipoint LSP Tunnels", Seisho Yasukawa, Alan Kullberg, 07-Mar-03, This document specifies extensions and mechanisms to RSVP-TE in support of MPLS point-to-multipoint LSPs. "Anycast-RP using PIM", Dino Farinacci, Yiqun Cai, 22-Jan-03, This proposal allows Anycast-RP to be used inside a domain which runs PIM only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem. "Requirements for Limiting the Rate of Event Notifications", Aki Niemi, 04-Mar-03, All event packages are required to specify a maximum rate at which event notifications are generated by a single notifier. Such a limit is provided in order to reduce network congestion. In addition to the fixed limits introduced by specific event packages, further mechanisms for limiting the rate of event notification are also allowed to be defined by event package specifications but none have been specified so far. This memo discusses the requirements for a throttle mechanism that allows a subscriber to further limit the rate of event notification. "An IP Forwarding Policy Information Base", Mohammed Boucadair, Christian Jacquenet, 27-Jun-03, This draft specifies a set of Policy Rule Classes (PRC) for the enforcement of an IP forwarding policy by COPS-PR-enabled routers. Instances of such classes reside in a virtual information store, which is called the IP Forwarding Policy Information Base. The corresponding IP forwarding policy provisioning data are intended for use by a COPS-PR IP TE Client-Type, and they complement the PRC classes that have been defined in the Framework PIB. "Mobile IPv4 Dynamic Home Agent Assignment Framework", Miland Kulkarni, Alpesh Patel, Kent Leung, 01-Jul-03, Mobile IP (RFC 3344) uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). The distance between a MN and HA affects the latency for control and data traffic. When the distance between the MN and HA is large, the resulting latency may be unacceptable. Therefore, it is advantageous to select a nearest HA to the MN during initial registration. There are other reasons for assigning an optimal HA beyond just locality, such as administrative policies, load balancing etc. This draft proposes a generic lightweight dynamic home agent assignment framework. The goal of the framework is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA assignment. The mobile node uses NAI extension for home address assignment. "Design Considerations for an NSIS Transport Layer Protocol", Andrew McDonald, Robert Hancock, Eleanor Hepworth, 24-Jan-03, A framework for NSIS is in preparation, and will identify a split into two layers. The lower layer, referred to as the NSIS Transport Layer Protocol (NTLP) provides generic support for different types of path coupled signalling, including QoS signalling. This document discusses issues to be considered in the design of an NSIS Transport Layer Protocol (NTLP). "Event Notification Filtering for Presence", Hisham Khartabil, 24-Jan-03, The Presence event package for the SIP events framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of user presence. The document details how watchers can subscribe for notifications of all authorised and available presence information about the presentity. The document does not describe a mechanism of how filtering of presence information can be achieved. This document defines a presence filter package for the Event Notification Filtering Architecture. The package provides the mechanism whereby a watcher can specify the presence event filtering rules, using XML, for the presence agent (PA) and how that PA is to behave when receiving such filter. "Requirements for Efficient Delivery of Presence Information", Jose Costa-Requena, Mikko Lonnfors, 24-Jan-03, A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents requirements for a solution that aids in reducing the impacts of those constrains and increasing efficiency. "Partial Notification of Presence Information", Jose Costa-Requena, Eva Leppanen, 24-Jan-03, A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and increasing efficiency, by introducing a new MIME-type ‘partial notifications’ and a Require header extension ‘partial-notification’. "An XML format for mail and other messages", Graham Klyne, 24-Jan-03, This document describes a coding of email and other messages in XML. This coding is intended for use by XML applications that exchange information about such messages. "Cable Gateway Quality of Service (QoS) Management Information Base for CableHome compliant Residential Gateways", Amol Bhagwat, Douglas Jones, 06-Mar-03, 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 a basic set of managed objects for SNMP- based management for prioritized Quality of Service functionality within a LAN, between a CableHome residential gateway device and CableHome compliant LAN host devices. 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. "The MIME application/vnd.cip4-jdf+xml Content-Type", Thomas Hastings, Ira McDonald, 27-Jan-03, The International Cooperation for the Integration of Processes in Prepress, Press, and Postpress (CIP4) is an international worldwide standards body located in Switzerland. The purpose of CIP4 is to encourage computer based integration of all processes that have to be considered in the graphic arts industry. CIP4 has defined two document formats that are encoded in W3C Extensible Markup Language (XML): (1) CIP4 Job Definition Format (JDF) - an open standard for integration of all computer aided business and production processes around print media; (2) CIP4 Job Messaging Format (JMF) - an open standard for job messaging using Hyper Text Transport Protocol/1.1 (HTTP/1.1, RFC2616) that defines Query, Command, Response, Acknowledge, and Signal message families. This document defines two new MIME sub-types for IANA registration: (1) 'application/vnd.cip4-jdf+xml' for CIP4 Job Definition Format; (2) 'application/vnd.cip4-jmf+xml' for CIP4 Job Messaging Format. "Flexible BGP Communities", Andrew Lange, 01-Jul-03, This document defines a new attribute for BGP called the Flexible Community attribute. Flexible Communities build on the experience and utility of the standard BGP community, and the extended BGP community attributes. This attribute allows operators to associate structured information with a route or set of routes. This information can be then be used to execute routing policy. An enhanced version of communities is necessary to accomodate IPv6, 4- byte ASN's, and introduce a more extensible and flexible policy expression. This document also introduces the concept of Neighbor Classes. A Neighbor Class is applied to a group of BGP neighbors who share certain attributes. For example, the PEER Neighbor Class could be applied to BGP sessions between ASN X and other networks with which ASN X has a non-transit peering relationship. "Remote Access to Embedded Devices", Olaf Pfeiffer, Paul Lukowicz, 27-Jan-03, The aim of this document is to standardize remote access options to parameters of embedded devices with limited resources. Typically such devices are based on 8-bit or 16-bit microcontrollers with limited memory (64K or less) and a low operating frequency (20 MHz or less). The protocol described in this document uses existing markup formats to specify modifiable parameters of embedded devices and existing protocols to transfer these parameters between clients and servers. "Issues when translating between IPv4 and IPv6", Ronald van der Pol, Suresh Satapati, Senthil Sivakumar, 28-Jan-03, During the transition from IPv4 to IPv6 both protocols will be used simultaneously. Most nodes will support both protocols and will be able to communicate via both IPv4 and IPv6 transport. Problems arise when a node only supports IPv4 and it wants to communicate with a node that only supports IPv6. Translation between the two IP protocols might be needed in some cases. This memo discusses the problems involved in translation between IPv4 and IPv6. "Protocol Topology Support for IS-IS", Kay Noguchi, Toshiaki Takada, 06-Mar-03, RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. [2] adds functionality to Integrated IS-IS so that it supports IPv6. RFC 1195 [1] places topological restrictions on networks that are routed using Integrated IS-IS, specifically, that every router in a level-1 area must be capable of all network layer protocols that are present in that area, and every router in a level-2 area must be capable of all network layer protocols that are present in the whole IS-IS routing domain. The mechanism described in this document enables a single IS-IS routing domain to support different network layer protocol topologies by maintaining separate SPF trees for each network layer protocol. "IP header compression in IP tunneling protocols", J Vilhuber, 28-Jan-03, Bandwidth consumption of RTP flows can be reduced by tunneling and compressing headers. This draft defines an IP protocol number and a header which can be used to transport IP Header Compressed [IPHC], Compressed RTP [CRTP], and Enhanced Compressed RTP [ECRTP] packets over an arbitrary IP tunnel (IP-in-IP or ESP, for example) to reduce bandwidth consumption for RTP flows. "IP header compression in IPsec ESP", J Vilhuber, 28-Jan-03, This draft outlines how to use IP Header compression over IP tunnels [HCOIP] inside IPsec ESP [ESP]. "Requirements for Presence specific Event Notification Filters", Tim Moran, Sreenivas Addagatla, 29-Jan-03, This document defines a set of structured requirements whereby an event subscriber (client) may specify when notifications are sent to it and what the contents should be. "Request to Move RFC1267 to Historic Status", David Meyer, 29-Jan-03, RFC1267 [RFC1267], 'A Border Gateway Protocol 3 (BGP-3)' describes a technology which is no longer commonly used. This document requests that RFC 1267 be moved to historic status. "Request to Move RFC1269 to Historic Status", David Meyer, 29-Jan-03, FC1269 [RFC1269], 'Definitions of Managed Objects for the Border Gateway Protocol (Version 3)' describes a technology which is no longer commonly used. This document requests that RFC 1269 be moved to historic status. "Request to Move RFC1265 to Historic Status", David Meyer, 29-Jan-03, RFC1265 [RFC1265], 'BGP protocol Analysis' documents how the requirements for advancing a routing protocl to Draft Standard have been satisfied by a BGP-3, a technology which is no longer commonly used. This document requests that RFC 1265 be moved to historic status. "Request to Move RFC1266 to Historic Status", David Meyer, 29-Jan-03, RFC1266 [RFC1266], 'Experience with the BGP Protocol' documents how the requirements for advancing a routing protocol to Draft Standard have been satisfied by a BGP-3, a technology which is no longer commonly used. This document requests that RFC 1266 be moved to historic status. "Multihoming Using IPv6 Addressing Derived from AS Numbers", Pekka Savola, 30-Jan-03, In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS- number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4. "Adaptive Mail Delivery Protocol (AMDP)", Adonis Fakih, 30-Jan-03, This document describes the Adaptive Mail Delivery Protocol (AMDP). It aims to resolve the problems associated with current email systems that rely on the mail delivery process defined by the Simple Mail Transfer Protocol (SMTP). This is done by extending and designing a backwards-compatible replacement for SMTP, as well as restructuring the mail delivery process. The process is built around an adaptive scheme that is able to addresses current and future demands for a secure and reliable e-mail delivery systems. "Address Management for IKE version 2", Francis Dupont, 01-Jul-03, The current IKEv2 proposal [1] lacks an address management feature. As it is compatible with the NAT traversal capability, this document specifies a complete address management with support for multi-homing and mobility. "IMAP Virtual Hosting", Harrie Hazewinkel, 30-Jan-03, This memo describes an extension to the IMAP protocol in order to enable virtual hosting. The concept of virtual hosting for HTTP is used and a new IMAP command is introduced to provide the virtual hosting feature. "STATIC DICTIONARY MANIPULATION PROTOCOL", Vishal Verma, 31-Jan-03, This document describes protocol with which content at endpoints can be synchronized with logical entity named as content controller(CoC). One of the application of this protocol includes management and synchronization of static dictionary at SigComp devices.Protocol deals with management and synchronization of content among devices in the network and is independent of content format. "SSPP over SNMP", Robert Moskowitz, 31-Jan-03, The Shared Secret Provisioning Protocol (SSPP) [2] provides the both the cryptographic functions and the basic protocol for provisioning shared secrets based on a Diffie-Hellman key exchange. This document describes the basic SNMP functions to support SSPP. "The Alternative Semantics for the Session Description Protocol Grouping Framework", Gonzalo Camarillo, Jonathan Rosenberg, 19-Jun-03, This document defines the alternative (ALT) semantics for the SDP grouping framework. The ALT semantics allow offering alternative transport addresses to establish a particular media stream. This is useful in scenarios that involve IPv4 and IPv6 and/or network address translators. "Enhancements to ECRTP with Applications to Robust Header Compression for Wireless", Vijay Madisetti, Sira Rao, Nitin Suresh, 03-Feb-03, Enhanced Compressed RTP (ECRTP) and Robust Header Compression (ROHC) are IP header compression schemes that have been proposed for use in wireless applications, primarily for voice and audio applications. While ROHC offers a high degree of compression and is robust, it is also computationally expensive. On the other hand, ECRTP does not achieve as high a compression, while being less expensive computationally. Our porposal, E2CRTP, is an enhanced version of ECRTP that offers a middleground between the ROHC and ECRTP, providing robustness, compression efficiency, and moderate computational complexity. "MTU Issues in IPv6 Neighbor Discovery", Fred Templin, 03-Feb-03, This document discusses Maximum Transmission Unit (MTU) issues in IPv6 Neighbor Discovery and suggests minor augmentations to the existing specification to rectify the issues. "News Article Format", Daniel Kohn, 28-Mar-03, This document defines the format of network news articles. 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. Since then Usenet has grown explosively, and many 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 defines the format of network news articles in the context of the Internet Message Format, and adds Multipurpose Internet Mail Extensions (MIME) support for multimedia and internationalized message bodies. "Requirements for Access Control in Domain Name Systems", Tatsuya Baba, 04-Feb-03, This document describes the requirements for access control mechanisms in the Domain Name System (DNS), which authenticate clients and then allow or deny access to resource records in the zone according to the access control list (ACL). "Clarifying the Role of Wild Card Domains in the Domain Name System", Edward Lewis, Bob Halley, 04-Feb-03, The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. "RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP)", Henning Schulzrinne, 19-Feb-03, The Rich Presence Information Data Format for SIP (RPIDS) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior and/or be delivered to watchers. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. "Internationalizing Mail Addresses in Applications (IMAA)", Paul Hoffman, Adam Costello, 18-Apr-03, The Internationalizing Domain Names in Applications (IDNA) specification describes how to process domain names that have characters outside the ASCII repertoire. A user who has an internationalized domain name may want to have their full Internet mail address internationalized, including the local part (that is, the part to the left of the '@'). This document describes how to use non-ASCII characters in local parts, by defining internationalized local parts (ILPs), internationalized mail addresses (IMAs), and a mechanism called IMAA for handling them in a standard fashion. "SNMP Overhead and Performance Impact", Louis Breit, 05-Feb-03, This memo provides an overview of the network and device overhead associated with SNMP polling and common network management platforms. In particular, it describes a means to calculate this overhead and determine the level of system impact prior to deployment, or as part of a planning process. "NSIS Authentication, Authorization and Accounting Issues", Hannes Tschofenig, 07-Mar-03, This document describes the implications of authentication, authorization and accounting for an NSIS QoS signaling protocol. We try to show that authorization and charging are very important for the internal machinery of a signaling protocol and for the security and trust model behind it. This document only addresses charging aspects for unicast data traffic. "An Out-of-Band authentication procedure for SIP", Manoj Wagle, Rohit Aradhaya, 06-Feb-03, This document describes a out-of-band security mechanisam using Kerberos-PKI for providing end-to-end security between SIP clients. "Analysis of MPA over TCP Operations", Uri Elzur, 06-Feb-03, Further explanation and analysis of architectural recommendations contained in the recent Internet-Draft, Marker PDU Aligned Framing for TCP Specification [MPA], is provided. The impact of the following three attributes of MPA over TCP is examined: * packing of multiple DDP ULPDUs into one TCP segment; * simplifying the receiver due to transmitter alignment of DDP headers with TCP headers; and * mistakenly attempting to interoperate an MPA-enabled endpoint with a non-MPA-enabled endpoint. "Framework of Overlay Multicast Control Protocol", Seok Koh, Je-Young Park, 07-Feb-03, This document describes Overlay Multicast Control Protocol (OMCP) used for realizing and managing Overlay Multicast, as also known as Application Layer Multicast. Overlay Multicast is a data delivery scheme for multicast applications, in which one or more intermediate relay agents are employed for relaying application data from a sender to many receivers along a pre-configured or automatically configured tree hierarchy. For standardization of Overlay Multicast, it needs to separate the data plane (for packet relaying) and the control plane (for tree configuration and session monitoring). We describe a control protocol for Overlay Multicast, named Overlay Multicast Control Protocol (OMCP). In OMCP, a special-purpose entity, called Session Manager, is used to manage and control the tree configuration and session monitoring. OMCP is designed to ensure that the multicast applications and services can be provided over current Internet environments in which IP multicast has not completely been deployed. "Considerations for the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 10-Feb-03, This draft explores several issues with the Session Initiation Protocol's non-INVITE transaction. It focuses on the use of provisional responses and on problems related to transaction timeouts. "Name Resolution in on-demand MANETS and external IP Networks", Paal Engelstad, Geir Egeland, 10-Feb-03, The most common user applications for data communication (including web browsing and e-mail) lack a method for name resolution in multi- hop wireless ad-hoc networks of mobile nodes (MANETs). While the Domain Name System (DNS) works well on the fixed Internet, it represents a centralized approach to name resolution, which is not suitable for MANETs. This document specifies a straightforward solution for name resolution in on-demand MANETs, i.e. MANETs that are routed with a reactive routing protocol, such as DSR [DSR] or AODV [AODV]. Names that are resolved locally within the MANET will normally have preference. However, MANET nodes that have access to external networks may complement the local name resolution by injecting into the MANET addresses resolved by a conventional DNS server. The proposed solution applies equally well to IPv4 or IPv6. "IANA Considerations for RADIUS", Bernard Aboba, 24-Apr-03, This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). This document updates RFC 2865. "An Evaluation on RSVP Transport Mechanism", Ping Pan, Henning Schulzrinne, 05-Mar-03, In this memo, we look into some of the transport-layer design issues in the original RSVP as defined in RFC2205 [RFC2205]. Based on the observation, we conclude that the current RSVP transport mechanism may not be adequate to support some applications. We recommend to use a different transport layer protocol such as TCP for next-generation signaling protocols. "FDALC - File Delivery for ALC", Toni Paila, 10-Feb-03, This document defines unidirectional delivery of files. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. Thus, this document specifies a technique called FDALC - a mechanism for signalling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. "A View on IPv6 Transition Architecture", Pekka Savola, 10-Feb-03, The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches. "Reorder Density Function - Metric for packet reordering measurement", Anura Jayasumana, Nischal Piratla, Abhijit Bare, Tarun Banka, 11-Feb-03, Out of order arrival of packets can degrade the performance of many TCP-based, VoIP-based and Video-based applications significantly. There is a need for a metric that can meaningfully, accurately and unambiguously characterize reordering. This memo proposes a new metric called Reorder Density function (RD), which can give an in-depth view of the reordering present in any packet sequence. This well-defined metric can also be used to evaluate effects of protocol and hardware implementations on packet reordering. The memo also provides an algorithm to compute the reorder density function followed by some illustrative examples. "Registration for enumservices of group messages", Rudolf Brandner, Lawrence Conroy, Richard Stastny, 11-Feb-03, This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:' "Practices for TCP Senders in the Face of Segment Reordering", Ethan Blanton, Robert Dimond, Mark Allman, 11-Feb-03, This document outlines actions a TCP sender can take after determining that a spurious fast retransmission has been sent due to packet reordering. The document outlines the method a TCP connection can use to 'undo' needless changes made to the congestion control state. In addition, several methods to help prevent future fast retransmits are outlined. "Integrated transition toolbox for 3gpp cases", Amit Thakur, Ajay Jain, 11-Feb-03, This document describes the implementation of a transition 'toolbox' which intelligently choses between usage of application proxies, translation and tunneling depending on the deployment scenario. This document does not attempt to solve NA(P)T-PT related issues, though it does deal with certain issues. "Use of SCTP for Seamless Handover", Seok Koh, 12-Feb-03, The Stream Control Transmission Protocol (SCTP) is a new reliable transport protocol that provides the multihoming feature. Without support of routers in the networks, the SCTP with the ADDIP extension (called mobile SCTP) can be used to provide seamless handover for the mobile host that is changing its IP subnetworks during the session. In the present form, the use of mobile SCTP is targeted for handover of the mobile sessions that are originated from the mobile clients (located in mobile networks) toward the fixed servers (located in the fixed networks). The support for the opposite directional session (initiated by fixed node to mobile node) requires an additional location management scheme such as Mobile IP. In this document, we discuss the generic procedures for seamless handover of mobile SCTP and the concerned implementation issues. "mSCTP with Mobile IP for IP Mobility Support", Seok Koh, 21-May-03, Mobile SCTP (mSCTP) is defined as SCTP with the ADDIP extension. The mSCTP can be used for providing seamless handover by exploiting its multi-homing feature. On the other hand, the Mobile IP basically provides the location management. In this document, we discuss the use of mSCTP along with Mobile IP for IP mobile support in the harmonized manner. The use of SCTP with Mobile IP is focused on the mobile sessions that are initiated by CN to MN. "URI Leasing in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 12-Feb-03, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. An example of such an application is call transfer, based on the REFER method. To date, a variety of techniques have been proposed for the contruction of such URI. All of them have fatal drawbacks. This document proposes that the problem is actually one of URI leasing - a feature whereby a UA can dynamically request the creation of an address-of-record (AOR) within a domain. Requirements for a URI leasing mechanism are outlined. "Using CMS to Protect Firmware Packages", Russell Housley, 01-Apr-03, This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages. A digital signature is used to protect the firmware package from undetected modification and provide data origin authentication. Encryption is optionally used to protect the firmware from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading signed receipt can optionally be generated to acknowledge the successful loading of a firmware package. "Requirements for a Coordinate Location Header Within the Session Initiation Protocol", James Polk, 14-Feb-03, This document calls for an extension to the Session Initiation Protocol for a Coordinate Location Header principally to be used in times of emergency. "Terminology for Benchmarking IGP Convergence", Scott Poretsky, 13-Feb-03, This draft describes the terminology for benchmarking IGP Route Convergence. The motivation and applicability for this benchmarking is provided in [1]. The methodology to be used for this benchmarking is described in [2]. The methodology and terminology to be used for benchmarking route convergence can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics. The purpose of this document is to introduce new terms required to complete execution of the IGP Route Convergence Methodology [2]. "Working Groups and their Stuckees", Ted Hardie, 13-Feb-03, This document describes one of the informal roles present in IETF working groups and explores how incorporating it more fully into the IETF's process might affect working group operations. "Benchmarking Methodology for IGP Route Convergence", Scott Poretsky, 13-Feb-03, This draft describes the methodology for benchmarking IGP Route Convergence. The applicability of this testing is described in [1] and the new terminology that it introduces is defined in [2]. Service Providers use IGP Convergence time as a key metric of router design and architecture. Customers of Service Providers observe convergence time by packet loss. IGP Route Convergence is a Direct Measure of Quality (DMOQ) when benchmarking the data plane and not the control plane. The test cases in this document are black-box tests that emulate the network events that cause route convergence, as described in [1]. Black-box test design accounts for all of the factors for route convergence time, as provided in [1]. The methodology and terminology is to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. "Benchmarking Applicability for IGP Route Convergence", Scott Poretsky, 13-Feb-03, This draft describes the applicability of IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence bechmarking terminology [2]. The methodology and terminology is to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [1]. "MPLS and GMPLS Change Process", Loa Andersson, 13-Feb-03, This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. With respect to standardization, this process means that (G)MPLS extensions and changes can be done through the IETF only, the body that created the (G)MPLS technology. The IETF will not publish a (G)MPLS technology extension RFC outside of the processes described here. "Reliable Server pool use in IP flow information exchange", Lode Coene, Phill Conrad, 13-Feb-03, This document describes the applicability of the relialeble server pool architecture to the IP flow information exchange using Endpoint Name Resolution Protocol(ENRP) function of Rserpool only. Data exchange in IPFIX between the router and the datacollector can be using a limited retransmission protocol. "SWAN", G Ahn, 14-Feb-03, This draft specifies SWAN, a stateless network protocol which uses distributed control algorithms to deliver service differentiation in MANETs. SWAN uses rate control for UDP and TCP best-effort traffic, and source-based admission control for UDP real-time traffic. SWAN also uses explicit congestion control notification (ECN) to dynamically regulate admitted real-time traffic in the face of network dynamics brought on by mobility or traffic overload conditions. SWAN is designed to support real-time services over best effort MACs without the need to install and maintain costly QOS state at MANET nodes. This makes the SWAN approach to MANET QOS simple, scalable, and robust. The ns-2 simulation code is available from the web http://comet.columbia.edu/swan/). "Delegation of 2.0.0.2.ip6.arpa", Randy Bush, Joao Luis Damas, 14-Feb-03, This document discusses the need for delegation of the 2.0.0.2.ip6.arpa DNS zone in order to enable reverse lookups for 6to4 addresses. "IPv6 Documentation Address", Geoff Huston, Anne Lord, Philip Smith, 14-Feb-03, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link- local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:0DB8::/32 as a reserved prefix for use in documentation. This prefix has been assigned by the Asia Pacific Network Information Centre (APNIC) for this purpose, on behalf of the Regional Internet Registries. "Support of address families in OSPFv3", Sina Mirtorabi, Michael Barnes, Abhay Roy, 18-Jun-03, This document describes an extensible mechanism to support Address Families in OSPFv3. One undefined field in the Router-LSA is used to define the address-families on a link. A router may participate in multiple address families on different links. This information needs to be advertised so that only applicable link are used in the SPF calculation when building an address family specific shortest path tree. "XMLCONF Configuration Protocol", Rob Enns, 14-Feb-03, There is a need for standardized mechanisms to manipulate, install, edit, and delete the configuration of a network device. In addition, there is a need to retrieve device state information and receive asynchronous device state messages in a manner consistent with the configuration mechanisms. There is great interest in using an XML based data encoding because a significant set of tools for manipulating ASCII text and XML encoded data already exists. "DVB thoughts on Service Discovery and Selection", Paul Stallard, Toni Paila, 18-Feb-03, This memo presents some thoughts on the requirements of Internet Media Guides. It is based on some similar work undertaken by the Digital Video Broadcasting (DVB) group. "A method for configuration of IPsec clients using DHCP", Michael Richardson, 18-Feb-03, IPsec technology is frequently used for remote access scenarios. A tunnel is established from a mobile node (such as a laptop) and an IPsec gateway located at the Enterprise. The mobile node's tunnel outer address is potentially any IP address on the Internet. The mobile node's tunnel inner address should be an address from within the enterprise. The assignment of this address should ideally be done dynamically. This document specifies a configuration mode called 'DHCP over IKE'. The document specifies that the payload of a DHCP exchange should be carried over an IKE phase 1 exchange. "Basic Network Mobility Support", Ryuji Wakikawa, Keisuke Uehara, Thierry Ernst, 18-Feb-03, This draft proposes a solution for Basic Network Support. It proposes Mobile IPv6 extensions as advocated by the NEMO working group. Our solution differs from Prefix Scope Binding Update (PSBU) which was originally proposed before the NEMO working group was set up. Our draft however uses mechanisms similar to those of PSBU, such as 'Prefix binding' and 'Searching mechanism of prefix binding'. The main difference relies on the management of the permanent address of the MR, which is assigned to the ingress interface, and not to the egress interface. "Inter-AS MPLS Traffic Engineering", Jean Vasseur, Runtong Zhang, 19-Feb-03, This draft proposes a set of mechanisms to establish and maintain MPLS Traffic Engineering Label Switched Path that span multiple Autonomous Systems, considering the set of requirements for inter-AS Traffic Engineering listed in [Inter-AS-TE-REQS]. Each mechanism is described along with its applicability to the set of requirements. "PIM upstream detection among multiple addresses", Steve Suzuki, Tatsuya Jinmei, 19-Feb-03, This memo describes a PIM routing problem owing to the reverse path forwarding (RPF) failure on routers having multiple addresses on a link. This memo also considers possible solutions with their pros and cons. The solutions include operational one which does not require any protocol change, and one which uses a new PIM Hello option. However, it is beyond the scope of this memo to discuss what is the most appropriate solution for this problem. "Protection for inter-AS MPLS tunnels", Stefaan De Cnodder, Cristel Pelsser, 19-Feb-03, This document describes a solution for link protection, node protection, SRLG protection and fast recovery of inter-AS LSPs. These problems are highlighted in [ASREQ]. The proposed solution is based on RSVP-TE [RFC3209] as recommended by [ASREQ]. "A framework for Zerouter operations", Yoann Noisette, Aidan Williams, 19-Feb-03, This document describes a framework for the operation of Zerouter mechanisms and protocols. It identifies the context in which the solutions specified within the Zerouter approach are likely to find their applicability. More precisely, it identifies the entities in a zerouter mesh and the interaction between zerouter entities and their environment. "Fast Router Discovery with RA Caching in AP", Joonhyuk Choi, DongYun Shin, 20-Feb-03, This document presents RA Caching in AP for Fast Router Discovery. For seamless handoff, a mobile node MUST quickly discover its new access router. In our proposal AP caches Router Advertisement message and sends it to a new mobile node as soon as L2 association is made. We present a way for AP to cache necessary RA. By putting 'RA Caching' and 'AP Notification' functionality on AP, we get the optimized result without IPv6 standard change. "GSS-API Extensions", Samuel Meder, Von Welch, 20-Feb-03, This document defines extensions to RFC 2743, Generic Security Service Application Program Interface Version 2, Update 1. Extensions include: credential export and import; delegation at any time; credential extensions (e.g. restrictions) handling. "Requirements for Session Initiation Protocol (SIP)-based Emergency Calls", Henning Schulzrinne, 21-Feb-03, This document enumerates requirements for emergency calls in VoIP and general Internet multimedia systems. We divide the requirements into 'last-mile' and 'end-to-end'. Last-mile solutions only exchange the emergency call center's circuit-switched access by an IP-based system. The requirements for end-to-end IP-based emergency calling address functional and security issues for determining the correct emergency address, for identifying the appropriate emergency call center and for identifying the caller and its location. While we focus on systems that employ the Session Initiation Protocol (SIP), many of the requirements also apply to other environments, such as those using H.248/Megaco or H.323. "Registration for enumservices voice and video", Rudolf Brandner, 21-Mar-03, This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange. Specifically, the 'enumservices' registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'. "Object Oriented Protocol Operations for the Simple Network Management Protocol", Wesley Hardaker, 21-Feb-03, This document defines new Protocol Data Units (PDUs) for use within the Simple Network Management Protocol (SNMP). The goals of the new PDUs are to reduce packet sizes and to reduce processing overhead required at the Command Responder side of the protocol. "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Eric Rosen, 21-Feb-03, [VPN] describes a method by which a Service Provider (SP) may provide a VPN service to its customers. In that method, BGP is used to carry customer routes across the SP's backbone. That method allows a variety of different protocols to be used as the routing protocol between the Customer Edge (CE) router and the Provider Edge (PE) router. [VPN-OSPF] specifies additional procedures to be used when the CE/PE router protocol is OSPF. In these additional procedures, customer OSPF routes from a CE router are translated into BGP routes by a PE router. Then they are sent via BGP to another PE router, which translates them back into OSPF routes and distributes them to another CE router. This translation may lose some of the information needed to prevent loops. This document proposes that one of the OSPF options bits be used to ensure that when a VPN route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. "Guidelines on the structure of a PPVPN Layer 2 solution document", Marco Carugi, 04-Mar-03, This document provides guidelines on how to structure a PPVPN Layer 2 solution document. The intent is to provide a common way of describing the various functional components of a Layer 2 solution, making easier their identification as well as the mechanisms providing those functionalities, and, possibly, facilitating further convergence in the solution space. These guidelines have been discussed internally to the PPVPN Layer 2 design team and agreed as a recommendation, although not mandatory, to authors of PPVPN L2 solution drafts. "Traffic Engineering Extensions to IS-IS for Generalized MPLS control of Sonet/SDH Networks", Eric Mannie, Dimitri Papadimitriou, 21-Feb-03, This document introduces the Sonet/SDH traffic engineering extensions required for existing IGP protocols in support of Generalized MPLS (GMPLS) signalling as defined in [RFC-3471] and [GMPLS-SONET-SDH]. Using [GMPLS-RTG] as guideline, this memo specifies the GMPLS routing traffic engineering extensions to ISIS for Sonet/SDH networks. Based on the Traffic Engineering (TE) extensions defined in [ISIS- TE], the proposed approach is aligned with link bundling as defined in [MPLS-BDL] and extends the set of Extended IS Reachability sub- TLVs proposed in [GMPLS-ISIS] to Sonet/SDH networks. The proposed extensions do not preclude any further integration with the Interface Switching Capability Descriptor specified in [GMPLS-ISIS]. "Internationalized Mail Address eXtensions (IMAX)", Edmon Chung, Jim Lam, 28-Feb-03, This document describes a set of extension mechanisms for mail servers and clients to handle the transportation and negotiation of multilingual email addresses, utilizing the standard SMTP and POP extension mechanisms. In other words, the mechanism discussed in this document promotes the use of multilingual email addresses that is immediately deployable by interested parties without affecting or breaking any other existing systems. "A Suggested Scheme for DNS Resolution of Networks and Gateways", Edward Warnicke, 27-Jun-03, This document specifies a method given an IP address to perform a series of DNS lookups to determine the network that contains that IP address, the netmask of that network, and the gateway(s) on that network. This method allows for variable length subnet masks, delegation of subnets on non-octet boundaries, and multiple gateways per subnet. "Early implementation of the Services in PSTN requesting Internet services (SPIRITS) protocol", Vijay Gurbani, 21-Feb-03, The SPIRITS protocol defines the mechanisms and the semantics to subscribe to and convey certain PSTN events to interested Internet hosts for service execution [1]. This Internet-Draft describes our initial implementation of a SPIRITS framework based on the architecture and requirements outlined in [2] and [3], respectively. We have implemented two services based on such an architecture: a SPIRITS-based presence service which provides a coarse-grained presence status for a user represented by a device (phone), and a SPIRITS-based Instant Messaging (IM) service whereby the PSTN sends a SIP IM to a SPIRITS User Agent (UA). These services, the attendant architecture and the relevant call flows are described next. It is expected that the reader is conversant in the SPIRITS and SIP terminology. For those who are not, [5,6] provide a good reference for SIP and its event-based mechanism, and [1,2,3] provide a good reference for SPIRITS. It is important to point out that the SPIRITS protocol [1] is not a standard yet, it is still an Internet-Draft. Thus, what is described in this draft is an early implementation designed to validate the suitability of the protocol as well as provide some implementation experience that will be leveraged in further refining the protocol. "Diameter User Session Mobility Application", Quentin Liu, 21-Feb-03, A mobile node will change its access router frequently during a Diameter session and the relevant AAA parameters may also be transferred between the access routers. However, the home AAA server does not know the movement of the mobile node before the mobile node re-authenticates, and a request from the home AAA server will always be forwarded to the former realm. Therefore, an efficient way is needed to forward the request to the new access router. "IFAX service of ENUM", Kiyoshi Toyoda, Dave Crocker, 21-Feb-03, This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is 'Facsimile using Internet Mail'. For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. "Event Notification Filtering for Watcher Info", Hisham Khartabil, Eva Leppanen, 21-Feb-03, Watcher information template-package for the SIP event framework refers to the set of users subscribed to a particular resource within a particular event package. The Watcher Information I-D does not describe a mechanism of how filtering of watcher information can be achieved. This document defines a watcher info filter. It provides the mechanism whereby a watcherinfo subscriber can specify the watcher info event filtering rules, using XML, for the notifier and how that notifier is to behave when receiving such filter. "Partial Notification of Presence Information", Mikko Lonnfors, Jose Costa-Requena, Eva Leppanen, 19-Jun-03, A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase efficiency, by introducing a mechanism called partial notification. "On demand services with throughput guarantees over DiffServ networks", Rudiger Geib, 21-Feb-03, On demand Internet services with guaranteed throughput are the major driver behind QoS signaling architectures. Guaranteeing throughput between two defined points of a DiffServ network requires a combination of flow information and Per Hop Behaviour. Handling aggregates instead of flows as specified by the DiffServ architecture is the most reasonable attempt to do so. This document describes an architecture using DiffServ mechanisms to provide on demand throughput guarantees between two points of a DiffServ network. "Diameter Multimedia Application", Maria-Carmen Belinchon, 16-Jun-03, This document specifies the Diameter Multimedia Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with the Session Initiation Protocol (SIP), and provides a Diameter client in a SIP server with the ability to request a Diameter server the authentication of users and authorization of SIP resources usage. This application does not require or is not related to other authentication services provided by the Mobile IP Diameter [7] or the Network Access Server Diameter [8] applications. "Y.1711 and LSP-PING", David Allan, 24-Feb-03, This internet draft shows that that the OAM tools defined by ITU-T SG13/Q3 and the IETF are complementary. "Registration for enumservices web and ft", Rudolf Brandner, 24-Feb-03, This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are primarily sources for information. "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", Caitlin Bestler, 24-Feb-03, This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). "Dynamic Parameters Signaling for MPLS-based Pseudowires", Himanshu Shah, 01-Jul-03, This document describes a mechanism along with extensions to [PWE3- CONTROL] draft that enable a PE to signal to the remote PE additional dynamic information about the pseudowire. This information may either be related to the operations of the pseudowire such as operational state of the Attachment circuit, the state of the pseudowire forwarders, the IP address and/or MAC address of the attached CE, or may affect the setup of the pseudowire, such as traffic engineering parameters, security related information, etc. "TINS: A Transport for Initiating and Negotiating Sessions using SDPng over XMPP", Joe Hildebrand, 24-Feb-03, This document describes a method of initiating and negotiating media sessions by using SDPng on top of the eXtensible Messaging and Presence Protocol (XMPP) as the signalling protocol. "Signaling Tunnel Encapsulation/Deencapsulation Capabilities", Rahul Aggarwal, 27-Jun-03, This document proposes a mechanism for signaling a PE router's tunnel encapsulation capabilities. One example is its capability to encapsulate MPLS using dynamic GRE and/or IP. This is applicable when a MPLS packet is tunneled using dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. For instance the MPLS packet may be a 2547 based MPLS VPN packet [2547bis], a layer 2 packet transported using MPLS [MARTINI], a MPLS tunneled IPv6 packet or a MPLS IPv6 VPN packet [BGP-VPN-IPv6]. Adding such a mechanism has several benefits. It helps in blackhole avoidance and eases transitioning from MPLS tunneling based Layer 3/Layer 2 VPNs to GRE/IP tunneling based Layer 3/Layer 2 VPNs (and vice versa). Such a mechanism is needed where a network may be using MPLS and GRE (or IP) for tunneling, simultaneously in different parts of the network. It can help in encapsulation selection when multiple tunneling technologies are supported. "IPv6 Socket API for source address selection", Erik Nordmark, 01-Jul-03, The IPv6 default address selection document describes the rules for selecting default source address by the system and indicates that the applications should be able to reverse the sense of system preference of source address selection for that application through possible API extensions. However, no such socket API exists in the basic or advanced IPv6 socket API documents. Hence this document specifies socket level options to prefer a particular source address as per choice of the applications. It also discusses implications on the name-to-address translation API that performs part of the default address selection. The socket APIs described in this document will be particularly useful for Mobile IPv6 enabled applications and other IPv6 applications which want to choose between temporary and public addresses, CGA (cryptographically generated addresses) and non-CGA addresses etc.. "Extension to Sockets API for Mobile IPv6", Samita Chakrabarti, Erik Nordmark, 01-Jul-03, This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API support for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. "Dynamic reverse DNS for IPv6", Alain Durand, 24-Feb-03, This document describes a method to dynamically generate PTR records and corresponding A or AAAA records when the reverse path DNS tree is not populated. A special domain dynrev.arpa. is reserved for that purpose. "Dual stack vs NAT-PT", Alain Durand, 24-Feb-03, Outside of the IETF community, lot of people think that IPv4 to IPv6 transition consist merely at solving the problem of how does a v4 box communicate with a v6 box and vice versa. Within the IETF, the dual stack approach has long been defined. There is an ongoing discussion to understand if translation with tools like [NAT-PT] is absolutly needed to enable IPv6 nodes to communicate with an IPv4 node or if we can/should mandate IPv6 nodes to also deploy an IPv4 stack if/when they needs to communicate with IPv4 nodes. This draft is aimed at clarifying the discussion without taking side by studying in 3 cases the implications of mandating a dual-stack versus the implications of deploying a translation device. "Issues with NAT-PT DNS ALG in RFC2766", Alain Durand, 24-Feb-03, Recent discussions on the need to translate or not between IPv4 and IPv6 have brought a better understanding on the impact of tools like NAT-PT [NAT-PT]. Several problems have been identified around the DNS ALG functionality. An alternative solution that does not require this DNS ALG for connections initiated by the IPv6 side has been proposed. This memo aims at analyzing the pros and cons of both solutions in that case. Connections initiated by the IPv4 side would always require the help of a DNS-ALG and thus are not covered by this memo. "SCSI Command Ordering Considerations with iSCSI", Mallikarjun Chadalapaka, Roger Elliott, 24-Feb-03, iSCSI is a SCSI transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the SCSI I_T nexus, and the iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. "Mobile Controlled Movement Tracking Local Mobility Agent Selection for Mobile IPv6", Yi Xu, 24-Feb-03, This document introduces a Local Mobility Agent selection algorithm in the Localized Mobility Management of Mobile IPv6. This proposed selection algorithm locates a Local Mobility Agent to register a visiting mobile node in a foreign domain where multiple Local Mobility Agents are deployed. The domain architecture, Local Mobility Agent selection and registration procedures are specified. This algorithm selects Local Mobility Agent on a per mobile node basis and reduces registration delay. It also helps to distribute the registration load to all the Local Mobility Agents, avoiding overcrowding at a particular one. "Regional Mobile IPv6 mobility management", Kyungjoo Suh, 24-Feb-03, This document defines a new protocol, namely, Regional Mobile IPv6 mobility management (RMM/RMIPv6). RMM mechanism satisfies the LMM requirements. This document therefore describes methods to be used to reduce the amount of signaling to the Home Agent and Correspondent Nodes. In addition, this scheme is flexible enough to adapt to any network topology assumed by IPv6. The network that using RMM/RMIPv6 is robust against the failure or the performance degradation. The mechanism is intended to reuse the Care of Address. Moreover, the forwarding tunnel length from an anchor point to a Mobile Node can be a controllable or configurable. "CCM: The Credential Cache GSS Mechanism", Mike Eisler, 24-Feb-03, This document describes a new mechanism under the GSS [RFC2743]. Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to authenticate every message transfer, thereby incurring significant overhead due to the costs of cryptographic computation. While hardware-based cryptographic accelerators can mitigate such overhead, it is more likely that acceleration will be available for lower layer protocols, such as IPsec [RFC2401] than for upper layer protocols like RPCSEC_GSS. CCM can be used as a way to allow GSS mechanism- independent upper layer protocols to leverage the data stream protections of lower layer protocols, without the inconvenience of modifying the upper layer protocol to do so. "Requirements for End-to-End VoIP Header Compression", Jerry Ash, 24-Feb-03, VoIP typically uses the encapsulation voice/RTP/UDP/IP/. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). This draft gives a problem statement and requirements for end-to-end VoIP header compression, possibly over MPLS. "vCard Extensions for IMPP", Cullen Jennings, 01-Jul-03, This draft describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. It allows a URL that is associated with IM or PP to be specified inside of a vCard. "EAP Key Derivation for Multiple Applications", Joseph Salowey, Pasi Eronen, 24-Feb-03, The Extensible Authentication Protocol (EAP) provides an extensible interface to various authentication mechanisms. Some EAP methods derive cryptographic material between the EAP peers; these keys can be used, for instance, with IEEE 802.11i encryption. This document proposes a mechanism that can be used to derive cryptographically separate keys for more than one cryptographic application, such as protecting subsequent EAP messages, distributing credentials for re- authentication, or handoff mechanisms involving multiple WLAN access points. "On selection of IS-41 SPIRITS mobility-related parameters", Alec Brusilovsky, 24-Feb-03, This document describes IS-41 mobility-related parameters (WIN information and its encoding) which the SPIRITS protocol can transport from the PSTN (wireline, as well as wireless) into the IP network. The SPIRITS protocol is a protocol through which PSTN can request actions (services) to be carried out in the IP network in response to events occurring within the PSTN/IN (wireline, as well as wireless). This draft outlines, what IS-41 mobility-ralated parameters are of immediate interest to SPIRITS, how they may be extracted and encoded for use within the SPIRITS domain. IS-41 is used as an example protocol to clarify the SPIRITS message encoding process. This Internet-Draft has been written in response to the SPIRITS WG chairs' call for SPIRITS Protocol proposals. It may be viewed as being a direct contribution to the Informational RFC on the SPIRITS protocol parameters. Section 1 of this document gives background of wireless cellular communication networks, including Core Networks, Section 2 gives a backgrouder for the Wireless Intelligent Network (WIN). Sections 3 and 4 briefly explain WIN Functional and Physical entities. Section 5 provides WIN BCSM Description. Section 6 gives ASN.1 Notation for the selected WIN Parameters. Sections 7, 8, 9, 10 and 11 respectively provide Acknowledgements, References, Author's Address, Acronyms and Full Copyright Statement, as required. Addendum 1 contains figures. "IRIS Certificate and Key Registry", Leslie Daigle, 24-Feb-03, This document defines a credentials registry (credreg) and provides a specification in terms of an IRIS (draft-ietf-crisp-iris-core) registry schema. This registry enables location of certificates and public keys -- credential metadata can be searched to yield (pointers to) credentials. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by credential registry administrators. "NFSv4.1: SECINFO Changes", Mike Eisler, 24-Feb-03, This document proposes some changes to security negotiation in NFS [RFC3010bis]. It is hoped that these changes will be part of a new minor version of NFS: NFSv4.1. "Radius/L2TP Based VPLS", Juha Heinanen, 24-Feb-03, This memo describes a simple mechanism to implement provider provisioned Virtual Private LAN Service (VPLS) using Radius for PE discovery and L2TP as the control and data plane protocol. "Distributed/End-Point Firewall Control (DEFCon) Requirements", Ravi Sahita, Priya Govindarajan, 24-Feb-03, This document describes the requirements for the architecture and a distributed framework for end-point firewall control (DEFCon). This draft also discusses requirements for the individual pieces in the framework. Perimeter firewalls are predominant in enterprise networks but do not provide the protection a mission critical network needs against misuse or abuse from nodes inside the network. Additionally, A wireless infrastructure makes every host vulnerable since in that case access is not fundamentally restricted by infrastructure. Likewise, traffic is increasingly being encrypted end-to-end using SSL, IPSec, etc. where viruses/worms/confidential information can also be hidden from the security components. This requires the perimeter firewall to become a man-in-the-middle for all secure sessions, which breaks the end-to-end principle and thus renders many protocols useless since they are inevitably blocked. A host-based firewall on nodes in the enterprise network protects the network from inside out. This approach does not preclude perimeter firewalls. Instead, it provides defense-in-depth and reduces the load on perimeter firewalls. The host-based approach also upholds the end-to-end theme since it allows traffic to be securely encrypted end-to-end and yet assures safety from infection, compromise and attack. "Requirements for conference policy data", Petri Koskelainen, 24-Feb-03, The conference participants may communicate with the conference policy server, using a conference policy control protocol (CPCP) which is a strictly client-server transactional protocol. This document describes the requirements for conference policy data. Media policy related requirements are beyond the scope of this document. CPCP protocol is not mandatory and the only mechanism to manipulate conference policy data in a conference. For example, web interface can be used as well to perform conference policy manipulation. However, for automata a protocol is needed. "Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP)", Raj Jain, Vijay Gurbani, 25-Feb-03, SIP over connection-oriented transport protocol based systems are likely to face certain distinct performance and behavioral issues that are not manifest when SIP is transported over connectionless protocols. Allowing SIP entities to mutually conserve connections over a predictable, extended period of time is one of the leading requirements to help SIP entities deliver their optimal performance in the network. Overall, this document contemplates transport layer connection management issues relating to SIP. Requirements and potential solutions for introducing a backward compatible notion of persistent connections in SIP are presented. "IRIS - A Lightweight Transport", A Newton, Leslie Daigle, 09-Jun-03, This memo defines a lightweight UDP transport for the Internet Registry Information Service (IRIS). "Multilevel Precedence and Preemption in the Session Initiation Protocol", James Polk, 02-Jul-03, This document proposes considerations and requirements for the extension of the Session Initiation Protocol (SIP) [1] to support Multi-Level Precedence and Preemption (MLPP) functionality originally set forth in [2&3]. This document will be limited in scope to the requirements of the SIP Protocol; MLPP within the IETF, utilizing other IETF Protocols, is left to other documents, therefore is considered out of scope here - although there is a general explanation of how MLPP functions currently within private circuit switched networks to give the necessary operational background for these requirements. "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", Jonathan Lang, Yakov Rekhter, 09-May-03, This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document. "An Application Configuration Access Protocol (ACAP) Dataset Classes for Presence List and Authorization Policy", Jonathan Rosenberg, 25-Feb-03, This specification discusses the applicability and usage of the Application Configuration Access Protocol (ACAP) for the client manipulation of presence lists (also known as buddy lists), and presence authorization policy. An ACAP dataset class is specified, and it is analyzed against the requirements that SIMPLE has developed for this function. "LSP Preemption policies for Diff-Serv-aware MPLS Traffic Engineering", Jaudelice de Oliveira, 21-Mar-03, When the establishment of a higher priority LSP requires the preemption of a set of lower priority LSPs, a node has to make a local decision on the set of preemptable LSPs and select which LSPs will be preempted, based on a certain objective, in order to accomodate the newly signaled high priority LSP. The preempted LSPs are then rerouted. This draft documents a preemption policy which can be modified in order to stress different objectives: preempt the lowest priority LSPs, preempt the minimum number of LSPs, preempt the exact required bandwidth in order to fit the new LSP. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority and wasted bandwidth is also included. "RTP Payload Format for the Speex Codec", Greg Herlein, 01-Jul-03, Speex is an open-source, patent-free, voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP) and a preliminary method of using Speex within H.323 applications. "SDP Usage for SOAP Sessions", Neil Deason, 25-Feb-03, This document defines how the Session Description Protocol (SDP) can be used to describe sessions of Simple Object Access Protocol (SOAP) messages. To achieve this it presents how existing SDP functionality should be utilized and defines two new SDP attributes. The usage of SDP for SOAP sessions within the Offer/Answer model is specifically discussed as this enables the Session Initiation Protocol (SIP) to be used to create, modify and terminate SOAP sessions. "Movement Detection Optimization in Mobile IPv6", Greg Daley, JinHyeock Choi, 09-May-03, This draft describes the state of the art techniques in movement detection and elaborates on their application to Mobile IPv6 networks. The aim of the draft is to describe the applicability of each mechanism and stimulate discussion on such techniques. "Internet Media Guide Metadata Format", Juha-Pekka Luoma, 25-Feb-03, This document defines the base metadata format for Internet Media Guides (IMGs), applicable to a wide variety of Internet hosts and communication links. IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. An IMG metadata model, semantics of the IMG media metadata entities, and an XML-based framing structure for IMG media metadata are defined. The aim is to reuse existing metadata standards for the IMG metadata format where possible. "A road-map for multihoming in IPv6", Kurt Lindqvist, 25-Feb-03, IPv6 was decided as the replacement to the widely deployed IPv4 in 1992. The new protocol was designed to meet a number of criteria that at that time was seen as the failures of IPv4, such as security and limited address space. IPv6 meet these needs, but it fails to meet other needs of the Internet of today such as scalable solutions for multihoming and portable address space for end-sites. The effects of the lack of scalable solutions to this is widely documented. In order to solve the multihoming scalability problems, the multi6 working group was created in the IETF. This group have so far not yet produced any documents as it has been hard to find consensus on even the most basic documents such as requirements. Multi6 have also suffered from problems reaching consensus on what type of solution will be required moving forward, and the attempt of trying to come up with a 'fit-all' solution from day one. This document tries to outline steps that could be taken to better understand the problem and what steps could be taken as we bit by bit tries to address the problem. "Intermediary-Based Transport Services, Performance Optimization Mechanisms, and Relevant Requirements", Igor Faynberg, 25-Feb-03, Network service providers are increasingly moving from providing just Internet connectivity to offering intermediary-based services and performance optimizations to enhance end user experience at reduced costs. These services and optimizations are being, or will be, offered with the help of intermediate nodes placed in the service provider network between communicating end-points. In this document, we list several intermediary-based transport services and performance optimization mechanisms that are being (or could be) provided by the intermediate nodes, and identify the requirements of any solution that securely offers these services and mechanisms. "DCCP Profile for EPIC", Julije Ozegovic, Mario Mornar, 25-Feb-03, This draft describes a profile for compressing Datagram Congestion Control Protocol DCCP/IP using the Efficient Protocol Independent Compression (EPIC) [2] scheme. The RObust Header Compression [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. DCCP [3] is a relatively new protocol and has not yet entered the process of wide implementation. It is intended to provide a unified congestion control interface to the end user applications. It should offer the same unreliable transport as UDP does, and on the other hand, include mechanisms for congestion avoidance and control. This profile describes a new profile for ROHC which will allow DCCP/ IP headers to be compressed. "Organizing Mobile IP Along Natural Architectural Boundaries", James Kempf, 25-Feb-03, A natural architectural split exists in Mobile IP between the mechanisms involved in global routing change and the mechanisms involved in local link routing change. The global mechanisms modify the mapping between a Mobile Node's routing identifier (care of address) and its global node identifier (home address). The local mechanisms allow the Mobile Node to obtain IP connectivity on the subnet and provide measures to locally mitigate routing failure while the global routing change is occurring. This draft makes a case for keeping the mechanisms involved in these two architectural components distinct and separate in Mobile IPv6, and suggests that the Mobile IP group might want to think about a separate working group specifically focused on local link routing changes for mobility in Mobile IPv6. "A Model of IPv6/IPv4 Dual Stack Internet Access Service", Yasuhiro Shirasaki, 10-Jun-03, This memo shows an example of how to provide IPv6 / IPv4 dual stack services to home users. In order to simplify user setup, these service should have mechanism to configure IPv6 specific parameters automatically. We focus on two basic parameters, prefix and addresses of IPv6 DNS servers, and specify the way to deliver them to Customer Premises Equipments (CPE) automatically. This memo is a digest of the user network interface specification of NTT communications' dual stack ADSL access service. "Multi-Level Expedited Forwarding", Steve Silverman, 08-Apr-03, Some networks require certain connections to have greater priority than others. This draft defines a new PHB (Per Hop Behavior), the Multi-Level Expedited Forwarding (MLEF) PHB. The standard Expedited Forwarding PHB (RFC3246) defines a PHB for applications requiring low latency. This document extends that concept and defines a PHB with multiple priority levels for applications requiring low latency. "Experimental Handoff Extension to RADIUS", William Arbaugh, Bernard Aboba, 21-May-03, In order to decrease handoff latency, the concept of pre-emptive provisioning is under investigation. This document describes an experimental extension that enables an accounting server to notify a NAS of a prospective handoff. This enables the NAS to reserve resources and obtain the session parameters prior to arrival of the client, potentially reducing handoff times. The extension described in this document may potentially be useful in enabling handoffs across access technologies and providers. However, whether the approach described in this document is effective, deployable or secure is the subject of current research. It is offered for RADIUS primarily because source code for RADIUS client and server implementations is readily available for research purposes. Given that this extension represents research work in progress, implementation of this specification for purposes other than research is not recommended. "The Text/Plain Format and DelSp Parameters", Randall Gellens, 27-Jun-03, This specification establishes two parameters to be used with the Text/Plain media type, and, in the presence of these parameters, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping, flowing, and quoting. "Multi-Level IS-IS Without Protocol Extensions", Janathan Sadler, 25-Feb-03, Work has started in the ITU, the IETF IP over Optical Working Group, and in the OIF to specify the requirements for ASON NNI routing. One of the requirements identified is support for multi-level hierarchies. IS-IS is one of the candidate protocols to provide this functionality. Therefore, methods for multi-level IS-IS routing need to be developed. This draft documents one that provides multi-level routing through the 'stacking' of Level 2 IS-IS instances. The method is possible using existing extensions to IS-IS. It also provides insight into some of the resulting operational issues. "Requirements for Server-to-Server Event Pipeline Protocols", Lisa Dusseault, 25-Feb-03, Server-to-server event pipelines are required in situations where an event source generates events for a number of end-users (or simply generates events without an idea of who the end recipients might be), and sends these events to an event or notification aggregator service. These kinds of event source servers are common in messaging (for example, voice messaging servers and calendar servers might send events to a user's main messaging server or to a single-purpose notification server). A general set of requirements is outlined here for the server-to-server aspect of these kinds of scenarios. "Security Framework for Provider Provisioned Virtual Private Networks", Luyuan Fang, 01-Jul-03, This draft addresses security aspects pertaining to Provider Provisioned Virtual Private Networks (PPVPNs). We first describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. We also describe how these security attacks should be detected and reported. We then discuss the possible user requirements in terms of security in a PPVPN service. These user requirements translate into corresponding requirements for the providers. In addition, the provider may have additional requirements to make its network infrastructure secure and meet the VPN customer’s expectations. Finally, we define how these user requirements apply to specific PPVPN technologies, namely RFC2547 PPVPNs, Virtual Router PPVPNs, IPSec VPNs, and Layer 2 PPVPNs. "Extending DHCP Options Codes", Bernard Volz, 25-Feb-03, RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP public option space which is managed by IANA as documented in RFC 2939. As this public option space has few unassigned options at this time, it is prudent to define a mechanism to extend this option space before it is too late. This Internet-Draft proposes two means to extend this option space. "Packetization Layer Path MTU Discovery", Matt Mathis, 25-Feb-03, This document describes a new Packetization Layer MTU probing algorithm which is not subject to the problems associated with the current path MTU discovery algorithms [RFC1191, RFC1981, RFC2923]. The general strategy of the new algorithm is to start with a small MTU and probe upward, testing successively larger MTUs by probing with single packets. If the probe is successfully delivered, then the MTU is raised. If the probe is lost, it is treated as an MTU limitation and not as a congestion signal. "Instant Message Delivery Notification (IMDN) for Common Presence and Instant Messaging (CPIM) Messages", Eric Burger, 25-Feb-03, This document describes a mechanism for instant message delivery notification (IMDN) in the CPIM (Common Presence and Instant Messaging) environment. The mechanism follows the procedures of ESMTP MDN. This document also includes a brief discussion of the differences between ESMTP and CPIM MDN. "Securing DHCP with DNSSEC bourne public keys", Ted Lemon, Michael Richardson, 25-Feb-03, This document is intended as a standards track document. "Operational Guidelines for 'local' zones in the DNS", Akira Kato, Paul Vixie, 25-Feb-03, A large number of DNS queries regarding to the 'local' zones are sent over the Internet in every second. This memo describes operational guidelines to reduce the unnecessary DNS traffic as well as the load of the Root DNS Servers. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", Ned Freed, John Klensin, 09-Jun-03, This document specifies various IANA registration procedures for the following MIME facilities: o media types, o external body access types, and o content-transfer-encodings. Registration of charsets for use in MIME is covered elsewhere and is no longer addressed by this document. "Early Retransmit for TCP and SCTP", Mark Allman, 25-Jun-03, This document proposes a new mechanism for TCP and SCTP that can be used to more effectively recover lost segments when a connection's congestion window is small. The 'Early Retransmit' mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. "The QCP File Format and Associated Media Types", Harinath Garudadri, Randall Gellens, 29-May-03, RFC 2658 specifies the streaming format for QCELP 13K vocoder data, but does not specify a storage format. Many implementations have been using the QCP file format for exchanging QCELP 13K data as well as EVRC and SMV data. (For example, Eudora, QuickTime(r), and cmda2000 handsets). "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Fred Templin, 03-Jun-03, This document specifies a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option for nodes that implement the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). "Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, 25-Feb-03, This document provides specification for one Bandwidth Constraints model for Diff-Serv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. "The LDAP No-Op Control", Kurt Zeilenga, 01-Jul-03, This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. "IP over InfiniBand: Connected Mode", Vivek Kashyap, 26-Feb-03, The InfiniBand Architecture(IBA) defines a high speed, channel based interconnect between systems and devices. IBA provides multiple modes of transport services with differing characteristics. This document describes IP over IBA's Connected transport modes. "Multiple Care-of Address Registration on Mobile IPv6", Ryuji Wakikawa, 26-Feb-03, This document describes how to manage and register multiple care-of addresses which are assigned to either single or multiple network interfaces with a single home address on Mobile IPv6. Associating multiple care-of addresses with a home address enable durable Internet connectivity [7] [1] [8]. For example, when a Mobile Node (MN) loses its Internet connectivity at one of the interface, it can use the second interface as a backup interface and still keep connectivity to the network. In addition, the MN can send each communication flow to a distinct network interface. This provides efficient network bandwidth consumption. A user can select the most suitable network interface per application. "A Transport Network View to LMP", Osama Aboul-Magd, 26-Feb-03, The Link Management Protocol (LMP) has bee defined at the IETF to facilitate the management of transport network for the sake of supporting IP traffic over transport network. The LMP development has been progressing in the context of GMPLS related work. The LMP was developed with a packet centric view in mind. Since it is intended for the control of transport network it is essential to bridge the gap between the two views. It is the objective of this draft to project LMP in a transport network context and to relate it to the discovery work that has been going on at the ITU. "Hybrid Virtual Private LAN Service", C.J. Lee, 02-Jul-03, This draft describes a solution to enable an emulated LAN Service or Virtual Private LAN Service (VPLS) by decoupling the bridging and tunneling of Ethernet traffic into Customer Located Equipment (CLE) or Customer Edge (CE) and Provider Edge (PE), respectively. This decoupling of functions allows an operator to provision point-to- point transport of Ethernet services for customer on PEs, while leveraging bridging functions at CLEs to forward traffic towards the appropriate point-to-point Ethernet service leading to the destination node. This decoupling of functions also allow providers to leverage existing network infrastructures to enable VPLS while easing migration to new network infrastructures. This approach scales as the number of customers and sites increases, and as customers' emulated LAN sites span over a large wide area network. It is also the intention to show that an interface like Ethernet can be offered to customers and emulated LAN services can be enabled, but it is not mandatory to introduce VLAN like technologies (or PE-based type of VPLS) in the provider's network. In addition, existing and heterogeneous access technologies can be supported in a common network infrastructure. "Framework and Requirements for TRIGTRAN", Spencer Dawkins, 26-Feb-03, IETF-standardized unicast transport protocols have been designed to allow two end points to maintain communications by individually reacting to loss or degraded packet arrival times. Historically, those protocols have assumed loss is congestive and have reacted by decreasing the packet transmission rate to ease congestion. There are a number of cases, however, where these assumptions are incorrect, and one or more path segments present losses due to intermittent connectivity, a high uncorrected error rate, or the need for access path changes ('hand-off's). Previous work [PILC] has addressed these conditions using end-to-end mechanisms. This draft examines the use of an on-path signaling mechanisms capable of providing advisory notifications for use in modifying the behavior of the transport in order to better respond to actual network conditions. This draft serves to create discussion in this area as there are many ways to skin the cat. We are interested in hearing about them through open discussion. "Conferencing media policy requirements", Roni Even, 26-Feb-03, This document defines the data model and the requirements for Media Policy, i.e. a set of rules associated with the media distribution of the conference. This document also presents the requirements for the media manipulations that can be done using these rules by conference participants or third parties using any kind of media/ conference policy control protocol. This document does not address the interface between the focus and the media policy. " Securing Feedback Messages: Secure and Scalable Many-to-one Communication", Lacshminath Dondeti, Thomas Hardjono, 26-Feb-03, Members in a secure group may need to communicate to the GCKS to Deregister from the group, for SA resynchronization, and to request retransmission of a Rekey message. A simple solution is to keep the registration SA around, but that comes at the expense of O(n) SA maintenance, and storage at the GCKS. Each member is also responsible for maintaining an extra SA. We propose an efficient method for mem- bers to securely send messages to the GCKS, using the Rekey SA. "Multi-Homing Issues in Bi-Directional Tunneling", Chan Ng, Julien Charbon, 27-May-03, This document describes deployment scenario of multi-homed Network in Motion (NEMO) and attempts to identify issues that arises when supporting multi-homing in NEMO. It is also the objective of this document to build a full taxonomy covering multi-homed scenarios in NEMO, so as to facilitate explorations into this aspect of NEMO. "Protecting Internet Routing Infrastructure from Outsider CPU Attacks", Alex Zinin, 26-Feb-03, The mechanism described in this document helps to secure an Internet Service Provider's router infrastructure from outsider attacks, including (but not limited to) Distributed denial of service (DDoS) attacks based on CPU and/or queue exhaustion (e.g., TCP SYN flooding and flooding of invalid MD5-signed routing protocol packets.) The presented approach is based on explicitly marking control packets from trusted sources by different link-layer encapsulation and does not require any modifications to user data exchange protocols, ICMP, routing protocols or changes to existing hardware in routers, which allows it to be deployed quickly throughout the Internet. "Certificate Discover for SIP", Cullen Jennings, 01-Jul-03, This draft describes a scheme in which a SIP user agent can create self signed certificate for use with the SIP S/MIME mechanism and can store the certificate on a web server associated with the address of record (AOR) for the user. Other user agents that want to call that AOR can retrieve these certificates from the web server. The result of this system is that, with no extra expense or effort for the end user, it is possible to have a reasonable degree of confidence about the identities of the parties in a SIP session. "IPv6 on by Default", Sebastien Roy, 26-Feb-03, The dual stack model is based on the assumption that applications can try communicating to destinations over IPv6 first and fall back to IPv4 if IPv6 doesn't work. Before turning the dual stack on by default, we need to make sure that this assumption holds even in cases where IPv6 connectivity is not perfect. This document looks at scenarios in which things can go wrong if the IPv6 dual stack is enabled by default. "Considerations on the IEPREP requirements for SIP", Jon Peterson, 26-Feb-03, The IEPREP working group has provided the SIPPING WG with a framework and requirements draft for prioritized communications services in SIP. The considerations raised in that draft are examined here, and some feedback and implementation recommendations based on its requirements are provided. "Enumservice Registration for Presence Services", Jon Peterson, 26-Feb-03, This document registers an ENUM service for presence services (as described in RFC2778 [3]) pursuant to the guidelines in RFC2916bis [2]. Specifically, this document focuses on provisioning pres URIs in ENUM. "PANA Enforcement Point(s) Provisioning and Accounting using COPS-PR", Yacine Mghazli, 26-Feb-03, This document considers the use of COPS-PR as the protocol that allows the PANA Authentication Agent to deliver the authorization information to one or more Enforcement Points when the PAA is separated from the Enforcement Point(s). "The Autoconfiguration of Recursive DNS Server and the Optimization of DNS Name Resolution in Hierarchical Mobile IPv6", Jae-Hoon Jeong, 18-Jun-03, This document provides the mechanism for the autoconfiguration of recursive DNS server in mobile node and the optimization of DNS name resolution in the hierarchical mobile IPv6 network. Whenever the mobile node moves into a new MAP domain, the region managed by another MAP, in the hierarchical mobile IPv6 network, it detects the addresses of recursive DNS servers which are placed in the region and replaces the old ones with the new ones for DNS name resolution. This allows the time for DNS name resolution much reduced by using the nearest recursive DNS server which exists in the region. Therefore, the mechanism of this document can optimize the DNS name resolution. "A Presence Architecture for the Distribution of Geopriv Location Objects", Jon Peterson, 26-Feb-03, Geopriv defines the concept of a 'using protocol', a protocol that carries geopriv location objects. Geopriv also defines various scenarios for the distribution of location objects that require the concept of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto geopriv architectures, and presents one pre-existing using presence protocol that might carry location objects. "Use Cases for Session Initiation Protocol (SIP) Caller Preferences", Jonathan Rosenberg, Paul Kyzivat, 26-Feb-03, This document describes a set of use cases for the SIP Caller Preferences and Callee Capabilities extension. Each use case is presented as a desired routing decision, followed by the actual headers and processing logic which would result in that decision. "Interactive Connectivity Establishment (ICE): A Methodology for Nettwork Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 26-Feb-03, This document describes a methodology for Network Address Translator (NAT) traversal for the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE is not a new protocol, but rather makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP). ICE works through the mutual cooperation of both endpoints in a SIP dialog. By having the endpoints work together in NAT traversal, a number of important properties are obtained. ICE always works, independent of the types or number of NATs. It always represents the cheapest solution for a carrier. It always results in the minimum voice latency. It can be done with no increase in call setup delays. It is far less brittle than STUN. ICE also facilitates the transition of the Internet from IPv4 to IPv6, supporting calls between dual-stack and v6 clients behind a 4to6 NAT. Preconditions can be used in conjunction with ICE, to guarantee that the phone never rings unless the users will both hear and see each other when they pick up. "An IPv4 - IPv6 multicast gateway", Stig Venaas, 26-Feb-03, This document describes an IPv4 - IPv6 gateway solution that embeds all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts to receive from and send to IPv4 multicast groups. "Protocol Requirements for Internet Media Guides", Yuji Nomura, Henning Schulzrinne, 26-Feb-03, This memo specifies requirements for a protocol for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. The requirements details general protocol operations and description formats transmitted by an uni- or bi- directional transport based on the IMG framework. "A Framework for Internet Media Guides", Yuji Nomura, Henning Schulzrinne, 26-Feb-03, This memo provides a framework for Internet media guides (IMGs). An IMG is a set of meta-data describing the features of multimedia content in order to subscribe to, manage and exchange multimedia content. We present an architecture, a protocol model and IMG data model for several scenarios. "Procedures for Modifying RSVP", Kireeti Kompella, Jonathan Lang, 27-Jun-03, This memo specifies procedures for modifying the Resource Reservation Protocol (RSVP). This memo also includes an IANA Considerations section that lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types and sub-objects. "Transition Analysis for ISP Networks", Cleveland Mickles, 26-Feb-03, This document provides analysis of how to transition the different types of Internet Service Provider (ISP) networks to IPv6. It will provide design recommendations which may be followed to successfully deploy IPv6 services on a network that began as an IPv4 network. This is the companion document to draft-mickles-v6ops-isp-scenarios-04.txt which provides detailed background information on all scenarios. "Requirements for Point-to-Multipoint capability extension to MPLS", Seisho Yasukawa, Ichiro Inoue, 26-Feb-03, This document presents a set of requirements for Point-to-Multipoint (P2MP) capability extension to Multiprotocol Label Switching (MPLS). It identifies the functional and performance extensions required to realize Content Distribution Network (CDN) by MPLS technology. It also identifies functional extensions required to implement CDN/VoIP/VPN sevice convergence network. These extensions can be used to provide high performance and scalable broadband service network with MPLS technology. "SIP/SIMPLE Based Presence and IM Architecture", Avshalom Houri, 01-Jul-03, This document is a initial attempt in creating a document that will describe the architecture of a presence and instant messaging system. The document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, functional model, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. The main changes from the previous version of the document is that sections about functional model and basic call flows were added. "Interworking between Digital Subscriber Signalling System No. one (DSS1) and Session Initiation", Peter Kotar, 26-Feb-03, This document specifies the interworking between the Digital Subscriber Signalling System No.one (DSS1) as specified in [1] and the Session Initiation Protocol (SIP) as specified in [2]. SIP is an Internet application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. DSS1 is a signalling protocol for establishing, modifying and terminating circuit-switched calls, in particular telephone calls, within Public Integrated Services Digital Networks (ISDN)and between the Public network and Private Networks. DSS1 is specified in a number of ETSI Standards and published also as ITU-T standards. The interworking SHALL be described from DSS1 viewpoint for the basic call procedures. The interworking between the above signalling protocols occurs in a Media Gateway Controller (MGC), also called Softswitch which contains the protocol functionality for the ISDN subscribers and the SIP protocol functionality. In case of contradictions between the mapping described in the present document and the requirements specified in the corresponding DSS1 standards and SIP RFC , the procedures in the DSS1 standards and SIP RFC applies. "User Interface Evaluation and Filtering of Internet Addresses and Locators -or- Syntaxes for Common Namespaces", John Klensin, 20-Jun-03, Many internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. Whether or not this practice is desirable from an overall network standpoint, the designers of the applications believe that it leads to a better and more responsive user experience. The introduction of new top level domains, expecially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. "Organization Zone Prefix Length Discovery", Brian Zill, 26-Feb-03, This document specifies an extension to IPv6 Neighbor Discovery which allows nodes to discover the prefix length of the organizational administrative zone associated with an advertised prefix. "Directed Transcoding", Eric Burger, 26-Feb-03, This document describes a mechanism for invoking transcoding services in a SIP network. A user, proxy server, or other agent can transparently request these services, without modification to the existing network. "Method to Setup LSP using VLAN Tag Switching", Tetsuya Kawakami, 26-Feb-03, This document describes a method to setup a Layer 2 tunnel over networks based on Ethernet technology. For this purpose, the ports of an Ethernet switch are configured to forward VLAN tag-labeled packets incoming from a certain port to another unambiguous port by using VLAN tag information. The Ethernet switches themselves are a part of the Label Switching Routers (LSRs), which distribute the VLAN tags using Label Distribution Protocol (LDP). To enable LDP to fulfil this function, an LDP extension is proposed. The introduced method simplifies the transport of Ethernet frames over wide area Ethernet networks. "Evaluation of Transition Mechanisms for Unmanaged Networks", Christian Huitema, 27-Feb-03, In a companion paper we defined the 'unmanaged networks' scope, which typically correspond to home networks or small office networks, and the requirements for IPv6 transition mechanism in that scope. We start from this analysis and evaluate here the suitability of mechanisms defined in the NGTRANS working group. "Path based route identification in SCTP", Toshiyuki Kubo, Katsuyoshi Iida, 27-Feb-03, Although SCTP provides multihoming function, a single point of failure may occur due to its lack of source address selection. RFC2960 describes that 'a host should pick the most divergent source- destination pair.' But, it also describes that selecting source address is implementation matter. In RFC3257, Coene et al. have claimed that a host must take careful in selectiong its source address. In this document, we propose a way of outgoing interface selection and its corresponding source address selection in SCTP. "MPLS Traffic Engineering Policy Information Base", Man Li, 27-Feb-03, This document specifies a set of policy rule classes (PRC) for configuring MPLS traffic engineering policy at network elements. Instances of these classes reside in a virtual information store called the MPLS-TE Policy Information Base (PIB). The COPS protocol [3] with extensions for provisioning [4] is used to transmit this policy information to network elements. The PRCs defined in this document are intended for use by the COPS-PR MPLS client type. These PRCs are in addition to any other PIBs that may be defined for the MPLS client type, as well as the PRCs defined in the Framework PIB [5]. "Role-based Authorization Requirements for the Session Initiation Protocol", Jon Peterson, 27-Feb-03, This document lays out a set of requirements related to role-based authorization for the Session Initiation Protocol. While numerous authentication mechanisms are described in the base SIP specification, role-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. "Threshold Validation: A Mechanism for Improved Trust and Redundancy for DNSSEC Keys", Johan Ihren, 27-Feb-03, This memo documents a proposal for a different method of validation for DNSSEC aware resolvers. The key change is that by changing from a model of one Key Signing Key, KSK, at a time to multiple KSKs it will be possible to increase the aggregated trust in the signed keys by leveraging from the trust associated with the different signees. By having multiple keys to chose from validating resolvers get the opportunity to use local policy to reflect actual trust in different keys. For instance, it is possible to trust a single, particular key ultimately, while requiring multiple valid signatures by less trusted keys for validation to succeed. Furthermore, with multiple KSKs there are additional redundancy benefits available since it is possible to roll over different KSKs at different times which may make rollover scenarios easier to manage. "Deflate-8bit and Deflate-base64: Compression Content-Transfer-Encodings for MIME", Ned Freed, 27-Feb-03, This document defines two additional MIME content-transfer-encodings, deflate-8bit and deflate-base64. Adding these CTEs to MIME that provide facilities for loss-less, adaptive, general-purpose compression. The first of these, deflate-8bit, produces 8bit output, while the second, deflate-base64, produces the same sort of output as the base64 content-transfer-encoding defined in RFC 2045. "Provider Provisioned CE-based Virtual Private Network solution using IPsec and HTTP", Jeremy De Clercq, 27-Feb-03, This document describes the procedures for a Service Provider to offer Virtual Private Network Services to its customers by provisioning the CE devices on behalf of the customer. The IPsec technology is used to protect the customer traffic, and the HTTP protocol is used to autodiscover the CEs' VPN configuration information. "Media Policy Manipulation in the Conference Policy Control Protocol", Rohan Mahy, Nermeen Ismail, 27-Feb-03, The SIP conferencing framework defines a model for tightly-coupled conferencing in the Session Initiation Protocol (SIP), in which a Conference Policy Control Protocol is used to manipulate policies relevant to a specific conference, such as conference membership policy, authorization policy, and media policy. This document describes a logical model to describe media processing in a SIP conference. It also defines specific protocol semantics and a specific syntax to manipulate that model. "Syntax of temporal URI fragment specifications", Silvia Pfeiffer, Craig Parker, 09-Jun-03, This document specifies a syntax for temporal offsets and intervals as URI fragments. Such fragment identifiers are useful to directly access temporal offset points and intervals in time-continuous resources such as audio and video. The URI fragment syntax specified in this document is comformant to the Generic URI Syntax as specified in RFC 2396 [2]. "Considerations in Benchmarking Routing Protocol Network Convergence", Russ White, Vishwas Manral, Robert Adams, 27-Feb-03, This document attempts to discuss some of the definitions required to undertake the specifications of such benchmarks, and also to discuss some of the possible ways to benchmark a routing protocol performance within a network, and some of the implications of those benchmarks. The definition of convergence is discussed first, then polling network devices. Several tests which are commonly used to measure network convergence are examined. This draft does not attempt to define what techniques should be used to benchmark network convergence, but only to provide considerations that testers shoudl consider when attempting to measure netowrk convergence using various methods. "TDM Circuit Emulation over Packet (CEP-TDM)", Tom Johnson, 27-Feb-03, This draft proposes a TDM emulation protocol for consideration by the PWE3 Working Group. The protocol defines methods for transporting DS3, E3, DS1, E1, and NxDS0 circuits over packet switched networks. It is based on ATM Circuit Emulation, but optimized for variable length packet networks. The intent is to provide a relatively simple but flexible method for transporting TDM signals over packet switched networks that also provides a path for interworking with ATM Circuit Emulation. "REmote Sample and CApture Protocol (RESCAP)", Fulvio Risso, D Dutt, 07-Mar-03, This document details a protocol that can be used to capture and sample frames on a remote device. This protocol could be a possible solution for the 'Report format and report stream format document' milestone of the PSAMP Working Group. This protocol defines a control connection, which is used to control the remote device, and a data connection, which is used to transport back the sampled data. This protocol includes has a set of optional parameters that allows customizing the behavior of the sampling process. This protocol can be used also for packet capture and it should be possible to implement it on both network devices (router and switches) and workstation hosts. "is-composing Indication for Instant Messaging Using the Session Initiation Protocol (SIP)", Henning Schulzrinne, 27-Feb-03, In instant messaging systems, it is useful to know that the other party is composing a message, e.g., typing. This document defines a new content type and XML namespace that conveys information about a message being composed. The message could be of any type, including text, voice or video "IPv6 Anycast Functionality/Terminology Definition", Satoshi Doi, 27-Feb-03, Today, the use of IPv6 anycast is limited. This is because the usage of IPv6 anycast is still unclear. This document describes the usage of IPv6 anycast with some examples. Moreover, we describe the functionalities of anycast, and try to define the terminology of anycast for future discussion "QoS considerations for L3 PPVPNs", Jeremy De Clercq, 27-Feb-03, Although QoS is identified as a very important requirement for L3 PPVPNs (see for example [PPVPN-REQ]), the proposed L3 PPVPN solutions ([2547bis], [VR], [CE-based]) have paid very little attention to describing how the proposed approach fulfills the QoS requirements. This document explores different points of view, describes dependencies and orthogonalities, and details a number of solutions and guidelines. "Pre-Midcom Requirements for Traversal of NATs for traffic not supported by STUN", Rohan Mahy, 27-Feb-03, STUN (Simple Traversal of UDP for NATS) specifies a mechanism which enables nodes in a private network to determine if they are behind a NAT, to discover their remapped address and port, and for many types of NATs to send UDP traffic through them. In addition TCP connections initiated from the private side of NATs already works. This document specifies requirements for a mechanism that enables traversal of expected TCP traffic through all NATs, and traversal of UDP traffic through symmetric NATs. "The use of Neighbor Graphs for Context Caching", Arunesh Mishra, 27-Feb-03, The use of neighbor graphs as a method for dynamically caching the context of mobile stations in front of the station's mobility path can reduce the latency of handoff's between base stations or access points. Neighbor graphs capture the set of all potential mobility paths for a wireless network. Given any base station or access point, the set of all possible hand-offs can easily be determined by examining the neighbor graph in either a distributed fashion (at each base station) or centralized at the AAA server. This draft describes how the neighbor graph algorithm works at both the base station and the AAA server. "The PKI SASL Mechanism", Tony Hansen, 27-Feb-03, This document defines a user/password Simple Authentication and Security Layer(SASL) mechanism called the PKI mechanism. The PKI mechanism is intended to be used in situations where (1) passwords must be encrypted, (2) the password must be recoverable, and (3) using TLS in combination with a SASL mechanism such as PLAIN is inappropriate. NOTE: This document is a straw proposal to see what interest there is in having a SASL mechanism such as this. See the first section below for more information on why this mechanism is needed. "Maximizing Alignment Between LDAP and X.500", Skip Slone, 27-Feb-03, This document is intended to provide information of interest to developers of Lightweight Directory Access Protocol (LDAP) specifications and products. It is intended to provide background information and to facilitate discussion within IETF Working Groups, most notably LDAPbis. This Internet-Draft highlights decisions made by group attending the ITU-T and ISO/IEC JTC1 Collaborative Meeting on the Directory in London in February 2003 for inclusion in an upcoming Proposed Draft Amendment (PDAM) to the ITU-T X.500 / IS 9594 Specification. It also identifies issues that the X.500 group would like to bring to the attention of the LDAPbis Working Group at the upcoming IETF meeting in March. "SIP Issues in Dual-stack Environments", Jasminko Mulahusic, Hakan Persson, 27-Feb-03, The advent of IPv6 in addition to IPv4 makes hosts and servers dual- stack. SIP communications can be used in both environments but there is little understanding what will happen if some nodes are dual-stack while others, presently the majority, is IPv4 only enabled. This document describes some scenarios and associated issues when dual- stack users and servers try to communicate with IPv4 only hosts using SIP. It is not evident that interoperability is achieved, and if that is not the case, this would severely limit the usability of both SIP and IPv6. "Using IKE with IPv6 Cryptographically Generated Address", Julien Laganier, Gabriel Montenegro, 01-Jul-03, This document describes IKE peer authentication via IPv6 Cryptographically Generated Addresses (CGA). This technique can be used to provide 'Opportunistic IPsec' between IPv6 nodes or security gateways. These CGA's have been proposed to solve several security issues in the absence of any centralized trusted security infrastructure. "An Approach for Increasing Root And TLD DNS Servers", Yasuhiro Morishita, 27-Feb-03, Currently, it is thought that the maximum number of DNS server hosts for a zone is 13. In fact, DNS server hosts of root zone and .com/.net zone are operated by 13 servers. This draft proposes an approach for increasing of DNS server hosts without changing DNS protocol by using 'multiple-addresses per host' basis. Especially, this approach is useful for adding IPv6 DNS servers for root and TLD zones. And it also may be useful for signing root zone for DNSSEC. "Cisco Systems NetFlow Services Export Version 9 Transport", Martin Djernaes, 27-Feb-03, NetFlow Export Version 9 Export is defined in the internet draft draft-claise-netflow-9 [NFv9], which describes how to transport NetFlow over UDP [RFC768]. This document describes how NetFlow would use SCTP [RFC2960] as a transport protocol. Traditionally NetFlow was transmitted over UDP to a physically closely located collector. As the networks grow this is not necessarily the case any longer, so issues like congestion avoidance and reliability are becoming an increasing issue for applications using NetFlow. This document addresses these issues in a simple way using the SCTP protocol. "Cryptographically Generated Addresses (CGA)", Tuomas Aura, 27-Feb-03, Cryptographically generated addresses (CGA) are IPv6 addresses where the interface identifier is generated by hashing the address owner's public key. The address owner can then use the corresponding private key to assert address ownership and to sign messages sent from the address without any additional security infrastructure. This document describes a generic CGA format that can be used in multiple applications. "A Framework for Data Packet Access Control (DPAC)", S Wu, Weiping Zhao, 27-Feb-03, This informational draft describes the DPAC (Data Packet Access Control) framework, potentially under PANA, to efficiently control 'data packets' to access the network. Instead of using potentially more expensive crypto-based mechanisms such as IPSec (layer 3) or IEEE 802.11i (layer 2), DPAC introduces the possibility of using and negotiating a range of light-weight per-data-packet source authentication methods to control the data packets from PANA Clients (PaC). In DPAC, each data packet sent from PaCs to Enhanced Point (EP) can be classified, with high probability, as either valid or invalid. Furthermore, under this framework, it is possible for EP and PAA to account reliably on the network usage of each PaC. "Requirements for Filtering of Watcher Information", Krisztian Kiss, Eva Leppanen, Hisham Khartabil, 27-Feb-03, This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcherinfo notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. Also the preference for full or partial state information is considered in requirements. "Context Transfer Extension to Cellular-IP", Michael Georgiades, 01-Jul-03, This Internet draft enhances cellular-IP mobility protocol with a Context Transfer mechanism aiming to further optimise the handoff operation in mobile networks. Within a cellular-IP domain, during the handoff from one cellular-IP base station to another, cellular-IP packets could be used to initiate and transfer authorised context from the previous cellular-IP base station via the cellular-IP gateway to the new cellular-IP base station. This draft presents how the context transfer extension introduced could facilitate in reducing latency and packet loss by avoiding the signalling required between the mobile node and the new base station in re-establishing the desired state information. "Group label allocation mechanism in MPLS networks", Jin Choi, 28-Feb-03, As the group communication become more important, the special label should be allocated in support of group management and maintenance. The allocation mechanism of group label can be applied to a point-to- multipoint communication in MPLS networks. Currently used label is locally significant, while this special label should be common object within a single MPLS domain. This document specifies the allocation mechanism of group label in order to perform unidirectional point-to- multipoint communication. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, 01-Jul-03, The draft presents an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to support Prepaid data services for a wide range of deployments such as Dial, Wireless, WLAN. Consideration for roaming using mobile-ip is also given. "TDM over IP using Loop Emulation", Jonathan Stein, Ronen Shashoua, Tuvia Segal, 28-Feb-03, This document describes a method for transporting time division multiplexed (TDM) signals over Pseudo Wires using AAL2 loop emulation. It is complimentary to TDM over IP using AAL1 circuit emulation as defined in [TDMoIP]. "Application of the MIPv6 protocol to the multi-homing problem", Marcelo Bagnulo, Alberto Garcia-Martinez, Ignacio Soto, 28-Feb-03, This note attempts to describe how to apply the MIPv6 protocol to provide fault tolerance to transport layer connections established between a multi-homed host and other hosts in the Internet. Specifically, this note addresses the usage of MIPv6 signaling messages to convey information about alternative address to be used when an outage occurs. Additionally, possible mechanisms to detect failures affecting the currently used path are explored. "Megaco/H.248 CAS Maintenance Package", Kushanava Laha, Vikram Nair, 03-Mar-03, This document is work in progress and defines the CAS Maintenance package in association with the Megaco/H.248 Protocol that can be used to control a Media Gateway (MG) from an external controller, called a Media Gateway controller (MGC). It is intended to satisfy the requirements in section 12 of the Megaco/H.248 requirement document [2]. "MIPv6 Inter-working with Packet Filtering", Xiaobao Chen, 17-Jun-03, This document provides considerations for some requirements on the IPv6 nodes using MIPv6 to communicate with their peers across a network boundary where some specific packet filtering is deployed for operator and service provider controlled access to the services and network resources. Depending on the operational policies, the packet filtering can be applied on either the incoming packets or the outgoing packets or in both directions. A mobile node using MIPv6 sends packets with Home IP address in the extension headers, while the packet filtering is often based on either the source address or the destination address or both in the basic IPv6 header.Packet filtering that complies with the policies from the mobility unaware applications will fail to perform properly due to the change of the source and destination addresses in the basic IPv6 header when MIPv6 is used. This document provides an analysis on the operation requirements on packet filtering and then proposes a simple solution that does not impose any change on IPv6 but requires an addition to IPv6 nodes using MIPv6. "The EAP Archie Protocol", Jesse Walker, Russell Housley, 24-Jun-03, This memo defines an EAP authentication protocol based on pre-shared keys, called EAP-Archie. This protocol performs mutual authentication, session establishment, and session key derivation. EAP-Archie is based on a static pre-shared key. EAP-Archie is designed as a native EAP method. "Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks", Paul Tan, 04-Mar-03, To achieve seamless layer 3 handover, mobile nodes must be able to perform movement detection and neighborhood candidate access routers discovery quickly and efficiently. In this document, we present a conceptual overview on how to extend the IEEE 802.11 Management frames to carry extensible application- specific Information Element, which allow access points to advertise the capabilities information of its associated network/provider and to improve movement detection. We believe that mobile nodes can thus dynamically discover neighboring candidate access routers or networks more quickly and efficiently, and also to obtain valuable capabilities information so as to select the 'best' target access router to initiate seamless handover. "Service Emulation Over IP - A Solution using Generic Routing Encapsulation (GRE)", Tissa Senevirathne, Som Sikdar, 04-Mar-03, Enhancement to Generic Routing Protocol (GRE) is presented. These enhancements are intend to Pseudo wire Services over IP networks. In addition methods presented in this document allow to transport Sub- IP protocols and services over IP networks. It is proposed, in this document, to use higher order bits of the GRE Key to identify the emulated service. "RSVP extensions for gmpls restoration signaling", Katsuhiro Shimano, Wataru Imajuku, 05-Mar-03, There are some efforts to categorize restoration schemes [Restoration-analysis]. We consider that pre-planned restoration has some advantages, for instance, enhancing the quickness to reduce downtime, extensions to recovery classes, risk management, and totally integrated distributed control. This document describes some requirements and extended properties for message objects on RSVP-TE [RSVP-GMPLS], LSR procedures, and pre-planned GMPLS restoration. We append a procedure to the recovery steps for working and restoration setup. Some objects are additionally required with respect to establishing working LSPs and reservation of restoration LSPs. This document shows that restoration activation is also needed and clarifies the required properties. "Synchronization in Border Gateway Protocol", V Girish, 07-Mar-03, BGP (Border gateway Protocol) is a routing protocol, which shares the information of its routing table on incremental basis. BGP needs to interact with the IGP peers within the autonomous system when all the routers inside the autonomous system do not run BGP. This document provides a detailed implementation of synchronization in BGP. This document specifies some implementation specifics of synchronization and also throws some of the pros and cons involved in implementing synchronization. This also reveals the points to be taken care when transition happens from synchronization to No synchronization and vice versa. Some of the precautions that are to be taken before implementing synchronization in BGP are also highlighted here. "RTSP Stream Switching", Philippe Gentric, 10-Mar-03, Stream switching is a technique used to change the data rate of a media being streamed, typically for the purpose of adaptation to the effectively available bandwidth of the network. A backward compatible and independent RTSP 'SWITCH' command is proposed in order to enable RTSP-based stream switching. "Extensions to LMP for Flooding-based Fault Notification", Toshio Soumiya, Richard Rabbat, 30-Jun-03, This draft describes extensions to the Link Management Protocol (LMP) for use in flooding-based fault notification in optical networks. We focus on networks that use a common control plane (e.g, Generalized Multi-Protocol Label Switching or GMPLS). These extensions implement the Fault Notification Protocol, a flooding-based approach to notifying faults to nodes in the network. We motivate the use of LMP extensions for flooding, define message formats and explain the communication messages that occur using LMP. "The EAP MD5-Tunneled Authentication Protocol (EAP-MD5-Tunneled)", Paul Funk, 20-Mar-03, EAP-MD5-Tunneled is an EAP protocol designed for use as an inner authentication protocol within a tunneling EAP protocol such as EAP- TTLS or EAP-PEAP. It is cryptographically equivalent to standard CHAP and the EAP-MD5-Challenge protocol. It can be used inside an EAP tunnel without exposing the system to the type of man-in-the- middle attack which use of CHAP or the original MD5 Challenge protocol is subject to, yet it is capable of being converted to CHAP credentials at the tunneling endpoint for proxy forwarding to legacy AAA servers, with no modification required of the legacy AAA server. It may also be converted to EAP-MD5-Challenge credentials at the tunneling endpoint for the purpose of proxy; however, the downstream server that terminates the EAP-MD5-Challenge must be modified to provide a challenge that meets certain criteria. "Mobile Messaging Architectures and Requirements", Alan Stebbens, Milt Roselinsky, 20-Mar-03, The increasing importance of messaging as a potential source of revenue for mobile networks has led operators to build or procure mobile messaging solutions. Some operators have built mobile messaging solutions using IETF standards (IMAP, SMTP, MIME). Another solution has been developed by consensus in the 3GPP and OMA groups, based on MIME, HTTP methods and WAP PUSH, which has been deployed by many operators. This document presents a taxonomy of messaging architecture components and models, providing a comparison of their feature sets. It also identifies the commonalities of these mobile messaging solutions and abstracts from these a set of mobile messaging requirements. The information is provided to inform and encourage future discussion of and improvements to Internet messaging in order to increase their applicability to mobile messaging systems. "Explicit Resource Control over GMPLS Link Bundles", Anca Zamfir, Zafar Ali, 09-May-03, Explicit label/ resource control using the Label ERO and Label RRO subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE links are bundled, identification of label resource is not enough for the purpose of explicit resource control. Specifically, when link bundling [GMPLS-BUNDLE] is used, resource identification requires mechanisms to specify the component link identifier, along the TE link identifier and Label. This draft defines the extensions to RSVP- TE [RFC2119, RFC3209] to specify component link identifiers for explicit resource control and recording over GMPLS link bundles. "Numeric Locators for Uniform Resource Identifiers", Ivan Nejgebauer, 20-Mar-03, This document describes the syntax of numeric character strings, called numeric locators or simply locators, which form a hierarchical name space where any node except the root can (or, if it is a leaf node, must) resolve to a single Uniform Resource Identifier. It also defines a mapping of the locator name space to the Domain Name System, which allows the use of the existing DNS infrastructure to resolve locators. "The OpenPGP HTTP Keyserver Protocol (HKP)", David Shaw, 20-Mar-03, This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. "The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header", Soohong Park, Hanna Lee, 20-Mar-03, This document presents a new method for the PMTU discovery for IPv6. To discover the PMTU of a path, a source node measures its actual PMTU using the newly defined Hop-by-Hop Option header, whereas a source node initially assumes that the PMTU of a path is the known MTU of the first hop in the path in the previous one [1981]. In order to measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet when node is beginning. This can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size). Most of all, since existing PMTU has a weak point for security and denial-of-service attacks, this document suggests a security function when PMTU is going on. All IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. "SPI-Based health checking mechanism for IPSEC", Yong Hwang, 21-Mar-03, This document describes a diagnostic protocol for unexpected failures between IPSEC gateways. The method covers two parts as IKE[1] consists of two phases. One is echo request/reply message between two IPSEC gateways to confirm health of IKE peer and the other is exchanging of IPSEC-SA SPI to assure exact state of IPSEC-SA. Two new Notification Payload message type is defined, SPI-PING-REQUEST and SPI-PING-REPLY "IPv4 traversal for MIPv6 based Mobile Routers", Pascal Thubert, Marco Molteni, Patrick Wetterwald, 30-May-03, Since IPv6 connectivity is not yet broadly available, there is a need in NEMO for a simple technology that allows a MIPv6 based Mobile Router to roam over IPv4 networks. The Doors Protocol proposed in this memo allows an arbitrary Mobile Node to roam even within private IPv4 address spaces, across both Network Address Translations (NAT), reverse NAT, and even Port Address Translation (PAT), in order to cope with the reality of today's Internet. "Finite State Machine (FSM) Framework for SIP Extensions", Amit Kaul, 21-Mar-03, This draft defines a Finite State Machine (FSM) Framework for the SIP Extensions using which various SIP extensions, having their unique definitions of a SIP transaction or a Dialog, can be implemented in a scalable manner, while keeping the logical meaning of a dialog or a transaction (as defined by RFC 3261 [1]) intact. This draft proposes a set of guidelines for implementing FSM in various SIP extensions. "A Survey of Mobile Messaging Architectures and Requirements", Alan Stebbens, Milt Roselinsky, 04-Jun-03, This document presents a taxonomy of messaging architecture components and models, providing a comparison of their feature sets. It also identifies the commonalities of these mobile messaging solutions and abstracts from these a set of mobile messaging requirements. The information is provided to inform and encourage future discussion of and improvements to Internet messaging in order to increase their applicability to mobile messaging systems. "Sieve -- Variables Extension", Kjetil Homme, 17-Apr-03, In advanced filtering rule sets, it is useful to keep state or con­ figuration details across rules. This extension adds an action to store data in variables, an action to retrieve the current time, changes the interpolation of strings, and supplies a new test so that the value of a string can be examined. "Bundle Protocol Specification", Keith Scott, Scott Burleigh, 24-Mar-03, This document describes the end-to-end protocol, header formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). "Delay-Tolerant Networking: An Example Interplanetary Internet Bundle Transfer", Robert Durst, 24-Mar-03, This document presents an example data transfer in a delay tolerant network. The particular delay tolerant network is the Interplanetary Internet, and the purpose of this document is to illustrate the key concepts in the Delay Tolerant Network architecture [DTNRG03]. The document describes the network and follows the progress of a bundle as it is transferred through that network. "Delay-Tolerant Network Architecture", Vinton Cerf, 24-Mar-03, This document describes an architecture for delay-tolerant networks, and is a generalization of the architecture designed for the Interplanetary Internet: a communication system to provide Internet- like services across interplanetary distances in support of deep space exploration. This generalization addresses networks with operational and performance characteristics make conventional networking approaches either unworkable or impractical. We define a message-based overlay that exists above the transport layer of the networks on which it is hosted. The document presents an architectural overview followed by discussions of services, topology, routing, security, reliability and state management. "Mobile Network Prefix Delegation extension for Mobile IPv6", Pekka Paakkonen, Juhani Latvakoski, 25-Mar-03, This draft proposes a dynamic Mobile Network Prefix (MNP) delegation extension for Mobile IPv6 protocol to enable MNP delegation for mobile networks. A MNP is an IPv6 prefix used in a mobile network. The extension supports dynamic delegation, return, refreshing and updating operations related to MNP delegation operations between a Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). This extension is proposed, because there is a lack for a dynamic MNP delegation protocol related to mobile networks, and currently MNPs have to be assigned statically to enable mobile networking. "BGP-4 Reference Attribute Capability", K Shankar, 25-Mar-03, As the size of the routing table in the Internet grows, there is a need for routing protocols to reduce the control information and also improve time taken for route convergence. In this draft we propose a new capability in Border Gateway Protocol (BGP) to reduce the size of the UPDATE message when the same path attributes are used for consecutive UPDATE messages. This allows more number of routes to be sent in a single UPDATE message and also reduces extraction processing in the receiving router. "A Method for Registering Internationalized Domain Names", Paul Hoffman, 27-Jun-03, This document describes some suggested practices for registering internationalized domain names (IDNs) in a zone. Before accepting registrations of domain names into a zone, the zone's registry should decide which codepoints in the Unicode character set the zone will accept. The registry should also decide whether particular characters in a registered domain name should cause registration of multiple equivalent domain names; these domain names might be added to the zone or blocked from registration. This document also describes how to handle character variants in registering IDNs, and how to publish tables that list the character variants. "Designated Mailers Protocol A Way to Identify Hosts Authorized to Send SMTP Traffic", Gordon Fecyk, 28-Apr-03, This document describes a proposed standard for identifying host computer systems designated as Simple Mail Transfer Protocol (SMTP) clients for an Internet domain or host through Domain Name System (DNS). This identification allows SMTP servers to verify if a connecting client is allowed to make outgoing SMTP connections on behalf of the client's domain. "Nameprep and IDNA Test Vectors", Simon Josefsson, 27-Mar-03, This document contains test vectors for Nameprep and IDNA "Lightweight Mobility Detection and Response (LMDR) Algorithm for TCP", Yogesh Swami, K Le, 28-Mar-03, TCP congestion control is based on the assumption that end-to-end path of a TCP connection does not change--or at best changes infrequently--once the connection is established. However, when a user moves from one subnet to another, this assumption does not hold. In these cases, relying on the rate of arrival of ACKs as the only criterion for congestion control can lead to congestion collapse if a (group of) receiver(s) can keep sending ACKs in a regular fashion even after subnet change. What's worse is that a TCP sender may be totally unaware of its peer's mobility to take any remedial action. In this document we describe a network layer independent mechanism by which a TCP host can propagate its subnet change information to its peer, based on which, the sender can appropriately reduce its data rate. "Context Transfer and Fast Mobile IPv6 Interactions in a Layer-2 Source-Triggered Anticipative Handover", Raymond Jayabal, 31-Mar-03, This draft was submitted to obtain comments for an experimental work in progress. It presents Fast Mobile IPv6 and Context Transfer interactions for a specific case of contextful, anticipative, network controlled and Layer-2 source-triggered IPv6 handover where one or more candidate access routers can be identified for selection as target. It is also meant to illustrate a case where it might be useful to: a) have Context Transfer messages as but options in handover negotiation messages (e.g., Fast MIPv6's HI/HACK messages) between Access Routers. b) have an additional flag in the Context Transfer Protocol Context Transfer Data message which indicates whether the new Access Router should install any context at all given that any one context fails to be installed. "Middlebox Communications (MIDCOM) Protocol Managed Objects", Mary Barnes, 01-Jul-03, This document describes and defines the managed objects for dynamic configuration of middleboxes. The scope of the middleboxes to which these managed objects apply is limited to NATs and Firewalls. However, the MIB module as defined by this document is intended to provide a baseline for the dynamic configuration of other types of middleboxes. The applicability of existing Management Information Base (MIB) modules to the MIDCOM requirements, framework and semantics is described. Additional managed objects are defined to satisfy the entirety of the MIDCOM requirements, framework and semantics, providing a complete MIDCOM MIB for NATs and Firewalls to fully realize the requirements of the MIDCOM protocol. "Cisco Support for Lawful Intercept In IP Networks", Fred Baker, Bill Foster, Chip Sharp, 02-Jun-03, For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. "Cisco Lawful Intercept Control MIB", Fred Baker, 31-Mar-03, Ths document describes an SNMP V3 MIB for controlling the Lawful Intercept architecture described in the associated document. Any comments on this document should be sent to: li-comment@external.cisco.com "On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks", Yunjung Yi, 31-Mar-03, 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 build 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. "The generalizedAudit object class and the generalizedAuditEvent attribute", Eric Hall, 31-Mar-03, This document defines an LDAP auxiliary object class and a single attribute, which together can be used to store and track the entities who may have accessed or modified a specific entry in an LDAP directory information tree. For example, an LDAP application may need to store information which can indicate when an entry was created, when it was accessed, who modified it, and other kinds of similar information, with this information acting as a general- purpose auditing log for that entry. The object class and attributes defined herein are designed for that purpose in particular, and are not intended to serve as detailed auditing information capable of withstanding court-of-law scrutiny, nor are they designed to be used for journaling-playback purposes. They are simply to be used for storing general information about the changes which have been made to a specific entry. "Delegation of E.F.F.3.IP6.ARPA", Randy Bush, Robert Fink, 02-Apr-03, This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this. "Path MTU Support for IPv6-in-IPv4 Tunnels", Fred Templin, 01-Apr-03, This document specifies a means for IPv6-in-IPv4 tunnels to participate in IPv6 path MTU discovery. Also specified is a means for the tunnel decapsulator to inform the encapsulator of appropriate per-neighbor MTU values using IPv6 neighbor discovery. "CHARPREP – Character Equivalency Preparations for IDN", Edmon Chung, 01-Apr-03, Charprep intends to take up where Nameprep [NAMEPREP] left off to provide additional preventive measures to bridge the users conceptual perception of a multilingual domain name with the domain matching process. The critical development from Nameprep is that common user perception is taken into account. That is, Charprep strives to take the 'case-insensitivity' concept of user-friendliness to another level for IDNs because of the inherent complexity and potential confusion that could arise from the use of multilingual characters in domain names. Charprep is designed to be a framework for Zone Administrators (e.g. domain registries) to employ relevant equivalency tables to compute and generate variants from the original string to variants that could possibly create confusion with users. The actual management of Reserved Variants (RV), Zone Variants (ZV) with the original string (Primary Domain) will be discussed in Zoneprep [ZONEPREP]. Furthermore, Charprep and Zoneprep are designed to be a recommended feature to be offered to users by a Zone Administrator (e.g. Domain Registries) in the management of Internationalized domain names (IDN). A key concept is that these are done without affecting the IDN protocol specified in [RFC3490], [RFC3491] and [RFC3492]. "ZONEPREP - Zone Preparations for IDN", Edmon Chung, 01-Apr-03, Zoneprep intends to provide a framework for applying Charprep variants to zone file management. More specifically, Charprep profiles are used to generate a set of perceptually equivalent domains from a given primary domain, Zoneprep policy profiles are used to determine which among the generated set of Charprep variants to include into the DNS zone file. This document does NOT provide any specific Zoneprep policy profiles, instead it describes a framework for Zone Administrators (e.g. registries) to consider when implementing IDN. More importantly, to consider the policy on reserving and publishing variants from the given primary domain to the DNS zone files. This framework also leads into the discussion of provisioning protocol for IDN, more importantly for a server to announce its policies on reserved variants and zone variants, as well as for the client to further manage the IDN. This document will NOT describe extensively this issue, for further discussion please refer to [EPP- I], which incorporates this framework into EPP. "EPP Internationalized Domain Name Mapping", Edmon Chung, Henry Tong, 01-Apr-03, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internationalized Internet domain names (that includes English alphanumeric domain names) stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. More specifically, EPP-IDN intends to provide a mechanism for explicitly managing and provisioning Reserved Variants and Zone Variants created for a Primary Domain Name. "OPES Callout Protocol (OCP)", Alex Rousskov, 02-Apr-03, This document specifies Open Pluggable Edge Services (OPES) callout protocol (OCP). OCP supports the remote execution of OPES services. This OCP specification is incomplete and cannot be used for implementing the protocol yet. Major missing pieces are transport binding(s) and message encoding(s). "Light Weight Access Point Protocol (LWAPP)", Pat Calhoun, 02-Jun-03, While conventional wisdom has it that wireless Access Points are strictly Layer 2 bridges, such devices today perform some higher functions that are performed by routers or switches in wired networks in addition to bridging between wired and wireless networks. For example, in 802.11 networks, Access Points can function as Network Access Servers. For this reason, Access Points have IP addresses and can function as IP devices. "iSCSI Implementation Guidelines for Fault Tolerance and Load Balancing using Temporary Redirection", Robert Gilligan, 03-Apr-03, An approach for achieving fault tolerance and load balancing in iSCSI using the iSNS discovery mechanism or iSCSI discovery session and the temporary redirection mechanism is outlined here. This approach requires no change to iSCSI or other protocols that initiators and targets implement. But the manner in which initiators perform target discovery, support the temporary redirection mechanism, and recover from failed iSCSI sessions affects their ability to support this approach. This paper provides implementation guidelines for iSCSI initiators to follow to support this form of fault tolerance and load balancing. "An Enhanced Multi-Link PPP with low overhead suitable for multiple scalable bandwidth links", Mustafa Shakeel, 03-Apr-03, This document proposes a new architecture for providing an enhanced way of fragmenting PPP protocol frames which is self-scalable to operate over a wide range of multiple links ranging from low-bitrate, sub-T1 line to very high speed SDH hierarchy. The scheme provides a relatively low overhead for fragmentation procedure and can scale very well to accommodate multiple and diverse types of communication links operating at different speed. In addition, the generated data fragments are distributed to the multiple communication links according to their QoS that maximize the real time utilization of the links. This proposal is not intended to limit the scope of functions and procedures described in RFC 1990[1]. This proposal solicits a new type of fragmentation procedure that can be used along with other functions and features described in the RFC 1990. "Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", Thomas Nadeau, Monique Morrow, George Swallow, 03-Apr-03, This document describes the Virtual Circuit Connection Verification Protocol (VCCV). VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. A network operator may use the VCCV protocol to test the network's forwarding plane liveliness. "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, Monique Morrow, 01-Jul-03, This document enumerates the OAM message mapping from pseudo wire emulated edge-to-edge services over MPLS and IP transport networks to their native attached services. "GMPLS and IP/MPLS Interworking Architecture", Eiji Oki, 03-Apr-03, Generalized MPLS extends MPLS to support various transport technologies. One GMPLS target is to seamlessly integrate IP/MPLS networks with vari- ous transport networks such as SONET/SDH and wavelength networks. How- ever, in the migration from IP/MPLS networks to GMPLS networks, both kinds of networks will coexist at some point. IP/MPLS nodes that do not support GMPLS protocols must also work with GMPLS networks. This docu- ment addresses the GMPLS and IP/MPLS interworking architecture, and examples both routing and signaling aspects. "MPLS and IP PW Payload ID", David Allan, 03-Apr-03, This memo defines an MPLS and PW payload ID. It describes how an MPLS payload ID may be used to address a number of issues associated with proprietary ECMP deployments. It describes how when used with PWs permits OAM and control protocols to be multiplexed with a PW. "EAP client-side transport", Benoit de Boursetty, Florent Bersani, 03-Apr-03, This document defines a new architecture on the client-side for authentication by EAP. This architecture complements the usual setup considered in EAP by making it become symmetric: the client-side is divided in two parts, the Authentication Token and the client, which are analogous respectively to the Authentication Server and the Authenticator on the server-side. Moreover, this document describes a framework for the use of Authentication Tokens with the EAP protocol. "Constrained VPN route distribution", Ronald Bonica, 04-Apr-03, This document defines MP-BGP procedures that can be used to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) between different autonomous systems or distinct clusters of the same autonomous system. "Site Specific Options for DHCP for IPv6", Bernard Volz, 07-Apr-03, This document specifies that a portion of the DHCP for IPv6 [DHCPv6] 16-bit option space is reserved for site-specific options. Site- specific options are to be used for site specific needs and MUST NOT be used for public (IANA assigned) or vendor specific options. "Local Scope Address Requirements", Tony Hain, 12-May-03, This memo will discuss the site network manager's requirements for an address range available for use in a local routing scope. "Reliable Multicast Transport Building Block:Tree based ACK (TRACK) Mechanisms", Dah Ming Chiu, 07-Apr-03, This document describes the RMT Building Block for Tree-based ACK (TRACK) mechanisms. It contains functions relating to positive acknowledgments and hierarchical tree construction and maintenance. It might primarily be used as part of the TRACK Protocol Instantiation. It is also designed to be useful as part of overlay multicast systems that wish to offer efficient confirmed delivery of multicast messages. "Reliable Multicast Transport Building Block: Tree Auto-Configuration", Seok Koh, 07-Apr-03, The Reliable Multicast Transport (RMT) Working Group has been chartered to standardize reliable multicast transport services and protocol instantiations, which include the tree-based ACK (TRACK) protocol. This document is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' "Using DNS SRV records to locate whois servers", Miguel Sanz, Gerhard Winkler, 07-Apr-03, Whois servers are used to locate administrative, technical and security contacts for given IP addresses, domain names or other network objects associated with an organisation, e.g. AS numbers. While usually Top Level Domain (TLD) registries run a whois server, there is no generic name for it and it may not even be obvious that the TLD registry's whois server is the right one to ask, since there are TLDs where registration takes place under specialised second level domains (e.g. UK, AT). The Regional Internet Registries (RIR) also provide whois service as part of their coordination task. All this can be solved by central 'master' or 'meta' whois servers, which keep track of all new and changing servers and refer to the DNS registries' or RIRs' whois servers. This document proposes a DNS-based approach which eliminates the need for a central master repository and works down to lower levels in the hierarchy. It is the intent to locate a whois server as close to the target (in terms of hierarchy) as possible, while preserving the opportunity to locate higher level servers for escalation purposes. "Mobile IP version 6 Route Optimization Security Design Background", Pekka Nikander, 07-Apr-03, In this document we present the design rationale behind the Mobile IPv6 (MIPv6) Route Optimization Security Design. The purpose of this document is to assemble together the collective wisdom and understanding obtained during the Mobile IPv6 Security Design in 2001-2002. The main body of the document is intentionally kept relatively short: the details of a number of specific issues are explored in appendices and elsewhere. "RSERPOOL Redundancy-model Policy", Qiaobing Xie, 07-Apr-03, This document defines RSERPOOL Redundancy-model Member Selection Policy parameter and the related procedures. This policy is designed to be flexible and capable of supporting a wide range of advanced redundancy models found in some high availability systems. The design uses the extensibility in RSERPOOL pool load sharing policy. "Network Address Translation and Peer-to-Peer Applications (NATP2P)", Bryan Ford, 08-Apr-03, This document describes and recommends methods by which peer-to-peer (P2P) applications can operate efficiently in the presence of Network Address Translation (NAT). This document also provides recommendations for the design of network address translators, in order for them to support P2P applications effectively without compromising security or performance. This memo focuses on the interaction of P2P with NAT in the absence of any special proxy, gateway, or relaying protocols. While not intending to preclude the use of such protocols, the goal of this memo is to enable P2P applications to function automatically without specific knowledge of the type, location, or configuration of the NAT. "Lumas-A Language for Universal Message Abstraction and Specification", Peter Cordell, 08-Apr-03, A number of methods and tools are available for defining the format of messages used for signalling protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are readily available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary verbosity both in the definition and on the wire. "BINPIDF - External Object Extension to Presence Information Data Format", Mikko Lonnfors, Eva Leppanen, Hisham Khartabil, 08-May-03, This memo specifies a methodology whereby external content to a presence information document can be referenced in XML encoded presence information document (PIDF). The external content can be either transferred directly in the payload of SIP messages or indirectly as an HTTP reference. The external part might contain binary data such as images. "Guidelines for Mandating Automated Key Management", Steven Bellovin, 09-Apr-03, The question often arises of whether or not a given security system requires some form of automated key management, or whether manual keying would suffice. This memo proposes guidelines for making such decisions; the presumption is that automated key management is generally but not always needed; if manual keying is proposed, the burden of proof is on the proposer. "SIEVE Include Extension", Cyrus Daboo, 10-Apr-03, The SIEVE [SIEVE] 'include' extension permits users to include one SIEVE script inside another. This can make managing large scripts or multiple sets of scripts much easier, as well as supporting common 'libraries' of scripts. Users are able to include their own personal scripts or site-wide scripts provided by the local SIEVE implementation. "Network Throughput and Performance Calculations", Louis Breit, 10-Apr-03, This memo provides an overview and summary of the mathematical calculations and formulas which can be used to determine network throughput and performance. "ICAP Extensions", Martin Stecher, 10-Apr-03, The Internet Content Adaptation Protocol (ICAP) [1] provides simple, object-based content vectoring for HTTP services. User-defined header extensions are widely used by many ICAP client and server implementations. Some implementations have also introduced new ICAP methods. This document describes and defines a number of ICAP extensions to ensure ongoing interoperability between the implementations. "Procedures for Renumbering an IPv6 Network without a Flag Day", Fred Baker, 11-Apr-03, This document addresses the key procedural issues in renumbering an IPv6 network. In certain areas, it is necessarily incomplete; it points out those areas, however. It may be considered an update to RFC 2072. It presumes the use of IPv6 Autoconfiguration as described in RFC 2894. "A URN Namespace For The Liberty Alliance Project", Michael Mealling, 11-Apr-03, This document describes a URN namespace that will identify various objects within the Liberty Architecture for federated network identity. "Fast Handover Agent (FHA) for Fast Router Discovery in FMIPv6", Soohong Park, Seok Koh, 14-Apr-03, This document describes a new entity 'Fast Handover Agent (FHA)', which can be used for fast router discovery and configuration in FMIPv6. The FHA is deployed to provide the fast RA for Mobile Nodes entering a new IP network, without any modification of existing FMIPv6 procedures. "The CWC-AES Dual-Use Mode", Tadayoshi Kohno, 03-Jun-03, The CWC dual-use mode is a fast, parallelizable, provably secure and patent-free mode of operation for providing both encryption and message integrity. In this document we specify CWC for the AES block cipher, though its principles can easily be applied to other block ciphers. "Preconfigured Binding Management Keys for Mobile IPv6", Charles Perkins, 15-Apr-03, A mobile node and a correspondent node may preconfigure a Binding Management Key for authorizing Binding Updates. "An advanced Mail Transfer Protocol", Hadmut Danisch, 16-Apr-03, This memo suggests an advanced mail transfer protocol in order to find a modern, flexible, extensible, efficient, and robust successor of SMTP. The presented protocol uses a HTTP-ish syntax. It is designed to give the receiver of a message finer control over accepting or rejecting the message, and to allow negotiation of transport details. The memo is still in a very early state and intended to initiate a discussion, not to present a finished protocol. The protocol can be understood as a workbench for future mail extensions. "Ascertech's Billing and Accounting System Exchange (BASE) Protocol", Harald Dickel, 02-May-03, This document describes the Billing and Accounting System Exchange (BASE) protocol. BASE is an application level protocol for carrying billing information between distributed Billing Agents and a shared Billing Engine. "A Practice for Revoking Posting Rights to IETF mailing lists", Marshall T. Rose, 12-May-03, All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a 'denial-of-service' attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. "A Proposal for RSVPv2-NSLP", Lars Westberg, 17-Apr-03, The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the demand for technologies offering services with different levels of quality of service to their customers. This memo seeks to initiate a dialog about the design of a new version of RSVPv1, called RSVPv2, that meet the requirements formulated by IETF NSIS working group. It also outlines the motivation for using RSVP2 as 'next step in signaling'. The RSVPv2 framework uses the layer-split architecture separating signaling application and transport functions. This concept was adopted by NSIS WG and the two layers are called NSLP NSIS Signaling Layer Protocol (NSLP) and NSIS Transport Layer Protocol (NTLP). This draft provides design guidelines and specifications for the development of the RSVPv2 NSLP part. RSVP2-NSLP offers increased modularity and contains less mandatory objects compared to RSVPv1, which allow lightweight implementation and flexible application. The new protocol is extended with PHR and PDR objects that makes it possible to use the protocol in different part of multi-domain networks and use the protocol in DiffServ environment. "RSS 2.0", Mark Nottingham, 17-Apr-03, This specification documents version 2.0 of RSS, an XML-based format for syndicating Web content and metadata. "IPv6 Router Advertisement based DNS Autoconfiguration", Jae-Hoon Jeong, 18-Apr-03, This document specifies the steps a node takes in deciding how to autoconfigure its domain name per interface in IP version 6 and the address of recursive DNS server. The autoconfiguration process includes a node's creating a domain name for its global address, verifying the uniqueness of the name in the domain where it is placed and registering both the regular domain name and inverse domain name information of the node with DNS server automatically. Also, it autoconfigures the address of recursive DNS server for DNS name resolution. "Sieve -- 'copy' extension", Jutta Degener, 21-Apr-03, This document defines a new keyword parameter, ':copy', to be used with the sieve 'fileinto' and 'redirect' actions. The new parameter prevents cancellation of the implicit keep. "Sieve -- 'editheader' extension", Jutta Degener, 21-Apr-03, This document defines three new actions for the 'sieve' language that add, delete, and change e-mail header fields. "Sieve -- Sequential Execution of Multiple Scripts", Jutta Degener, Rand Wacker, 21-Apr-03, This document defines sieve behavior relevant when multiple scripts are executed sequentially on the same message. "The Nortel Networks Ethernet Layer 2 Virtual Private Service Protocol", Marc Holness, Michael Chen, Dinesh Mohan, 17-Jun-03, This draft specifies an Ethernet Layer 2 Virtual Private Service Protocol, using Ethernet addressing hierarchy and service separation, which enables Service Providers to deploy an Ethernet Network and offer scalable and manageable layer 2 Transparent LAN Services (L2TLS). The primary goal of this protocol is to eliminate the need of the Service Provider to manage customer address information and forwarding within its network. Another goal is to allow auto provisioning of VPN service instances within the Service Provider networks. This solution maintains customer benefits of simplicity of access to the VPN, allows efficient utilization of Service Provider network resources, and overcomes distance limitations of customer's LANs. "IPv6 Extensions for DNS Plug and Play", Soohong Park, Syam Madanapalli, 21-Apr-03, This document proposes automatic configuration of domain name (FQDN) for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as a part of IPv6 plug and play feature. 6DNAC allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAC function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAC does not require any changes to the existing DNS system. "Telephony Tunneling Protocol (TTP)", Michael Ross, 22-Apr-03, The purpose of this document is to propose a protocol called Telephony Tunneling Protocol (TTP) to tunnel one or more plain old telephone system (POTS) connections between two Internet hosts. The hosts may have one or more telephones connected directly to them or may receive calls from the local Public Switched Telephone Network (PSTN). The Internet hosts are connected via two or more TCP connections (one for control and each of the others for one channel of voice traffic). This document makes no specification for sending Signaling System 7 (SS7) or other PSTN control commands through the control connection, though such commands may be outlined in other documents. Comments are solicited and should be sent to the author, Michael Ross "Using Recursive Xcast Packets for Multicast Delivery", Ali Boudani, Bernard Cousin, 22-Apr-03, In this document, we propose a new multicast protocol called MXcast (Multiple Xcast Packets). This protocol uses a very simple method to deliver multicast packets without constructing multicast trees using the Xcast [1] and xcast+ [2] technique "OSPF Areas Considered Harmful", Mikkel Thorup, 23-Apr-03, We point out that forcing an area decomposition onto an IP backbone can easily have a detrimental effect on the routing and lead to a substantial increase of information to be flooded in connection with link-failures. "SIMPLE-XMPP Interworking", Daniel-Constantin Mierla, 23-Apr-03, This document describes the behavior for the logical entity known as the SIMPLE-XMPP Interworking Function (SIMPLE-XMPP IWF) that will allow the interworking between the SIMPLE (Session initiation protocol for Instant Messaging and Presence Leveraging Extensions) and XMPP (eXtensible Messaging and Presence Protocol - also known as Jabber protocol) protocols. "The Case for the 'A' Bit in the MPLS and IP PID", David Allan, 23-Apr-03, This memo describes the underlying rationale for inclusion of the LSR alert bit in the proposed MPLS payload ID. "Overview of the FEC-CV proposed extension to the Y.1711 protocol", David Allan, 23-Apr-03, This Internet Draft provides an overview of the FEC-CV probe proposed as an extension to the Y.1711 protocol. This is a private informational submission. Those interested in more detail are directed to the ITU-T recommendations and SG13/Q3 living lists. "RFC2547bis networks using internal BGP as PE-CE protocol", Pedro Marques, 23-Apr-03, This document defines protocol extensions and procedures for BGP PE- CE router iteration in RFC2547bis networks. These have the objective of making the usage of the RFC2547bis VPN transparent to the customer network, as far as routing information is concerned. "Experience with the BGP-4 Protocol", Danny McPherson, Keyur Patel, 24-Apr-03, The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. "Mentioning Intellectual Property Rights Considerations in Last Calls", Pekka Savola, 27-May-03, This memo describes an additional policy with last calls regarding Intellectual Property Rights (IPR) disclosures or other knowledge of IPR. The existence and the pointer to the IPR disclosures or an indication of non-existence of knowledge of such disclosures must be mentioned in all IETF last calls and should be mentioned in working group last calls. Additionally, all documents under the IETF change control for which a last call prior to the approval was not required and IPR disclosures are known, must now be either last-called or rejected. This memo updates RFC 2026 and RFC 2418. "EAP IKEv2 Method (EAP-IKEv2)", Hannes Tschofenig, Dirk Kroeselberg, 24-Apr-03, EAP-IKEv2 is an EAP method which reuses the cryptography and the payloads of IKEv2, creating a flexible EAP method that supports both symmetric and asymmetric authentication. Furthermore protection of legacy authentication mechanisms is supported. This EAP method offers the security benefits of IKEv2 without the goal of establishing IPsec security associations. "IPv6 Site Multihoming: Now What?", Pekka Savola, 25-Apr-03, ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices cause a significant increase the routing table size, change rates and instability, the tragedy of the commons by encouraging selfish routing practices, the exhaustion of the 16-bit AS number space, and may collapse the Internet interdomain routing architecture. As there has been a desire to avoid similar problems as seen with IPv4, the use of similar techniques to achieve site multihoming has been prevented operationally in IPv6. However, the long effort to proceed with other IPv6 multihoming mechanisms has produced lots of heat but little light. This memo tries to list available techniques, split the organizations to different types to separately examine their multihoming needs, to look at the immediate and short-term solutions for these organization types, and to list a few immediate action items on how to proceed with IPv6 site multihoming. "Security Algorithms for IKEv2", Paul Hoffman, 16-May-03, The IKEv2 protocol [IKEv2] relies on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IKEv2 systems cannot interoperate unless they are using the same algorithms. This document specifies an initial set of algorithms for registration with IANA, and specifies which are mandatory to implement. This document also specifies optional suites of algorithms and attributes that can be used to simplify the administration of IKEv2. "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)", John Drake, Dimitri Papadimitriou, 28-Apr-03, This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in the present document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. "RDMA Protocol Verbs Specification", Jeff Hilland, 28-Apr-03, This document describes an abstract interface to a RDMA enabled NIC (RNIC). This interface is implemented as a combination of the RNIC, its associated firmware, and host software. It provides access to the RNIC queuing and memory management resources, as well as the underlying networking layers. "Load Sharing in Stream Control Transmission Protocol", Ahmed Abd El Al, 29-Apr-03, Stream Control Transmission Protocol (SCTP) RFC2960 [1] specifications utilize the possible multiple paths between the sender and receiver for retransmission of lost data chunks and as a backup for the primary path, in case of primary path failure. Other than that, all the data chunks are being sent on the primary path chosen by the SCTP user during the association initiation. This memo describes an extension to SCTP that allows endpoints to use the multiple available paths for simultaneous data transmission. The extension maintains SCTP congestion control on each path, so as to ensure fair integration with other traffic in the network. "Network Management Requirements for MPLS MIBs", Wai Lai, Li-Jin Chung, 30-Apr-03, In this document, requirements for three MPLS-related MIBs (LDP-MIB, VPN-MIB, and BGP4-MIB) are presented for the support of specific network management needs for fault and performance management. "Technical Considerations for Spam Control Mechanisms", Dave Crocker, 01-Jul-03, Internet mail has operated as an open and unfettered channel between originator and recipient. This invites some abuses, called spam, such as burdening recipients with unwanted commercial email. Spam has become an extremely serious problem, is getting much worse and is proving difficult (or impossible) to eliminate. The most practical goal is to bring spam under control; it will require an on-going, adaptive effort, with stochastic rather than complete results. This note discusses available points of control in the Internet mail architecture, considerations in using any of those points, and opportunities for creating Internet standards to aid in spam control efforts. It offers guidance about likely trade-offs, benefits and limitations. "Textual Representation of IPv4 and IPv6 Addresses", Andrew Main, 02-May-03, Historically, the conventional textual representations of IPv4 and IPv6 addresses have been poorly specified. This document gives precise definitions of these conventions, together with advice for implementors. "CE-CE IPSec within an RFC-2547 Network", Jim Guichard, 02-May-03, This document describes a reference architecture that may be used to tightly integrate CE-CE [IPSec] encryption with the any-to-any connectivity model of [RFC2547]. Using this mechanism, a Service Provider is able to provide an IP VPN service with data encryption between customer edge routers, but without the need of direct routing protocol exchange, or IP-based tunnels such as provided by [GRE]. "Redundant Fault Tolerant Configurations", Srinivas Pitta, 05-May-03, The ability of the system to deliver its normal service in the presence of any unexpected errors and able to recover from the errors and restore to normal operation is called a fault tolerant system. Such systems whose behavior is predictable in nearly every possible situation are often in redundant fault tolerant configurations. This document defines the various redundant fault tolerant configurations that make these systems dependable systems or high availability systems. "LDAP: matching rules for facsimile telephone numbers", Norbert Klasen, 14-May-03, Based on changes to the 4th edition of X.500, this document updates the Lightweight Directory Access Protocol (LDAP). It defines an equality and a substrings matching rule for the 'Facsimile Telephone Number' syntax and updates the 'facsimileTelephoneNumber' attribute type to use them. "Encapsulating Security Payload for Link Layers (ESPLL)", Subrata Goswami, 05-May-03, The trend has been to use different encryption mechanism for different layers. Although it can be argued that multiple layers is good protection, such an approach is higly inefficient from the view performance and necessity. In some situations this kind separate encryption mechanism may afford the bytes 7 levels of encryption, for example : AES (from 802.11)+ 3DES (from IPSec) + 3DES (from TLS/SSL). Recently link layer encryption has become an important issue, specially in the context of wireless networks. Although this document does not attempt to solve this multiple layer encryption issue, it is an effort to that goal. Specifically, this document describes a way to use ESP in several link layer technologies. "LDAP Multi-master Replication Considered Harmful", Kurt Zeilenga, 01-Jul-03, Over the last few years there has been significant development of Lightweight Directory Access Protocol (LDAP) replication mechanisms supporting a multi-master service model. While multi-master replication may be useful in some situations, the deployment of multi-master replication alters the standard LDAP service model in a manner which can be harmful. Specifically, the LDAP service model properties of atomicity, consistency, isolation, and durability (ACID) would be lost. This memo discusses the LDAP service model, how multi-master replication alters the service model, and how this alteration is harmful to existing directory applications. "LDAP: Internationalized String Preparation", Kurt Zeilenga, 05-May-03, The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how string matching is to be performed. This lead to a number of usability and interoperability problems. This document defines string preparation algorithms for matching rules defined for use in LDAP. "Diameter Credit-control Application", Harri Hakala, 06-May-03, This document specifies a Diameter application that is used for real- time cost and credit-control between a service element and a credit- control server in a service environment. Diameter accounting messages using additional AVPs defined in the document are used to transfer service and credit-control information between the service element and the credit-control server. "Schema to Support Query Containment in LDAP Directories", Apurva Kumar, 06-May-03, Lightweight Directory Access Protocol (LDAP) directories are being used at the backend of many internet and intranet web applications. LDAP servers that cache entries which are returned as search results for recently evaluated search requests, can use the semantic information associated with these requests, to answer subsequent search requests which are contained in them. This document describes LDAP schema for representing the semantic information and for supporting query containment of LDAP queries. "Establishing Point to Multipoint MPLS TE LSPs", Rahul Aggarwal, 06-May-03, This document describes a solution for point to multipoint (P2MP) Traffic Engineering (TE). The objective is to optimize packet replication and minimize state and intelligence in the core of the network, while performing P2MP TE. The solution relies on RSVP-TE in the core of the network. It is based on setting up a P2MP LSP by merging P2P LSPs in the network. The setup of P2P LSPs is source intiated. Simple enhancements are made to RSVP-TE to facilitate the set up of a P2MP TE LSP. There is no need to run a multicast routing protocol in the network core. There can be various applications for P2MP TE LSPs such as multicast. Specification of how such applications will use a P2MP LSP is outside the scope of this document. "End-to-end Security for Firewall/NAT Traversal within the Session Initiation Protocol (SIP)", Klaus Umschaden, 06-May-03, This document describes an extension for the Session Initiation Protocol (SIP), which enables end-to-end security of the Session Description Protocol (SDP) together with firewall/Network Address Translation (NAT) traversal. This solution relies on Secure Multipurpose Internet Mail Extension (S/MIME) and the middlebox communications (MIDCOM) protocol. The user authorises a proxy server to encrypt the session description on behalf of the user. The proxy determines the capabilities of the receiving party and encrypts the SDP for a SIP proxy server in the receiving domain. Using MIDCOM, each proxy can dynamically control its firewall to open pinholes or request NAT bindings for the media flows. As long as each end-user may contact its trustworthy SIP proxy via a secure connection and authorise this proxy to encrypt the signalling data, the session information is secured end-to-end. "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", James Kempf, 07-May-03, When an IPv6 node receives a Router Advertisement, how does it know that the node which sent the advertisement is authorized to announce that it routes the prefix? When an IPv6 node receives a Neighbor Advertisement message, how does it know that the node sending the message is, in fact, authorized to claim the binding? The answer is, in the absence of a preconfigured IPsec security association among the nodes on the link and the routers, they don't. In this draft, a lightweight protocol is described for securing the signaling involved in IPv6 Neighbor Discovery. The protocol allows a node receiving a Router Advertisement or a Neighbor Advertisement to have the confidence that the message was authorized by the legitimate owner of the address or prefix being advertised without requiring a preconfigured IPsec security association. A certain degree of infrastructural support is required, but not any more than is currently common for public access IP networks. The protocol is based on some results in identity based cryptosystems that allow a publicly known identifier to function as a public key. "Careful Additional Review of Documents (CARD)by Senior IETF Reviewers (SIRS)", Brian Carpenter, Dave Crocker, 13-Jun-03, IETF specifications may not receive significant review, especially beyond a single working group, until they are submitted to the IESG. Hence, significant problems with a specification often are not detected until a problematic approach has been adopted and considerable effort has been spent developing and documenting this approach. Major changes to address problems identified late in the process take considerable effort and significantly delay a document that its authors believed to be ready for publication. The procedure described in this document is intended to solve, or palliate, a number of related problems that have been observed in the IETF process. The basic model is to create a team of Senior IETF Reviewers (SIRS), and have all documents receive a certain number of reviews by SIRs, prior to being submitted for publication. Review by SIRs at a very early stage is strongly encouraged. "Unique Local IPv6 Unicast Addresses", Robert Hinden, 02-Jul-03, This document defines an unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet given current routing technology. "Use of SRV records for POP3, POP3S, IMAP and IMAPS.", Gary Bajaj, 08-May-03, DNS records for the mail services POP3, POP3S, IMAP and IMAPS do not currently provide failover switching as do the DNS MX records for SMTP. This document looks at the issues involved and recommends a solution using SRV records. "RPSLng", Larry Blunk, Joao Luis Damas, Florent Parent, Andrei Robachevski, 08-May-03, This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. "Internet Application Protocol Comparator Registry", Chris Newman, 12-May-03, Many Internet application protocols include string-based lookup, searching, or sorting operations. However the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function and the repertoire of comparison functions can be extended in the future. "PPP Internet Protocol Control Protocol Extensions for Route Table Entries", Doug Kehn, 12-May-03, The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The PPP Internet Protocol Control Protocol (IPCP) [2] defines the NCP for establishing and configuring the Internet Protocol (IP) [3]. This document extends IPCP by defining the negotiation of IP route table entries. This extension provides added functionality but is optional and preserves compatibility. "The LDAP Assertion Control", Kurt Zeilenga, 12-May-03, This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control which allows a client to specify that a directory operation should only be processed if the assertion when applied to the target entry of the operation. It can be used to construct 'test and set' and 'test and clear' operations. "The LDAP entryUUID operational attribute", Kurt Zeilenga, 12-May-03, This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. "The NewReno Modification to TCP's Fast Recovery Algorithm", Sally Floyd, Tom Henderson, 12-May-03, RFC 2581 [RFC2581] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [RFC2018], 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. The NewReno mechanism described in 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]. "Mapping Network Addresseses into Domain Name Space", Andrew Main, 13-May-03, Several network protocols and applications need to perform a DNS lookup using a network address, rather than a host or service name, as (part of) the key. This document provides a technique to map network protocol addresses into domain names for the purposes of such applications. "Securing the first hop in PANA using IPsec", Mohan Parthasarathy, 13-May-03, The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. But it does not specify any mechanism for preventing service theft. This document discusses the details for establishing an IPsec security association for securing the link between PANA client and the enforcement point, which can be used to prevent service theft. "ISIS as the PE/CE Protocol in BGP/MPLS VPNs", Sheng Cheng, 13-May-03, IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [1]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [1]. "EPP parameters for .pl ccTLD", Tomek Zygmuntowicz, 13-May-03, This document is a proposed description of the cooperation protocol between NASK and its Partners. The proposal can be replaced with the new document or can be invalidated. The content of this proposal relates to the documents: , , , , RFC 3375 published by Internet Engineering Task Force. "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", Hee Jung, 25-Jun-03, This document addresses Fast Handover over HMIPv6 networks. A simple integration of FMIPv6 with HMIPv6 may induce unnecessary processing overhead for re-tunneling at the previous Access Router and inefficient usage of network bandwidth. This document describes the Fast Handover for HMIPv6 (F-HMIPv6), which is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the Mobile Nodes inform the MAP about its movement anticipation and thus the bi- directional tunnels for fast handover are established between MAP and NAR, not between PAR and NAR. The F-HMIPv6 scheme utilizes the existing FMIPv6 messages, without defining any new control messages. "Advertising Equal Cost Multi-Path (ECMP) routes in BGP", Manav Bhatia, 14-May-03, This document describes an extensible mechanism that will allow a BGP [BGP4] speaker to advertise equal cost multi-path (ECMP) routes for a destination to its peers without changing the semantics of the UPDATE message. A new BGP attribute is introduced that will be used to advertise the multiple next hops for the feasible and the un-feasible ECMP BGP routes to the remote peers. The mechanisms described in this document are applicable to all routers, both those with the ability to inject multiple routing entries in their forwarding table and those without (although the latter need not implement some extensions described in this document). "State Model for IP Interfaces", Syam Madanapalli, 16-Jun-03, This document specifies a generic flexible state model for IP Interfaces. This state model can be implemented for both IPv4 and IPv6 interfaces. "RDMA Transport for ONC RPC", Brent Callaghan, Thomas Talpey, 15-May-03, A protocol is described providing RDMA as a new transport for ONC RPC. The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. "NFS Direct Data Placement", Brent Callaghan, Thomas Talpey, 15-May-03, The RDMA transport for ONC RPC supports direct data placement for NFS data. Direct data placement not only reduces the amount of data that needs to be copied in an NFS call, but allows much of the data movement over the network to be implemented in RDMA hardware. This draft describes the use of direct data placement by means of server- initiated RDMA Writes into client-supplied buffers in a Write list for implementations of NFS versions 2, 3, and 4 over an RDMA transport. "NFSv4 RDMA and Session Extensions", Thomas Talpey, Spencer Shepler, 15-May-03, Extensions are proposed to NFS version 4 which enable it to support sessions, connection management, and operation atop RDMA-capable RPC. These extensions enable universal support for Exactly-once Semantics by NFSv4 servers, enhanced security, and multipathing and trunking of transport connections. These extensions provide identical benefit over both TCP and RDMA connection types. "Scalable mNAT-PT Solution", Soohong Park, 15-May-03, This document provides scalability extension to NAT-PT. The extension is based on the use of DNS-ALG and exchange of load metrics amongst a cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT. mNAT-PT is valuable in connecting large V6 domains to legacy V4 domain. "NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering", Cedric de Launois, Olivier Bonaventure, 15-May-03, More and more ISPs are multihomed and need to engineer their interdomain traffic. Unfortunately, both multihoming and traffic engineering contribute to the growth of the BGP routing tables. For IPv6, a better solution for multihoming and traffic engineering is required. This document proposes a host-centric IPv6 multihoming solution that relies on the utilization of a 'Name, Address and ROute System' (NAROS) server. A key advantage of using this server is that it allows a multihomed site to engineer its interdomain traffic without transmitting any BGP message. "Extensions to OSPF for Advertising Optional Router Capabilities", Acee Lindem, 27-Jun-03, It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information opaque LSA is proposed for this purpose. "Requirements and Use Cases for Stream Switching", Philippe Gentric, 16-May-03, Stream switching is a technique used to change the data rate of a media being streamed, typically for the purpose of adaptation to the effectively available bandwidth of the network. This memo lists the use cases and the requirements for stream switching. "Redemption Grace Period Mapping for the Extensible Provisioning Protocol", Scott Hollenbeck, 19-May-03, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to the Redemption Grace Period (RGP) policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for RGP processing. "IANA Considerations for PPP", Vernon Schryver, 19-May-03, The charter of the Point-to-Point Protocol Extensions (pppext) working group includes the responsibility to 'actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value.' In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be 'first come first served.' "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", Hisham Khartabil, 20-May-03, The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. "Functional Description of Event Notification Filtering", Hisham Khartabil, 20-May-03, The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. The format of the filter is outside the scope of this document. "Layer Two Tunneling Protocol (Version 3) Graceful Restart", Sharon Galtzur, Gonen Zilber, 20-May-03, This document describes a mechanism that helps to minimize the negative effects on L2TP traffic caused by L2TP Control Connection Endpoint (LCCE) control plane restart, specifically by the restart of its control protocol component, on LCCEs that are capable of preserving the L2TP forwarding component ( a.k.a. the L2TP data plane) across the restart. The mechanism described in this document is applicable to all LCCEs, both those with the ability to preserve Forwarding State during the control plane (CP) restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks", Gorry Fairhurst, Bernhard Collini-Nocker, 20-May-03, This document contains an alternative Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IP Datagrams directly over ISO MPEG-2 Transport Streams (TS) as TS private data. The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. "Fixed Content Storage (FCS) Application Programming Interface (API)", John Canessa, 21-May-03, During the past twelve months there has been interest in Fixed Content Storage servers. Vendors have been introducing offerings that use proprietary API calls. This is causing delay in acceptance. By using a set of standard API calls software developers, vendors and end-users would benefit. This document provides background on the need for an API. It defines a simple and reduced yet robust set of Application Programming Interface (API) calls to be supported by implementations of FCS servers. Store, query and retrieve operations are described in detail. The concept, description and format of a Global Unique Identifier (GUID) are provided. A GUID serves as a unique handle to each object stored by a FCS server. The list of the set of API calls is defined. A basic set of data structures and support functions is presented. "A SPEECHSC protocol for Media Resource Control", Saravanan Shanmugham, 22-May-03, This document describes a proposal for the SPEECHSC protocol and aims to meet the requirements specified in the SPEECHSC working group requirements document. It is based on the Media Resource Control Protocol (MRCP) developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks Inc. The SPEECHSC protocol will control media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers etc. over a network. This protocol depends on a session management protocol such as the Session Initiation Protocol (SIP) to establish a separate SPEECHSC control session between the client and the media server. It also depends on SIP to establish the media pipe and associated parameters between the media source or sink and the media server. Once this is done, the SPEECHSC protocol exchange can happen over the control session established above allowing the client to command and control the media processing resources that may exist on the media server. "OSPF TE LSA Extensions in Support of Vendor/Organization Specific Attributes", Udo Neustadter, 22-May-03, Type-length-value structures have made their way into the messages distributed opaquely by OSPF. This document specifies an interoperable method to add vendor specific extensions to existing message structures. "Ingress Filtering for Multihomed Networks", Fred Baker, Pekka Savola, 23-May-03, RFC 2827, BCP 38, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. However, it causes problems of its own. This document addresses the issues and proposes several possible solutions. This memo updates RFC 2827. "RObust Header Compression (ROHC): Context Replication for ROHC Profiles", Ghyslain Pelletier, 23-May-03, This document defines context replication, an alternative to the context initialization procedure found in ROHC (Robust Header Compression) [RFC-3095]. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure, and may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as for example short- lived TCP flows. "End-to-end, Implicit 'Link-Up' Notification", Spencer Dawkins, 26-May-03, The Performance Implications of Link Characteristics [PILC] working group is recommending an end-to-end implicit notification when an access link outage ends. This document codifies the 'Link Up Notification' for TCP. "BaseStream - A Simple Typed Stream Protocol", Frans Lundberg, 26-May-03, BaseStream is a simple light-weight binary protocol consisting of a sequence of typed and possibly named data elements. It can be used whenever sequences of bytes are handled, for example, as a base for a TCP protocol or a file format. An instance the BaseStream protocol has a corresponding XML representation that makes it possible to use existing XML software to view, edit, validate, and transform BaseStream data. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Jonathan Rosenberg, 26-May-03, This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. "A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Documents", Jonathan Rosenberg, 27-May-03, This specification defines a Session Initiation Protocol (SIP) event package for finding out about changes to documents managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to manipulate XML documents on a server which contain configuration information for application protocols. Multiple clients can potentially access the same document, in which case the other clients would like to be notified of a change in the document made by another. This event package allows a client to do that. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists", Jonathan Rosenberg, 27-May-03, This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating lists of presentities (also known as buddy lists or rosters). It does so by specifying an XML Schema that contains a list of presentities that a user is interested in watching. "OSPF Tunnel Adjacency", Sina Mirtorabi, Peter Psenak, 27-May-03, OSPF specification requires that intra-area paths are always preferred over Inter-area paths regardless of the path's cost. This document describes a solution that will remedy this limitation without introducing any significant change to the current specification. Further, this solution provides some other benefits such as automatic partition repair described in application section. "A Namespace For NFS Version 4", Robert Thurlow, 28-May-03, Recent work on Replication and Migration for NFSv4 has reminded us of a more fundamental problem: NFS currently lacks a coherent enterprise or global namespace. With changes in a minor revision of NFS Version 4, this can be addressed to make services like replication and migration of filesystems fully functional. "Ad Hoc IP Address Autoconfiguration", Jae-Hoon Jeong, 28-May-03, This document specifies the steps a node in ad hoc network takes in deciding how to autoconfigure its IPv4 or IPv6 address in network interface. Because the ad hoc IP address autoconfiguration in this document considers ad hoc network's partition and mergence, the address duplication that can be caused by ad hoc network's mergence can be resolved. "Signaling for QoS Measurement", Alban Couturier, 28-May-03, This document defines SQM (Signaling for QoS Measurement), an architecture for QoS measurements of IP flows along their paths. The goal of this architecture is to configure on demand several probes, and to collect and coordinate the results in a multi domain environment, in order to determine in real time the QoS experienced by a flow on several nodes of its path. A new signaling is used to install metering and reporting states in network nodes. A coordination of works related to NSIS, PSAMP and IPFIX could achieve the SQM specification. "User identification in a SIP/QSIG environment", John Elwell, 28-May-03, This document examines means of identifying or naming users of telephony services within an enterprise. Numeric names (numbers) are used in traditional Private Integrated Services Networks (PISNs) using QSIG as the network signalling protocol. They are also used for external communication, e.g., with a public Integrated Services Digital Network (ISDN). Names need not be numeric in Internet Protocol (IP) networks employing signalling protocols such as the Session Initiation Protocol (SIP). This document therefore looks at naming schemes that are appropriate within enterprise IP networks, in particular enterprise IP networks employing SIP as the signalling protocol. It also investigates naming schemes that are appropriate in a mixed QSIG/SIP enterprise network and the treatment of names at an interworking point. It details the use of names not only for selecting a user to participate in a call, but also as a means of identifying a user in a call to other users in that call. ENUM and private ENUM-like services are also examined. "Dynamic Mobile IP Key Update for cdma2000(R) Networks", Christopher Carroll, Frank Quick, 28-May-03, The Dynamic Mobile IP Key Update procedure is a secure and efficient mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data which is often referred to as 1xEV-DO). Because the Dynamic Mobile IP Key Update (DMU) procedure occurs at the IP layer directly between the MIP MN and RADIUS or DIAMETER AAA Server, DMU may be used to securely bootstrap the MN-AAA key (and other cryptographic keys) in MIP networks using any Radio Access Network technology. "Standardized Byte Order Mark (BOM)for plain text documents formats recognition", Andre Tremblay, 28-May-03, This document propose a way to standardize the Byte Order Mark (BOM) for plain text documents, involving few changes in the current protocoles and softwares, using already established protocoles. And, to include informations useful to process documents. "TCP/IP Compressed Packet Formats", Richard Price, Mark West, 29-May-03, This document proposes a set of compressed packet formats for the ROHC-TCP compression profile [ROHC-TCP]. The ROHC-TCP profile is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. "Device Discovery Protocol (DDP)", Rob Enns, Pedro Marques, Daemon Morrell, 29-May-03, The Device Discovery Protocol (DDP) allows network elements to discover adjacent devices without relying on consistent network layer configuration. "Requirements for Full-mesh Conference Model using Baseline Session Initiation Protocol", Victor Paulsamy, 29-May-03, This memo enumerates requirements to realize full-mesh multiparty conferencing using baseline Session Initiation Protocol. Primary requirement is to advertise conference members’ addresses to new participants by concatenating multiple SDP session descriptions together. This particular requirement can solve several well-known problems, including disjoint meshes and race conditions, that are lingering in full-mesh conferencing for a while now. "Architecture of Mobile SCTP for IP Mobility Support", Seok Koh, 18-Jun-03, This document discusses the architecture of mobile SCTP (mSCTP) for IP mobility support. The SCTP is the third transport layer protocol next to TCP/UDP. It can also be used for IP mobility from the multi- homing features. The SCTP with the ADDIP extension (or mSCTP) would provide seamless or soft handover for the mobile host without support of routers or agents in the networks. For location management, the mSCTP could be used along with Mobile IP, Session Initiation Protocol or Reliable Server Pooling. "NFS version 4 MIB for Server Implementations", Spencer Shepler, 29-May-03, Insert your abstract here for the document. Refer to other Internet Drafts for examples of what this is supposed to contain and length. It usually is about two or three paragraphs long. "NFS version 4 Directory Notifications", Spencer Shepler, 29-May-03, NFSv4 [RFC3530] contains within it a mechanism for the delegation of file data to a client. The intent of this feature is to reduce the necessary interaction between a client and server such that overall performance is improved. The same type of mechanism does not exist for directory contents and to determine validity of cached directory contents an NFSv4 client is left with polling the server to determine if updates have occurred. The proposal described here is for an NFSv4 minor version that would allow a client to register interest in a directory and to receive a callback RPC upon update of that directory. This type of interaction would reduce or eliminate the polling that occurs between client and server and improve scalability of the server's resources along with improved performance for the client's directory content caching. "Router Advertisement Link Identification for Mobile IPv6 Movement Detection", Brett Pentland, 30-May-03, This document defines a mechanism by which Access Routers on a link may automatically assign a consistent identifier to this link to aid in Movement Detection. This assists Movement Detection by allowing a Mobile Node to rapidly determine whether it has moved to a new link upon reception of a Router Advertisement containing this identifier. "RSVP Domain of Interpretation for ISAKMP", Hannes Tschofenig, Henning Schulzrinne, 30-May-03, RSVP does not provide dynamic key management for the RSVP Integrity object. It is difficult to provide security for RSVP based on standard security protocols. This draft proposes the usage of the ISAKMP protocol with a new Domain of Interpretation (DoI) and allows to establish the necessary security parameters for the RSVP Integrity object. The Integrity object protects RSVP signaling messages at the application layer and uses this DoI to dynamically establish the necessary security associations. This document also addresses the NSIS NTLP work and protocol design implications. "Considerations for DNS Resource Records", Eric Hall, 01-Jul-03, This document discusses some common design considerations for DNS resource records and data models. "A Method and Protocol for Mapping User and Group names from Multiple Domains to Internal Security Identifiers", Nicolas Williams, 01-Jul-03, This document presents a model for mapping the domain-qualified user and group names used in the Network File System version 4's Access Control List (ACL) entries (ACEs) to internal identifiers such as POSIX UIDs and GIDs, as well as reverse mappings as well as a protocol for effecting such mappings in a consistent way across a server cluster, site, or entire domain. The main goals of this model and protocol are to allow the use of user and group names from multiple domains to be used in POSIX environments as well as enabling multi-protocol fileserver implementations which must support the use of a variety of user and group identifiers. "Preserving MIPv6 communications when the HoA becomes unreachable", Marcelo Bagnulo, 02-Jun-03, This note proposes a modification to the MIPv6 specification in order to allow the preservation of established communications when the path between the MN and the CN through the HoA becomes unavailable. The proposed modification essentially consists on allowing the extension of BCE lifetime upon the reception of ICMP Destination Unreachable message as reply to a Binding Refresh Request (BRR) message. "Advance Duplicate Address Detection", Youn-Hee Han, 03-Jun-03, This document proposes to automatically allocate a globally unique care-of IPv6 addresses (CoA) for the use of mobile nodes that want to be fast handovered. Each access router maintains a 'CoA Pool' of which each address is in advance generated and tested for its uniqueness by the access router. Also, the access router acts as 'Passive Proxy' for the stored addresses in order not to affect the destination cache and neighbor cache of its neighbor and not to disturb the normal CoA configuration procedure of the nodes who do not obey this draft. As soon as a mobile node, which obeys this draft, gains connectivity on a new link, it inquires one of CoAs stored by its access router. After successfully acquiring the one, the mobile node assigns it on the interface which attaches to the new link, without the normal DAD. Consequently, the proposed scheme can completely take off the DAD procedure/time from L3 handover procedure/latency "Auto Summarization in RIPv2", S Karthikeyan, S Srivastava, 03-Jun-03, This document describes an extensible mechanism that allows a RIPv2 [RIP2] speaker to advertise summarized routes to its peers without changing the format of the RESPONSE message. Summarized routes are carried in RESPONSE message like normal RIPv2 routes. Summarized routes are treated as normal routes on the receiving side. No extra provisions are required to discriminate between summarized and normal routes. The mechanisms described in this document is OPTIONAL and is applicable to all RIPv2 speaking routers, with some modifications in the routing information base and output processing for storing and advertising summary routes. This mechanism cannot be applied to RIPv1 [RIP1]. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 03-Jun-03, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. "Java(tm) Management Extensions Protocol", Ward Harold, 04-Jun-03, This document describes a protocol, composed of a set of BEEP profiles [9], that provides access to the attributes, operations, and notifications supported by the MBeans registered with a JMX Agent. "Enhancements to Asserted Identity to Enable Called Party Name Delivery using SIP", V Venkataramanan, 04-Jun-03, This document describes the expected business telephony requirements for delivering called party name towards SIP entities. A couple of mechanisms exist to deliver calling name and number to the called party. None exist for exposing the called party name or preferred identity to the calling party. This draft proposes a mechanism to provide this capability. "Extensions to IS-IS for Advertising Optional Router Capabilities", Acee Lindem, 05-Jun-03, It is useful for routers in an IS-IS domain to know of the capabilities of their neighbors, and/or of other routers in the domain. This draft proposes extensions to IS-IS for advertising optional router capabilities. In particular it defines an optional Router Capability TLV for IS-IS. "Implementation of CASP NTLP", Maarten Buchli, 05-Jun-03, This document describes the implementation of a signaling protocol based on the two protocol layer concept of NSIS. The implementation of the transport layer is based on the CASP proposal and is discussed in this document. The design of a client layer for QoS signaling is detailed in a separate document. "LDAP: Additional Matching Rules", Kurt Zeilenga, 06-Jun-03, This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. "Symmetric NAT Traversal using STUN", Yutaka Takeda, 06-Jun-03, It is generally known that the binding acquisition for symmetric NATs with STUN (Simple Traversal of UDP through NATs) protocol will not yield a usable address for traversing symmetric NAT. The use of symmetric RTP allows you to accompolish symmetric NAT traversal only in situations where the other end is open to the Internet, or has a full-cone or a restricted-cone NAT. This document proposes an analytical method for symmetric NATs to obtain more detailed characteristics of the symmetric NAT using STUN, and describes how we can establish a peer-to-peer UDP connection even in situations where NATs (including symmetric NATs) are present at both ends. "Network Security Requirements for Devices Implementing Internet Protocol", George Jones, 09-Jun-03, This document defines a list of security requirements for devices that implement the Internet Protocol (IP). These requirements apply to devices that makeup the network core infrastructure (such as routers and switches) as well other devices that implement IP (e.g., cable modems, personal firewalls,hosts). A framework is defined for specifying 'profiles', which are collections of devices applicable to certain classes of devices. The goal is to provide consumers of network equipment a clear, concise way of communicating their security requirements to vendors of such equipment. Please send any COMMENTS TO: 'opsec-comment@ops.ietf.org'. ALSO SEE 'http:// www.port111.com/opsec/opsec-meta.txt'. "Specification of the Continuous Media Markup Language (CMML), Version 1.0", Silvia Pfeiffer, Craig Parker, 09-Jun-03, This specification defines the Continuous Media Markup Language (CMML), version 1.0, an XML-based [1] markup language for time-continuous data. It is a sister document to the specification of the ANNODEX(TM) [12] annotation and indexing format for time-continuous data. The CMML is an authoring language for annotating, indexing and hyperlinking time-continuous data in the ANNODEX(TM) [12] format. Its tags provide for the creation of structured and unstructured annotations as well as hyperlinks and addressable named anchor points for fragments of time-continuous data. The tag names in use in CMML are similar to the ones in XHTML [3]. At this point in time, the right to produce derivative works is not granted to the IETF as the authors are uncertain about the necessity to create a working group. The specification is not encumbered by patents. The ANNODEX(TM) format is protected by a trademark to prevent the use of the term 'annodex' for any related but non-conformant and therefore non-interoperable technology. "Multicast Listener Discovery Authentication protocol (MLDA)", Tsunemasa Hayashi, 09-Jun-03, This memo documents the Multicast Listener Discovery Authentication protocol (MLDA). MLDA provides not only the functionality of multicast listener discovery between hosts and their first hop routers as MLD does, but also user authentication and accounting functionalities. MLDA is designed to be used in a controlled or managed IPv6 multicast environment. It provides with a viable alternative to MLD in IP multicast networks when authentication and accounting are required. The user authentication information in MLDA can enable a provider to control the distribution of the multicast traffic as well as collecting real time user accounting information. MLDA also use same ICMPv6 [ICMPv6] (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types as same as that of MLD. "Deployment of inter-operable and cost-effective monitoring infrastructure in ISP networks", Supratik Bhattacharyya, 09-Jun-03, This document identifies issues and concerns in monitoring ISP networks. It outlines the components of a monitoring infrastructure designed to support ISP requirements. It discusses deployment and inter-operability issues. Related IETF working groups are identified. The goal of this document is to open a discussion on whether there should be a BOF addressing this issue at the next IETF (Vienna, July 2003). "Teredo: Tunneling IPv6 over UDP through NATs", Christian Huitema, 09-Jun-03, We propose here a service that enables nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of 'Teredo servers' and 'Teredo relays'; the Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the 'native' IPv6 Internet. "Considerations for Mobility Support in NAT-PT", Myung-Ki Shin, Jon Lee, 09-Jun-03, The document specifies considerations for mobility support in NAT- PT (RFC-2766) [1]. "Specification of the ANNODEX(TM) annotation format for time-continuous bitstreams, Version 1.0", Silvia Pfeiffer, Craig Parker, 09-Jun-03, This specification defines a file format for annotating and indexing time-continuous bitstreams for the World Wide Web. The format has been named ANNODEX(TM) for annotating and indexing. The ANNODEX(TM) format enables the specification of named anchor points in time-continuous bitstreams together with textual annotations and hyperlinks in URI [4] format. These anchor points are merged time-synchronously with the time-continuous bitstreams on authoring a file in ANNODEX(TM) format. The ultimate aim of the ANNODEX(TM) format is to enable an integration of time-continous bitstreams into the browsing and searching functionality of the World Wide Web. At this point in time, the right to produce derivative works is not granted to the IETF as the authors are uncertain about the necessity to create a working group. The specification is not encumbered by patents. The ANNODEX(TM) format is protected by a trademark to prevent the use of the term 'annodex' for any related but non-conformant and therefore non-interoperable technology. "IMPP Working Group History and De Facto Charter", Mark Day, Derek Atkins, 09-Jun-03, This is a 'de facto IMPP charter' to accompany the IMPP submissions to the IESG. Such an arrangement is not ordinarily part of the IETF process, but appears to be the most effective means of providing necessary context to the IESG as it considers the IMPP documents. The first part of this document describes the circumstances that have led to this unusual de facto charter. The second part describes the IMPP charter as it has been understood by the current chairs. "Alternative Decision Making Processes for Consensus-blocked Decisions in the IETF", Ted Hardie, 10-Jun-03, This document proposes alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot come to consensus on the decision itself. This document describes alternative mechanisms which can be used to come to a decision in those cases. "A proposal describing categories of IETF documents: unbaked, baking, baked, eaten, and boiled", Ted Hardie, 10-Jun-03, Over time, the document series associated with the IETF has grown and changed. One such change is the increase in the use of secondary markers to identify when documents fit specific categories and, especially, when they are or are not the product of specific IETF processes. The author believes that these secondary markers have largely failed but that the distinctions they were meant to draw remain valuable. A new set of category labels is proposed to re-emphasize these distinctions. The formal categories proposed are Internet Note, Candidate Specification, Proposed IETF Standard, Confirmed IETF Standard, and External Internet Engineering Document. These may be informally understood as ideas which are unbaked, baking, baked, eaten, and boiled. "Observations on Proposing Protocol Enhancements that Address Stated Requirements but also go Further by Meeting more General Needs", Adrian Farrel, 11-Jun-03, Procedures in place and currently being developed within the IETF encourage the development and agreement of clear requirements before the new protocols or protocol extensions are accepted as work items. This does not preclude nor prohibit individuals from engaging in such protocol work outside of the IETF, but it acknowledges that acceptance of the work may be subject to proving the requirements through a requirements document or through deployment and usage experience. That work within the IETF on a requirements document may change the underlying assumptions made by protocol developers and thereby render their work obsolete or risible is a risk taken by all who spend their time enhancing the set of available protocols without first agreeing the requirements. At the same time, some problem statements or requirement documents are very narrowly scoped to address a very specific need. There is a risk that the development of a solution to such a precise problem may be non-extensible and may make the protocol unusable in a wider context. This document examines the need to avoid tying new protocol developments too tightly to the problem statement or requirement documents. It uses an example from the ITU ASON requirements for signaling protocols within optical networks to illustrate how adhering to the requirements statement too zealously may unnecessarily restrict the applicability of the protocol in a wider context. "Carry the ifIndex Number In Certain ICMP and ICMPv6 Messages", Enke Chen, Naiming Shen, 11-Jun-03, To facilitate network debugging we propose that the ifIndex number be carried in the ICMP/ICMPv6 'Time Exceeded Message' and 'Destination Unreachable Message (port unreachable)'' "Japanese characters in Internationalized Domain Name label", Yoshiro Yoneya, Yasuhiro Morishita, 11-Jun-03, Internationalized Domain Name (IDN) makes expression of domain name rich. The demand for such enrichment is to use native language characters in a domain name. IDN itself has no language dependency as a protocol, but to utilize IDN in the real world, language and/or regional aspects should be taken into account. This document explains a guideline to any DNS zone administrator who accepts Japanese as an IDN label. "Avoid BGP Best Path Transition from One External to Another", Enke Chen, Srihari Sangli, 11-Jun-03, In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) "Motivation for Network Controlled Handoffs using IP mobility between heterogeneous Wireless Access Networks", Eric Njedjou, 11-Jun-03, In the near future, multi-interfaces Mobile Nodes will be used for connecting to the Internet by way of a multitude of Radio Access Networks including 802.11 based WLANs, GPRS, CDMA2000 and 3G based cellular networks. Ensuring the non-disrupted flow of real-time applications data, as well as adhering to subscribed service profiles while the Mobile Node moves between Access Networks of different technologies, is an issue that needs to be addressed. It is assumed that a unified and external IP core network is used to support such a multitude of Access Networks. This will probably be the case for a mobile network operator intending to benefit its subscribers with its own hot-spots broadband internet access. Consequently, the need arises to define managed handoff mechanisms between heterogeneous attachment networks, while providing service continuity to the Mobile Node. As such, information necessary for the Mobile Node to performing a judicious handoff across Wireless Access Networks, will have to be gathered from the involved Access Networks, transferred across the IP network that interconnects them, to the operators home network. This document discusses the desirability of a network controlled handoff process for optimizing inter-Access Network Mobile Node mobility. The approach presented provides the means for the operator home network to achieve the best possible selection of the Mobile Node target Access Network for handoff, on the basis of information gathered on the most relevant nodes. It introduces a new function located in the operator network and referred to as a Mobility Manager. It also introduces the concepts for implementing such a handoff process to make it compatible with Mobile IPv6. Other documents will be needed to specify the protocol structures that are intended for handling the handoff process hereafter described. "BGP-4 Multiprotocol Next Hop Attribute", Francois Le Faucheur, 11-Jun-03, This document specifies a new BGP attribute, called the BGP-4 Multiprotocol Next Hop (MP_NEXT_HOP), which can optionally be used in conjunction with the MP_REACH_NLRI defined in [MP-BGP] (or the NLRI field defined in BGP-4) to advertise next hop information associated with a different Network Layer protocol to the one associated with the NLRI. This is desirable or required in a number of environments, but is not currently possible with [MP-BGP]. In addition, the MP_NEXT_HOP provides the generic capability to advertise information (set of TLVs) associated with the next hop. Finally, provision is made for a future potential extension to allow advertisement of multiple next hops. "Implementing Bridged Line Appearances Using Session Initiation Protocol (SIP)", Anand Kumar, V Venkataramanan, 12-Jun-03, This document describes a proposal for implementing Bridged Line Appearance for SIP User Agents "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", Jae-Hoon Jeong, 12-Jun-03, This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router provides the prefix of its care-of- address for its mobile nodes by playing the role of ND-proxy. Through binding updates associated with the network prefix of an access network, the mobile nodes can perform route optimization. "Framework for Deploying IP Multicast in IPv6", Leonard Giuliano, 02-Jul-03, This document describes an architectural framework for deploying interdomain multicast for IPv6 with simplicity, scalability, efficiency and security as the primary goals, applying the lessons learned from deploying IPv4 multicast. In order to achieve this objective, the deprecation of network-based source discovery, and therefore Any Source Multicast, is proposed. Source-Specific Multicast is proposed as the service model supported for deploying interdomain IPv6 multicast. The architectural components responsible for providing source discovery are also discussed. "Real-time Certificate Status Facility for CMS - (RTCS)", Peter Gutmann, 12-Jun-03, This document describes how the Cryptographic Message Syntax may be used for communicating certificate status information in a manner suitable for use with CMS data and CMS-related messaging mechanisms such as S/MIME. "A Network Service Layer Protocol for QoS signaling", Maarten Buchli, 12-Jun-03, The Next Steps In Signaling (NSIS) working group within the IETF is currently in the process of defining a signaling protocol. Consensus was reached to split the protocol into two layers; a general-purpose transport layer and a client layer that is application specific. The subject of this document is the specification of a client layer that can be used to request Quality of Service (QoS) to a network. "Cohabitation of the Nicname/Whois Protocol with the CRISP Protocol", A Newton, Leslie Daigle, 12-Jun-03, This document describes a method to allow an Internet registry operate both a nicname/whois service side-by-side with a CRISP service in a coherent and well understood manner. This document does not attempt to alter the nicname/whois protocol to meet this goal, nor does it attempt to make CRISP backwards-compatible with current nicname/whois deployments. "Authenticated Mail Transfer Protocol", Brice Crouzet, 12-Jun-03, Authenticated Mail Transfer Protocol is a second version of Simple Mail Transfer Protocol. Authenticated Mail Transfer Protocol (AMTP) improves Simple Mail Transfer Protocol (SMTP) and modifies the protocol in order to protect email against anonymous mails. The improvements included in Authenticated Mail Transfer Protocol will be helpful for the Internet community. The purpose of this document is to describe the different states of Authenticated Mail Transfer Protocol to the Internet community. There are five states: => Identified: It is used to identify the user to the server. => Email: It is used to send an email. => Logout: It is used to release any resources in the server when the user closes the connection. => Information: It is used to inform the recipient’s server that an email is waiting to be retrieved on the sender’s server. => Retrieved: It is used to instruct the recipient’s server to retrieve the email from the sender’s server. "NAT-PT Security Considerations", Satomi Okazaki, Anand Desai, 12-Jun-03, NAT-PT (RFC2766) is an address translation mechanism designed to facilitate communications between IPv6-only and IPv4-only nodes. This mechanism was designed to be used when tunneling transition mechanisms cannot be used. This document is intended to be a compilation of known security issues related to NAT-PT and includes a few new ones. These issues are discussed in some detail, and suggestions on how to deal with them are included in this document. "WHOIS Protocol Specification", Leslie Daigle, 12-Jun-03, This document updates the specification of the WHOIS protocol, thereby obsoleting RFC954 [1]. The update is intended to remove the material from RFC954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC954. "History of the IEEE 802/IETF Relationship", Les Bell, Dan Romascanu, Bernard Aboba, 13-Jun-03, Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and AAA applications. This document describes the history of that cooperation, and the policies and procedures that have developed in order to coordinate between the two organizations. "TFTP Restart and Session Option Definitions", Michael Johnston, 13-Jun-03, This document describes a mechanism that can be used by TFTP [1] and multicast TFTP (MTFTP) clients to restart aborted image downloads. "TFTP Streaming Definition", Michael Johnston, 13-Jun-03, This document describes a mechanism that can be used by TFTP clients and servers to improve throughput. This is accomplished by having the receiver collect a group (stream) of DATA packets and sending one ACK packet for the received DATA packets. "Design for a Routing Bridge", Radia Perlman, Aidan Williams, 13-Jun-03, This design provides the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. This capability is often provided today with bridges. Bridges have the advantage of being plug-and-play. However, they have disadvantages: routing is confined to a spanning tree, the header on which the spanning tree forwards has no hop count, spanning tree forwarding in the presence of loops spawns exponential copies of packets, nodes can have only a single point of attachment, and the spanning tree, in order to avoid temporary loops, is slow to start forwarding on new ports. The design in this paper avoids those disadvantages of bridges. The basic design is layer 3-independent, and is a design for bridging with a shortest-path routing algorithm (instead of spanning tree paths), and with more robust forwarding. Then the design is extended to provide IP-specific optimizations. "CAP (Calendar Access Protocol) sorting extension", Doug Royer, 16-Jun-03, Small devices may not have sufficient memory to store and then sort query results from a CAP server. This memo suggests an expendable CAP CAPABILITY extension called 'CAP-SORT' and a new parameters 'SORT' and 'LOCALE'. This memo specifies an optional minimum sort order and and locale sort extension. These extensions will only effect CUA's that have specifically requested these extensions be used in the session or for specific queries. The reader should be familiar with the CAP protocol prior to reading this memo. "TFTP Directory Op-Code Definition", Michael Johnston, 16-Jun-03, This document defines a new TFTP op-code, DATA packet format and option definition that can be used to get a list of files residing in the current logical directory of a TFTP server "TFTP Multicast Definition", Michael Johnston, 16-Jun-03, This document defines a backwards compatible multicast extension to TFTP (multicast TFTP or MTFTP, for short). MTFTP is a way for a server to download one image to multiple clients at the same time, potentially reducing the network load and overall download time. "Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating", Michael StJohns, 16-Jun-03, This document describes an extension or revision to the DNS NOTIFY mechanism which would allow a child zone to securely notify a parent zone of the need to update records that appear in the parent zone, but are related to records in the child zone. At this time, the two resource record types are the NS or Name Server record, and the DS or Delegation Signer record. "CAP notification of upcoming VEVENTs, VTODOs or any changes", Doug Royer, 16-Jun-03, This memo describes a method used to ask for and receive notifications. These notifications will be the direct result of a stored VALARM and the notifications or changes to components or the store and are represented in iCalendar format. This is an extensions to CAP. This memo includes a new CAP command types of 'REQUEST-NOTIFY', 'NOTIFICATION', and 'CANCEL-NOTIFY', a new property of 'OBSERVER', a new component 'NOTIFICATION', CAP capabilities of 'CAN-NOTIFY', 'NOTIFY-UPDATES', and 'ALLOW-NOTIFY-BOT'. A 'REQUEST-NOTIFY' command is a request to add an observer to an component in the 'TARGET' calendar. In addition the 'REQUEST-NOTIFY' command can alert the CUA of changes to specific components or in the calendar or calendar store. Everything is subject to VCAR restrictions. These are asynchronous notifications must be advertised by the CS and requested by the CUA. This memo discusses how to transport them using CAP. In addition if the CS and CUA support the 'NOTIFY-UPDATES' capability, then the CS will send 'NOTIFICATION' components to the CUA describing the UIDs or TARGETS that have changed since the currently authenticated CU was last connected allowing for easier synchronization. "IMAP-PROXY service for mobile clients to do submitting and forwarding", Doug Royer, 16-Jun-03, This memo describes a method that allows mobile clients to use the IMAP protocol and submit messages to a IMAP-PROXY service that understands [E]SMTP and IMAP. "Requirements for the Initial Release of a Directory Schema Listing Service", Chris Apple, 16-Jun-03, 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, 16-Jun-03, This memo specifies a file name syntax for use by the primary listing repository operator of the directory schema listing service. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", Vesa Torvinen, Jari Arkko, 16-Jun-03, HTTP Digest is known to be vulnerable to man-in-the-middle attacks, even when run inside TLS, if the same passwords are used for authentication in some other context without TLS. This is a general problem that affects not just HTTP digest but also other IETF protocols. However, for a class of strong algorithms the attack is avoidable. This document defines version 2 of the HTTP Digest AKA algorithm. Unlike previous versions of HTTP Digest such as MD5 or AKAv1, this algorithm is immune to the man-in-the-middle attack. "The AES-XCBC-PRF-128 algorithm for IKE", Paul Hoffman, 16-Jun-03, Some implementations of IPsec may want to use a pseudo-random function derived from AES. This document describes such an algorithm, called AES-XCBC-PRF-128. "Common Misbehavior against DNS Queries for IPv6 Addresses", Yasuhiro Morishita, Tatsuya Jinmei, 17-Jun-03, There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication which should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of the known cases and discusses the effect. "TFTP Big Block Number Option Definition", Michael Johnston, 17-Jun-03, This document describes a mechanism that can be used by TFTP and multicast TFTP (MTFTP) clients and servers to reliably transfer very large files without embedding additional alignment information into the data stream and without experiencing dropped connections when the Block Number field in the DATA/ACK packets rolls over to zero. "Bridge-like Neighbor Discovery Proxies (ND Proxy)", Dave Thaler, Mohit Talwar, 17-Jun-03, Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. "Extensions to OSPF Version 2 to support a Generalized Virtual Router Architecture", Robert May, 17-Jun-03, This document provides a generalized Virtual Router (VR) architecture and specifies the required extensions for [OSPFv2] to adapt the protocol to this architecture, such that separate 'instances' of OSPF can be used for different Service Provider (SP) customers connected to different PE to CE links of a single PE box. This architecture accommodates the deployment of layer 3 IP VPNs to facilitate services such as Intranet connectivity, and allows the consolidation of multiple Service Provider (SP) customers onto a single Provider Edge (PE) device, while enforcing all necessary security between different customer data. "Kerberos Clock Synchronization", Joel Weber, 23-Jun-03, This document discusses the security vulnerabilities that can exist in the Kerberos protocol and related protocols when clock synchronization is insecure, alternative methods that can be used to reduce or eliminate dependency on secure clock synchronization, and sanity checks which can be used when setting the system clock using an insecure time source as a reference in order to remove security vulnerabilities. "Scenarios for Introducing IPv6 into ISP Networks", Mikael Lind, 17-Jun-03, This document describes different scenarios for the introduction of IPv6 in an IPv4 ISP network. The goal is the addition of a native IPv6 service to the already existing IPv4 service without interruption of the IPv4 service. During the IPv6 introduction the network can go through 4 different stages including the initial IPv4 only stage. To move between the stages there will be some form of transition that can be defined in different transition scenarios. "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", Gregory Vaudreuil, 17-Jun-03, This memo defines two extensions to the SMTP service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called 'BDAT', for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 3030. "The Flat Multicast Key Exchange protocol", Laurence Duquerroy, Sebastien Josset, 17-Jun-03, This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange). Its objective is to manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These members can be identified for instance by a multicast IP address, a virtual LAN identifier, or a generic group label. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols which wish to secure group communications. For the time being, the considered Data Security protocol is a multicast version of the IPSEC ESP protocol, but other Data Security protocols could be envisaged. The FMKE protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key Encryption Keys). The FMKE protocol is optimized for very large groups with direct connections such as satellite systems, or wireless systems such as WIFI. "IPv6-IPv4 Translators in 3GPP Networks", Karim El Malki, 17-Jun-03, There have been discussions on the v6ops mailing list and at IETF meetings regarding the suitability of translators (e.g. NAT-PT) as mechanisms for IPv4 to IPv6 transition. It has often been stated that NAT-PT is not a mechanism to be recommended in general to solve the IPv6-IPv4 transition problem and some modifications to NAT-PT have been proposed. However there have also been discussions regarding special scenarios where some form of translators could be deployed if their use is documented appropriately. The aim of this draft is to document the rationale for using translators in 3GPP networks, in particular for IPv6-only IMS (IP Multimedia Subsystem) and to describe possible solutions to the problem and the interactions with SIP. "End-Host Mobility and Multi-Homing with Host Identity Protocol", Pekka Nikander, 17-Jun-03, This document specifies end-host mobility and multi-homing mechanisms for the Host Identity Protocol. "IPv4 Network Attachment Detection", Bernard Aboba, 18-Jun-03, This specification attempts to synthesize experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link- Local addresses. Given this experience, this document suggests optimizations for IPv4 network attachment detection as well as heuristics for determining when assignment of an IPv4 Link-Local address is appropriate. "Message-Submission SRV Resource Record", Eric Hall, John Klensin, 18-Jun-03, This document specifies the use of SRV resource records for locating the message-submission servers associated with a known mail domain. "NSIS NAT/FW NSLP: Problem Statement and Framework", Marcus Brunner, 18-Jun-03, This memo presents the problems for using the Next Steps in Signaling base protocol for firewall/NAT traversal commonly refered to middlebox traversal "P2P CHAT - A Peer-to-Peer Chat Protocol", Frank Strauss, Sherrie Schmidt, 30-Jun-03, This memo presents a protocol for a peer-to-peer based chat system. Messages can be cryptographically signed and encrypted allowing authentic and closed group communication. This work is the output of a practical course on distributed systems at the Technical University of Braunschweig. It is experimental work that is not intended to go to the IETF standards track. "Requirements for Mobile Multicast Clients", Greg Daley, Gopi Kurup, 18-Jun-03, This document describes the existing systems available for mobile devices to receive multicast data streams. It provides a case for common handling of Network Attachment Detection for moving multicast clients independent of global mobility signalling. "Switched ATM L2VPN", Christopher Metz, 18-Jun-03, Many providers operate ATM networks that support a suite of network services. These networks employ ATM signaling and routing protocols to expedite connection setup and recovery. Over time these providers will migrate all or portions of their ATM infrastructure and services to an IP/MPLS-based Packet Switched Network (PSN) thus leading to the creation of ATM L2VPNs. This document describes a solution that supports dynamic signaling and routing of point-to-point switched ATM connections (i.e. VP or VC) across an IP/MPLS network. It is based on the L2VPN (VPWS) architecture which employs an {attachment circuit, PE, pseudo-wire, PE, attachment circuit} tuple to define a distinct point- to-point L2 connection between two end-points within the VPN [PPVPN L2]. The presumption is that the L2 connection is a switched ATM VC or VP and that one or both ACs and the PW are established in real-time using routing and signaling protocol machinery native to the ATM and IP/MPLS networks. We call this a switched ATM L2VPN. The key component of a switched ATM L2VPN is a PWE3 native service processing (NSP) function on the PE that serves as an interworking gateway between native ATM and IP/MPLS signaling and routing protocols. The NSP learns of ATM prefixes reachable through the local attachment circuits. The ATM prefixes are exchanged with a co-resident MP-BGP instance for automatic distribution and discovery of ATM reachability to participating PEs and their directly-attached ATM networks. The NSP is capable of processing the necessary native ATM signaling messages for real-time connection management. The NSP interacts with the co- resident PWE3 signaling machinery for concurrent PW connection management. Extensions to the PWE3 signaling protocol are required to support dynamic single-sided provisioning and to transport ATM signaling parameters between the NSPs for connection management purposes. Extensions to the MP-BGP protocol are needed distribute ATM prefixes and associated next hop information between PEs. "RTP Payload Format for BroadVoice Speech Codecs", Juin-Hwey Chen, 18-Jun-03, This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs developed by Broadcom Corporation. The document also provides specifications for the use of BroadVoice with MIME and SDP. "Handling Overload Conditions in the NSIS Protocol Suite", Robert Hancock, 19-Jun-03, The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2] and a framework in [3]. The framework describes a 2-layer protocol architecture, with a common lower NSIS 'transport' layer protocol (NTLP) supporting a variety of upper layer NSIS signaling layer protocols (NSLPs). It is an open issue where within this architecture to place the responsibility for handling overload conditions. These conditions relate both to overload of the IP layer itself, as well as overload of buffer/processing resources within the NTLP/NSLPs. This note discusses the requirements and the implications of various approaches, and proposes a way forwards. "DHCP Preboot eXecution Environment Suboptions", Michael Johnston, 19-Jun-03, Define DHCP suboptions being used by PXE and EFI clients "Registration Restrictions on Internationalized Domain Names - An Overview", John Klensin, 19-Jun-03, IETF has introduced standards-track mechanisms to enable the use of 'internationalized', i.e., non-ASCII, names in the DNS and applications that use it. This has led, in turn, to concerns that characters with similar meanings or appearance could cause user confusion and opportunities for deliberate deception and fraud. Part of this problem can be addressed by limiting, on a per-zone (or per-registry) basis, the specific characters that can be used to be a subset of the list allowed by the standard and by creating 'reservations' of labels that might create confusion with those that are permitted. The model for doing this for languages that use characters that originated with Chinese has been extensively developed in another document. This document discusses some of the issues in that design and relates them to considerations and mechanisms that might be appropriate for other languages and scripts, especially those involving alphabetic characters. This document is intended to supply a basis for adapting methods developed for Chinese, Japanese, and Korean to other languages and scripts. If these adaptations are made carefully and with due consideratio for local issues, the likelihood of problematic DNS registrations with be significantly reduced. "Secure Neighbor Discovery using separate CGA extension header", Pekka Nikander, 19-Jun-03, The Secure Neighbor Discovery (SEND) Working Group has produced an Internet Draft that proposes to use an IPsec AH header that carries both a public key and a signature. However, based on the recent discussion at the mailing lists it seems that such a usage of AH is considered inappropriate at least by some members of the IPSEC WG. In this draft we introduce an alternative method, where a separate extension header is used to carry the public key, and the AH header only contains a signature. "RTP Payload Format for 1394/61883 Isochronous Streams", Bruce Fairman, 19-Jun-03, This document describes a payload format for transporting IEC 61883-1[2] (CIP) compliant IEEE1394 isochronous transport data using RTP. A 1394[3] CIP isochronous transport may carry a stream format, such as DV[4], AM824[5] or MPEG[6], that has been packetized for isochronous transport by the source. The format is opaque to the transport mechanism. The isochronous transport clock is derived from the 1394 cycle timer clock. This protocol may be used to transport 1394 61883 streams between 1394 buses by IP, specifically Ethernet/IP. "LDAP: The Binary Encoding Option", Steven Legg, 19-Jun-03, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e. data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, which can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. "LDAP: Transfer Encoding Options", Steven Legg, 19-Jun-03, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e. data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document introduces a new category of attribute options, called transfer encoding options, which can be used to specify that the associated attribute values are encoded according to one of these other methods. "SEcure Neighbor Discovery (SEND)", Jari Arkko, 19-Jun-03, IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. If not secured, ND protocol is vulnerable to various attacks. This document specifies security mechanisms for ND. Contrary to the original ND specifications, these mechanisms do not make use of IPsec. The purpose of this draft is to present an alternative to the current approach in the Working Group. "The Internet Assigned Number Authority Universal Resource Identifier Parameter Registry for the Session Initiation Protocol", Gonzalo Camarillo, 19-Jun-03, This document creates an IANA registry for SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. "Common utilizations of the BGP community attribute", Olivier Bonaventure, Bruno Quoitin, 19-Jun-03, Since its introduction in RFC1997, the BGP community attribute has been used by many Autonomous Systems to build more scalable routing policies. We describe here the most common utilizations of the BGP community attribute and provide some examples. "MCOP operation for first hop routers", Rami Lehtonen, 19-Jun-03, This draft defines Multicast Control Protocol (MCOP) operation for first hop routers. In this context, MCOP may be used as a tool for multicast network management. MCOP provides multicast network remote management with centralized information database located at Multicast Control Server (MCS). It allows gradual, group and network specific multicast network deployment. The control is done by MCOP enabled first hop routers, Multicast Control Clients (MCC), based on the information received from the MCS. MCC can filter IGMP/MLD reports and multicast packets before they reach the IGMP/MLD processing layer or multicast routing stack of the router. MCOP is independent of multicast routing protocols. "Multicast Control Protocol (MCOP) over COPS", Heikki Vatiainen, 19-Jun-03, This document defines a COPS Client-Type for Multicast Control Protocol (MCOP) and the encapsulation for transmitting MCOP messages over COPS. The document also defines message formats when MCOP over COPS is used for MCOP operation for first hop routers [1]. "Definitions of Early URI Schemes", Paul Hoffman, Daniel Kohn, 19-Jun-03, This document specifies many Uniform Resource Identifier (URI) schemes that were originally specified in RFC 1738 [RFC1738]. Some of these schemes are specified more fully in this document. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the schemes on standards track. "Internet Message Access Protocol (IMAP) - URLAUTH Extension", Mark Crispin, Chris Newman, 19-Jun-03, This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can create 'signed' URLs which can be used to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of 'URLAUTH'. "Simple Dual Homing Experiment", Christian Huitema, David Kessens, 20-Jun-03, The current Internet routing architecture does not provide for a scalable multi-homing solution. Scalability of the interdomain routing architecture is already a problem and is expected to become an even larger problem if millions of home users and small businesses will start to use multi-homing technology in order to achieve redundancy and reliability that traditionally can only be provided by BGP multi-homing. Authors believe that it is possible to solve the problems of end- users and small businesses with a multi-addressing mechanism and source address selection mechanism instead of using the routing system. This draft proposes a setup that will allow us to try a multi- addressing solution. Instead of trying to solve the problems for more complex network setups, it was decided to go for a solution that covers most simple setups but that cover the majority of home and small business networks. Authors believe that we can more easily reach progress by starting with a simple solution that can later be extended to solve the issues of a larger class of users. "Twelve heresies, two visions, and one belief", Ted Hardie, 20-Jun-03, The IETF brings together a technical community that shares a common dedication to making the best possible engineering choices and protocol standards for the Internet as whole. The community shares a number of common beliefs, which create the basis of a common work style and inform many of the decisions made within the IETF. As in many communities of believers, some of these beliefs have been elevated to the status of dogma. In the process of considering reform, the treatment of these as unquestionable may be hindering progress. This document challenges some of the beliefs which the author believes have become dogmatic. It also presents two visions for the evolution of the IETF and articulates a single belief. "A URN Namespace For Content-Based Unique Identifiers", Peter Thiemann, 20-Jun-03, This document describes a URN namespace to identify immutable octet- stream resources using content-based unique identifiers. The naming scheme relies on an algorithm that computes identifiers from media types and cryptographic hashes without a central authority. "iSeries Telnet Enhancements", Thomas Murphy, 20-Jun-03, This draft describes the interface to the IBM iSeries 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 iSeries 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, DES/SHA encrypted passphrase exchange. Applications may need to use system API's on the iSeries in order to xtract Telnet session settings from the device name description. Refer to the Retrieve Device Description (QDCRDEVD) API described in the iSeries System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates. This draft describes how the IBM iSeries Telnet server supports Work Station Function (WSF) printers using iSeries Display Station Pass- Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. "Dissemination of flow specification rules", Pedro Marques, 20-Jun-03, This document specifies the procedures necessary for the distribution of flow specification rules both intra an inter-as. Additionally it defines its application for the purpose of traffic filtering in order to mitigate (distributed) denial of service attacks. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. "DDP/RDMAP Security", Jim Pinkerton, 20-Jun-03, This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The model includes a definition of resources that can be attacked. This document then introduces various Trust Models between a local peer and a remote peer and the tools that can be used to create countermeasures against attacks. Finally, the document reviews various attacks and the countermeasures to be used against them, grouping the attacks into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. "Procedure for handling liaison statements from and to various standards bodies", Fred Baker, 20-Jun-03, This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF/ISOC to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. "MIBs Standardization for Fibre Channel", Silvano Gai, 20-Jun-03, Fibre Channel (FC) is a high speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI) and IP. Fibre Channel is standardized by the INCITS T11 Technical Committee. Fibre Channel Standards include Framing and Signaling protocols [FC-FS], Generic Services protocols [FC-GS-3], Switch Fabric protocols [FC-SW-2], etc. The management of a Fibre Channel network requires to monitor and set many parameters related to these protocols and this may be accomplished defining a proper set of MIBs. "Remote Authentication Dial-In User Service (RADIUS) Reliable Transport", Avi Lior, 20-Jun-03, Remote Authentication Dial-In User Service (RADIUS) Request For Comments (RFCs) do not address RADIUS reliability with respect to transport of RADIUS messages. This Informational Internet Draft describes procedures for Retransmission, Failover and Failback. "IPv6 Transition/Co-existence Security Considerations", Pekka Savola, 20-Jun-03, The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6: the notion of increased end-to-end transparency, implications of tunneling, the use of IPv4-mapped addresses, the considerations of IPv6 service piloting without firewalls, IPv6 protocol-specific issues, IPv6 transition/co-existence mechanism -specific issues, consequences of enabling IPv6 by default, and operational security issues when enabling IPv6 in the network infrastructure. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy Manipulation", Petri Koskelainen, Hisham Khartabil, 20-Jun-03, This document describes conference policy data elements and the mechanisms to manipulate them at a server via Conference Policy Control Protocol (CPCP). Extensible Markup Language (XML) Configuration Access Protocol (XCAP) is used to implement CPCP. This document specifies an XML Schema and XCAP application usage that are needed to implement CPCP. "QoS Resource Allocation in Mobile Networks with CASP", Sven Hermann, 20-Jun-03, This document discusses QoS resource allocation in mobile networks with Cross-Application Signaling Protocol [1].CASP separates signaling message delivery from the discovery of the next suitable CASP node. When the discovery is done by scout messages, it may introduce considerable latency in the (re-)registration procedure in handover cases. Therefore, advanced discovery mechanisms are recommended. "RTP Payload Format for 3GPP Timed Text", Jose Rey, 20-Jun-03, This document specifies an RTP payload format for the transmission of 3GPP timed text. Timed text is defined as a part of 3GP file format. It is currently used for downloading timed text contents with or without audio/video contents. In the following sections the problems of streaming timed text are addressed and a means for streaming 3GPP timed text over RTP is specified. "Interworking between SIP and QSIG for call diversion", John Elwell, 20-Jun-03, This document specifies call diversion interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP network and a participant in the QSIG network, taking into account the impact of diversion during call establishment. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. "Tunnelling of QSIG over SIP", John Elwell, 20-Jun-03, This document specifies tunnelling of 'QSIG' over the Session Initiation Protocol (SIP). This enables calls between 'islands' of circuit switched networks that use QSIG signalling to be interconnected by an IP network that uses SIP signalling without loss of QSIG functionality. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. "Diameter NASREQ Extensions for the Delivery of Service-Flow Charging Rules", Mark Grayson, 20-Jun-03, This document specifies a Diameter authorization extension that is used for the delivery of Service-Flow Charging Rules. These Service-Flow Charging Rules identify service flows that can be used within a credit control environment for distinguishing individual packet flows for which credit control applies. Multiple Service-Flows can be provided which then enable independent rating of the individual packet flows. Service-Flows can be provided at authentication and may be dynamically updated throughout the lifetime of an AAA session. "ETS Requirements for Stub Domains", Ken Carlberg, 20-Jun-03, This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single adminsitrative stub domain. This document is an extension of the General Requirements of [2] and focuses on a more specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. "Requirements for Limited-Scope Unicast Addressing in IPv6", Fred Templin, 20-Jun-03, The IPv6 addressing architecture specifies global and local-use unicast addressing schemes. Recent consensus call in the IPng working group has deprecated site-local addressing due in part to its inherent ambiguity. This document outlines requirements for use in evaluating candidate proposals for a replacement scheme. "Domain Name and Related Definitions", Ross Rader, 20-Jun-03, A number of policy and technical development efforts related to the DNS are underway within the engineering community, ICANN-circles and elsewhere due to the evolving scope and utility of DNS, domain name registries and related entities. It is important that accepted definitions act as the foundation for this work. This document is an attempt to create an optional starting point for the requisite dialogue that will ultimately foster the determination and acceptance of these new technical and contractual protocols. This document obsoletes , and . "EAP-SSC Secured Smartcard Channel", Pascal Urien, Mesmin Dandjinou, 20-Jun-03, This document describes a means of setting up an EAP secured channel between a smartcard and an Authentication Server AS (e. g. RADIUS server), as well according to an asymmetric key exchange model as a symmetric key exchange model. This channel permits to convey in secure all other types of payload between a smartcard and the AS, for example the commands which can setup or update the Directory Information Base (DIB) associated to the LDAP (Lightweight Directory Access Protocol) in the smartcard. "Life cycle key management costs in secure multicast", Michael Howarth, 20-Jun-03, This Internet-Draft considers efficient key management for encrypted multicast traffic in large groups, where the group size and dynamics have a significant impact on the network load. We consider the life cycle key management costs of a multicast connection, and show for a Logical Key Hierarchy (LKH) how member pre-registration and periodic admission reduces the initialization cost, and how the optimum outdegree of a hierarchical tree varies with the expected member volatility and rekey factor. "The Energy Aware Dynamic Source Routing Protocol", Tim Brown, 23-Jun-03, The energy aware dynamic source routing (EADSR) protocol is an extension to the dynamic source routing (DSR) protocol for mobile ad hoc networks. It retains the features and benefits of DSR while it incorporates new features for energy limited nodes. The EADSR features include (1) a DSR header option so that link power costs can be passed with source routes; (2) an extended route discovery protocol to find lower energy routes than minimum hop routes; and (3) an additional route maintenance mechanism that allows the source node to respond to link changes without route disruption. The protocol is able to find routes with minimum total transmit power cost. It is able to track changes in link power on a route, choose between routes based on cost, and notify the source of new lower cost routes as they become available. This document specifies the EADSR header option and operation changes to DSR. "An overview of Y.17iw", David Allan, 23-Jun-03, This internet draft provides an overview of ITU-T draft recommendation Y.17iw 'OAM functionality for ATM-MPLS interworking'. "Configuration Guidelines for Basic Classes of Managed Traffic", Fred Baker, 23-Jun-03, This paper summarizes a recommended correlation of applications to Differentiated Service Code Points (DSCP) and packet treatments in the network. There is no intrinsic requirement that individual DSCPs correspond to given applications, but as a policy it is useful if they can be applied consistently. "NFS RDMA Problem Statement", Thomas Talpey, 23-Jun-03, This draft addresses applying Remote Direct Memory Access to the NFS protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other sources. The potential benefits of RDMA to these implementations are explored, and the reasons why RDMA is especially well-suited to NFS and network file protocols in general are evaluated. "Directory Schema Listing Metadata", Chris Apple, 23-Jun-03, 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. "Directory Schema Listing Procedures", Chris Apple, 23-Jun-03, 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. "Extended MPLS/PW PID", Mustapha Aissaoui, 23-Jun-03, This draft proposes the extension of the proposed MPLS/PW PID to include the identification of user protocols and multiple control plane protocols carried in a PW or MPLS LSP. "Secure Shell 'none' Public Key Algorithm", Joel Weber, 23-Jun-03, This document describes the 'none' public key encryption algorithm for the Secure Shell protocol, which is useful for rekeying when the server has no keys to support for non-GSSAPI key exchange and when GSSAPI credentials are expired, or for use in embedded systems where there is a desire to minimize the overhead of rekeying to prevent sequence number rollover. "RTCP Summary Report Delivery to SIP Third Parties", Alan Johnston, 23-Jun-03, This document discusses the motivation and requirements for the delivery of RTCP extended reports and other summary reports to non-participants in the session. Several solution mechanisms are also discussed and compared. "Securely Enabling Intermediary-based Transport Services", Uri Blumenthal, 23-Jun-03, The growth of the Internet has witnessed an emergence of transport services that rely on or can benefit from assistance of network intermediaries between communicating end-points. Such services, for example, include TCP performance enhancements, multimedia packet filtering, header compression, and prevention of Denial-of-Service. In this draft, we describe some of the important aspects of the problem of securely enabling intermediary-based services. We also present several scenarios where this problem is manifested. "SIP-B: SIP for Business Phones Requirements for Implementing Business Telephony Features on SIP Endpoints", V Venkataramanan, Sharath Rajasekar, 23-Jun-03, This informational internet draft describes the requirements for a standard business telephone based on the Session Initiation Protocol (SIP). The objective of this document is to provide a minimum set of requirements for implementing business features on SIP endpoints. This draft is intended to serve as a requirements document for vendors implementing business features on SIP based devices/entities. Details of how each capability or feature is best implemented in SIP, is beyond the scope of this document and may be tracked through the working group draft submissions. "A SOAP Binding for NETCONF", Ted Goddard, 23-Jun-03, While the device management protocol NETCONF is generally well served by BEEP, there are environments where additional transports are desirable. The binding to SOAP described here may find application where SOAP-based tools and implementations are prevalent or where the network configuration favors HTTP. When used with multiple HTTP connections, SOAP over HTTP is sufficient for all NETCONF features except those involving asynchronous notification. "Use of Overbooking in Diffserv-aware MPLS Traffic Engineering", Jerry Ash, Wai Lai, 23-Jun-03, This document presents a precise formulation and a functional description of overbooking methods used in DS-TE from the operational perspective of service providers. To minimize operational complexity, an integrated approach to overbooking is recommended. "SIMPLE Buddylist Configuration Problem Statement", Adam Roach, 23-Jun-03, This document contains a brief discussion of a particular challenge that exists in making users' buddy list information available when a SIMPLE client first starts up. It also provides a very brief analysis of various solutions to the problem. "Optical Network Failure Recovery Requirements", Richard Rabbat, 23-Jun-03, This draft presents requirements for control plane-based recovery in optical networks. We focus on data-plane failure recovery in optical networks that use a GMPLS-based control plane, but use different transport plane technologies. Our goal is to gather and systematically lay out these requirements in one document to serve as a coherent basis for work on protocol and solution development. We begin with a brief overview and consideration of the requirements, and then list the requirements. "Identifying intra-realm calls with explicit addressing realm identifier attribute", Francois Audet, 23-Jun-03, This draft describes the use of an explicit addressing identifier SDP attribute to assist in the process of choosing which addresses shall be used by SIP User Agents (UAs) when multiple IP addresses are known (STUN-derived, local, etc.). This draft complements the Interactive Connectivity Establishment (ICE) draft. "Extensions to the REFER mechanism for Third Party Call Control", Sean Olson, 23-Jun-03, This document proposes a number of extensions to the REFER method used by the Session Initiation Protocol (SIP) for the purpose of third party call control. "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", Randall Gellens, 23-Jun-03, The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-MMS-* headers to and from that used in ESMTP and Internet message headers. "Message Composition", Chris Newman, 23-Jun-03, The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. The chunking extension provides a way for a client to compose a message for submission from a series of client provided pieces. This specification further extends the chunking facility so that a client can compose a message from additional sources. For example, a client could use this facility to forward a message from an IMAP server or forward a web page as an attachment to a new message. "Access Router Based Movement Detection and CoA Configuration", Yong-Geun Hong, 23-Jun-03, This document proposes Access Router (AR) based movement detection and Care-of Address (CoA) configuration for fast handover in Mobile IPv6. An Active Access Router (AcAR) which will serve a Mobile Node (MN) performs movement detection, formulates a new CoA of the MN and does Duplicate Address Detection (DAD) on behalf of the MN. After confirming the uniqueness of the new CoA, the AcAR sends it through a RA message. Since an AcAR can quickly determine the L3 movement by the comparison between neighbor caches and L2 information of a MN, a MN does not have to wait to receive RA messages from ARs. Thus, the movement detection delay is reduced. Since DAD is performed by an AcAR in advance, a MN does not have to do normal DAD and it can use the new CoA for its interface directly. "Forwarding Protocol 41 in NAT Boxes", Jordi Palet, 23-Jun-03, Some NAT boxes/routers allow the establishment of IPv6 tunnels from systems in the private LAN (using private IPv4 addresses) to routers or tunnel servers in the public Internet. As far as we know this is not a common way of use IPv6 tunnels; the usual way is to finish the tunnel directly in a device with an IPv4 public address. This behavior provides a big opportunity to rapidly deploy a huge number of IPv6 nodes and networks, without the need of new transition mechanism. This option is very important to facilitate the IPv6 deployment. This document describes this behavior and provides hints that should be applied in the NAT boxes and tunnel brokers to facilitate it. "Secure Origin BGP (soBGP) Certificates", Brian Weis, 23-Jun-03, This document describes the format of digital certificates that are used by the Secure Origin BGP (soBGP) extensions to BGP, as well as acceptable use of those certificates. Included are certificates providing authentication, authorization, and policy distribution. "Inter-region MPLS Traffic Engineering", Arthi Ayyangar, Jean Vasseur, 23-Jun-03, This draft proposes mechanisms for the establishment and maintenance of MPLS Traffic Engineering (TE) Label Switched Paths (LSP) that traverse multiple regions, where a region could be an IGP Area or an Autonomous System or a GMPLS overlay network. This document also outlines different mechanisms that an operator could employ within his region to facilitate the setup of these inter-region TE LSPs. "Session Initiation Protocol Location Requirements", James Polk, 23-Jun-03, This document presents the requirements for an extension to the Session Initiation Protocol (SIP) [1] for conveyance of user location information from one Session Initiation Protocol (SIP) User Agent to another SIP User Agent. The idea that in some cases the UAC's location could affect proper routing of the SIP message is explored as well. "LDAP Read Entry Controls", Kurt Zeilenga, 23-Jun-03, This specification describes controls which can be attached to a Lightweight Directory Access Protocol (LDAP) update request to obtain copies of the target entry before and/or after the requested update is applied. "IPv6 Multicast address-family in OSPFv3", Sina Mirtorabi, 23-Jun-03, This document describes IPv6 multicast address-family support in OSPFv3. There is no additional LSA introduced to the existing LSA defined for IPv6 unicast address-family to carry prefixes. A new bit is defined in the Prefix Options field in order to include a prefix in IPv6 multicast address-family. "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", K. Lee, 23-Jun-03, This document describes how to support Route Optimization for Mobile Nodes in IPv6 Mobile Network. The support is provided by Prefix Delegation. Mobile Router gets a prefix from an access router using Prefix Delegation protocol and advertises the delegated prefix to its subnet. Each Mobile Nodes makes its care-of address from the prefix and performs binding update. It allows the Mobile Nodes to communicate with Correspondent Nodes directly, avoiding ingress filtering. "Bootstrapping RFC3118 Delayed authentication using PANA", Hannes Tschofenig, 23-Jun-03, PANA provides network access authentication and uses the Extensible Authentication Protocol (EAP) to carry different authentication methods. The combination of EAP with an AAA architecture allows authentication and authorization of a roaming user to an access network. "Conferencing media policy requirements", Roni Even, 23-Jun-03, This document defines the requirements for Media Policy, i.e. a set of rules associated with the media distribution of the conference. This document presents the requirements for the media manipulations that can be done using these rules by conference participants or third parties using any kind of media/conference policy control protocol. This document does not address the interface between the focus and the media policy. "Conferencing Scenarios", Roni Even, 23-Jun-03, This document describes SIP conferencing scenarios. It will describe basic and advance conferencing scenarios. These conferencing scenarios will help with definition and evaluation of the requirements for SIP conferencing framework. "Link Name and Sequence Options for IPv6 Neighbor Discovery", Naiming Shen, 24-Jun-03, To facilitate network troubleshooting and management in IPv6 environment, two new options for IPv6 Neighbor Discovery messages are proposed in this document. The Link-Name option is used in Router Advertisement message, and the Sequence-Number option is used in Neighbor Solicitation and Neighbor Advertisement messages. "A Framework for Data Packet Access Control (DPAC)", Fan Zhao, 23-Jun-03, This informational draft describes the DPAC (Data Packet Access Control) framework, potentially under PANA, to efficiently control "Electronics and Telecommunications Research Institute", Souhwan Jung, 23-Jun-03, This document describes possible security threats on mobile networks that include multi-homing. Many different kinds of security threats exist on signaling and communication paths including mobile routers and home agents. It is also the goal of this draft to explain a three-layer threat model and to investigate vulnerabilities of the network entities in NEMO. "GXcast: Generalized Explicit Multicast Routing Protocol", Ali Boudani, 23-Jun-03, Recently several multicast mechanisms were proposed that scale better with the number of multicast groups than traditional multicast does. These proposals are known as small group multicast (SGM) or explicit multicast (Xcast). Explicit multicast protocols, such as the Xcast protocol, encode the list of group members in the Xcast header of every packet. If the number of members in a group increases, routers may need to fragment an Xcast packet. Fragmented packets may not be identified as Xcast packets by routers. In this paper, we show that the Xcast protocol does not support the IP fragmentation and we show also that avoiding fragmentation induces hard-coded limits inside the protocol itself in terms of group size. First, we describe the Xcast protocol, the Xcast+ protocol (which is an extension of Xcast) and we compare these two protocols with traditional multicast protocols.We propose then a generalized version of the Xcast protocol, called GXcast, intended to permit the Xcast packets fragmentation and to support the increasing in the number of members in a multicast group. "Vendor-Identifying Vendor Options for DHCPv4", Joshua Littlefield, 23-Jun-03, The DHCP options for Vendor Class and Vendor-Specific Information can be ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity. "Basic Socket API Extensions for LIN6 End-to-End Multihoming", Arifumi Matsumoto, 23-Jun-03, This document describes a method for multihoming support in application layer. We extend the basic socket API(Application Programming Interface) and propose some new interfaces for multihoming. Multihoming nodes are expected to have multiple addresses. The existing socket APIs, however, are not designed to manipulate multiple addresses in a connection. Proposed APIs help an application to handle multiple addresses, to avoid connection failure and to do load-balancing possibly. Right now, the proposed APIs are for LIN6 nodes, one of the mobile protocols. This is because LIN6's addressing architecture, which is called '8+8', is very friendly and consistent with multihoming. In this document, we propose a host- based multihoming solution and which is called end-to-end multihoming. In end-to-end multihoming, a fault-tolerant connection can be achieved relying not on routers but on the pair of end-nodes only. "A Mechanism to Secure SIP Identity headers inserted by Intermediaries", Mary Barnes, 24-Jun-03, This draft defines a standard mechanism for securing SIP headers that are inserted into requests and responses. The fundamental requirements, for securing the headers inserted by an intermediary routing or retargeting a request or response, are summarized. The solution is directed towards headers that contain identity related information, such as Record-Route, Via, and History-Info. The proposed solution defines an Authenticated Inserted Identity Header Body based on S/MIME to secure the headers. This mechanism is optional, however, the use of it enhances the overall security of SIP by ensuring the integrity of the inserted headers. "IPv6 Address Assingment and Route Selection for End-to-End Multihoming", Kenji Ohira, 24-Jun-03, IPv6 suppose that network is hierarchical. Though the present IP network topology is not hierarchical at the point of multihoming. In this document, we clarify that a) how to assign address blocks to ISPs and sites in order to achieve multihome environment without destroying hierarchical structure of IPv6 b) requirements in order for end hosts to select an adequete route from multiple routes when multihoming. "QoS NSLP Authorization Issues", Hannes Tschofenig, 24-Jun-03, Various proposals for NSIS QoS NSLPs have been published recently. The design of a QoS NSLPs has to consider more than only exchanging QoS objects. Authorization has to be handled properly to make this protocol both useful and performant. Authorization in mobile environments, unfortunately, raises additional questions. This document provides an introduction to the topic. "Security Implications of the Session Identifier", Hannes Tschofenig, 24-Jun-03, As one result of the analysis activities in the NSIS group it was realized that mobility and the ability to change the flow identifier causes problems with existing QoS reservations. To be able to associate a signaling message with existing state an identifier other than the flow identifier had to be used. Such an abstraction is achieved with the session identifier which allows identification of established state independently of the flow characteristics. "ISIS Extensions for BGP Peer Discovery", Robert Raszuk, 24-Jun-03, This document proposes an extension to IS-IS protocol [ISO10589] to support BGP peer auto discovery. We propose the addition of new information that an Intermediate System can flood in it's LSPDU. Such information is required for network based auto discovery of IBGP peers as described in [IBGP-AM]. "IBGP Auto Mesh", Robert Raszuk, 24-Jun-03, The distribution of BGP routing information within an autonomous system requires all border routers to be fully meshed. This constitutes a significant operational problem in terms of configuration management. This has led to the wide-spread adoption of route reflection [RFC2796], primarily in order to reduce the number systems which configuration must be modified in order to introduce or remove a new internal BGP speaker. Route reflection, however, implies with it information reduction which is not always desired. This document defines a discovery mechanism that is designed to address the problem of introducing (or removing) a BGP speaker into an iBGP mesh without implying any other behavior change when compared to manual configuration. "OSPF Extensions for BGP Peer Discovery", Robert Raszuk, 24-Jun-03, This document proposed an extension to OSPF Router Information LSA [LINDEM1] to distribute selected information about BGP process on a router to other routers in the same area or in the same domain. Such information is required for network based auto discovery of IBGP peers as described in [IBGP-AM]. "Requirements for a QoS AAA Protocol", Frank Alfano, 24-Jun-03, This document describes requirements for a protocol that would perform Authentication, Authorization, and Accounting for Quality-of- Service reservations. This protocol would be used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources used during the life of the application flow. A QoS AAA protocol should also support dynamic authorization of QoS as a function of application and account state. While we assume the existence of some QoS reservation protocol to allow endpoints to request QoS from network elements, complete requirements for such a protocol are outside the scope of this document and a QoS AAA protocol could be used to support more than one kind of reservation protocol. A QoS AAA protocol could be used between any bearer-level network element that lies along the path of an application flow and an application server that lies anywhere in the network, allowing for a wide variety of flexible service deployment models. "Geopriv Authorization Policies", Hannes Tschofenig, Jorge Cuellar, 24-Jun-03, This document describes authorization policies for usage with Geopriv. It suggests using the eXtensible Access Control Markup Language (XACML). XACML provides functionality required to express policies for access to location information. "The NSIS Transport Layer Protocol (NTLP)", Melinda Shore, 24-Jun-03, The RSVP [RFC2205] model for communicating requests to network devices along a datapath has proven useful for a variety of appli- cations beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ [RFC1633]. The NSIS working group is developing a modernized version that, among other things, is based on a 'two- layer' architecture that divides protocol function into transport and application. This document describes the transport protocol. "Recommendations for using MIME body parts in SIP", Cullen Jennings, 24-Jun-03, This document describes conventions for using MIME body parts in SIP messages. It uses a transport encoding of 'binary' since SIP messages are always passed over an 8bit clean transport. "Geopriv Location Object Markup Language", Jorge Cuellar, Christian Guenther, 26-Jun-03, This draft presents and illustrates a foundational version of an markup language suitable for representing the Geopriv Location Object. This language is defined by means of an XML schema. In addition, we compile a list of open issues that the Geopriv Working Group must solve in order to allow for precise definitions of Location Object data formats. "Best Current Practices for Internet Emergency Preparedness Use of IP Telephony", Janet Gunn, 24-Jun-03, This document proposes best current practices for Internet Emergency Preparedness in the context of IP telephony in private IP networks designed, engineered and managed with telephony as the dominant application. It takes a top-down approach, and is intended to stimulate discussion and further revision and enhancement. "Kerberos Initial Authentication Methods", Joel Weber, 24-Jun-03, This document discusses the various methods that have been used for initial authentication in Kerberos, using passwords and various other forms of key material, as well as various methods that may offer significant benefits which may justify the effort of specifying and implementing them, as well as the advantages and disadvantages of the various approaches relative to each other. "IRIS - An ENUM Registry (ereg) Type for the Internet Registry Information Service", A Newton, 24-Jun-03, This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. "Media Objects Markup Language (MOML)", Tim Melanchuk, Garland Sharratt, 24-Jun-03, The Media Objects Markup Language (MOML) is used to define media processing objects which execute on media servers. It defines a set of primitive media objects (called primitives) and provides tools to group primitives together and specify how they interact with each other. Clients use MOML to create precisely tailored media processing objects which may be used as parts of application interactions with users or conferences or to transform media flowing internal to a media server. IVR is an example of an application interaction with a user. "Media Sessions Markup Language (MSML)", Tim Melanchuk, Garland Sharratt, 24-Jun-03, The Media Sessions Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. Clients can use it define how media sessions interact on a media server and to apply services to individual or groups of users. MSML can be used, for example, to control media server advanced conferencing features, create sidebars, and insert media processing objects into media streams. As well, clients can use it with other languages such as the Media Objects Markup Language (MOML) or VoiceXML to interact with individual users or with groups of conference participants. "Conference Policy Control Protocol for Centralized Conferencing", Orit Levin, 24-Jun-03, This document lists operations to be addressed by a Conference Policy Control Protocol (CPCP). Each operation carries mandatory and optional parameters. Initially, for readability, the operations are presented using informal XML syntax. The actual protocol of choice and its formal syntax will be defined as a part the XCON working group process. "Working Group Document Process", Margaret Wasserman, 24-Jun-03, This document describes a process that IETF working groups may use to produce documents. It defines terminology and process stages that may prove useful as we attempt to improve our WG processes. This document may also help new or struggling WG chairs to understanding how to control the flow and quality of their WG's output. "LDAP Schema Extensions for Internationalized Domain Names", Eric Hall, 24-Jun-03, This document defines schema and behavioral rules which are necessary to fully accommodate the use of internationalized domain names as UTF-8 sequences in LDAP. Specifically, this document defines an internationalized domain component attribute, email address attribute, URI syntax, and several related object classes, and also discusses their usage considerations. "The Calling Party's Category tel URI Parameter", Rohan Mahy, 24-Jun-03, This document specifies a new parameter for the tel URI that represents the Calling Party's Category, a parameter used in SS7 ISUP signaling. "Conveying Tones in the Session Initiation Protocol (SIP)", Rohan Mahy, 24-Jun-03, One of the major applications of the Session Initiation Protocol (SIP) is in Internet telephony. In this context it is often useful or convenient for a SIP entity to request another SIP User Agent generate some type of tone, without generating this tone as part of a session. This document describes how SIP can be used without modification to carry such tones and explores issues relating to their use. Finally this document defines a new MIME type which is useful for conveying computer generated tones. "Public Policy Considerations for Internet Design Decisions", John Morris, Andy Davidson, 24-Jun-03, This document suggests public policy questions that the IETF should consider and possibly address when developing new standards and protocols, and modifying or enhancing old standards and protocols. This document contains questions to be considered, as opposed to guidelines or rules that should in all cases be followed. This first draft provides a framework for identifying and discussing questions of public policy concern, and invites members of the IETF community to contribute to the questions and discussions raised here. "Benchmarking Methodology for MPLS Protection Mechanisms", Scott Poretsky, 24-Jun-03, This draft describes the methodology for benchmarking MPLS protection mechanisms. An overview of existing MPLS Protection terminology and functionality is provided as as background for the methodology. The methodology can be applied to any MPLS Protection mechanism such as Headend Reroute, Standby LSP, Fast Reroute Detour Mode, and Fast Reroute Bypass Mode. The data plane is measured to obtain the benchmarking metrics. Discussion is included to explain the differences between MPLS Protection mechanisms, the network events that cause failover, and the benefits of measuring the data plane for black-box MPLS Protection benchmarking. Measurements can be used to compare failover performance of different Label-Switched Routers and evaluate the different MPLS protection mechanisms. "Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering", Jim Boyle, 24-Jun-03, Traffic engineering using MPLS within a single IGP area has become quite prevalent in networks today. This gives a network operator several advantages, including better traffic measurement capabilities, faster restoration times, and of course the ability to better manage congestion points within their network. However, the current uses have been limited to one IGP area. OSPF based networks usually do traffic engineering only in their backbone area, and many ISIS networks still operate at a single level. It would be useful to be able to extend these capabilities across hierarchical areas within a single IGP, as well as to be able to extend across AS boundaries if it is so-found to be useful and possible. This document first breaks down some of the current applications of MPLS TE, and then it addresses how these might be used (or precluded) across IGP areas or AS boundaries. "FAST TCP for High-Speed Long-Distance Networks", Cheng Jin, 24-Jun-03, This document proposes FAST TCP, a modification to the TCP congestion control algorithm for high-speed long-distance networks. The standard AIMD congestion control mechanism in current TCP constrains the size of congestion window under realistic network conditions, resulting in low throughput in high-speed long-distance networks. FAST TCP uses additional feedback information to detect and control network congestion to achieve higher throughput. "Requirements of Burst-Level Control in Optical Networks", Jun Choi, 24-Jun-03, This draft presents the requirements of burst-level control in order to improve channel efficiency in optical networks. By processing and control the finer granularity of burst data, the network can improve its utilization than the present circuit switching based optical networks. Implementation issues of transmission and switching for data burst are took into consideration. "Extensions to the Dialog event package for Third Party Call Control", Sean Olson, 24-Jun-03, This document defines extensions to the dialog event package and corresponding application/dialog-info+xml MIME type for the purpose of third-party call control. "GEOPRIV Location Data Considerations", James Polk, Jorge Cuellar, 24-Jun-03, This document describes the Geopriv Location Data Fields of the Location Object that MUST be present under what conditions, which fields SHOULD be present, and which MAY be present. This document does not address the privacy and security requirements of the GEOPRIV Protocol or the privacy and security requirements of the GEOPRIV LO Using Protocol. "RADIUS Issues in Public Wireless LAN Roaming Scenarios", Farid Adrangi, 25-Jun-03, There are a number of IETF drafts that describe use of RADIUS in a variety of scenarios. However, in the context of Public Wireless LAN (PWLAN) deployments, there are still some areas where either use of RADIUS is unclear or not covered. To address this problem, we first need to generate a list of RADIUS issues significant to public wireless LAN roaming (authenticating and obtaining service on a network operated by or affiliated with a home provider’s 'roaming partner'). Once these issues are understood and analyzed, we can take appropriate actions to solve them. This document describes some of RADIUS issues encountered in PWLAN deployments and roaming scenarios. "A Presence-based GEOPRIV Location Object Format", Jon Peterson, 25-Jun-03, This document describes a object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and has similar properties. "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, 25-Jun-03, When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. "Considerations of FMIPv6 in 802.11 networks", Yong-Geun Hong, 25-Jun-03, This document describes the applicability of Fast Handovers for Mobile IPv6 in 802.11 networks. Fast Handovers for Mobile IPv6 proposes a set of protocol enhancements to reduce handover latency due to IP protocol operations as small as possible by the help of L2 information. 802.11 networks are considered as a popular wireless infrastructure to meet broadband network service requirement in the future. If Fast Handovers for Mobile IPv6 is applied to wireless network, 802.11 might be a practicable target for deployment. At this point some Fast Handover methods for Mobile IPv6 are thought to be directly applicable to 802.11 networks and some others are not. "Two Stage Standardization Approach", Spencer Dawkins, Charles Perkins, 25-Jun-03, This specification points out the (obvious) distinction between the RFC 2026 Standards Track as documented and the IETF standards track as practiced, and proposes a two-step standard track, with judicious use of Experimental RFCs, as an alternative. "802.11 Mobility Framework Supporting GPRS Handover", Soohong Park, 25-Jun-03, In this draft, we describe a new mobility framework to extend 802.11 [WLAN] to seamlessly manage roaming into GPRS access network, whenever the mobile node is out of range from any 802.11 domain. "Requirements for multicast service using a group label over MPLS", Jun Choi, 25-Jun-03, As the group communication become more important, the special label should be allocated in support of group management and maintenance. The allocation mechanism of a group label can be applied to a point- to-multipoint(P2MP) communication in MPLS networks. Currently used label is locally significant, while this group label should be common object within a single MPLS domain. This document presents a set of requirements for multicast service using a group label over Multiprotocol Label Switching(MPLS). It identifies functional and performance capabilities required to allocate a group label in master-slave network and peer to peer network, which facilitates efficient and reliable group communication and Quality of Service(QoS) in MPLS domain. It also identifies functional capabilities required to implement several services related to Content Distribution Network(CDN) in master-slave network. "Media Policy Manipulation in the Conference Policy Control Protocol", Rohan Mahy, Nermeen Ismail, 25-Jun-03, The SIP conferencing framework defines a model for tightly-coupled conferencing signaled via the Session Initiation Protocol (SIP), in which a Conference Policy Control Protocol is used to manipulate policies relevant to a specific conference, such as conference membership policy, authorization policy, and media layout. This document describes a logical model, which can apply to any session setup protocol, to describe media processing in a tightly-coupled conference. It also defines specific protocol semantics and a specific syntax to manipulate that model. "Framework of Priority Promotion Scheme", Naotaka Morita, Gunnar Karlsson, 25-Jun-03, This document describes a framework of a new scheme for traffic control to achieve end-to-end QoS for interactive multimedia services. The scheme is based on end-to-end measurement of network resources by end systems. The network is assumed to fully support the priority control scheme specified in the Diffserv architecture for QoS and SIP [1] for session control. Since the scheme relies on the behavior of the end systems, this document also touches on mechanisms for monitoring end-system behavior. "Two Prefixes in One Address", Iljitsch van Beijnum, 25-Jun-03, This memo presents a possible solution to the multihoming in IPv6 problem. It borrows from earlier 8+8 and GSE proposals but it diverts from these approaches in order to be more readily deployable. A source host that wants to initiate communications looks up the IPv6 addresses that will function as the transport-layer identifier and the IP-level locators for the remote end in the DNS and collapses both of its own addresses into a single one. This makes it possible to communicate without prior negotiation, but without opening the door to trivial identity theft that must be repaired by cryptographic means. "Traffic Accounting Requirements for MPLS Networks", Shigeki Matsushima, Ken-ichi Nagami, 25-Jun-03, This document describes that requirements of traffic accounting in per LSP basis. That is important as providing SLA and the evidence of bandwidth guarantee so that these service are on their LSP. "Requirements for Conference Policy Control Protocol", Petri Koskelainen, 25-Jun-03, The conference policy server allows clients to manipulate and interact with the conference policy. One mechanism to manipulate the policy is to use conference policy control protocol (CPCP). This document gives the requirements for CPCP. "Passive One-way Delay Measurement", Lutz Mark, 25-Jun-03, This document describes a non-intrusive method for measuring one-way delay of IP packets. "Address Resolution for IP datagrams over MPEG-2 networks", Gorry Fairhurst, Marie-Jose Montpetit, 25-Jun-03, This document describes mechanisms to bind IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). Protocols are required to signal these addresses to the link receivers and transmitters, known as Address Resolution, or Neighbour Discovery. Although this is often associated with Ethernet [RFC803], these processes are essential to the operation of any L2 network. MPEG-2 transmission networks often utilize broadcast media (e.g., satellite and cable) where the mapping may take into account issues related to network operations and traffic engineering. In MPEG-2 transmission networks, an IP address must be associated with a Packet ID (PID) and specific transmission multiplex. Address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions, such as SDP, and IMG. In this document the different mechanisms used for address resolution are reviewed and guidelines for future developments of efficient schemes are given. "Resource Mapping for GMPLS with Heterogeneous Interfaces", Jun Choi, 25-Jun-03, The new forms of label used in GMPLS to deal with the widening scope of MPLS into the optical and time domain are collectively referred to as a 'Generalized Label' related to resource. In this draft, we describe the relationship of labels and resources. We also describe the resource mapping methods for GMPLS with heterogeneous interfaces. Particularly we present the methods for resource mapping at incoming and outgoing switching interface where data flows with label of a different granularity are aggregated into the data flow of large bandwidth. "BGPv4 SAFI-Specific Attribute", Ruchi Kapoor, 25-Jun-03, This document defines a new BGP attribute called the 'SAFI [IANA-SAFI] Specific Attribute' (SSA). This attribute consists of a set of TLVs (it MUST contain atleast one TLV; it MAY contain more than one TLV). Each Subsequent Address Family Identifier (SAFI) that uses this attribute MUST define the Typecodes that are valid for the respective SAFI. "IPv4-Tunnel SAFI", Gargi Nalawade, 25-Jun-03, There is a need for Tunnel end-point discovery within and across Autonomous Systems. BGP is the only protocol that is widely-spoken across Autonomous Systems and can carry this information. This document defines how BGP speakers can convey Tunnel end-point reachability information. "Requirements for Floor Control", Petri Koskelainen, 25-Jun-03, This document defines the requirements for floor control in a multi-party conference environment. "Method to Set up LSP using VLAN Tag Switching", Tetsuya Kawakami, 25-Jun-03, This document describes a method to set up a Layer 2 tunnel over Ethernet-based networks. For this purpose, the ports of an Ethernet switch are configured to forward VLAN tag-labeled frames incoming from a certain port to another unambiguous port by using only the VLAN tag information. The Ethernet switches form the transport plane and are a part of Label Switching Routers (LSRs). In the control plane the VLAN tags are distribute using Label Distribution Protocol (LDP) and Resource Reservation Protocol-Traffic Engineering (RSVP- TE). To enable LDP and RSVP-TE to fulfil that function, this document proposes extensions in these protocols. The introduced method simplifies the control and management of wide area Ethernet networks and limits the distribution of broadcast/multicast frames. "The SNMP Information Model", Sharon Chisholm, 25-Jun-03, This memo attempts to capture the de facto information model of SNMP MIBs. "Mobility Support in NSIS", Xiaoming Fu, 25-Jun-03, Mobility support was one of the shortcommings of RSVP and a number of proposals have been made in the past to improve various features. This document attempts to determine what the expected functionality is, how various problems can be solved and what implications are caused by certain design decisions. "Location Objects and Location Privacy Information for Presence Information", Henning Schulzrinne, 25-Jun-03, Location information is a natural extension of presence information. This document describes how the Presence Information Data Format (PIDF) can be extended to deliver geospatial and civil location information, as well as privacy policy information. The privacy policy information can be used both within the presence agent (PA) as well as the presence document. "A Comprehensive Approach to Quality (COACH)", John Loughney, Bernard Aboba, 25-Jun-03, This document describes an approach to improving the quality of IETF documents which is based on quality plans developed by Working Groups, and approved by the Area Director. This document describes the components of a quality plan, as well as a list of materials which need to be compiled in order to assist Working Groups in developing their plans. "A Framework for Supporting ETS in Stub Domains", Ken Carlberg, 25-Jun-03, This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting ETS within a stub domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. "Extensions to the Presence Information Document Format (PIDF) for Conveying Phone State", Jonathan Rosenberg, Jon Peterson, 25-Jun-03, This document presents extensions to the Presence Information Document Format (PIDF) for representing the state of telephones. This state includes whether the telephone is in a call or not, whether it is registered to the network, whether it is ringing, and so on. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, 25-Jun-03, One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router (MR) for use on the links in the mobile network. DHCPv6 prefix delegation can be used for this configuration task. "EAP-LDAP Protocol", Helena Mancini, 26-Jun-03, This document specifies an Extensible Authentication Protocol (EAP) mechanism for a challenge-based authentication using MD5 in conjunction with the hash algorithm used to store the password within an identity store. This document defines the EAP-LDAP method, which provides one-way authentication and MD5 key generation. As a result, the EAP-LDAP method, when used by it self, is only appropriate for use on networks where physical security can be assumed. These methods SHOULD NOT be used on wireless networks, or over the Internet, unless the EAP conversation is protected. This can be accomplished using technologies such as IPsec or TLS. "Multihomed ISPs and Policy Control", Masataka Ohta, 26-Jun-03, Policy control of next level ISPs, delegated address spaces from top level ISPs, is discussed. While global policy coodination requires top level aggregators, local policy can be controlled with next level aggregators. "Use of the Odd Characteristic Extension Field in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Akira Kato, 26-Jun-03, This document specifies algorithm identifiers and ASN.1 [X.660] encoding formats for additional elliptic curve field for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). This specification supplements [RFC 3280], 'Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile.' and [RFC3279] 'Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. ' Implementations of this specification MUST also conform to RFC 3280 and RFC 3279. In RFC 3279 only prime-field and two-characteristic-field were used as field which defines an elliptic curve. This document introduce odd-characteristic-extension-field as the 3rd field. "GIMPS: General Internet Messaging Protocol for Signaling", Henning Schulzrinne, 26-Jun-03, The Generic Internet Messaging Protocol for Signaling (GIMPS) provides a generic transport messaging service to set up, modify and tear down signaling state in signaling nodes. "End-to-middle security in the Session Initiation Protocol(SIP)", Kinji Ono, Shinya Tachimoto, 26-Jun-03, End-to-end encryption for confidentiality services can conflict with some of the features provided by intermediaries. For example, if a SIP UA encrypts the message body by using S/MIME for end-to-end security, it cannot use features that the proxy employs to inspect the message body contained in the request. This situation requires securing information passed between the UA and an intermediary proxy, also called 'end-to-middle security', which can work with end-to-end security. This document describes a method of achieving end-to-middle security, allowing a SIP UA to disclose message data to selected intermediaries and protect the data from being seen by other intermediaries. It describes how to apply S/MIME CMS EnvelopedData body for use in end-to-middle security. "Laboratory and 'Field' Experiments with IPv6 Mobile Networks in Vehicular Environments", Hong Lach, 26-Jun-03, This document gives a short high-level overview of several practical experiments performed with mobile networks using Mobile IPv6-based NEMO extensions in the context of the IST OverDRiVE project. Laboratory experiments include simple and nested mobile networks in a pure IPv6 environment while 'field' experiments demonstrated continuous IPv6 vehicular connectivity over two publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and inside a metropolitan area. "Simple TDM Pseudowire Protocol", Jonathan Stein, Amnon Ilan, 26-Jun-03, This document describe a simple method for transporting time division multiplexed (TDM) digital voice and data signals over Pseudowires. "Network Access Co-ordination to Complement IP Mobility Protocols", Hong Lach, Miguel Catalina-Gallego, 26-Jun-03, This draft addresses the need to complement the IP mobility protocols with respect to the co-ordination of a mobile node's network access. The concept of Network Access Agent (NAA) is introduced as a functional entity in the network to assist the mobile node's IP handoff strategy. The Network Access Co-ordination Protocol (NACP) is proposed as an interaction mechanism between the NAA and the mobile node, so that the NAA can provide valuable information and recommendations to the mobile node to consider in IP handoff. The NACP is conceived so that it is completely independent of the Mobile IP protocols. "Supplementing IPFIX Flow Informaion with Per-packet Records", Charlie Kim, Taesang Choi, 26-Jun-03, This document describes extensions required to supplement the IP flow information export with per-packet records. The extension supports more precise application-aware usage accounting, detailed traffic profiling, enhanced intrusion and attack detection, etc. Extensions on the information model, the Metering Process, the Exporting Process, and Configuration are mentioned. "Signaling Extension for the End-to-End Restoration with SRLG", Jun Choi, 26-Jun-03, This draft describes the requirements and scenario for end-to-end restoration with SRLG for disjointness of resources. Furthermore, we also describe the signaling extension for restoration scheme suggested in pre-OTN network. For the disjointness of end-to-end restoration path from failed working path, we extend the RSVP-TE signaling message including SRLG. "Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router", Hyunsik Kang, 26-Jun-03, This document shows how to route optimization by using bi-directional tunnel between home agent and top level mobile router. A packet will be transmitted directly from the home link of the mobile node to top level mobile router of the correspondent node through this tunnel. "Multicast Signaling Conduit Protocol", Keyur Patel, 26-Jun-03, This document describes an approach for solving the 'last-mile' problem for multicast, especially SSM-style multicast, called Multicast Signaling Conduit Protocol (MSCP). It is intended to facilitate an endnode whose OS does not support IGMPv3, or who resides in a portion of the Internet infrastructure without multicast, to join multicast groups. It is especially intended for SSM-style groups, although it could be adapted for use for other multicast groups. "XML Network Management Interface", Weijing Chen, Kenneth Allen, 26-Jun-03, This document describes XML network management interface between network managed system and network managing system. The XML network management interface is intended for use in diverse network environment where transport and data model requirements vary greatly. It is unlikely that a single transport and data model specification will meet the needs of all anticipated service operators. Therefore, the XML network management interface is partitioned into the layered components. "Pre Association Phase Protocol (PAP)", Richard Takourout, 26-Jun-03, This document introduces a protocol for the pre-association phase as defined in the ForCES (Forwarding and Control Element Separation) requirements documents [1]. The main purpose of this protocol is to bring mechanisms to automate the discovery and the configuration of logical elements in this ForCES architecture. "XML based Model for Control and Forward Element Separation", Richard Takourout, 26-Jun-03, This document introduces a set of modeling requirements for the logical elements between the control and data forwarding planes of a network element. This document presents a model representation of ForCES logical elements with the W3C Extensible Markup Language [3]. "QoS Signaling for IP-based Radio Access Networks", Sang Lee, 26-Jun-03, The IETF NSIS WG is standardizing IP signaling protocols with QoS signaling as the first use case. It is desirable to consider QoS signaling procedures for resource reservations in an IP-based RAN where mobide nodes undergo frequent handoffs. In this draft, we describe general QoS signaling procedures for an IP-based RAN, which are based on the analysis of the existing QoS signaling solutions in mobile wireless networks. We also present a specific QoS signaling scheme based on the proposed general signaling procedures. "MPLS IP Bridging Configuration Guidance for IEPREP", Pat McGregor, 26-Jun-03, An Internet Emergency Preparedness (IEPREP) telephony service IP Bridging topology using Multi-Protocol Label Switching (MPLS) should provide Emergency Telecommunications Service (ETS) using a) Session Initiation Protocol (SIP) Priority header value of 'emergency', b) Session Description Protocol (SDP) attribute experimental parameters to designate the call (session) as either a National Emergency call, International Emergency call, or both, c) MEGACO context descriptors of priorities 1-6 and emergency indication, and d) MPLS E-LSPs with a dedicated codepoint specifying application of ETS Per-Hop Behavior (PHB). IP Differentiated Services marking should use specified code points allocated from the Experimental and Local Use pool (pool 2) to designate the traffic as either National Emergency or International Emergency for corresponding PHB use. Signaling between the Signaling Gateway (SG) and Media Gateway Controller (MGC) should apply the MTP3 SS7 protocol over the M2UA adaptation protocol for use of the Stream Control Transmission Protocol (SCTP). Support is suggested for work in progress on defining a SIP Resource Priority header and defining a SIP telephone url extension for calling party category designation. "Protocol identifiers for IPv6", Emile Stephan, Jordi Palet, 26-Jun-03, Despite IPv6 is operational there are no protocol identifiers to extend the use of RMON MIBs and of the IPPM REPORTING MIB to IPv6. This memo defines basis protocol identifiers for IP Version 6 and sub IP. "LSR Self-Test", George Swallow, Dan Tappan, 26-Jun-03, This document defines a means of self test for a Label-Switched Router (LSR) to verify that its dataplane is functioning for certain key Multi-Protocol Label Switching (MPLS) applications including unicast forwarding based on LDP [LDP] and traffic engineering tunnels based on [RSVP-TE]. A new Loopback FEC type is defined to allow an upstream neighbor to assist in the testing at very low cost. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] messages are extended to do the actually probing. "Extra class LSP service using protecting resources in GMPLS networks", Katsuhiro Shimano, 26-Jun-03, This document provides the problem statement on a extra class LSP ser- vice and addresses the issues. The extra class LSP uses the resource reserved but not allocated for the protecting LSPs in the pre-planned LSP re-routing without extra-traffic (including shared mesh) recovery method. Network utilization is improved because the resource reserved for the protecting LSPs are used for the extra class LSPs. The extra class LSP is preempted less frequently than the conventional priority mechanism using setup and holding priorities because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. This document pro- poses the extra class LSP service using the resource reserved but not allocated for the protecting LSP at the provisioning phase. This docu- ment addresses the issues on the extra class LSP: (1) advertisement of available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended connections. "A Proposal for Generic Traceroute Over Tunnels", Xiaoming Fu, Rene Soltwisch, 26-Jun-03, We identify some issues for generic traceroute for tunnels (tunnel- trace): (1) it is possible that some IP hops do not support tunneltrace, (2) for each tunnel wishing to be traced, at least the two end points should support the tunneltrace, (3) tracing message should be able to by-pass firewalls and NATs. One possible solution, based on the CASP signaling protocol (stateless mode), is proposed to support generic routetracing over tunnels. "Path MTU Discovery", Matt Mathis, 26-Jun-03, This document describes Path MTU Discovery for the Internet. It is largely derived from RFC 1191 and RFC 1981, which describe ICMP based Path MTU Discovery for IP versions 4 and 6, plus a robust new algorithm. "GMPLS Extensions to support Multi-Granularity Optical Cross-Connect with Heterogeneous Optical Interfaces", David Kim, 26-Jun-03, This document defines information needed when GMPLS signaling is used on the multi-granularity of optical cross-connect (MG-OXC) over Generalized Multiprotocol Label Switching (GMPLS) networks because existing documents deal only with singular wavelength OXC. The basic optical label handlings (including add, drop, swap, merge, and stack) are required for using the MG-OXC in GMPLS networks. Also the protocol related to signaling is extended for supporting the MG-OXC. "Requirements for IPv6 Signaling as NTLP", Jun Choi, 26-Jun-03, In this draft, we present the features of IPv6 protocol related to NSIS Transport Layer Protocol (NTLP) and requirements for IPv6 signaling as NTLP in different Internet transport infrastructure, such as SDH/SONET switch, Optical cross-connect (OXC), ATM switch, Ethernet switch, wireless system, and router. In this framework, user data is transported via nodes in the data plane and signaling messages are routed to NEs in the control plane. We propose the new protocol, Internet Signaling Message Protocol (ISMP) for carrying signaling messages. And other delivering methods of signaling messages in IPv6 network are also presented in appendix. "The Real Time Transport Protocol (RTP) Denial of Service (Dos) Attack and its Prevention(", Jonathan Rosenberg, 26-Jun-03, The Real Time Transport Protocol (RTP) provides unreliable transport of real time media from a sender to one or more recipients. RTP sessions are typically set up through signaling protocols such as the Session Initiation Protocol (SIP) or the Real Time Streaming Protocol (RTSP). When RTP is set up with these protocols, a potential Denial of Service (DoS) attack is introduced. This attack allows an attacker to cause a flood of RTP packets to be sent towards a target. We describe this attack, and also show how it is effectively prevented using Interactive Connectivity Establishment (ICE), first introduced as a means of handling Network Address Translator (NAT) traversal. "Memorandum for multi-domain PKI Interoperability", Masaki SHIMAOKA, 26-Jun-03, This memo is used to share the awareness necessary to deployment of multi-domain PKI. Scope of this memo is to establish trust relationship and interoperability between plural PKI domains. Both single-domain PKI and multi-domain PKI are established by the trust relationships between CAs. Typical and primitive PKI models are specified as single-domain PKI. Multi-domain PKI established by plural single-domsin PKI is categorized as multi-trust point model and single-trust point model. Multi-trust point model is based on trust list model, and single-trust point model is based on cross- certification. "Designated Relays Inquiry Protocol (DRIP)", Russell Brand, Laurence Sherzer, 26-Jun-03, The Designated Relays Inquiry Protocol, DRIP, is a method for domain name owners to specify the IP addresses that are authorized to relay mail as a domain name. The protocol provides a method for server MTAs to reject SMTP connections from IP addresses not authorized to use a domain name. "Cryptographic Message Syntax (CMS) algorithms for GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94.", Serguei Leontiev, 27-Jun-03, This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption arbitrary message contents. "OSPF Security Vulnerabilities Analysis", Kathy Jones Repage, Olivier Le Moigne, 27-Jun-03, Internet infrastructure protocols were designed at the very early stages of computer networks when 'cyberspace' was still perceived as a benign environment. As a consequence, malicious attacks were not considered to be a major risk when these protocols were designed, leaving today's Internet vulnerable. This paper provides an analysis of OSPF vulnerabilities that could be exploited to modify the normal routing process across a single domain together with an assessment of when internal OSPF mechanisms can or cannot be leveraged to better secure a domain. "Extra class LSP service using protecting resources in GMPLS networks", Katsuhiro Shimano, 27-Jun-03, This document provides the problem statement on a extra class LSP ser- vice and addresses the issues. The extra class LSP uses the resource reserved but not allocated for the protecting LSPs in the pre-planned LSP re-routing without extra-traffic (including shared mesh) recovery method. Network utilization is improved because the resource reserved for the protecting LSPs are used for the extra class LSPs. The extra class LSP is preempted less frequently than the conventional priority mechanism using setup and holding priorities because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. This document pro- poses the extra class LSP service using the resource reserved but not allocated for the protecting LSP at the provisioning phase. This docu- ment addresses the issues on the extra class LSP: (1) advertisement of available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended connections. "Addition of GOST Ciphersuites to Transport Layer Security (TLS)", Grigorij Chudov, Serguei Leontiev, 27-Jun-03, This document is intended to register new cipher suites for the Transport Layer Security (TLS) protocol, according to the procedure specified in section A.5 of [TLS]. Those cipher suites are based on Russian national cryptographic standards - key establishment algorithms based on GOST R 3410-94 and GOST R 3410-2001 public keys, GOST 28147-89 encryption algorithm and GOST R 34.11-94 digest algorithm. "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificates and Certificate Revocation List (CRL),corresponding to the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST", Serguei Leontiev, 27-Jun-03, This document describes identifiers and appropriate parameters for the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, and also ASN.1 encoding scheme for digital signatures and public keys, used in Internet X.509 Public Key Infrastructure (PKI). This specification extends [RFC 3279], 'Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' and, correspondingly, [RFC 3280], 'Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile'. All realizations of this specification also MUST correspond [RFC 3280]. "A Quality of Service NSLP for NSIS", Andrew McDonald, 30-Jun-03, This draft describes a protocol to be used for signaling QoS reservations in the Internet. It is compatible with the framework and requirements for such signaling protocols developed within NSIS; in conjunction with the NSIS Transport solution, it provides functionality comparable to RSVP: it is independent of the details of QoS specification, and adds support for a greater variety of reservation models, but is simplified by the elimination of support for multicast flows. "SMTP Service Extension for Trust of Addressing Information", Marc-Andre Pelletier, 01-Jul-03, This document defines an SMTP service extension [ESMTP] whereby an SMTP client may establish a trust relationship with the server attesting its confidence in the validity of the originator of a message. This confidence, or its absence, can then be used to mitigate the cost of undesirable messages (primarily spam) without disrupting operations between, or with, SMTP implementations not supporting the extension. "Windows Internet Security and Privacy Guidlines", Joe Williams, 02-Jul-03, This document describes guidelines and good practices for privacy and security while using the Microsoft Windows Operating System. It also gives examples of software to protect the users information. Background information of the Internet is also included as a introduction. "A Framework for Large-scale Distributed Intrusion Detection System(LDIDS)", Yi Yang, 02-Jul-03, Intrusion Detection Systems (IDSs) are designed to detect intrusions and protect the relative network or hosts. Now the network scale is becoming larger and larger, Large-scale Distributed Intrusion Detection Systems, which are IDSs that work in such environments, are the trends of IDSs evolution. This document describes a hierarchy framework for Large-scale Distributed Intrusion Detection Systems, with which a Large-scale Distributed IDS can be flexibly deployed. Each node in this framework can be seen as a simple IDS. This document gives a four-layer structure for the simple IDS. This four-layer structure can also be the structure of an independent IDS. "The Security Components Exchange Protocol(SCXP)", Yi Yang, 02-Jul-03, At present, various security components have appeared. All the security components should work together to establish a stronger defense architecture in the future, so it is necessary for these components to communicate with each other. This document describes the Security Components Exchange Protocol (SCXP), an application-level protocol for exchanging data between security components. SCXP supports mutual-authentication, integrity, confidentiality and replay protection over a connection-oriented protocol. Next Steps in Signaling (nsis) ------------------------------ "Requirements for Signaling Protocols", Marcus Brunner, 18-Jun-03, This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service such as The Resource Reservation Protocol, however in recent years several other applications of signaling have been defined such as signaling for label distribution in Multiprotocol Label Switching or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. "Next Steps in Signaling: Framework", Robert Hancock, 07-Mar-03, The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing and mobility. The different routing and mobility events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. "Security Threats for NSIS", Hannes Tschofenig, Dirk Kroeselberg, 27-Jan-03, This threats document provides a detailed analysis of the security threats relevant for the NSIS working group. It motivates and helps to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS protocols. "RSVP Security Properties", Hannes Tschofenig, 07-Mar-03, As the work of the NSIS working group has begun there are also concerns about security and its implication for the design of a signaling protocol. In order to understand the security properties and available options of RSVP a number of documents have to be read. This document tries to summarize the security properties of RSVP and to view them from a different point of view. This work in NSIS is part of the overall process of analyzing other protocols and to learn from their design considerations. This document should also provide a starting point for security discussions. "Analysis of Existing Quality of Service Signaling Protocols", Jukka Manner, Xiaoming Fu, 03-Feb-03, This document presents a review of existing protocols for signalling the Quality of Service requirements of flows to nodes in an IP network. Protocols are reviewed independently and not compared against the NSIS requirements document nor to RSVP itself. The purpose is to learn from existing work and to avoid common misconceptions about the protocols. A further goal is to avoid to redesign ideas already implemented in another protocol. "Requirements of a QoS Solution for Mobile IP", Hemant Chaskar, 18-Jun-03, Mobile IP ensures correct routing of packets to mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer, 03-Jun-03, This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Open Pluggable Edge Services (opes) ----------------------------------- "An Architecture for Open Pluggable Edge Services (OPES)", A Barbir, 12-Dec-02, This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. "Requirements for OPES Callout Protocols", Andre Beck, 12-Dec-02, This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluating possible protocol candidates as well as to guide the development of such protocols. "OPES Use Cases and Deployment Scenarios", A Barbir, 06-Aug-02, This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. "Policy, Authorization and Enforcement Requirements of OPES", A Barbir, 10-Feb-03, This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a given OPES flow. "Security Threats and Risks for Open", A Barbir, 10-Feb-03, The document investigates the security threats associated with OPES. The effects of security threats on the underlying architecture are discussed. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. "OPES Callout Protocol Core", Alex Rousskov, 09-Jun-03, This document specifies Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP is an application-agnostic protocol that facilitates exchange of application messages between an OPES processor and a callout server, for the purpose of adaptation of application messages at the callout server. "OPES processor and end points communications", A Barbir, 11-Jun-03, This memo documents tracing requirements for Open Pluggable Edge Services (OPES) "OPES Treatment of IAB Considerations", A Barbir, Alex Rousskov, 12-Jun-03, IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations when Open Pluggable Edge Services (OPES) working group was being chartered at the IETF. The working group was chartered under the condition that IAB considerations were addressed by the group. This document describes how OPES addresses those considerations. Operations & Management Open Area (opsarea) ------------------------------------------- "Guidelines for MIB Authors and Reviewers", C.M. Heard, 24-Feb-03, This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may used as a basis for reviews of other MIB documents. "Textual Conventions for IPv6 Flow Label", Bert Wijnen, 22-May-03, This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. "Textual Conventions for Internet Network Addresses", Michael Daniele, 25-Feb-03, This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. This document obsoletes RFC 3291. Open Shortest Path First IGP (ospf) ----------------------------------- "Traffic Engineering Extensions to OSPF Version 2", Dave Katz, Derek Yeung, Kireeti Kompella, 18-Jun-03, This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering, using Opaque Link State Advertisements. "Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, Sebastian Zwolinski, Jacek Kwiatkowski, 07-Apr-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol for IPv6. Please send comments to ospf@discuss.microsoft.com. "OSPF Refresh and Flooding Reduction in Stable Topologies", Padma Pillay-Esnault, 17-Jun-03, This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements in stable topologies. The OSPF current behavior requires that all LSAs other than DoNotAge LSAs to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs to reduce protocol traffic in stable topologies "OSPF Version 2 Management Information Base", Spencer Giacalone, Dan Joyal, Rob Coltun, Fred Baker, 16-Apr-03, 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 Open Shortest Path First Routing Protocol. This memo is intended to update and possibly obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1580 are explained in Appendix B. Please send comments to ospf@discuss.microsoft.com. "Detecting Inactive Neighbors over OSPF Demand Circuits", Sira Rao, Alex Zinin, Abhay Roy, 04-Feb-03, OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits is optimized in RFC1793 to minimize the amount of overhead traffic. A part of OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect a OSPF-inactive neighbor over such a link. This memo addresses the above problem by the neighbor probing mechanism. "Graceful OSPF Restart", John Moy, 26-Mar-03, This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called 'graceful restart' or 'non-stop forwarding'. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance", G Choudhury, 29-May-03, This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Simulation results in support of some of the recommendations are given in the appendix sections. "Authentication/Confidentiality for OSPFv3", Mukesh Gupta, Nagavenkata Melam, 18-Apr-03, This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. "Traffic Engineering Extensions to OSPF version 3", Kunihiro Ishiguro, Toshiaki Takada, 17-Apr-03, This document describes extensions to the OSPF version 3 to support intra-area Traffic Engineering. This document expands OSPFv2 traffic engineering to make both IPv4 and IPv6 network applicable. New sub-TLVs are defined to support IPv6 network. Use of these new sub-TLVs are not limited in OSPF version 3. They can be used in OSPF version 2. "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", Eric Rosen, 23-Jun-03, [VPN] describes a method by which a Service Provider (SP) may provide an 'IP VPN' service to its customers. In VPNs of that sort, a Customer Edge (CE) Router and a Provider Edge Router become routing peers, and the customer routes are sent to the SP. BGP is then used to carry the customer routes across the SP's backbone to other PE routers, and the routes are then sent to other CE routers. Since CE routers and PE routers are routing peers, it is customary to run a routing protocol between them. [VPN] allows a number of different PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the PE must execute additional procedures not specified in [VPN]; these procedures are specified in [OSPF-VPN]. These additional procedures translate customer OSPF routes from a CE router into BGP routes. The BGP routes are sent to the other PE routers, which translate them back into OSPF routes, and then distribute them to CE routers. During this translation, some of the information needed to prevent loops may be lost. The procedures specified in this document remedy this situation by specifying that one of the OSPF options bits be used to ensure that when a VPN route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Problem Statement and Usage Scenarios for PANA", Yoshihiro Ohba, 29-Apr-03, Network access authentication is a function that is typically required in most scenarios. This is accomplished in most networks via protocols such as PPP, PPPoE, IEEE 802.1X and others. The PANA (Protocol for carrying Authentication for Network Access) WG is considering the network access authentication function being performed at or above the IP layer. This document captures the various usage scenarios/applicability of a protocol that is used for network access authentication that is at layer-3 or above and additionally identifies the problem being addressed by the WG. "Protocol for Carrying Authentication for Network Access (PANA)Requirements", Alper Yegin, Yoshihiro Ohba, 20-Jun-03, It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. "PANA Threat Analysis and security requirements", Mohan Parthasarathy, 19-May-03, The PANA (Protocol for carrying authentication for Network Access) working group is developing methods for authenticating clients to the access network using IP based protocols. This document discusses the threats to such protocols. The security requirements arising out of these threats will be used as additional input to the PANA WG for designing the IP based network access authentication protocol. "Protocol for Carrying Authentication for Network Access (PANA)", Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin, 03-Apr-03, This document defines the Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method, and can be used on any link that can carry IP. PANA covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. Performance Implications of Link Characteristics (pilc) ------------------------------------------------------- "Advice for Internet Subnetwork Designers", Phil Karn, 19-Feb-03, This document provides advice to the designers of digital communication equipment, link-layer protocols and packet-switched subnetworks (collectively referred to as subnetworks) who wish to support the Internet protocols but who may be unfamiliar with Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document represents a consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group. Protocol Independent Multicast (pim) ------------------------------------ "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Mark Handley, Isidor Kouvelas, Tony Speakman, Lorenzo Vicisano, 20-Jun-03, This document discusses Bi-directional PIM, a variant of PIM Sparse-Mode [9] that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides a default route to the RP thus eliminating the requirement for data-driven protocol events. "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, 06-Mar-03, This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Bill Fenner, 03-Mar-03, This document specifies the Bootstrap Router (BSR) mechanism for Protocol Independent Multicast - Sparse Mode (PIM-SM). BSR is one way that a PIM-SM router can learn the set of group-to-RP mappings required in order to function. "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Andy Adams, Jonathan Nicholas, William Siadak, 12-Feb-03, This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. "Protocol Independent Multicast MIB", Jonathan Nicholas, 01-Nov-02, 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 the Protocol Independent Multicast (PIM) protocol. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure:Roadmap", Alfred Arsenault, Sean Turner, 26-Jul-02, 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 Public Key Infrastructure, Privilege Management Infrastructure (PMI), and Time Stamping and Data Certification Infrastructures. It identifies each document developed by the PKIX working group, and describes the relationships among the various documents. 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. "Simple Certificate Validation Protocol (SCVP)", Ambarish Malpani, Russell Housley, Trevor Freeman, 30-Jun-03, SCVP allows a client to offload certificate handling to a server. The server can provide the client with a variety of valuable information about the certificate, such as whether the certificate is valid, a certification path to a trust anchor, and revocation status. SCVP has many purposes, including simplifying client implementations and allowing companies to centralize trust and policy management. "Internet X.509 Public Key Infrastructure Certificate Management Protocols", Carlisle Adams, Stephen Farrell, 15-Apr-03, This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides online interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. "Internet X.509 Public Key Infrastructure Permanent Identifier", Denis Pinkas, Thomas Gindin, 04-Dec-02, This document define a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that the certificate relates to the same entity even if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. Also, the new name form can carry a name that is unique for each subject entity certified by a CA. "Internet X.509 Public Key Infrastructure Repository Locator Service", Sharon Boeyen, Phillip Hallam-Baker, 22-Nov-02, This document defines a PKI repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", Michael Myers, Carlisle Adams, Dave Solo, David Kemp, 15-Apr-03, 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. "Internet X.509 Public Key Infrastructure Proxy Certificate Profile", Steven Tuecke, 09-May-03, This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", Santosh Chokhani, 25-Apr-03, This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. 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 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: Logotypes in X.509 certificates", Stefan Santesson, Russell Housley, Trevor Freeman, 06-Mar-03, This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. Please send comments on this document to the ietf-pkix@imc.org mailing list. "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", Peter Gutmann, 24-Mar-03, 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 Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. "Policy Requirements for Time-Stamping Authorities", Denis Pinkas, N Pope, J Ross, 07-Apr-03, This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in the current document. Such a policy shall incorporate or further constrain the requirements identified in the current document. The contents of this Informational RFC is technically equivalent to ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023]. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org "Internet X.509 Public Key Infrastructure Warranty Certificate Extension", Duane Linsenbardt, Sue Pontius, Alice Sturgeon, 27-Jun-03, This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for a the certificate containing the extension. "Attribute Certificate Policies extension", Christopher Francis, Denis Pinkas, 07-Apr-03, This document describes one certificate extension to explicitly state the Attribute Certificate (AC) policies that apply to a given Attribute Certificate. "Certificate Extensions and Attributes Supporting Authentication in PPP and Wireless LAN", Russell Housley, Tim Moore, 16-Dec-02, This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). "Certificate Validation Protocol", Denis Pinkas, 20-Jan-03, This document defines a protocol called Certificate Validation Protocol (CVP) that can be used to: (1) query the validation or discovery policies supported by a CVP server, (2) validate one or more public key certificates according to a single validation policy, or (3) obtain one or more certification paths for one or more certificates according to a single discovery policy. "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", Jeong Park, 01-Nov-02, This document provides the new straightforward approach to generate and verify unique information for identifying of the certificate subject. A Virtual ID(VID) may be put into the 'othername' field of the X.509 subjectAltName certificate extension to make provisions for identifying the subject. "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, version 2", Michael Myers, Ambarish Malpani, Denis Pinkas, 12-Dec-02, The Online Certificate Status Protocol (OCSP) enables applications to determine on line the revocation status of a certificate. This document specifies one extension for the OCSP protocol and defines a version v2 for that protocol which allows additional means to designate the certificate for which the revocation status is requested. It also allows to ask for the revocation status of either a public key certificate (PKC) or an attribute certificate (AC). "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Russell Housley, Burton Kaliski, 06-Jan-03, This document supplements RFC 3279. It describes the conventions for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm, and additional one-way hash functions with the PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. "NIST Recommended EC Domain Parameters For PKIX", Daniel Brown, 06-Jan-03, This document gives the object identifiers for the elliptic curve domain pararmeters that the National Institute of Standards and Techology recommends in its publication 'Digital Signature Standard "DPV and DPD over OCSP", Michael Myers, 09-Jan-03, This specification standardizes means by which the extensibility mechanisms of OCSP are to be used for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). Familiarity with OCSP core syntax [RFC2560] is assumed. "Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs", David Chadwick, Mikhail Sahalayev, 10-Feb-03, This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry. An object class is defined for this CRL entry. Each attribute type uses an existing LDAP syntax, so that new matching rules do not need to be defined. "Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates", David Chadwick, Mikhail Sahalayev, 14-Feb-03, This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. "Trusted Archive Protocol (TAP)", Carl Wallace, Santosh Chokhani, 19-Feb-03, A Trusted Archive Authority (TAA) is a service that supports long- term non-repudiation by maintaining secure storage of cryptographically refreshed information. This document defines a set of transactions for interacting with a Trusted Archive Authority (TAA) and establishes a means of representing archived information. "Internet X.509 Public Key Infrastructure:Qualified Certificates Profile", Stefan Santesson, Magnus Nystrom, 05-Mar-03, This document forms a certificate profile, based on RFC 3280, for dentity certificates issued to physical persons. The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. The profile does however not define any legal requirements for such Qualified Certificates. Policy Framework (policy) ------------------------- "Policy Core LDAP Schema", John Strassner, Robert Moore, Ryan Moats, Ed Ellesson, 11-Oct-02, This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. "Policy QoS Information Model", Yoram Snir, Yoram Ramberg, John Strassner, Ron Cohen, Bob Moore, 06-May-03, This document presents an object-oriented information model for representing policies that administer, manage, and control access to network QoS resources. This document is based on the IETF Policy Core Information Model and its extensions. This defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol. "Information Model for Describing Network Device QoS Datapath Mechanisms", Bob Moore, David Durham, John Strassner, Andrea Westerinen, Walter Weiss, 27-May-03, The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This documenthis document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two drafts describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- "Derivating Keys for use with Microsoft Point-to-Point Encryption (MPPE)", Glen Zorn, 01-Nov-00, 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. "Class Extensions for PPP over ATM Adaptation Layer 2", B Thompson, bruce Buffam, Tmima Koren, 04-Feb-02, PPP over ATM Adaptation Layer 2 defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the AAL2 adaptation layer. This document defines a set of class extensions to PPP over AAL2 that implement equivalent functionality to Multi Class Multi Link PPP over a single ATM virtual circuit. Instead of using Multi Link PPP as the basis for fragmentation functionality, this document uses the functionality of the Segmentation and Reassembly Service Specific Convergence Sublayer that is already required as the basic encapsulation format of PPP over AAL2. "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Paul Funk, Simon Blake-Wilson, 07-Nov-02, EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. "PPP IPV6 Control Protocol Extensions for DNS Server Addresses", Tom Hiller, Glen Zorn, 16-Jun-03, The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol 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 Version 6 of the Internet Protocol (IPV6) over PPP, defining the negotiation of primary and secondary Domain Name System (DNS) server IPV6 addresses. Provider Provisioned Virtual Private Networks (ppvpn) ----------------------------------------------------- "Service requirements for Layer 3 Provider Provisioned Virtual Private Networks:", Marco Carugi, David McDysan, 16-Apr-03, This document provides requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use for the provisioning of a VPN service. This document expresses a service provider perspective, based upon past experience of IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer as well as a service provider perspective. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Ross Callon, Muneyoshi Suzuki, 26-Mar-03, This document provides a framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy De Clercq, 07-Mar-03, This document describes the procedures for a Service Provider to offer Virtual Private Network Services to its customers by provisioning the CE devices on behalf of the customer. The IPsec technology is used to protect the customer traffic. "BGP-MPLS VPN extension for IPv6 VPN", Tri Nguyen, 07-Nov-02, This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method extends the 'BGP/MPLS VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding route distribution in 'Multiprotocol BGP'. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IPsec, IP-in-IP and GRE. "MPLS/BGP Virtual Private Network Management Information Base Using SMIv2", Thomas Nadeau, 06-Nov-02, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, in response to customer demands and strong input from vendors, it describes managed objects for modeling and managing Multi-Protocol Label Switching (MPLS) [MPLSArch]/Border Gateway Protocol (BGP) Virtual Private Networks (VPNs) [RFC2547bis]. "BGP/MPLS VPNs", Eric Rosen, 02-Jun-03, This document describes a method by which a Service Provider may use an IP backbone to provide VPNs (Virtual Private Networks) for its customers. This method uses a 'peer model', in which the customers' edge routers ('CE routers') send their routes to the Service Provider's edge routers ('PE routers'). BGP is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute, to the CE routers in a particular VPN, the routes from other the CE routers in that VPN. The CE routers do not peer with each other, hence there is no 'overlay' visible to the VPN's routing algorithm. Each route within a VPN is assigned an MPLS label; when BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the Service Provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route that is the best match to the packet's destination address. This MPLS packet is further encapsulated (e.g., with another MPLS label, or with an IP or GRE tunnel header) so that it gets tunneled across the backbone to the proper PE router. Thus the backbone core routers do not need to know the VPN routes. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider which uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. This document obsoletes RFC 2547. "Use of PE-PE IPsec in RFC2547 VPNs", Eric Rosen, 06-Feb-03, [RFC2547bis] specifies a particular way of implementing Layer 3 VPNs. It presupposes the use of MPLS Label Switched Paths (LSPs) for carrying VPN traffic between Provider Edge (PE) routers, and specifies the use of two labels in the MPLS label stack. In some circumstances, it is desirable to support the same type of VPN architecture, using an IPsec Security Association in place of an MPLS LSP, thus replacing the topmost of the two MPLS labels with an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of RFC2547bis VPNs using the IPsec encapsulation. "Use of PE-PE GRE or IP in RFC2547 VPNs", Yakov Rekhter, Eric Rosen, 31-Mar-03, This draft describes a variation of RFC2547 [RFC2547] in which the outermost MPLS label of a VPN packet is replaced with either IP or a GRE encapsulation. This enables the VPN packets to be carried over non-MPLS networks. "Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs", Hamid Ould-Brahim, 13-May-03, In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for both layer-2 VPN architectures and layer-3 VPNs ([VPN-VR]). This mechanism is based on the approach used by [RFC2547-bis] for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. "Network based IP VPN Architecture using Virtual Routers", Hamid Ould-Brahim, 05-May-03, This draft describes a network-based VPN architecture using virtual routers. The VPN service is built based on the virtual router (VR) concept, which has exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Within a VPN domain, an instance of routing is used to distribute VPN reachability information among VR routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers. "Virtual Router Management Information Base Using SMIv2", Elwin Stelzer, S Hancock, Benson Schliesser, Joseph Laria, 01-Jul-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In paticular, it defines objects for managing networks using Virtual Routers (VR). "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management", Benson Schliesser, Thomas Nadeau, 06-Nov-02, This document describes Textual Conventions used for managing PPVPNs. "Requirements for Virtual Private LAN Services (VPLS)", Waldemar Augustyn, 04-Nov-02, This draft describes service requirements related to emulating a virtual private LAN over an IP or MPLS network infrastructure. The service is called VPLS. It is a class of Provider Provisioned Virtual Private Network [2]. The general requirements can be found in [3]. "Applicability Statement for VPNs Based on rfc2547bis", Eric Rosen, 14-Jan-03, This document provides an Applicability Statement for the VPN solution described in [2547bis] and other documents listed in the References section. "Guidelines of Applicability Statements for PPVPNs", Junichi Sumimoto, 27-Jun-03, This document plays a role of guidelines to assist development of applicability statements for each specific Layer 2 and Layer 3 PPVPN approach. It provides a check-list which consists of metrics, each of which is intended to clearly point out what must be evaluated and written in each approach specific applicability statement document. "L2VPN Framework", Loa Andersson, Eric Rosen, 03-Mar-03, This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable Layer 2 PPVPNs. "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", Ananth Nagarajan, 01-Jul-03, This document is an applicability statement for Layer 3 Provider Provisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR) approaches. This document describes how VR-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document. "CE-to-CE Member Verification for Layer 3 VPNs", Ronald Bonica, Yakov Rekhter, 10-Feb-03, This document describes a CE-based verification mechanism that PPVPN customers can use to detect security breaches caused by misconfiguration of the provider network. "Generic Requirements for Provider Provisioned VPN", Ananth Nagarajan, 15-Jan-03, This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Waldemar Augustyn, Yetik Serbest, 02-May-03, This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint to multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. "Virtual Private LAN Service", Kireeti Kompella, 26-May-03, Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 VPN; however, in the case of VPLS, the customers in the VPN are connected by a multipoint network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, and proposes a mechanism for signaling a VPLS, as well as for forwarding VPLS frames across a packet switched network. "Virtual Private LAN Services over MPLS", Marc Lasserre, 24-Jun-03, This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling demultiplexor labels, extending [PWE3-CTRL] and rudimentary support for availability (multi-homing). It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3- ETHERNET]. Problem Statement (problem) --------------------------- "IETF Problem Statement", Elwyn Davies, 12-May-03, This memo summarizes perceived problems in the structure, function and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to May 2003. The problem list has been further analyzed to try and determine the root causes, that are at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to determine the structures and processes that will carry out the corrections. "IETF Problem Resolution Processes", Margaret Wasserman, 12-May-03, This document suggests processes to address the problems identified in the IETF Problem Statement. This document decomposes each of the problems described in the problem statement into a few areas for improvement, categorizes those areas into longer-term and near-term problems, and suggests processes to address each area. Provisioning Registry Protocol (provreg) ---------------------------------------- "Extensible Provisioning Protocol", Scott Hollenbeck, 21-Mar-03, This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. "Extensible Provisioning Protocol Contact Mapping", Scott Hollenbeck, 24-Apr-03, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as 'contacts') stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts. "Extensible Provisioning Protocol Domain Name Mapping", Scott Hollenbeck, 24-Apr-03, This document describes an Extensible Provisioning Protocol (EPP) map- ping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names "Extensible Provisioning Protocol Host Mapping", Scott Hollenbeck, 24-Apr-03, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. "Extensible Provisioning Protocol Transport Over TCP", Scott Hollenbeck, 29-Jan-03, This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) Protocol to protect information exchanged between an EPP client and an EPP server. "Guidelines for Extending the Extensible Provisioning Protocol", Scott Hollenbeck, 30-May-03, The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. Packet Sampling (psamp) ----------------------- "A Framework for Passive Packet Measurement", Nick Duffield, 05-Mar-03, A wide range of traffic engineering and troubleshooting tasks rely on reliable, timely, and detailed traffic measurements. We describe a framework for passive packet measurement that is (a) general enough to serve as the basis for a wide range of operational tasks, and (b) needs only a small set of packet selection operations that facilitate ubiquitous deployment in router interfaces or dedicated measurement devices, even at very high speeds. Comments on this document should be addressed to the PSAMP WG mailing list: psamp@ops.ietf.org To subscribe: psamp-request@ops.ietf.org, in body: subscribe Archive: https://ops.ietf.org/lists/psamp/ "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, Maurizio Molina, Fredric Raspall, Nick Duffield, 27-Jun-03, This document describes sampling and filtering techniques for IP packet selection. It introduces information models for packet sampling, for packet filtering and for combinations of methods. The information models describe what information has to be specified in order to describe the method. This information is used for configuring the selection technique in measurement processes and for reporting the technique in use to the measurement data collection process. The document first suggests some terminology, then it describes in detail packet sampling and packet filtering techniques and their parameters. It also describes how these two techniques can be combined to build more elaborate packet selectors. Finally, it introduces information models for the most common sampling and filtering techniques. The document first suggests some terminology, then it describes in detail packet sampling and packet filtering techniques and their parameters. It also describes how these two techniques can be combined to build more elaborate packet selectors. Finally, it introduces information models for the most common sampling and filtering techniques. "Definitions of Managed Objects for Packet Sampling", Thomas Dietz, 25-Jun-03, This memo defines managed objects for packet sampling. These objects provide information about managed nodes supporting packet sampling, including packet sampling capabilities, configuration and statistics. They also allow to configure packet sampling concerning the IP interface at which packets are sampled, the packet selections methods used for sampling, and the collector to which packet samples are exported. Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) ------------------------------------------------------------------------- "NOPEER community for BGP route scope control", Geoff Huston, 13-May-03, This document describes the use of a scope control BGP community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. "Controlling the redistribution of BGP routes", Olivier Bonaventure, 19-Feb-03, This document proposes the redistribution extended community. This new extended community allows a router to influence how a specific route should be redistributed towards a specified set of eBGP speakers. Several types of redistribution communities are proposed. The first type may be used to indicate that a specific route should not be announced over a specified set of eBGP sessions. The second type may be used to indicate that the attached route should only be announced with the NO_EXPORT community over the specified set of eBGP sessions and the third type may be used to indicate that the attached route should be prepended n times when announced over a specified set of eBGP sessions. Pseudo Wire Emulation Edge to Edge (pwe3) ----------------------------------------- "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", X Xiao, 01-Jul-03, This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e. 'synchronous bit streams at rates defined by ITU G.702') are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. "Pseudo Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, Dave Danenberg, Sharon Mantin, 17-Jun-03, 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 modeling of Pseudo Wire (PW) services on a general Packet Switched Net (PSN). "Pseudo Wire (PW) over MPLS PSN Management Information Base", David Zelig, Thomas Nadeau, Dave Danenberg, 17-Jun-03, 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 MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). "Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management", Thomas Nadeau, Dave Danenberg, David Zelig, Andrew Malis, 17-Jun-03, 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 the textual conventions to be used in the various Pseudo Wire (PW) MIB modules. "SONET/SDH Circuit Emulation over Packet (CEP)", Andrew Malis, 01-Jul-03, The generic requirements and architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3- ARCH]. Additional requirements for emulation of SONET/SDH and lower-rate TDM circuits has been defined in [PWE3-TDM-REQ]. This draft provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over a packet-switched network (PSN). "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", Luca Martini, 02-Jul-03, An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. "Pseudowire Setup and Maintenance using LDP", Luca Martini, Nasser El-Aawar, Eric Rosen, 02-Jul-03, Layer 2 services (such as Frame Relay, ATM, ethernet) can be 'emulated' over an IP and/or MPLS backbone by encapsulating the layer 2 PDUs and then transmitting them over 'pseudowires'. It is also possible to use pseudowires to provide SONET circuit emulation over an IP and/or MPLS network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to LDP. Procedures for encapsulating layer 2 PDUs are specified in a set of companion documents. "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2", David Zelig, Andrew Malis, 04-Nov-02, 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 modeling Native Service Processing of SONET/SDH circuits over a Packet Switch Network (PSN). "Ethernet Pseudo Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, 17-Jun-03, 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 modeling of Ethernet Pseudo Wire (PW) services. "PWE3 Architecture", Stewart Bryant, Prayson Pate, 16-Jun-03, This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, specifies the various protocol elements and their functions. "PWE3 Fragmentation and Reassembly", Andrew Malis, W. Mark Townsley, 18-Jun-03, This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. "Frame Relay over Pseudo-Wires", Claude Kawa, 22-Oct-02, This document defines frame relay pseudo-wire emulation edge-to-edge. A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over IP and MPLS packet switched network (PSN). Two mapping modes are defined: One-to-one mapping mode characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs is defined for MPLS PSN. The other mode is known as port mode or many-to-one mapping mode and is defined for MPLS PSN and IP PSN with L2TPv3. "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks", Luca Martini, 01-Jul-03, A framework for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [3]. This draft provides encapsulation formats and guidelines for transporting a variety of ATM services over a PSN. "Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)", Maximilian Riegel, 10-Feb-03, This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits. "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", Luca Martini, W. Mark Townsley, 16-Jun-03, The Control and maintenance protocol for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [2]. This document pre-allocates the fixed Pseudo-wire identifier , and other fixed protocol values that are to be assigned by IANA using the 'IETF Consensus' policy defined in RFC2434 "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and MPLS Networks", Luca Martini, 16-Jun-03, A Pseudowire (PW) can be used to carry PPP, or HDLC Protocol Data Units over an IP or MPLS network without terminating the PPP/HDLC protocol. This enables service providers to offer 'emulated' HDLC, or PPP link services over existing IP or MPLS networks. This document specifies the encapsulation of PPP/HDLC PDUs within a pseudowire. Resource Allocation Protocol (rap) ---------------------------------- "COPS Over TLS", Jesse Walker, Amol Kulkarni, 27-May-03, This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. "Framework Policy Information Base for Usage Feedback", Diana Rawlins, 07-Apr-03, This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects that usage information is collected from. "Framework for Binding Access Control to COPS Provisioning", Walter Weiss, 08-Nov-02, There is an ever-growing distinction between edge and core functionality. While the core continues to focus on stability and pure forwarding functionality, the edges increasingly need to deal with dynamic capabilities like QoS management, VPN encapsulations, encryption, dynamic steering and service monitoring. The dynamic deployment of these functions is dependent on specific contextual knowledge such as the physical location of the data stream and the identity of the client or system generating the data. Remote Direct Data Placement (rddp) ----------------------------------- "Stream Control Transmission Protocol (SCTP) Remote Direct Memory Access (RDMA) Direct Data Placement (DDP) Adaption", Randall Stewart, 26-Feb-03, This document describes a method to adapt Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) to Stream Control Transmission Protocol (SCTP) RFC2960 [2] using a generic description found in [RDMA-Draft] [4] and [DDP-Draft] [3]. "DDP and RDMA Concerns", David Black, 02-Dec-02, This draft describes technical concerns that should be considered in the design of standardized RDMA and DDP protocols/mechanisms for use with Internet transport protocols. This draft was written to provide input to the proposed new Remote Direct Data Placement (rddp) WG, and is not intended for publication as an RFC. This is an updated version of draft-black-rdma-concerns-00.txt to change its name and expand Section 4.1 to incorporate an application integrity issue raised on the rddp mailing list. "The Architecture of Direct Data Placement (DDP)And Remote Direct Memory Access (RDMA)On Internet Protocols", Stephen Bailey, Thomas Talpey, 27-Jun-03, This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g. RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. "RDMA over IP Problem Statement", Allyn Romanow, Jeffrey Mogul, Thomas Talpey, Stephen Bailey, 27-Jun-03, This draft addresses an IP-based solution to the problem of high system costs due to network I/O copying in end-hosts at high speeds. The problem is due to the high cost of memory bandwidth, and it can be substantially improved using 'copy avoidance.' The high overhead has limited the use of TCP/IP in interconnection networks especially where high bandwidth, low latency and/or low overhead of end-system data movement are required by the hosted application. "An RDMA Protocol Specification", Renato Recio, 19-Feb-03, This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into ULP Buffers without intermediate data copies. It also enables a kernel bypass implementation. "Direct Data Placement over Reliable Transports", Himanshu Shah, 24-Feb-03, The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. "Applicability of Remote Direct Memory Access Protocol (RDMA)and Direct Data Placement (DDP)", Caitlin Bestler, Lode Coene, 12-Jun-03, This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It contrasts the different transport options over IP that DDP can use, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. Resource Capabilities Discovery (rescap) ---------------------------------------- "ResCap Requirements", John Beck, 24-Jun-02, A variety of resource identifiers have been widely deployed on the Internet as a means of identifying various resources, services, and destinations. However, a means of attaching a set of attributes or characteristics to a given resource identifier and subsequently assessing those attributes or characteristics has not been specified and deployed. Two tasks are envisioned. The first task will be to define a general resolution protocol that will translate resource identifiers to a list of attributes. The second task will be to define an administrative model and update protocol that can be used to set up and maintain the information the resolution protocol accesses. "RESCAP Scenarios", Graham Klyne, 11-Jan-02, This memo explores some scenarios for the resource capabaility discovery protocol (RESCAP). It is intended to provide some grounding in specific use-cases for decisions about RESCAP goals and design. Remote Network Monitoring (rmonmib) ----------------------------------- "Application Performance Measurement MIB", Steven Waldbusser, 02-Jul-03, 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 measuring the application performance as experienced by end- users. "Transport Performance Metrics MIB", Russell Dietz, Robert Cole, 27-Jun-03, 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 monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics are defined through reference to existing IETF, ITU and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. s. "Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms.", Carl Kalbfleisch, Robert Cole, Dan Romascanu, 27-Jun-03, 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 for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", Steven Waldbusser, 04-Jun-03, The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Anwar Siddiqui, Dan Romascanu, 04-Jun-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB - RFC 2819. In particular, it describes managed objects used for real-time application QOS monitoring. Distribution of this memo is unlimited. "Real-time Application Quality of Service Monitoring (RAQMON) Framework", Anwar Siddiqui, 10-Jun-03, There is a need to extend the RMON framework to monitor end devices such as IP Phones, Pagers, Instant Message Clients, Mobile Phones, and various other Hand held computing devices. This memo extends RMON Framework to allow Real-time QoS Monitoring of various Applications that run on these types of end devices and allows such information be integrated with RMON Framework via SNMP. Distribution of this memo is unlimited. Distribution of this memo is unlimited. "Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU)", Anwar Siddiqui, 10-Jun-03, This memo defines a common protocol data unit (PDU) used between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC) to report QOS statistics using RTCP and SNMP as Transport Protocols. This memo also outlines mechanisms to use the Real Time Transport Control Protocol (RTCP) and the Simple Network Management Protocol (SNMP) to transport these PDUs between RAQMON Data Source (RDS) and RAQMON Report Collector (RRC). Distribution of this memo is unlimited. Reliable Multicast Transport (rmt) ---------------------------------- "Reliable Multicast Transport Building Block: Tree Auto-Configuration", Brian Whetten, Seok Koh, 13-Feb-03, The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL01][HWKFV00]. "NACK-Oriented Reliable Multicast (NORM) Building Blocks", Brian Adamson, Carsten Bormann, Mark Handley, Joseph Macker, 09-Jun-03, This document discusses the creation the of negative-acknowledgment This document discusses the creation the of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional 'building blocks' that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. "NACK-Oriented Reliable Multicast Protocol (NORM)", Brian Adamson, Carsten Bormann, Mark Handley, Joseph Macker, 09-Jun-03, This document describes the messages and procedures of the Negative- acknowledgement (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgement mechanism for transport reliability and offers additional protocol mechanisms to conduct reliable multicast sessions with limited 'a priori' coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) from the senders to receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. "Reliable Multicast Transport Building Block for TRACK", Brian Whetten, Dah Ming Chiu, 27-Nov-02, This document describes the TRACK Building Block. It contains functions relating to positive acknowledgments and hierarchical tree construction and maintenance. It is primarily meant to be used as part of the TRACK Protocol Instantiation. It is also designed to be useful as part of overlay multicast systems that wish to offer efficient confirmed delivery of multicast messages. "PGMCC single rate multicast congestion control: Protocol Specification", Luigi Rizzo, Gianluca Iannaccone, Lorenzo Vicisano, Mark Handley, 01-Jul-03, This document describes PGMCC, a single rate multicast congestion control scheme which is TCP-friendly and achieves scalability, stability and fast response to variations in network conditions. PGMCC is suitable for both non-reliable and reliable data transfers. It is mainly designed for NAK- based multicast protocols, and uses a window-based, TCP-like control loop using positive ACKs between one representative of the receiver group (the ACKER) and the sender. The ACKER is selected dynamically and may change over time. PGMCC is made of two components: a window-based control loop, which closely mimics TCP behaviour, and a fast and low- overhead procedure to select (and track changes of) the ACKER. The scheme is robust to measurement errors, and supports fast response to changes in the receiver set and/or network conditions. "Wave and Equation Based Rate Control building block", Michael Luby, Vivek Goyal, 11-Dec-02, Wave and Equation Based Rate Control provides rate and congestion control for data delivery. Wave and Equation Based Rate Control is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion- controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. Wave and Equation Based Rate Control requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. "TCP-Friendly Multicast Congestion Control (TFMCC):Protocol Specification", Joerg Widmer, Mark Handley, 04-Nov-02, This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications such as streaming media where a relatively smooth sending rate is of importance. "Reliable Multicast Transport Building Block Generic Router Assist - Signalling Protocol Specification", Tony Speakman, Lorenzo Vicisano, 21-Jan-03, This draft specifies the signalling protocol to be implemented in both end systems and network elements to activate built-in GRA functionality in network elements. It specifies this protocol specifically in the context of UDP as well as generally in the context of prospective (reliable multicast) transport protocols for IP. "Compact Forward Error Correction (FEC) Schemes", Michael Luby, Lorenzo Vicisano, 14-May-03, This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452 [6]. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, 12-Jun-03, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. Robust Header Compression (rohc) -------------------------------- "Requirements for ROHC IP/TCP Header Compression", Lars-Erik Jonsson, 13-Jun-03, This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the ROHC WG. The document discusses the scope of TCP compression, performance considerations, assumptions on the surrounding environment, as well as IPR concerns. The structure of this document is inherited from the document defining RTP/UDP/IP requirements for ROHC. "Definitions of Managed Objects for Robus Header Compression", Juergen Quittek, 06-Mar-03, 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 monitoring of running instances of robust header compression. The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP profile, the ROHC UDP profile, and the ROHC ESP profile. "RObust Header Compression (ROHC): TCP/IP Profile (ROHC-TCP)", Ghyslain Pelletier, Qili Zhang, Lars-Erik Jonsson, HongBin Liao, Mark West, 23-May-03, This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. Existing TCP/IP header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common. In addition, existing schemes [RFC-1144, RFC-2507] have not addressed how to compress TCP options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-2883] and Timestamps [RFC-1323]. "ROHC Implementer's Guide", Lars-Erik Jonsson, Peter Kremer, 04-Mar-03, This document describes common misinterpretations and some ambiguous points of ROHC [RFC 3095], which defines the framework and four profiles of a robust and efficient header compression scheme. These points have been identified by the members of the ROHC working group during different interoperability test events. "Requirements for RoHC IP/SCTP Robust Header Compression", Christian Schmidt, Michael Tuexen, 14-Feb-03, This document contains requirements for the IP/SCTP header compression scheme (profile) to be developed by the ROHC WG. The structure of this document is inherited from the document defining IP/TCP requirements for ROHC. "TCP/IP Field Behavior", Mark West, Steven McCanne, 06-Mar-03, This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible thanks to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095 [31]. This memo performs a similar role for the compression of TCP/IP. "RObust Header Compression (ROHC):Terminology and Channel Mapping Examples", Lars-Erik Jonsson, 13-Feb-03, RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms like network elements and IP interfaces, commonly used for example when addressing MIB issues. "Interoperability of RFC 3095", Lars-Erik Jonsson, 16-Apr-03, RFC 3095 defines a Proposed Standard protocol for RObust Header Compression (ROHC). In order to move the standard further to Draft Standard status, it is required to demonstrate interoperability for all functionality defined by the RFC. This document outlines those features to be tested, and also the test status for each feature, based on reports from interoperability tests or other proof of interoperability. "RObust Header Compression (ROHC): A Compression Profile for IP", Lars-Erik Jonsson, Ghyslain Pelletier, 30-Jun-03, The original RObust Header Compression (ROHC) RFC, RFC 3095, defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. "ROHC-TCP: Unidirectional Operation Enhancements", Qian Zhang, 27-May-03, This document describes how to efficiently implement certain mechanisms of unidirectional operation in ROHC-TCP (robust header compression scheme for TCP/IP), RFC XXX, which can significantly improve the compression efficiency compared to using simple control scheme. All the operational modes and state machines mentioned in this document are the same as the ones described in [ROHC-TCP]. "Formal Notation for Robust Header Compression (ROHC-FN)", Richard Price, 07-Mar-03, This document defines ROHC-FN: a formal notation for specifying how to compress and decompress fields from an arbitrary protocol stack. ROHC-FN is intended to simplify the creation of new compression profiles to fit within the ROHC [RFC-3095] framework. "RObust Header Compression (ROHC):Profiles for UDP-Lite", Ghyslain Pelletier, 11-Apr-03, This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in [RFC-3095] for UDP [RFC-768]. Although both transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because it does not share protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field and as a consequence cannot always be inferred anymore. "Implementer's Guide for SigComp", Abigail Surtees, 27-Jun-03, This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. "SigComp User Guide", Richard Price, 17-Jun-03, This document provides an informational guide for users of the SigComp protocol. The aim of the document is to assist users when making SigComp implementation decisions; for example the choice of compression algorithm and the level of robustness against lost or misordered packets. "RObust Header Compression (ROHC):Context Replication for ROHC Profiles", Ghyslain Pelletier, 19-Jun-03, This document defines context replication, a complement to the context initialization procedure found in ROHC (Robust Header Compression) [RFC-3095]. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure, and may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as for example short- lived TCP flows. "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", Zhigang Liu, Richard Price, 20-Jun-03, This document describes some specifics when Signaling Compression (SigComp) [RFC-3320] is applied to the Session Initiation Protocol (SIP) [RFC-3261]. Any SigComp implementation that is used for SIP compression must follow this document, in addition to [RFC-3320] and [RFC-3485]. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "Generic Threats to Routing Protocols", A Barbir, Sandra Murphy, Yibin Yang, 06-May-03, Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. This document provides a description and a summary of generic threats that affects routing protocols in general. The work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. Reliable Server Pooling (rserpool) ---------------------------------- "Architecture for Reliable Server Pooling", Michael Tuexen, Q Xie, 01-Jul-03, This document describes an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. "Comparison of Protocols for Reliable Server Pooling", John Loughney, 02-Jul-03, This document compares protocols that may be applicable for the Reliable Server Pooling problem space. This document discusses the usage and applicability of these protocols for the Reliable Server Pooling architecture. "Aggregate Server Access Protocol (ASAP)", Randall Stewart, Q Xie, Maureen Stillman, Michael Tuexen, 16-May-03, Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Name Resolution Protocol (ENRP) [6] provides a high availability data transfer mechanism over IP networks. ASAP uses a name-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool Elements (PE) and Pool Users (PU) MUST have an accompanying transports mapping document. Note that ASAP messages passed between PE's and ENRP servers MUST use SCTP. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for name to address translation, load sharing management, and fault management while ENRP defines the high availability name translation service. "Enpoint Name Resolution Protocol (ENRP)", Q Xie, Randall Stewart, Maureen Stillman, 16-May-03, Endpoint Name Resolution Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture. Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. "Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution (ENRP) Parameters", Randall Stewart, Qiaobing Xie, Michael Tuexen, 16-May-03, This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution Protocol (ENRP) protocols defined within the Reliable Server Pooling (RSERPOOL) architecture. "Services Provided By Reliable Server Pooling", Phill Conrad, Peter Lei, 05-Nov-02, RSerPool [1] is a framework to provide highly available services between clients and servers. This is achieved by grouping servers into pools, each with an identifier and pooling policy. Three classes of entities are defined: Pool Users (clients), Pool Elements (servers), and Name Servers. This memo defines the services provided by this framework to upper layer protocols and applications for Pool Users and Pool Elements. It describes the service primitives that the framework provides and describes example scenarios. "TCP Mapping for Reliable Server Pooling Failover Mode", Phill Conrad, Peter Lei, 05-Nov-02, This memo defines the shim protocol that maps the requirements of the ASAP protocol [5] to the capabilities of the TCP protocol [7]. In particular, this shim protocol adds the following capabiltiies that are required by ASAP, but not provided by TCP: (1) message orientation, (2) heartbeat messages, (3) undelivered message retrieval, and (4) multiple streams. "Threats Introduced by Rserpool and Requirements for Security in response to Threats", Maureen Stillman, 12-Dec-02, This Internet draft is an attempt to describe security threats against the Rserpool protocol. This draft presents requirements for a security solution to thwart these threats in environments where it is likely to be deployed. The threats and requirements identified herein and the document should be considered as work in progress. "Reliable Server pool applicability Statement", Lode Coene, 20-Jun-03, This document describes the applicability of the reliable server pool architecture and protocols to applications which want to have High avialebility services. This is accomplished by using redundant servers and failover between servers of the same pool in case of server failure. Processing load in a pool may de distributed/shared between the members of the pool according to a certain policy. Also some guidance is given on the choice of underlying transport protocol (and corresponding transport protocol mapping) for transporting application data and Rserpool specific control data. "TCP Mapping for Reliable Server Pooling Failover Mode", Phill Conrad, Peter Lei, 26-Jun-03, This memo defines the shim protocol that maps the requirements of the ASAP protocol [5] to the capabilities of the TCP protocol [7]. In particular, this shim protocol adds the following capabiltiies that are required by ASAP, but not provided by TCP: (1) message orientation, (2) heartbeat messages, (3) multiple streams, and (4) undelivered message retrieval (if provided). Open Security Area Directorate (saag) ------------------------------------- "Encryption and Security Requirements for IETF Standard Protocols", Jeffrey Schiller, 11-Jul-01, It is the consensus of the IETF that IETF standard protocols MUST make use of appropriate strong security mechanisms. This document describes the history and rationale for this doctrine and establishes this doctrine as a best current practice. Securely Available Credentials (sacred) --------------------------------------- "Securely Available Credentials - Credential Server Framework", Dale Gustafson, Mike Just, Magnus Nystrom, 27-Jun-03, As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in [RFC3157] by presenting an abstract protocol framework "Securely Available Credentials Protocol", Stephen Farrell, 27-Jun-03, This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a BEEP profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). Simple Authentication and Security Layer (sasl) ----------------------------------------------- "The Anonymous SASL Mechanism", Kurt Zeilenga, 05-May-03, It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. "The Plain SASL Mechanism", Kurt Zeilenga, 05-May-03, This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. "Using Digest Authentication as a SASL Mechanism", Paul Leach, Chris Newman, Alexey Melnikov, 30-Jun-03, This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. "SASLprep: Stringprep profile for user names and passwords", Kurt Zeilenga, 27-May-03, This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. "Simple Authentication and Security Layer (SASL)", Alexey Melnikov, 30-Jun-03, SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 09-Jun-03, This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting (seamoby) --------------------------------------------------------------------------------------- "General Requirements for a Context Transfer", Gary Kenward, 07-Oct-02, The success of time sensitive services like VoIP telephony, video, etc., in a mobile environment depends heavily on the ability to minimize the impact of the traffic redirection during a change of packet forwarding path. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. The transfer of context information may be advantageous in minimizing the impact of host mobility on IP services. This document captures the set of requirements for a context transfer framework and the requirements for a generic context transfer protocol to carry the context between the context transfer peers. "Issues in candidate access router discovery for seamless IP-level handoffs", Dirk Trossen, Govind Krishnamurthi, Hemant Chaskar, James Kempf, 17-Oct-02, Handoff in IP mobility protocols involves moving a mobile node's Layer 3 routing reachability point from one access router to another, before or after the mobile node has established a Layer 2 connection with the radio access point that is covered by the new access router. In addition, other context information about the mobile node's IP service may be transferred from the old access router to the new one, in order to minimize the service disruption during the handoff process. While the exact details of how this is accomplished vary depending on the IP mobility and seamless handoff protocols, one common thread required for IP-level handoffs is discovering the candidate access routers for the mobile node's handoff. Discovering the candidate access router involves identifying its IP address as well as its capabilities that the mobile node might be interested in. At the time of IP-level handoff, if a collection of candidates is identified, an algorithm is run to determine the target access router for the mobile node's handoff. This document describes the problem of candidate access router discovery. The document does not discuss the algorithm by which the actual target access router is selected, nor how the handoff to the target is achieved. "Requirements for CAR Discovery Protocols", Govind Krishnamurthi, 17-Oct-02, The pre-requisite for IP based seamless mobility protocols is the knowledge of the access router (AR) to which a mobile node can be handed over to. Further, a handoff can be optimized if the capabilities of the AR being considered for handoff are known. The protocol which discovers ARs for potential handoff along with their capabilities is called the CAR discovery protocol. In this draft we list the requirements which are to be met by any solution for CAR Discovery. "Mobility Related Terminology", Jukka Manner, Markku Kojo, 25-Apr-03, There is a need for common definitions of terminology in the work to be done around IP mobility. This memo defines terms for mobility related terminology. It is intended as a living document for use by the Seamoby Working Group in Seamoby drafts and in WG discussions, but not limited in scope to the terms needed by the Seamoby Working Group. Other working groups dealing with mobility may take advantage of this terminology. "Candidate Access Router Discovery", Marco Liebsch, 01-Jul-03, To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called 'candidate access router discovery' (CARD). At the time of IP-layer handover, that CAR, whose capabilities is a good match to the preferences of the MN, may be chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. "Context Transfer Protocol", John Loughney, 30-May-03, This document presents a context transfer protocol that enables authorized context transfers. Context transfers allows better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reducing latency, packet losses and avoid re-initiation of signaling to and from the mobile node. Secure Shell (secsh) -------------------- "SSH Transport Layer Protocol", Tatu Ylonen, Tero Kivinen, Markku Juhani Saarinen, Timo Rinne, Sami Lehtinen, 23-Sep-02, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport 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 provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, 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 protocol. "SSH Authentication Protocol", Tatu Ylonen, Tero Kivinen, Timo Rinne, Sami Lehtinen, 23-Sep-02, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. "SSH Connection Protocol", Tatu Ylonen, Tero Kivinen, Timo Rinne, Sami Lehtinen, 23-Sep-02, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. 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", Tatu Ylonen, Tero Kivinen, Timo Rinne, Sami Lehtinen, 23-Sep-02, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. "Generic Message Exchange Authentication For SSH", Martin Forssen, Frank Cusack, 29-Apr-03, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). "SSH File Transfer Protocol", Joseph Galbraith, Tatu Ylonen, Sami Lehtinen, 20-Dec-02, The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", Jeffrey Hutzelman, Joseph Salowey, Joseph Galbraith, Von Welch, 06-Mar-03, The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [2] provides security services to callers in a mechanism-independent fashion. "SECSH Public Key File Format", Joseph Galbraith, Rodney Thayer, 17-Oct-02, This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol", Markus Friedl, Niels Provos, William Simpson, 21-Feb-03, This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. "Secure Shell Authentication Agent Protocol", Darren Moffat, Timo Rinne, Sami Lehtinen, 10-Feb-03, This document describes the Secure Shell authentication agent protocol (i.e., the protocol used between a client requesting authentication and the authentication agent). This protocol usually runs in a machine-spe- cific local channel or over a forwarded authentication channel. It is assumed that the channel is trusted, so no protection for the communica- tions channel is provided by this protocol. "SSH Fingerprint Format", Markus Friedl, 28-Mar-03, This document formally documents the fingerprint format in use for verifying public keys from SSH clients and servers. "SSH Protocol Assigned Numbers", Sami Lehtinen, Darren Moffat, 04-Oct-02, This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH- CONNECT], [SSH-USERAUTH]. This document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. "Using DNS to securely publish SSH key fingerprints", Jacob Schlyter, Wesley Griffin, 02-Apr-03, This document describes a method to verify SSH host keys using DNSSEC. The document defines a new DNS resource record that contains a standard SSH key fingerprint. "SSH Transport Layer Encryption Modes", Mihir Bellare, 24-Mar-03, Researchers have recently discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy and integrity/authenticity attacks. "Session Channel Break Extension", Joseph Galbraith, Phillip Remaker, 08-Apr-03, The Break Extension provides a way to send a break signal during a SSH terminal session. Securing Neighbor Discovery (send) ---------------------------------- "IPv6 Neighbor Discovery trust models and threats", Pekka Nikander, 14-Apr-03, The existing IETF standards specify that IPv6 Neighbor Discovery and Address Autoconfiguration mechanisms MAY be protected with IPsec AH. However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. "SEcure Neighbor Discovery (SEND)", Jari Arkko, 05-Jun-03, IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. If not secured, ND protocol is vulnerable to various attacks. This document specifies an extension to IPsec for securing ND. Contrary to the original ND specifications that also called for use of IPsec, this extension does not require the creation of a large number of manually configured security associations. "Cryptographically Generated Addresses (CGA)", Tuomas Aura, 16-Jun-03, This document describes a method for binding a public signature key to an IPv6 address in Secure Neighbor Discovery (SEND). Cryptographically Generated Addresses (CGA) are IPv6 addresses where the interface identifier is generated by computing a cryptographic one-way hash function from the address owner's public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. SEND protocol messages are protected with an Authentication Header (AH) that contains the public key and the auxiliary parameters and is signed with the corresponding private key. The protection works without a certification authority or other security infrastructure. Signaling Transport (sigtran) ----------------------------- "Stream Control Transmission Protocol Management Information Base", Javier Pastor, Maria-Carmen Belinchon, 06-Jun-03, The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport PSTN signaling messages over the connectionless packet network, but is capable of broader applications. This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. "Signalling Connection Control Part User Adaptation Layer (SUA)", John Loughney, Greg Sidebottom, 05-Jul-02, This Internet Draft defines a protocol for the transport of any Signalling Connection Control Part-User signalling (e.g., Transaction Capabilities Protocol, Radio Acccess Network Application Protocol, etc.) over IP using the Stream Control Transport Protocol. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. Protocol elements are added to allow operation between peers in the Signaling System No.7 and IP domains. "Telephony Signalling Transport over SCTP applicability statement", Lode Coene, Javier Pastor, 26-Mar-03, This document describes the applicability of the new protocols developed under the signaling transport framework[RFC2719]. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP)[RFC2960] and each adaptation layer for transport of telephony signalling information over IP infrastructure is explained. "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Tom George, 01-Jul-03, This Internet Draft defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. "SS7 MTP3-User Adaptation Layer (M3UA)Management Information Base using SMIv2", Antonio Roque, 13-Jun-03, The MTP3-User Adaptation Layer is a protocol for the transport of any SS7 TP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3- User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database. It is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. "V5.2-User Adaption Layer (V5UA)", Eva Weilandt, Neeraj Khanchandani, Sira Rao, 01-Jun-03, This document defines a mechanism for backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 sig- naling over a standard V5.2 interface. This document builds on top of the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. "DPNSS/DASS 2 extensions to the IUA protocol", Anil Vydyam, Ken Morneault, 16-Jan-03, This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in BTNR 188, is used to interconnect Private Branch Exchanges (PBX) in a private network and DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/ DASS 2 User Adaptation (DUA) implementation. "M3UA Implementor’s Guide", Javier Pastor, Ken Morneault, 06-Mar-03, This document contains a compilation of all defects found up until October 2002 for M3UA [RFC3332]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M3UA to clarify errors in the original M3UA document. This document updates RFC3332 and text within this document supersedes the text found in RFC3332. "IUA (RFC 3057) Outstanding Issues", Ken Morneault, 04-Nov-02, This document captures problems and issues discovered on the SIGTRAN mailing list and at future bakeoffs for IUA [RFC3057]. This document will be updated after each bakeoff augmenting the existing draft to include any new issues discovered during inter-operability testing. Two basic sets of problems are identified by this draft: first, issues that need to be addressed when the next revision of IUA is created, i.e. issues that should be remembered in a BIS document; second, issues that were found that are strictly implementation problems. "Security Considerations for SIGTRAN Protocols", John Loughney, 01-Jul-03, This documents discusses how TLS and IPSec can be used to secure the communication for SIGTRAN protocols. The support of IPSec is mandatory for all nodes running SIGTRAN protocols and the support of TLS is optional. "GR-303 extensions to the IUA protocol", R Mukundan, Ken Morneault, 12-Dec-02, This document defines a mechanism for backhauling of GR-303 [2] messages over IP by extending the ISDN User Adaptation Layer Protocol [3] and to be the base for a GR-303 User Adaptation (GR- 303UA) implementation. "ISDN Q.921-User Adaptation Layer", Ken Morneault, 15-May-03, This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "A Presence Event Package for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 31-Jan-03, This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. "An Extensible Markup Language (XML) Based Format for Watcher Information", Jonathan Rosenberg, 31-Jan-03, Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an XML document format for such state. "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 31-Jan-03, This document defines the watcher information template-package for the SIP event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", Jonathan Rosenberg, Markus Isomaki, 30-Jun-03, In any presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their presentity list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a framework and requirements for such data manipulations. "SIMPLE Presence Publication Requirements", Ben Campbell, 12-Feb-03, This document describes requirements for an extension to the Session Initiation Protocol (SIP) [1]. The purpose of this extension would be to create a means for publishing event state used within the framework for SIP Event Notification (RFC3265 [2]). The first application of this extension is targeted at the publication of presence information as defined by the SIMPLE [5] working group. "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Adam Roach, Jonathan Rosenberg, Ben Campbell, 13-Jun-03, This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. "Session Initiation Protocol (SIP) Extension for Presence Publication", Aki Niemi, 01-Jul-03, This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better suited mechanisms for this purpose (FTP, HTTP, etc.) "Requirements for Efficient Delivery of Presence Information", Mikko Lonnfors, 06-May-03, A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. if presence information is delivered over radio links with high latency and low bandwidth. This memo presents requirements for a solution that can aid to reduce the impacts of these constrains and helps to increase efficiency. "Requirements for Filtering of Watcher Information", Krisztian Kiss, 09-May-03, This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher infomation notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. "Instant Message Sessions in SIMPLE", Ben Campbell, 01-Jul-03, This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the SDP offer/answer model carried by a signaling protocol such as SIP. MSRP supports end-to-end Instant Message Sessions, as well as sessions traversing one or two relays. "Requirements for Presence Specific Event Notification Filtering", Tim Moran, 19-Jun-03, This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence infomation notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server. "RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP)", Henning Schulzrinne, 02-Jul-03, The Rich Presence Information Data Format for the Session Initiation Protocol (SIP) (RPIDS) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior or be delivered to watchers. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. "Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization", Jonathan Rosenberg, 24-Jun-03, This document describes three usages of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) that allow a client to provide authorization decisions regarding watchers of their presence. The first of these usages, called permission-statements, contains statements about what permissions are to be granted to watchers of presence. The second of these usages, called compound-permissions, allows a client to define new permissions as combinations of other defined permissions. The third usage, called supported-permissions, allows a client to determine what permissions are understood by the provider. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Jonathan Rosenberg, 25-Jun-03, This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. "A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Documents", Jonathan Rosenberg, 25-Jun-03, This specification defines a Session Initiation Protocol (SIP) event package for finding out about changes to documents managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to manipulate XML documents on a server which contain configuration information for application protocols. Multiple clients can potentially access the same document, in which case the other clients would like to be notified of a change in the document made by another. This event package allows a client to do that. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists", Jonathan Rosenberg, 25-Jun-03, This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating lists of presentities (also known as buddy lists or rosters). It does so by specifying an XML Schema that contains a list of presentities that a user is interested in watching. Session Initiation Protocol (sip) --------------------------------- "Session Timers in the Session Initiation Protocol (SIP)", Steve Donovan, Jonathan Rosenberg, 02-Jul-03, This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new header fields, Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. "Caller Preferences and Callee Capabilities for the Session Initiation Protocol (SIP)", Henning Schulzrinne, Jonathan Rosenberg, Paul Kyzivat, 07-Mar-03, This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining four new request headers, Accept-Contact, Reject- Contact, Require-Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the capabilities and characteristics of a UA. "Management Information Base for Session Initiation Protocol", Kevin Lingle, Joon Maeng, Jean-Francois Mule, Dave Walker, 01-Jul-03, 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 manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 08-Nov-02, The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. "The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol", Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, 01-Jul-02, This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. "Internet Media Types message/sipfrag", Robert Sparks, 29-Apr-02, This document registers the message/sipfrag MIME media type. This type is similar to message/sip , but allows fragments of well formed SIP messages to be used for the same tunelling purposes as message/ sip. In addition to end-to-end security uses , message/sipfrag is used with the REFER method to tunnel information about the status of a referrenced request. "The Session Inititation Protocol (SIP) 'Replaces' Header", Billy Biggs, Rick Dean, Rohan Mahy, 06-Mar-03, This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Retrieve from Call Park'. Note that definition of these example features is non-normative. "DHCPv6 Options for SIP Servers", Henning Schulzrinne, Bernard Volz, 05-Nov-02, This document defines a DHCPv6 option that contains a list of domain names or IPv6 addresses that can be mapped to one or more SIP outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. "The SIP Referred-By Mechanism", Robert Sparks, 18-Jun-03, The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. "Compressing the Session Initiation Protocol", Gonzalo Camarillo, 04-Nov-02, This document describes a mechanism to signal that compression is desired for one or more SIP messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. "Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration", Dean Willis, Bernie Hoeneisen, 14-May-03, This document defines a SIP extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. "Session Initiation Protocol Extension to Assure Congestion Safety", Dean Willis, Ben Campbell, 14-Feb-03, The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines what it means for SIP nodes to be congestion safe and specifies an extension by which a SIP User Agent may require that its requests are treated in a congestion safe manner. "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", Sean Olson, 03-Jun-03, This document proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", Jonathan Rosenberg, Joel Weinberger, Henning Schulzrinne, 30-Sep-02, The Session Initiation Protocol (SIP) operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called 'rport', that allows a client to request that the server send the response back to the source IP address and port where the request came from. "The Session Inititation Protocol (SIP) 'Join' Header", Rohan Mahy, Dan Petrie, 01-Jul-03, This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Barge-In', answering-machine-style 'Message Screening' and 'Call Center Monitoring'. Note that definition of these example features is non- normative. "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Jon Peterson, 07-Mar-03, The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute cryptographically secure authenticated identities within SIP messages. "SIP Authenticated Identity Body (AIB) Format", Jon Peterson, 02-Jul-03, RFC3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. "S/MIME AES Requirement for SIP", Jon Peterson, 02-Jul-03, RFC3261 currently specifies 3DES as the required minimum ciphersuite for implementations of S/MIME in SIP. This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME. "An Extension to the Session Initiation Protocol for Request History Information", Mary Barnes, 23-Jun-03, This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, HistInfo, to be included in the Supported header is defined to allow UAs to indicate whether the HistInfo should be returned in responses to a request which has captured the history information. "Communications Resource Priority for the Session Initiation Protocol (SIP)", Henning Schulzrinne, James Polk, 24-Jun-03, This document defines a new SIP header field for communications resource priority, called 'Resource-Priority'. This header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not influence the forwarding behavior of IP routers. "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 26-Jun-03, This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents. These capabilities are conveyed as parameters of the Contact header field. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Using ENUM for SIP Applications", J Peterson, Hong Liu, James Yu, Ben Campbell, 02-Jul-03, Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. "Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol", Gonzalo Camarillo, 03-Feb-03, This document describes a way to map ISUP overlap signalling to SIP. This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). "Session Initiation Protocol Service Examples", Alan Johnston, Steve Donovan, 06-Mar-03, This informational document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join headers. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. "SIP Support for Real-time Fax: Call Flow Examples And Best Current Practices", Jean-Francois Mule, Jian Li, 05-Mar-03, The Session Initiation Protocol (SIP) allows the establishment of real-time Internet fax communications. Real-time facsimile communications over IP may follow 2 modes of operation: T.38 fax relay as defined by the ITU-T T.38 recommendation or fax pass- through. This document clarifies the options available to Internet telephony gateway vendors to handle real-time fax calls using SIP. While our primary focus is to address the more reliable real-time T.38 Group 3 fax mode, we briefly cover the fax pass-through mode to enable fallback operations and super G3 fax communications using SIP. We also give examples of SIP call flows for real-time Internet fax gateways or SIP proxy redirect servers. Elements in these call flows include SIP User Agents, SIP Proxy Servers, and Gateways to the PSTN (Public Switch Telephone Network). This document introduces best current practices for SIP T.38 fax and SIP fax pass-through sessions. A session starts with audio capabilities, and, upon fax tone detection, T.38 fax capabilities are negotiated; upon successful negotiation, the session continues with fax capabilities and the media termination hosts exchange T.38 Internet fax packets. The T.38 fax call scenarios include various aspects of the call sequence: the detection of fax transmission, the usage of the T.38 session description attributes, the optional fallback into fax pass-through mode and the session termination. The fax pass-through call scenarios involve some specific SDP media attributes to enable proper fax transmission. Fax transmission can be detected by the receiving side, the emitting side or both (in the latter case, a 'glare' effect may appear). This document only covers the case when the fax transmission is detected by the receiving side: it is the most common practice and the other cases do not represent any particular challenges and are therefore left for future discussions). Call flow diagrams and message details are shown. A list of IANA defined SDP attribute names for T.38 is summarized in section 7. "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, 07-Mar-03, This document defines a framework and requirements for multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals which embody the spirit of SIP applications as used on the Internet. "Best Current Practices for Third Party Call Control in the Session Initiation Protocol", Jonathan Rosenberg, J Peterson, Henning Schulzrinne, Gonzalo Camarillo, 06-Mar-03, Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of the SIP for third party call control. "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", Rohan Mahy, 01-Jul-03, This draft proposes a SIP event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. "Requirements for Content Indirection in Session Initiation Protocol (SIP) Messages", Sean Olson, 03-Mar-03, This specification defines requirements for a mechanism to indirectly specify the content of a SIP message for the purpose of transferring the content via a non-SIP channel. "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP", Jonathan Rosenberg, Henning Schulzrinne, 05-Mar-03, This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user, an receive notifications about the changes in state of INVITE initiated dialogs that the user is involved in. "Session Initiation Protocol PSTN Call Flows", Alan Johnston, Steve Donovan, 07-Apr-03, This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown. "Session Initiation Protocol Basic Call Flow Examples", Alan Johnston, 07-Apr-03, This informational document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown. "Session Initiation Protocol Torture Test Messages", Alan Johnston, 27-Aug-02, This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and 'torture' a parser. They were developed as part of the SIPit SIP interoperability testing events. "SIP Generic Request History Capability – Requirements", Mary Barnes, 24-Jun-03, Many services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via 'click to talk' SIP URLs on a web page, 'call history/logging' style services within intelligent 'call management' software for SIP UAs and calls to voicemail servers and call centers. While SIP implicitly provides the redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This 'request history' information allows the receiving application to determine hints about how and why the call arrived at the application/user. This draft discusses the motivations in support of a mechanism for recording the 'request history', and proposes detailed requirements for such a generic 'request history' capability. "Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol", John Loughney, Gonzalo Camarillo, 02-Jun-03, As SIP services are deployed on the Internet, there is a need for authentication, authorization and accounting of SIP sessions. This document sets out the basic requirements for this work. "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, 11-Oct-02, The 3rd Generation Partnership Project (3GPP) has selected SIP [2]as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of the Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements to establish a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document we express the requirements identified by 3GPP to support SIP for the Release 5 of the 3GPP IMS in cellular networks. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, Alan Johnston, 12-Feb-03, This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). This work is part of the SIP Multiparty Call Control Framework. "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, 28-Oct-02, When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document presents requirements for addressing this shortcoming, and separately proposes an example mechanism which addresses this deficiency. "A Session Initiation Protocol (SIP) Event Package for Registrations", Jonathan Rosenberg, 31-Oct-02, This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications "Interworking between SIP and QSIG", John Elwell, 10-Apr-03, This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. "Requirements for SIP User Agent Profile Delivery Framework", Dan Petrie, Cullen Jennings, 03-Mar-03, This document attempts to identify the requirements for a protocol framework to provide SIP user and device profiles to SIP user agents. The objective is not to invent new special purpose protocols, but to identify the requirements such that a rational decision can be made as to what existing protocol(s) should be used to solve the problem of providing user and device profiles to SIP user agents. This document also contains an evaluation of a set of applicable protocols. "A Framework for SIP User Agent Configuration", Dan Petrie, 03-Mar-03, This document defines the application of a set of protocols for configuring a SIP user agent. The SIP user agent must discover how and from where to retrieve its initial configuration and be notified of changes and updates which impact its configuration. The objective is to define a means for automatically configuring a user agent such that it can be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent configuration is defined here. This framework is also intended to ease ongoing administration, configuration and upgrading of large scale deployments of SIP user agents. The contents and format of the configuration data to be defined is outside the scope of this document. "Session Initiation Protocol Call Control - Conferencing for User Agents", Alan Johnston, Orit Levin, 01-Jul-03, This document defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. "High Level Requirements for Tightly Coupled SIP Conferencing", Orit Levin, Roni Even, 24-Apr-03, This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. "A Framework for Conferencing with the Session Initiation Protocol", Jonathan Rosenberg, 01-May-03, The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. "Requirements for Session Policy for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 26-Jun-03, The proxy server plays a central role as an intermediary in the establishment of sessions in the Session Initiation Protocol (SIP). In that role, they can define and impact policies on call routing, rendezvous, and other call features. However, there is no standard means by which proxies can have any influence on session policies, such as the codecs that are to be used. As such, ad-hoc and non-conformant techniques have been deployed to allow for such policy mechanisms. There is a need for a standards-based and complete mechanism for session policies. This document defines a set of requirements for such a mechanism. S/MIME Mail Security (smime) ---------------------------- "Examples of S/MIME Messages", Paul Hoffman, 01-Jul-03, This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. 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 . 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 . "CMS Symmetric Key Management and Distribution", Sean Turner, 14-Jan-03, This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). "Use of the RSAES-OAEP Transport Algorithm in CMS", Russell Housley, 03-Dec-02, This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. "Transporting S/MIME Objects in X.400", Paul Hoffman, Chistopher Bonatti, 02-Jul-03, This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. "Securing X.400 Content with S/MIME", Paul Hoffman, Chistopher Bonatti, Anders Eggen, 02-Jul-03, This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. "Use of the AES Encryption Algorithm in CMS", Jim Schaad, 29-May-03, This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption with the Cryptographic Message Syntax (CMS) [CMS]. "S/MIME Version 3.1 Certificate Handling", Blake Ramsdell, 20-Feb-03, 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 certificate processing requirements documented in this document 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. "S/MIME Version 3.1 Message Specification", Blake Ramsdell, 03-Jun-03, 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 data confidentiality (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. "Use of the Camellia Encryption Algorithm in CMS", Shino Moriai, Akira Kato, 27-Jun-03, This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). "Use of the PSS Signature Algorithm in CMS", Jim Schaad, 30-Apr-03, This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. "Use of the RSA-KEM Key Transport Algorithm in CMS", Burton Kaliski, 19-May-03, The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) Configuration Management with SNMP (snmpconf) --------------------------------------------- "The Differentiated Services Configuration MIB", Harrie Hazewinkel, David Partain, 06-Jun-03, This memo describes a MIB module that provides a conceptual layer between high-level 'network-wide' policy definitions that affect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. "Policy Based Management MIB", Steven Waldbusser, Jon Saperia, Thippanna Hongal, 06-Mar-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of SNMP infrastructures as well as a scripting language and a script execution environment. SNMP Version 3 (snmpv3) ----------------------- "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", Rob Frye, David Levi, Shawn Routhier, Bert Wijnen, 06-May-03, The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. Speech Services Control (speechsc) ---------------------------------- "Requirements for Distributed Control of ASR, SI/SV and TTS Resources", David Oran, 06-Jun-03, This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to-speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. Discussion of this and related documents is on the speechsc mailing list. To subscribe, send the message 'subscribe speechsc' to speechsc-request@ietf.org. The public archive is at http:// www.ietf.org/mail-archive/workinggroups/speechsc/current/ maillist.html "SPEECHSC Protocol Evaluation", Brian Wyld, 30-Jun-03, This document is the Protocol Evaluation Document for the SPEECHSC Working Group. Section 3 provides the summary of the individual protocol comparisons (in the sections 4-N following) against the SPEECHSC requirements [1]. Service in the PSTN/IN Requesting InTernet Service (spirits) ------------------------------------------------------------ "The SPIRITS (Services in PSTN requesting Internet services)Protocol", Vijay Gurbani, Igor Faynberg, 06-Mar-03, This document describes SPIRITS protocol. The purpose of the SPIRITS protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting, Internet Caller-ID Delivery, are examples of SPIRITS services; as are location-based services or application-specific ones. The protocol is to define the building blocks from which many other services can be built. "Mobility Events Management in SPIRITS", Daniel Moreno, 03-Feb-03, This document describes the management of the mobility events considered in SPIRITS protocol and the definition of their related parameters. The mobility events management will allow a SPIRITS server to subscribe to and to be notified of location changes of a mobile user. The events would only be applicable to mobile users reachable through a CS network. The sending of these events must be allowed by setting the related marks in the HLR. Besides, the SPIRITS protocol must be able to translate the CAMEL operations involving mobility information into events that can be transferred to the SPIRITS client. "Services in the PSTN/IN Requesting InTernet Services (SPIRITS) protocol security", Vijay Gurbani, 14-Oct-02, This document analyses the trust model inherent in SPIRITS with the result of documenting possible security implications for the entities participating in the SPIRITS network. It also proposes solutions for countering the security threats that are possible in such a network. Source-Specific Multicast (ssm) ------------------------------- "An Overview of Source-Specific Multicast(SSM)", Supratik Bhattacharyya, 01-May-03, The purpose of this document is to provide an overview of Source- Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. "Source-Specific Multicast for IP", Hugh Holbrook, Bradley Cain, 08-May-03, IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. It defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. Secure Network Time Protocol (stime) ------------------------------------ "Public-Key Cryptography for the Network Time Protocol Version 2", David Mills, 05-Nov-02, This document describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. its design is based on the premiss that IPSEC schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, PKI schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping function and authentication function in ways not yet considered by the IETF. This Document includes the Autokey requirements analysis, design principles and protocol specification. A detailed description of the protocol states, events and transition functions is included. A prototype of the Autokey design based on this document has been implemented, tested and documented in the NTP Version 4 (NTPv4) software distribution for Unix, Windows and VMS at http://www.ntp.org. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "Syslog-Sign Protocol", John Kelsey, Jon Callas, 29-May-03, This document describes syslog-sign, a mechanism adding origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to syslog. Syslog-sign provides these security features in a way that has minimal requirements and minimal impact on existing syslog implementations. It is possible to support syslog-sign and gain some of its security attributes by only changing the behavior of the devices generating syslog messages. Some additional processing of the received syslog messages and the syslog-sign messages on the relays and collectors may realize additional security benefits. "Syslog MIB", Glenn Keeni, Bruno Pape, 01-Jul-03, This memo provides a MIB module that can be used to monitor and manage syslog processes. It defines objects that allow the collection of information related to syslog processes, it also defines objects that can be used to monitor and/or control syslog processes. Internet Traffic Engineering (tewg) ----------------------------------- "A Traffic Engineering MIB", Kireeti Kompella, 06-Mar-03, This memo defines a standards-track portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered Tunnels, for example, Multi-Protocol Label Switched Paths. "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, William Lai, 25-Feb-03, This document presents the Service Provider requirements for support of Diff-Serv aware MPLS Traffic Engineering (DS-TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff- Serv-aware Traffic Engineering is required. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. "OSPF-xTE: An experimental extension to OSPF for Traffic Engineering", Pyda Srisuresh, Paul Joseph, 10-Feb-03, This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. New TE LSAs are defined to disseminate TE metrics within an autonomous System (AS) - intra-area as well as inter-area. An Autonomous System may consist of TE and non-TE nodes. Non-TE nodes are uneffected by the distribution of TE LSAs. A stand-alone TE Link State Database (TE-LSDB), separate from the native OSPF LSDB, is generated for the computation of TE circuit paths. OSPF-xTE is also extendible to non-packet networks such as SONET/TDM and optical networks. A transition path is provided for those using [OPQLSA-TE] and wish to adapt OSPF-xTE. "A Framework for Internet Traffic Engineering Measurement", Wai Lai, Richard Tibbs, Steven Van den Berghe, 14-Feb-03, In this document, a measurement framework for supporting the traffic engineering of IP-based networks is presented. Uses of traffic measurement in service provider environments are described, and issues related to time scale and read-out period are discussed. Different measurement types are classified, with each being specified as a meaningful combination of a measurement entity and a measurement basis. For interoperable compatibility, uniform definitions across vendors and operators must be ensured, e.g., in the distinction between offered load and achieved throughput. To aid network dimensioning, mechanisms to collect node-pair-based traffic data should be developed to facilitate the derivation of per-service-class traffic matrix statistics. For service assurance, there is a need for the use of higher-order statistics. To preserve representative traffic detail at manageable sample volumes, there is a need for packet- sampled measurements. To manage large volume of measured data, use of bulk transfer and filtering/aggregation mechanisms may be appropriate. "Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, 17-Jun-03, This document specifies the IGP and RSVP-TE signaling extensions (beyond those already specified for existing MPLS Traffic Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering (DS-TE). These extensions address the Requirements for DS-TE spelt out in [DSTE-REQ]. "Use of Interior Gateway Protocol Metric as a second MPLS Traffic Engineering Metric", Francois Le Faucheur, 11-Sep-02, This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g. link bandwidth) for some Traffic Engineering tunnels (e.g. Data Trunks) while optimizing another metric (e.g. propagation delay) for some other tunnels with different requirements (e.g. Voice Trunks). "Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, 17-Jun-03, This document provides specification for one Bandwidth Constraints model for Diff-Serv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", Jerry Ash, 27-Jun-03, This document complements the DiffServ-aware MPLS TE (DSTE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) bandwidth constraint model. Assumptions, applicability, and examples of the operation of the MAR bandwidth constraint model are presented. MAR performance is analyzed relative to the criteria for selecting a bandwidth constraint model, in order to provide guidance to user implementation of the model in their networks. "MPLS Inter-AS Traffic Engineering requirements", Raymond Zhang, JP Vasseur, 29-May-03, This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). The main objective of this document is to present a set of requirements which would result in a set of general guidelines in the definition, selection and specification development for any technical solution(s) meeting these requirements. "Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, Wai Lai, 25-Jun-03, This document provides specification for one Bandwidth Constraints model for Diff-Serv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. Transport Layer Security (tls) ------------------------------ "ECC Cipher Suites For TLS", Vipul Gupta, 04-Jun-03, This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. "Using SRP for TLS Authentication", Dave Taylor, 17-Jun-03, This memo presents a technique for using the SRP [2] (Secure Remote Password) protocol as an authentication method for the TLS [1](Transport Layer Security) protocol. "Using OpenPGP keys for TLS authentication", Nikos Mavroyanopoulos, 02-Apr-03, This document proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This document uses the same notation used in the TLS Protocol draft. "The TLS Protocol Version 1.1", Tim Dierks, Eric Rescorla, 01-Jul-03, 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. "Transport Layer Security Protocol Compression Methods", Scott Hollenbeck, 28-May-03, The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. "Use of Shared Keys in the TLS Protocol", Peter Gutmann, 02-Jun-03, The TLS handshake requires the use of CPU-intensive public-key algorithms with a considerable overhead in resource-constrained environments or ones such as mainframes where users are charged for CPU time. This document describes a means of employing TLS using symmetric keys or passwords shared in advance among communicating parties. No modifications or alterations to the TLS protocol are required for this process. Internet Open Trading Protocol (trade) -------------------------------------- "Payment API for v1.0 Internet Open Trading Protocol (IOTP)", Werner Hans, Hans Beykirch, Yoshiaki Kawatsura, Masaaki Hiroya, 05-Apr-01, The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. "SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP)", Yoshiaki Kawatsura, 27-Nov-00, This document describes detailed Input/Output parameter for the IOTP Payment API and a procedure in the Payment Bridge for use SET as the payment protocol within Version 1.0 of the Internet Open Trading Protocol (IOTP). "XML Voucher: Generic Voucher Language", Ko Fujimura, Masayuki Terada, 28-Feb-03, This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide-range of electronic-values, including coupons, tickets, loyalty points, and gift certificates, which are often necessary to process in the course of payment and/or delivery transactions. "Electronic Commerce Modeling Language (ECML):Version 2 Specification", Donald Eastlake, 29-Jan-03, Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchicly organized payment related information fields in an XML syntax are defined as the second version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software "Voucher Trading System Application Programming Interface (VTS-API)", Masayuki Terada, Ko Fujimura, 28-Feb-03, This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system to securely transfer vouchers, e.g., coupons, tickets, loyalty points, and gift certificates; this process is often necessary in the course of payment and/or delivery transactions. "DNS SRV Location of Higher Level Services", Donald Eastlake, 30-Oct-02, DNS naming conventions specified in RFC 2782 are extended to higher level services and a registry created for the tokens used. Transport Area Working Group (tsvwg) ------------------------------------ "TCP Processing of the IPv4 Precedence Field", X Xiao, Alan Hannan, Vern Paxson, Edward Crabbe, 03-May-00, This draft describes a conflict between TCP [RFC793] and DiffServ [RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This draft proposes a modification to TCP for resolving the conflict. "Robust ECN Signaling with Nonces", David Wetherall, Neil Spring, David Ely, 04-Nov-02, This note describes the ECN-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECT codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Randall Stewart, 03-Mar-03, This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, 03-Mar-03, This document describes a mapping of the Stream Control Transmission Protocol SCTP RFC2960 [8] into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. "Stream Control Transmission Protocol (SCTP) Implementors Guide", Randall Stewart, Lyndon Ong, 03-Mar-03, This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document. This document updates RFC2960 [3] and text within this document supersedes the text found in RFC2960 [3]. "The UDP-Lite Protocol", Lars-Åke Larzon, Mikael Degermark, 06-Dec-02, This document describes the UDP-Lite protocol, which is similar to UDP [RFC-768], but can also serve applications that in error-prone network environments prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP- Lite is semantically identical to UDP. "TCP Extended Statistics MIB", Matt Mathis, Jeremy Heffner, 06-Mar-03, This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. "The Eifel Response Algorithm for TCP", Reiner Ludwig, Andrei Gurtov, 04-Mar-03, The Eifel response algorithm requires a detection algorithm to detect a posteriori whether the TCP sender has entered loss recovery unnecessarily. In response to a spurious timeout it adapts the retransmission timer to avoid further spurious timeouts, and can avoid - depending on the detection algorithm - the often unnecessary go-back-N retransmits that would otherwise be sent. Likewise, it adapts the duplicate acknowledgement threshold in response to a spurious fast retransmit. In both cases, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. "SCTP Partial Reliability Extension", Randall Stewart, 19-Jun-03, This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes (1) the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example partially reliable service that can be provided to the upper layer via this mechanism. "The NewReno Modification to TCP's Fast Recovery Algorithm", Sally Floyd, Tom Henderson, 20-Jun-03, RFC 2581 [RFC2581] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [RFC2018], 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. The NewReno mechanism described in 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]. RFC 2582 [RFC2582] specified the NewReno mechanisms as Experimental in 1999. This document is a small revision of RFC 2582 intended to advance the NewReno mechanisms to Proposed Standard. RFC 2581 notes that the Fast Retransmit/Fast Recovery algorithm specified in that document does not recover very efficiently from multiple losses in a single flight of packets, and that RFC 2582 contains one set of modifications to address this problem. "Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions", Ethan Blanton, Mark Allman, 23-Jun-03, TCP and SCTP provide notification of duplicate segment receipt through DSACK and Duplicate TSN notification, respectively. This document presents a conservative method of using this information to identify unnecessary retransmissions for various applications. UniDirectional Link Routing (udlr) ---------------------------------- "Experiments with RFC 3077", Emmanuel Duros, 01-Nov-02, In March 2001, [RFC 3077] was published and describes a protocol which allows to integrate unidirectional links in the Internet. Since then, a number of experimentations and deployements using this protocol have been led. This document presents various protocols, e.g. layer 2 and layer 3 protocols, which have been commonly used over [RFC 3077] in a satellite environment. This document raises issues for each of these protocols. Usenet Article Standard Update (usefor) --------------------------------------- "News Article Format", Charles Lindsey, 30-Jun-03, This Draft is intended as a standards track document, obsoleting RFC 1036, which itself dates from 1987. This Standard defines the format of Netnews articles and specifies the requirements to be met by software which originates, distributes, stores and displays them. Since the 1980s, Usenet has grown explosively, and many Internet and non-Internet sites now participate. In addition, the Netnews technology is now in widespread use for other purposes. Backward compatibility has been a major goal of this endeavour, but where this standard and earlier documents or practices conflict, this standard should be followed. In most such cases, current practice is already compatible with these changes. IPv6 Operations (v6ops) ----------------------- "Transition Scenarios for 3GPP Networks", Jonne Soininen, 01-Apr-03, This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. "Analysis on IPv6 Transition in 3GPP Networks", Juha Wiljakka, 13-Jun-03, This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. "Unmanaged Networks IPv6 Transition Scenarios", Christian Huitema, Rob Austein, Suresh Satapati, Ronald van der Pol, 17-Jun-03, In order to evaluate the suitability of IPv6 transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged network', which typically corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. "Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Application Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF General Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Operations & Management Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF documented standards. This material was originally presented in a single document, but has subsequently been split into 8 documents based on IETF Areas. This document is a general overview of the project. "Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards", Philip Nesser II, 14-Feb-03, This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. "IPv6 Enterprise Networks Scenarios", Yanick Pouffary, Jim Bound, 14-Feb-03, IPv6 will be deployed in Enterprise networks. This scenario has requirements for the adoption of IPv6. This document will focus upon and define: a set of technology scenarios that shall exist for the enterprise network, the set of transition variables, transition methods, and tools required by different scenarios. The document using these definitions will define the points of transition for an Enterprise network. "Basic Transition Mechanisms for IPv6 Hosts and Routers", Erik Nordmark, Robert Gilligan, 26-Feb-03, This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. "Evaluation of Transition Mechanisms for Unmanaged Networks", Christian Huitema, 26-Jun-03, In a companion paper we defined the Voice Profile for Internet Mail (vpim) -------------------------------------- "Voice Profile for Internet Mail - version 2", Gregory Vaudreuil, Glenn Parsons, 18-Feb-02, This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. "Internet Voice Messaging", Stuart McRae, Glenn Parsons, 02-Jul-02, This document provides for the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure. The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2, but rather an alternative specification for a different application. "Voice Message Routing Service", Gregory Vaudreuil, 19-Jun-03, Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list "Voice Messaging Directory Service", Gregory Vaudreuil, 19-Jun-03, This document provides details of the VPIM directory service. The service provides the email address of the recipient given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient. Please send comments on this document to the VPIM working group mailing list "High-Level Requirements for Internet Voice Mail", Emily Candell, 20-Jun-03, This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 [VPIM2] designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2 [VPIM2]. "VPIM (Voice Profile for Internet Mail) Addressing", Glenn Parsons, 02-Jul-02, This document lists the various VPIM (Voice Profile for Internet Mail) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. "Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration", Gregory Vaudreuil, Glenn Parsons, 15-Feb-02, This document is an Internet-Draft and is in full conformance with This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. This document obsoletes RFC 2422. "Content Duration MIME Header Definition", Gregory Vaudreuil, Glenn Parsons, 15-Feb-02, This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). This document obsoletes RFC 2424. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Virtual Router Redundancy Protocol", Robert Hinden, Peter Hunt, Danny Mitzel, Peter Higginson, Mike Shand, Acee Lindem, Steve Knight, Douglas Weaver, David Whipple, 21-May-03, This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns "Virtual Router Redundancy Protocol for IPv6", Robert Hinden, 21-May-03, This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address associated with a virtual router is called the Master, and forwards packets sent to this IP address. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discovery [ND] mechanisms. "Definitions of Managed Objects for the VRRP IPv6", Kalyan Tata, 26-Jun-03, 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 for IPv6 as defined in draft-ietf-vrrp-ipv6-spec-04.txt [19]. This memo specifies a MIB module in a manner that is compliant with SMIv2 [5], and semantically identical to the SMIv1 definitions [2]. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "WebDAV Access Control Protocol", Geoffrey Clemm, 30-Jun-03, This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the acl@webdav.org mailing list. Other related documents can be found at http://www.example.com/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. "WebDAV Ordered Collections Protocol", E Whitehead, Julian Reschke, 23-Jun-03, This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. "HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis", Lisa Dusseault, John Crawford, 01-Jul-03, WebDAV consists of 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). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience. "Binding Extensions to WebDAV", Geoffrey Clemm, John Crawford, 30-Jun-03, This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. "Quota and Size Properties for DAV Collections", Brian Korver, Lisa Dusseault, Claudia Warner, 06-Mar-03, WebDAV servers are frequently deployed with collection quota (size) limitations. This Internet-Draft discusses the two properties and minor behaviors needed for clients to interoperate with quota implementations on WebDAV repositories. XML Digital Signatures (xmldsig) -------------------------------- "Exclusive XML Canonicalization, Version 1.0", John Boyer, Donald Eastlake, Joseph Reagle, 13-Jun-03, Canonical XML [XML-C14N] specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the 'xml:' namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. "XML-Signature XPath Filter 2.0", John Boyer, Merlin Hughes, Joseph Reagle, 23-Jan-03, XML Signature [XML-DSig] recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- "XMPP Instant Messaging", Peter Saint-Andre, Jeff Miller, 02-Jul-03, This document describes specific extensions to and applications of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging and presence functionality defined in RFC 2779. "XMPP Core", Peter Saint-Andre, Jeff Miller, 02-Jul-03, This document describes the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming XML elements in order to exchange messages and presence information in close to real time. While XMPP provides a generalized, extensible framework for transporting structured information, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. "End-to-End Object Encryption in XMPP", Peter Saint-Andre, 02-Jul-03, This document defines a method for end-to-end object signing and encryption in the Extensible Messaging and Presence Protocol (XMPP). "Resourceprep: A Stringprep Profile for Resource Identifiers in XMPP", Peter Saint-Andre, Joe Hildebrand, 05-Jun-03, This document defines a stringprep profile for resource identifiers in the eXtensible Messaging and Presence Protocol (XMPP). "Nodeprep: A Stringprep Profile for Node Identifiers in XMPP", Peter Saint-Andre, Joe Hildebrand, 05-Jun-03, This document defines a stringprep profile for node identifiers in the eXtensible Messaging and Presence Protocol (XMPP). "XMPP CPIM Mapping", Peter Saint-Andre, T Bamonti, 02-Jul-03, This document describes a mapping of the Extensible Messaging and Presence Protocol (XMPP) to the Common Presence and Instant Messaging (CPIM) specifications. Zero Configuration Networking (zeroconf) ---------------------------------------- "Requirements for Automatic Configuration of IP Hosts", Myron Hattig, 25-Sep-02, Many common TCP/IP protocols such as DHCP [RFC2131], DNS [RFC1034][RFC1035], MADCAP [RFC2730], and LDAP [RFC2251] must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, automobile networks, airplane networks, or ad hoc networks at conferences, emergency relief stations, and many others. Such networks may be nothing more than two isolated laptop PCs connected via a wireless LAN. For all these networks, an administrative staff will not exist and the users of these networks neither have the time nor inclination to learn network administration skills. Instead, these networks need protocols that require zero user configuration and administration. This document is part of an effort to define such zero configuration (zeroconf) protocols. Before embarking on defining zeroconf protocols, protocol requirements are needed. This document states the zeroconf protocol requirements for four protocol areas; they are: IP interface configuration, translation between host name and IP address, IP multicast address allocation, and service discovery. This document does not define specific protocols, just requirements. The requirements for these four areas result from examining everyday use or scenarios of these protocols. "Dynamic Configuration of Link-Local IPv4 Addresses", Bernard Aboba, Erik Guttman, 03-Jun-03, To participate in wide-area IP networking, a host needs to be configured, either manually by the user or automatically from a source on the network such as a DHCP server. Unfortunately, such external configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP network to always be functional, even when no configuration information is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. Communication using Link-Local IPv4 addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link.