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", P. Calhoun, 17-JAN-02, The AAA Evaluation Team's recommendation document raised some issueswith the DIAMETER protocol. The AAA WG has created a design team toaddress these issues. This document is an attempt to describe theproblems, which the WG can then concentrate on solving. "Authentication, Authorization and Accounting (AAA) Transport Profile", B. Aboba, Jonathan Wood, 15-APR-02, This document discusses transport issues that arise with protocols forAuthentication, Authorization and Accounting. It also providesrecommendations on the use of transport by AAA protocols. This includesusage of standards-track RFCs as well as experimental proposals. "Diameter Base Protocol", P. Calhoun, 25-JUL-02, The Diameter base protocol is intended to provide an AAA frameworkfor applications such as network access or IP mobility. Diameter isalso intended to work both with local AAA and with roamingsituations. This draft specifies the message format, transport, errorreporting, accounting and security services to be used by allDiameter applications and MUST be supported by all Diameterimplementations. "Diameter Mobile IPv4 Application", C. Perkins, P. Calhoun, T. Johansson, 28-AUG-02, This document specifies a Diameter application that allows a Diameterserver to authenticate, authorize and collect accounting informationfor Mobile IPv4 services rendered to a mobile node. Combined withthe Inter-Domain capability of the base protocol, this applicationallows mobile nodes to receive service from foreign serviceproviders. Diameter Accounting messages will be used by the Foreignand Home agents to transfer usage information to the Diameterservers. "Diameter NASREQ Application", Allan Rubens, G. Zorn, William Bulley, P. Calhoun, Jeff Haag, David Spence, 07-MAR-02, This document describes the Diameter application that is used for AAAin a PPP/SLIP Dial-Up and Terminal Server Access environment. Thisapplication, combined with the base protocol, satisfies therequirements defined in the NASREQ AAA criteria specification and theROAMOPS AAA Criteria specification. "The DIAMETER API", P. Calhoun, James Kempf, David Frascone, 28-MAR-02, The Diameter authentication, authorization, and accounting (AAA)protocol provides support for peering AAA transactions across theInternet. This document describes a standardized API for the Diameterprotocol. The API is defined for the C language. The intent of theAPI is to foster source code portability across multiple programmingplatforms. "Diameter CMS Security Application", William Bulley, P. Calhoun, Stephen Farrell, 05-MAR-02, The Diameter base protocol leverages either IPsec or TLS forintegrity and confidentiality between two Diameter peers, and allowsthe peers to communicate through relay and proxy agents. Relay agentsperform message routing, and other than routing AVPs, do not modifyDiameter messages. Proxy agents, on the other hand, implement policyenforcement, and actively modify Diameter messages. "Diameter Extensible Authentication Protocol (EAP) Application", G. Zorn, Tom Hiller, 24-JUN-02, The Extensible Authentication Protocol (EAP) provides a standardmechanism for support of various authentication methods. Thisdocument defines the Command-Codes and AVPs necessary for a Diameternode to support the PPP Extensible Authentication Protocol (EAP). Application Configuration Access Protocol (acap) ------------------------------------------------ "ACAP Authorization Identifier Datasets Classes", Steve Hole, Alexey Melnikov, 16-JUN-02, Most distributed (client/server) applications require an authenti-cation process between the client and the server before the serverwill grant access to its managed resources. Many applications pro-vide varying levels of access to server resources based on a combi-nation of authentication credentials and access control rules.The collection of information used to control access to resourcesis called 'authorization information'.The authorization identifer datasets contain lists of users andgroups of users that can be used by applications for authorizationpurposes. Access control mechanisms can be abstracted from under-lying authentication mechanisms and credential formats. They canbe extended to include group memberships in dynamic calculationsfor access rights to resources or in definition of one time autho-rization certificates.The Application Configuration Access Protocol (ACAP) supports theremote storage and access of many types of structured configurationinformation. The authorization identifier datasets specificationdescribes the 'userid' and 'groupid' datasets which contain theauthorization information. It also describes ACAP server capabili-ties that advertise a server's support for authorization user andgroup semantics. "ACAP Application Options Dataset Class", Steve Hole, Alexey Melnikov, 16-JUN-02, The Application Configuration Access Protocol (ACAP) is designed tosupport remote storage and access of application option,configuration and preference information. The generalized form ofthis runtime configuration is called ''options''. Options consist ofany type of structured or unstructured data that an applicationrequires to operate in a user specific manner. ADSL MIB (adslmib) ------------------ "Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines", Faye Ly, Greg Bathrick, 12-SEP-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 additional managed objects used formanaging Asymmetric Digital Subscriber Line (ADSL) interfaces notcovered by the ADSL Line MIB [RFC2662]. "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", Bob Ray, Rajesh Abbi, 14-JUN-02, This document defines a 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 speedDigital Subscriber Line (VDSL) interfaces [T1E1311, T1E1011, T1E1013,ETSI2701, ETSI2702, ITU9931].This document specifies a MIB module in a manner that is compliant to the SMIv2 (STD 58 [RFC2578, RFC2579, RFC2580]). "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Bob Ray, Rajesh Abbi, 14-JUN-02, This document presents a set of Textual Conventions for MIB moduleswhich extends the conventions presented in RFC2493 to 64 bitresolution using the conventions presented in RFC2856. Application Exchange (apex) --------------------------- "The APEX Presence Service", M. Rose, D. Crocker, Graham Klyne, 15-JAN-02, This memo describes the APEX presence service, addressed as the well-known endpoint 'apex=presence'. The presence service is used tomanage presence information for APEX endpoints. AToM MIB (atommib) ------------------ "Definitions of Supplemental Managed Objects for ATM Interface", Kaj Tesink, Andrew Smith, E. Spiegel, Faye Ly, M. Noto, 13-MAY-02, 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 SONET Linear APS Architectures", J Johnson, Michael Thatcher, J Kuhfeld, 09-MAY-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 networks using SONETlinear Automatic Protection Switching (APS) architectures. "Definitions of Managed Objects for the Optical Interface Type", A. Huynh, Mark Stewart, K. Lam, 13-JUN-02, 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 performancemonitoring and/or configuration of such optical interface. "Definitions of Managed Objects for the SONET/SDH Interface Type", Kaj Tesink, 14-JAN-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 formanaging Synchronous Optical Network/Synchronous DigitalHierarchy (SONET/SDH) interfaces. This document is acompanion to the documents that define Managed Objects for theDS1/E1/DS2/E2 and DS3/E3 Interface Types [RFC2496][RFC2495]. "Definitions of Managed Objects for the DS3/E3 Interface Type", Orly Nicklass, 05-SEP-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, it describes objects used formanaging DS3 and E3 interfaces. This document is a companiondocument with Definitions of Managed Objects for the DS0,DS1/E1/DS2/E2 and SONET/SDH Interface Types, RFC2494 [25], RFC2495[17] and RFC2558 [18].This memo specifies a MIB module in a manner that is both compliantto the SNMPv2 SMI, and semantically identical to the peer SNMPv1definitions.This memo does not specify a standard for the Internet community.This document entirely replaces RFC 2495. "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", Orly Nicklass, 05-SEP-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, it describes objects used formanaging DS1, E1, DS2 and E2 interfaces. This document is acompanion document with Definitions of Managed Objects for the DS0,DS3/E3 and SONET/SDH Interface Types, RFC2494 [30], RFC2496 [28] andRFC2558 [29].This memo specifies a MIB module in a manner that is both compliantto the SNMPv2 SMI, and semantically identical to the peer SNMPv1definitions.This memo does not specify a standard for the Internet community.This document entirely replaces RFC 2495. "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Kaj Tesink, 28-FEB-02, This document defines a set of Textual Conventions for MIBmodules which make use of performance history data based on 15minute intervals. Audio/Video Transport (avt) --------------------------- "RTP Profile for Audio and Video Conferences with Minimal Control", Stephen Casner, H. Schulzrinne, 29-NOV-01, This memorandum is a revision of RFC 1890 in preparation foradvancement from Proposed Standard to Draft Standard status.This document describes a profile called 'RTP/AVP' for the use of thereal-time transport protocol (RTP), version 2, and the associatedcontrol protocol, RTCP, within audio and video multiparticipantconferences with minimal control. It provides interpretations ofgeneric fields within the RTP specification suitable for audio andvideo conferences. In particular, this document defines a set ofdefault mappings from payload type numbers to encodings. "RTP: A Transport Protocol for Real-Time Applications", V. Jacobson, Stephen Casner, R. Frederick, H. Schulzrinne, 29-NOV-01, This memorandum is a revision of RFC 1889 in preparation foradvancement from Proposed Standard to Draft Standard status. "MIME Type Registration of RTP Payload Formats", Stephen Casner, Philipp Hoschka, 29-NOV-01, This document defines the procedure to register RTP Payload Formatsas audio, video or other MIME subtype names. This is useful in atext-based format or control protocol to identify the type of anRTP transmission. This document also registers all the RTP payloadformats defined in the RTP Profile for Audio and Video Conferencesas MIME subtypes. Some of these may also be used for transfermodes other than RTP. "SDP Bandwidth Modifiers for RTCP Bandwidth", Stephen Casner, 29-NOV-01, This document defines an extension to the Session DescriptionProtocol (SDP) to specify two additional modifiers for thebandwidth attribute. These modifiers may be used to specify thebandwidth allowed for RTCP packets in a Real-Time TransportProtocol (RTP) session. "RTP Payload for Comfort Noise", Robert Zopf, 03-APR-02, This document describes an RTP [2] payload format for transportingcomfort noise (CN). The CN payload type is primarily for use withaudio codecs that do not support comfort noise as part of the codecitself such as ITU-T Recommendations G.711 [3], G.726 [4], G.727[5], G.728 [6], and G.722 [7]. "Tunneling multiplexed Compressed RTP ('TCRTP')", Dan Wing, B Thompson, Tmima Koren, 05-MAR-02, This document describes a method to improve the end-to-end bandwidth utilization of RTP streams over an IP network using compression and multiplexing. This is accomplished by combining three standard protocols: Enhanced CRTP [ECRTP] for header compression, PPP [PPP] Multiplexing [PPP-MUX] for multiplexing, and L2TP tunneling [L2TP] for transmission of PPP over an IP network. "RTP Payload Format for SMPTE 292M Video", A. Mankin, C. Perkins, L. Gharai, G. Goncher, 06-SEP-02, This memo specifies a RTP payload format for encapsulating uncompressedHigh Definition Television (HDTV) as defined by the Society of MotionPicture and Television Engineers standard, SMPTE 292M. SMPTE is the mainstandardizing body in the motion imaging industry and the SMPTE 292Mstandard defines a bit-serial digital interface for local area HDTVtransport. "Compressing IP/UDP/RTP headers on links with high delay,packet loss and reordering", Stephen Casner, P Ruddy, B Thompson, Tmima Koren, John Geevarghese, 04-MAR-02, This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on CRTP, the IP/UDP/RTP header compression described in [RFC2508]. "An RTP Payload Format for Generic FEC with Uneven Level Protection", Adam Li, 30-APR-02, This document specifies a payload format for generic forward errorcorrection to achieve uneven level protection (ULP) for media dataencapsulated in RTP. It is an extension of the forward errorcorrection scheme specified in RFC 2733 [1], and it is based on thesame exclusive-or (parity) operation. This payload format allows endsystems to apply protection using arbitrary protection lengths andlevels, in addition to using arbitrary protection group sizes. Italso enables both complete recovery or partial recovery of thecritical payload and RTP header fields depending on the packet losssituation. This scheme is completely backward compatible with non-FECcapable hosts and with hosts that are only capable of handling theFEC schemes specified in RFC 2733 [1]. Those receivers that do notknow about ULP forward error correction can simply ignore theextensions. "RTP Payload Formats to Enable Multiple Selective Retransmission", Akihiro Miyazaki, 21-JUN-02, This document describes new RTP payload formats, i.e. RTX and SEL,to enable multiple and optional selective retransmissions in RTP.These are especially applicable to environments where enhanced RTCP-based feedback, as per the RTP/AVPF profile [4], is available. Usingthese payload formats it is possible to classify the media streamaccording to prioritisation of packets or according to thetransmissions status of the packet ( i.e. transmission orretransmission). These payload formats can be tailored to fitdifferent scenarios, with different requirements and where differentsolutions are needed. Typical scenarios are unicast transmission andsmall multicast groups. In this document we give examples how thesepayload formats can be used to accommodate different retransmissionschemes. "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams", Guenther Liebl, 17-JUN-02, This document specifies an efficient way to ensure erasure-resilient transmission of progressively encoded multimediasources via RTP using Reed-Solomon (RS) codes together withinterleaving. The level of erasure protection can be explicitlyadapted to the importance of the respective parts in the sourcestream, thus allowing a graceful degradation of applicationquality with increasing packet loss rate on the network. Hence,this type of unequal erasure protection (UXP) schemes is intendedto cope with the rapidly varying channel conditions on wirelessaccess links to the Internet backbone. Nevertheless, backwardcompatibility to currently standardized non-progressivemultimedia codecs is ensured, since equal erasure protection(EXP) represents a subset of generic UXP. By applyinginterleaving and RS codes a payload format is defined, which canbe easily integrated into the existing framework for RTP. "The Secure Real-time Transport Protocol", M Baugher, 27-JUN-02, 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. "RTP Payload Format for MPEG-4 Streams", C. Perkins, 25-FEB-02, This document describes a payload format for transporting MPEG-4 encoded data using RTP. MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data. Several services provided by RTP are beneficial for MPEG-4 encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. "Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)", J Ott, 02-JUL-02, Real-time media streams that use RTP are not 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. "Transport of MPEG-4 Elementary Streams", D. Singer, Philippe Gentric, Jan Van der Meer, D Mackie, V Swaminathan, 03-JUL-02, 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, 29-JUL-02, This document specifies an RTP payload format for encapsulating ETSIStandard ES 201 108 front-end signal processing feature streams fordistributed 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 VariableRate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech.Two sub-formats are specified for different application scenarios. Abundled/interleaved format is included to reduce the effect of packetloss on speech quality and amortize the overhead of the RTP headerover more than one speech frame. A non-bundled format is alsosupported for conversational applications. "The MIDI Wire Protocol Packetization (MWPP)", John Lazzaro, John Wawrzynek, 02-JUL-02, The MIDI Wire Protocol Packetization (MWPP) is a general-purposeRTP packetization for the MIDI command language. MWPP is suitablefor use in both interactive applications (such as the pseudo-wireemulation of MIDI cables) and content-delivery applications (suchas MIDI file streaming). MWPP is designed for use over unicast andmulticast UDP, and defines MIDI-specific resiliency tools for thegraceful recovery from packet loss. In addition, a lightweightconfiguration option supports the efficient use of MWPP over TCP.MWPP-specific SDP parameters support the customization of MWPPbehavior (including the MIDI rendering method) during sessionsetup. MWPP is compatible with the MPEG-4 generic RTP payloadformat, to support the MPEG 4 Audio object types for General MIDI,DLS2, and Structured Audio. "RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback", Julian Chesterfield, 05-JUL-02, 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 framework", David Leon, Victor Varsa, 01-JUL-02, RTP retransmission is an effective packet loss recovery scheme forreal-time applications with relaxed delay bounds.This document describes an RTP retransmission framework. It definesa payload format for retransmitted packets and recommends rules forsending these packets. Retransmitted RTP packets are sent in aseparate stream from the original RTP stream. It is assumed thatfeedback from receivers to senders indicating the occurred packetlosses is available by some means not defined here. "RTP Payload for Interleaved Audio", Orion Hodson, 07-MAY-02, This document describes a payload format for use with theReal-time Transport Protocol (RTP) version 2 for interleavingencoded audio data. It is intended for use in audio streamingdelay tolerant applications operating over best-effort packetnetworks. The goal of interleaving is to disperse burstlosses into a series of shorter losses. The total amount ofaudio lost is not changed by interleaving, but the individualloss events are shorter and easier to conceal at the receiver. "RTP Payload Format for JPEG 2000 Video Streams", Eric Edwards, 01-JUL-02, This document describes a payload format for transporting JPEG 2000video streams using RTP (Real-time Transport Protocol). JPEG 2000video streams are formed as a continuous series of JPEG 2000 stillimages. The JPEG 2000 payload format described in this document hasthree features: (1) Improvement of robustness to packet loss byintelligently fragmenting JPEG 2000 packet units, (2) Persistency ofmain header to minimize loss effect and maximize recovery, (3)Priority information field for scalable delivery from the same codestream. These will allow for scalability and robustness of JPEG2000's potential to be maximized in streaming applications. "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", H. Schulzrinne, Scott Petrack, 29-MAY-02, 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. "RTP Payload Format for AC-3 Streams", Jason Flaks, 02-AUG-02, This document describes an RTP payload format for transporting AC-3 encoded audio data. AC-3 is a high quality multichannel audio coding system fully described in [2] by the Advanced Television Standards Committee (ATSC). 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. Border Gateway Multicast Protocol (bgmp) ---------------------------------------- "Border Gateway Multicast Protocol (BGMP): Protocol Specification", D Thaler, 22-JUL-02, This document describes BGMP, a protocol for inter-domain multicastrouting. BGMP builds shared trees for active multicast groups, andoptionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports'source-specific multicast' (SSM). To also support 'any-sourcemulticast' (ASM), BGMP requires that each multicast group be associatedwith a single root (in BGMP it is referred to as the root domain). Itrequires that different ranges of the class D space are associated(e.g., with Unicast-Prefix-Based Multicast addressing) with differentdomains. Each of these domains then becomes the root of the shareddomain-trees for all groups in its range. Multicast participants willgenerally receive better multicast service if the session initiator'saddress allocator selects addresses from its own domain's part of thespace, thereby causing the root domain to be local to at least one ofthe session participants. Benchmarking Methodology (bmwg) ------------------------------- "Methodology for IP Multicast Benchmarking", Debra Stopp, Hardev Soor, 07-AUG-02, 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. "Benchmarking Methodology for Firewall Performance", David Newman, T Martin, B Hickman, Saldju Tadjudin, 18-JUN-02, This document discusses and defines a number of tests that may beused to describe the performance characteristics of firewalls. Inaddition to defining the tests this document also describes specificformats for reporting the results of the tests.This document is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF). "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", David Newman, Jerry Perser, 13-JUN-02, This document describes terminology for the benchmarking ofdevices that implement traffic control based on IP precedence ordiff-serv code point criteria.New terminology is needed because most existing measurementsassume the absence of congestion and only a single per-hop-behavior. This document introduces several new terms that willallow measurements to be taken during periods of congestion. "Terminology for Benchmarking BGP Device Convergence in the Control Plane", H. Berkowitz, 29-JUL-02, This draft establishes terminology to standardize the description ofbenchmarking methodology for measuring eBGP convergence in thecontrol plane of a single BGP device. Future documents will addressiBGP convergence, the initiation of forwarding based on convergedcontrol plane information and multiple interacting BGP devices. Thisterminology is applicable to both IPv4 and IPv6. Illustrativeexamples of each version are included where relevant. "Benchmarking Methodology for Basic BGP Convergence", H. Berkowitz, 05-MAR-02, This draft establishes standards for measuring BGP convergenceperformance. Its initial emphasis is on the control plane of singleBGP routers. We do not address forwarding plane performance. "Methodology for Forwarding Information Base (FIB) based Router Performance", Guy Trotter, 17-JAN-02, 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", Russ White, Vishwas Manral, Aman Shaikh, 10-MAY-02, This draft explains the terminology and concepts used in [2] andfuture OSPF benchmarking drafts. "Benchmarking Methodology for Basic OSPF Convergence", Russ White, Vishwas Manral, Aman Shaikh, 10-MAY-02, This draft establishes standards for measuring OSPF convergenceperformance on a single router (SR-Convergence [4]). Its initialemphasis is on the control plane of single OSPF routers. We do notaddress forwarding plane performance. Bridge MIB (bridge) ------------------- "Definitions of Managed Objects for Bridges", E Bell, K Norseth, 22-MAY-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 onthe 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 bridgesconnected by subnetworks other than LAN segments.The MIB presented in this memo is a direct translation of the BRIDGEMIB defined in [RFC1493], to the SMIv2 syntax required for currentIETF MIB standards. This memo obsoletes RFC 1493. "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", E Bell, Vivian Ngai, 18-JUN-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 a MIB module for managing the RapidSpanning Tree capability defined by the IEEE P802.1t [802.1t] andP802.1w [802.1w] amendments to IEEE Std 802.1D-1998 for bridgingbetween Local Area Network (LAN) segments.Provisions are made for support of transparent bridging. Provisionsare also made so that these objects apply to bridges connected bysubnetworks other than LAN segments. This memo also includes a MIBmodule in a manner that is compliant to SMIv2 [RFC2578]. "Definitions of Managed Objects for Bridges with TrafficClasses, Multicast Filtering and Virtual LAN Extensions", E Bell, Vivian Ngai, 26-MAR-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 two MIB modules for managing the newcapabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards forbridging between Local Area Network (LAN) segments. One MIB moduledefines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001.The other MIB module defines objects for managing VLANs, as specifiedin IEEE 802.1Q-1998, P802.1u and P802.1v. "Definitions for Port Access Control (IEEE 802.1X) MIB", K Norseth, 30-MAY-02, This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-basedinternets. In particular, it defines objects for managing theoperation of Port Access Control, based on the specificationcontained in Clause 8 and Clause 9 of the IEEE 802.1X standard. Thisclause includes a MIB module that is SNMPv2 SMI compliant.This standard defines a mechanism for Port-based network accesscontrol that makes use of the physical access characteristics ofIEEE 802 LAN infrastructures in order to provide a means ofauthenticating and authorizing devices attached to a LAN port thathas point-to-point connection characteristics, and of preventingaccess to that port in cases in which the authentication andauthorization process fails.This standard is part of a family of standards for local andmetropolitan area networks. This draft is written within the IEEE 802.1X working group and isbeing presented to the IETF for informational purposes. Calendaring and Scheduling (calsch) ----------------------------------- "Calendar Access Protocol (CAP)", Paul Hill, G Babics, S. Mansour, Doug Royer, 03-JUL-02, The Calendar Access Protocol (CAP) is an Internet protocol describedin this memo that permits a Calendar User (CU) to utilize a CalendarUser Agent (CUA) to access an [iCAL] based Calendar Store (CS).The CAP definition is based on requirements identified by theInternet Engineering Task Force (IETF) Calendaring and Scheduling(CALSCH) Working Group. More information about the IETF CALSCHWorking 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 thereferences within this memo for further information on how to accessthese various documents. "iCalendar DTD Document (xCal)", Frank Dawson Jr., Surendra Reddy, Doug Royer, Eric Plamondon, 26-JUL-02, This memo defines a [XML] Document Type Definition (DTD) thatcorresponds to the iCalendar, Internet Calendaring and SchedulingCore Object Specification defined by [RFC 2445]. This DTD providesequivalent functionality to the standard format defined by [RFC2445]. Documents structured in accordance with this DTD may also beknown as 'XML iCalendar' documents or 'xCal'. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Generalized MPLS - Signaling Functional Description", E Mannie, 29-AUG-02, This document describes extensions to MPLS (Multi-Protocol LabelSwitching) signaling required to support Generalized MPLS.Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous DigitalHierarchy, SONET/SDH), wavelength (optical lambdas) and spatialswitching (e.g. incoming port or fiber to outgoing port or fiber).This document presents a functional description of the extensions.Protocol specific formats and mechanisms, and technology specificdetails are specified in separate documents. "Generalized MPLS Signaling - CR-LDP Extensions", E Mannie, P. Ashwood-Smith, 29-AUG-02, This document describes extensions to MPLS (Multi-Protocol LabelSwitching) CR-LDP (Constraint-based Routed Label DistributionProtocol) signaling required to support Generalized MPLS. GeneralizedMPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.incoming port or fiber to outgoing port or fiber). This documentpresents a CR-LDP specific description of the extensions. A genericfunctional description can be found in separate documents. "Generalized MPLS Signaling - RSVP-TE Extensions", E Mannie, 29-AUG-02, This document describes extensions to MPLS (Multi-Protocol LabelSwitching) RSVP-TE (Resource ReserVation Protocol - TrafficEngineering) signaling required to support Generalized MPLS.Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous DigitalHierarchy, SONET/SDH), wavelength (optical lambdas) and spatialswitching (e.g. incoming port or fiber to outgoing port or fiber).This document presents a RSVP-TE specific description of theextensions. A generic functional description can be found inseparate documents. "Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control", E Mannie, D. Papadimitriou, 29-AUG-02, This document is a companion to the Generalized MultiprotocolLabel Switching (GMPLS) signaling. It defines the SynchronousOptical Network (SONET)/Synchronous Digital Hierarchy (SDH)technology specific information needed when using GMPLS signaling. "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", E Mannie, 03-SEP-02, Future data and transmission networks will consist of elements such as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc that will use Generalized MPLS (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.This document describes the architecture of GMPLS. GMPLS extendsMPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709),wavelength (lambdas), and spatial switching (e.g. incoming port orfiber to outgoing port or fiber). The main focus of GMPLS is on thecontrol plane of these various layers since each of them can usephysically diverse data or forwarding planes. The intention is tocover both the signaling and the routing part of that control plane. "Link Management Protocol (LMP)", J. Lang, 28-AUG-02, 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 neighboring 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", Y. Rekhter, K. Kompella, 28-AUG-02, This document specifies routing extensions in support of GeneralizedMulti-Protocol Label Switching (GMPLS). "OSPF Extensions in Support of Generalized MPLS", Y. Rekhter, K. Kompella, 28-AUG-02, This document specifies encoding of extensions to the OSPF routingprotocol in support of Generalized Multi-Protocol Label Switching. "Generalized Multiprotocol Label Switching Extensions to Control Non-Standard SONET and SDH Features", E Mannie, D. 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, 02-JUL-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 modeling the LinkManagement Protocol (LMP). "TITLE: Optical Link Interface Requirements", A Fredette, 12-FEB-02, The emergence of transparent optical switches, together with a movement towards more dynamic, multi-vendor networks, has introduced a need for information sharing between optical line systems and client devices. The information that needs to be shared includes link status and link properties. We call this interface the Optical Link Interface (OLI). In this document, we provide high-level requirements for the OLI. "Link Management Protocol (LMP) for DWDM Optical Line Systems", A Fredette, 12-FEB-02, A suite of protocols is being developed in the IETF to allow networks consisting of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM optical line systems (OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS-based control plane to dynamically provision resources and to provide network survivability using protection and restoration techniques. "Framework for GMPLS-based Control of SDH/SONET Networks", E Mannie, Vishal Sharma, Greg Bernstein, 23-MAY-02, 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, Y. Rekhter, 21-JUN-02, This document provides a survey of GMPLS signaling implementations.The primary focus of this survey are the signaling protocolmechanisms specified in the Generalized MPLS signaling documents.Other specifications and documents are listed if included in thesubmitted form. The survey form and latest version of this documentare available from http://www.labn.net/gmpls-survey. "Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control", D. Papadimitriou, 11-JUN-02, This document is a companion to the Generalized MPLS (GMPLS)signalling documents. It describes the technology specificinformation needed to extend GMPLS signalling to control OpticalTransport Networks (OTN); it also includes the so-called pre-OTNdevelopments. "Definition of Textual Conventions and OBJECT-IDENTITIES for Generalized Multiprotocol Label Switching (GMPLS) Management", Thomas Nadeau, 28-JUN-02, This memo describes Textual Conventions and OBJECT-IDENTITIES common to the Management Information Bases(MIBs) for managing Generalized Multiprotocol LabelSwitching (GMPLS) networks.It supplements [TCMIB] which describes TextualConventions and OBJECT-IDENTITIES common to theManagement Information Bases (MIBs) for managingMultiprotocol Label Switching (MPLS) networks. "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", T Nadeau, 28-JUN-02, This memo defines an experimental portion of theManagement Information Base (MIB) for use with networkmanagement protocols in the Internet community. Inparticular, it describes managed objects for GeneralizedMultiprotocol Label Switching (GMPLS) [GMPLSArch] basedtraffic engineering. "Generalized Multiprotocol Label Switching (GMPLS) Label Switch Router Management Information Base", Thomas Nadeau, 28-JUN-02, This memo defines a portion of the Management InformationBase (MIB) for use with network management protocols inthe Internet community. In particular, it describesmanaged objects for Generalized Multiprotocol LabelSwitching (GMPLS) Label Switched Routers (LSRs). "Recovery (Protection and Restoration) Terminology for GMPLS", E Mannie, D. Papadimitriou, 02-JUL-02, This document defines a common terminology for GMPLS based recoverymechanisms (i.e. protection and restoration) that are underconsideration by the CCAMP Working Group. "Tracing Requirements for Generic Tunnels", Ron Bonica, K. Kompella, David Meyer, 03-SEP-02, This document specifies requirements for a generic route-tracingapplication. It also specifies requirements for a protocol that willsupport the generic route-tracing application. "SONET/SDH Encoding for Link Management Protocol (LMP) Test messages", D. Papadimitriou, J. Lang, 10-SEP-02, This document details the Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when sending Link Management Protocol (LMP) test messages Content Distribution Internetworking (cdi) ------------------------------------------ "A Model for Content Internetworking (CDI)", Mark Day, 03-MAY-02, Content [distribution] internetworking (CDI) is the technology forinterconnecting content networks, sometimes previously called'content peering' or 'CDN peering.' A common vocabulary helps theprocess of discussing such interconnection and interoperation. Thisdocument introduces content networks and content internetworking, anddefines elements for such a common vocabular "Known CN Request-Routing Mechanisms", Brad Cain, A Barbir, 08-MAY-02, 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. In this memo the term Request-Routing represents techniques that are commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. "Content Internetworking Architectural Overview", Mark Green, 02-JUL-02, There is wide interest in the technology for interconnecting ContentNetworks, variously called 'Content Peering' or 'ContentInternetworking'. We present the general architecture and corebuilding blocks used in the internetworking of Content Networks. Thescope of this work is limited to external interconnections withContent Networks and does not address internal mechanisms used withinContent Networks, which for the purpose of the document areconsidered to be black boxes. This work establishes an abstractarchitectural framework to be used in the development of protocols,interfaces, and system models for standardized ContentInternetworking. "Request-Routing Requirements for Content Internetworking", Brad Cain, 01-JUL-02, Request-routing systems (RRS) are components of Content DistributionNetworks (CDNs) that direct client requests to an available copy ofcontent based on one or more metrics. To enable the interconnection ofCDNs [MODEL][ARCH], it is necessary for their request-routing systems tointerconnect and exchange information such that client requests can berouted between CDNs. This is called request-routing internetworking.This document specifies the requirements for request-routinginternetworking. "Distribution Requirements for Content Internetworking", Lisa Amini, 22-FEB-02, This document specifies requirements for interconnecting, orpeering, the distribution systems of Content Networks (CN).Distribution internetworking requires advertising the capabilitiesof a CN offering distribution services, moving content from one CNto another, and signaling requirements for consistent storage anddelivery of content. This document does not address requirements fordirecting user agents to distributed content, nor for aggregatingaccess information for distributed content. "Content Distribution Internetworking (CDI) AAA Requirements", Don Gilletti, 13-JUN-02, In developing a solution for CDN Internetworking it is necessary todefine and accommodate requirements for Authentication,Authorization, and Accounting. Since the Authentication,Authorization, and Accounting (AAA) working group is already focusedon defining these requirements, this document attempts to leveragethat work. It contains the requirements that would have to besupported by a AAA service to formulate a solution for CDN peering. "Content Internetworking (CDI) Scenarios", Mark Day, Don Gilletti, Phillip Rzewski, 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. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "The Internet Resource Query Service and the Internet Resource Schema", Eric Hall, 30-JUL-02, This document describes an architectural framework for locating and retrieving information about network resources, using LDAPv3 for the data-formatting and query-processing services. This document also defines LDAP schema and searching rules for four Internet resource types: DNS domains, IPv4 addresses, IPv6 address, and AS numbers. The framework specified in this document also allows additional documents to define additional Internet resource types and their handling rules. "Defining and Locating DNS Domains using the Internet Resource Query Service", Eric Hall, 30-JUL-02, This document defines LDAP schema and searching rules for DNS domains, in support of the Internet Resource Query Service described in [ldap-whois]. "Defining and Locating Autonomous System Numbers using the Internet Resource Query Service", Eric Hall, 30-JUL-02, This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Internet Resource Query Service described in [ldap-whois]. "Defining and Locating IPv6 Address Blocks using the Internet Resource Query Service", Eric Hall, 30-JUL-02, This document defines LDAP schema and searching rules for IPv6 addresses and address blocks, in support of the Internet Resource Query Service described in [ldap-whois]. "Defining and Locating Contact Persons using the Internet Resource Query Service", Eric Hall, 30-JUL-02, This document defines LDAP schema and searching rules for contact persons, in support of the Internet Resource Query Service described in [ldap-whois]. "Defining and Locating IPv4 Address Blocks using the Internet Resource Query Service", Eric Hall, 30-JUL-02, This document defines LDAP schema and searching rules for IPv4 addresses and address blocks, in support of the Internet Resource Query Service described in [ldap-whois]. "Cross Registry Internet Service Protocol (CRISP) Requirements", A Newton, 02-AUG-02, Internet registries expose administrative and operational data viavarying directory services. This document defines functionalrequirements for the directory services of domain registries and thecommon base requirements for extending the use of these services forother types of Internet registries. "IRIS Domain Registry Schema", A Newton, 15-AUG-02, This document describes an IRIS (draft-ietf-crisp-iris-core-00.txt )registry schema for registered DNS information. The schema extendsthe necessary query and result operations of IRIS to provide thefunctional information service needs for syntaxes and results usedby domain registries and registrars. "Internet Registry Information Service (IRIS)", A Newton, 15-AUG-02, This document describes an application layer client-server protocolfor a framework of representing the query and result operations ofthe information services of Internet registries. Specified in XML,the protocol defines generic query and result operations and amechanism for extending these operations for specific registryservice needs. "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", A Newton, 15-AUG-02, This document specifies how to use the Blocks Extensible ExchangeProtocol (BEEP) as the application transport substrate for theInternet Registry Information Service (IRIS) as describeddraft-ietf-crisp-iris-core-00.txt. "IRIS Address Registry Schema", A Newton, 15-AUG-02, This document describes an IRIS registry id and schema forregistered Internet address information. The schema extends thenecessary query and result operations of IRIS(draft-ietf-crisp-iris-core-00.txt) to provide the functionalinformation service needs for syntaxes and results used by Internetaddress registries. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Ralph Droms, C. Perkins, J. Bound, B. Volz, M. Carney, T. Lemon, 10-JUN-02, The Dynamic Host Configuration Protocol for IPv6 (DHCP) enablesDHCP servers to pass configuration parameters such as IPv6 networkaddresses to IPv6 nodes. It offers the capability of automaticallocation of reusable network addresses and additional configurationflexibility. This protocol is a stateful counterpart to 'IPv6Stateless Address Autoconfiguration' (RFC2462), and can be usedseparately or concurrently with the latter to obtain configurationparameters "DHCP Failover Protocol", Ralph Droms, B. Volz, K. Kinnear, Arun Kapur, Mark Stapp, Greg Rabil, Mike Dooley, Steve Gonczi, 24-JAN-02, DHCP [RFC 2131] allows for multiple servers to be operating on asingle network. Some sites are interested in running multipleservers in such a way so as to provide redundancy in case of serverfailure. In order for this to work reliably, the cooperating primaryand secondary servers must maintain a consistent database of thelease information. This implies that servers will need to coordinateany and all lease activity so that this information is synchronizedin case of failover.This document defines a protocol to provide such synchronizationbetween two servers. One server is designated the 'primary' server,the other is the 'secondary' server. This document also describes away to integrate the failover protocol with the DHCP load balancingapproach.This document is a substantial reorganization as well as a technicaland editorial revision of draft-ietf-dhc-failover-05.txt. "Dynamic Host Configuration Protocol (DHCP) Server MIB", Glenn Waters, Richard Barr Hibbs, 15-FEB-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet Community. In particular, it defines objects used forthe management of Dynamic Host Configuration Protocol (DHCP) andBootstrap Protocol (BOOTP) servers. "The Classless Static Route Option for DHCP", B. Volz, T. Lemon, S. Cheshire, 05-JUL-02, This document defines a new DHCP option which is passed from theDHCP Server to the DHCP Client to configure a list of static routesin the client. The network destinations in these routes areclassless - each routing table entry includes a subnet mask. "DHCP Option for CableLabs Client Configuration", B. Beser, P. Duffy, 26-AUG-02, This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. "The DHCP Client FQDN Option", Y. Rekhter, Mark Stapp, 21-JUN-02, DHCP provides a powerful mechanism for IP host configuration.However, the configuration capability provided by DHCP does notinclude updating DNS, and specifically updating the name to addressand address to name mappings maintained in the DNS.This document specifies a DHCP option which can be used to exchangeinformation about a DHCP client's fully-qualified domain name, andabout responsibility for updating DNS RRs related to the client'sDHCP lease. "Resolution of DNS Name Conflicts Among DHCP Clients", Mark Stapp, 21-JUN-02, DHCP provides a powerful mechanism for IP host configuration.However, the configuration capability provided by DHCP does notinclude updating DNS(RFC1034[1], RFC1035[2]), and specificallyupdating the name to address and address to name mappings maintainedin the DNS.The 'Client FQDN Option'[14] specifies the client FQDN option,through which DHCP clients and servers can exchange informationabout client FQDNs. This document describes techniques for theresolution of DNS name conflicts among DHCP clients. "DHCP Lease Query", Richard Woundy, K. Kinnear, 05-MAR-02, Access concentrators that act as DHCP relay agents need to determinethe endpoint locations of IP addresses across public broadband accessnetworks such as cable, DSL, and wireless networks. Because ARPbroadcasts are undesirable in public networks, many accessconcentrator implementations 'glean' location information from DHCPmessages forwarded by its relay agent function. Unfortunately, thetypical access concentrator loses its gleaned information when theaccess concentrator is rebooted or is replaced. This memo proposesthat when gleaned DHCP information is not available, the accessconcentrator/relay agent obtains the location information directlyfrom the DHCP server(s) using a new, lightweight DHCPLEASEQUERYmessage. "Encoding Long Options in DHCPv4", T. Lemon, S. Cheshire, 11-SEP-02, This document specifies the processing rules for DHCPv4 optionsthat appear multiple times in the same message. Multipleinstances of the same option are generated when an option exceeds255 octets in size (the maximum size of a single option) or whenan option needs to be split apart in order to take advantage ofDHCP option overloading. When multiple instances of the sameoption appear in the options, file and/or sname fields in a DHCPpacket, the contents of these options are concatenated togetherto form a single option prior to processing. "Link Selection sub-option for the Relay Agent Information Option", Richard Johnson, K. Kinnear, Jay Kumarasamy, Mark Stapp, 29-APR-02, In RFC 2131, the giaddr specifies an IP address which determines botha subnet and thereby a link on which a DHCP client resides as well asan IP address which can be used to communicate with the relay agent.The subnet-selection option [RFC 3011] allows these functions of thegiaddr to be split so that when one entity is performing as a DHCPproxy, it can specify the subnet/link from which to allocate an IPaddress which is different from the IP address with which it desiresto communicate with the DHCP server. Analgous situations exist wherethe relay agent needs to specify the subnet/link on which a DHCPclient resides which is different from an IP address which can beused to communicate with the relay agent. The link-selection sub-option (specified here) of the relay-agent-information option allowsa relay agent to do this. "VPN Identifier sub-option for the Relay Agent Information Option", Richard Johnson, K. Kinnear, Jay Kumarasamy, Mark Stapp, 05-MAR-02, In some environments, a relay agent resides in a network elementwhich also has access to one or more VPNs. If one DHCP server wishesto offer service to DHCP clients on those different VPNs the DHCPserver needs to know the VPN on which each client resides. "DSTM Options for DHCPv6", J. Bound, 26-APR-02, The DSTM Global IPv4 Address option and the DSTM Tunnel EndpointOption provide DSTM (Dual Stack Transition Mechanism) configurationinformation to DHCPv6 hosts. "DNS Configuration Options for DHCPv6", J. Bound, 02-MAY-02, This document describes DHCPv6 options for passing a list ofavailable 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, 21-FEB-02, A network access device may choose to authenticate the identity of adevice before granting that device access to the network. The IEEE802.1X protocol is an example of a mechanism for providingauthenticated layer 2 network access. A network element using RADIUSas an authentication authority will receive attributes from a RADIUSserver that may be used by a DHCP server in the selection of an IPaddress for assignment to the device through its DHCP client. TheRADIUS Attributes sub-option allows a network element to pass alongattributes for the user of a device received during RADIUSauthentication to a DHCP server. "Load Balancing for DHCPv6", B. Volz, 31-JUL-02, This document specifies a load balancing algorithm for use withDHCPv6. Load balancing enables multiple cooperating DHCPv6 serversto decide which one should service a client, without exchangingany information beyond initial configuration. It expands on RFC3074 'DHC Load Balancing Algorithm' to include DHCPv6. "DSTM Ports Option for DHCPv6", Myung-Ki Shin, 28-JUN-02, The DSTM Ports Option provide DSTM (Dual Stack TransitionMechanism) configuration information to DHCPv6 hosts "NIS Configuration Options for DHCPv6", A Vijayabhaskar, 10-MAY-02, This document describes four options for NIS-related configurationinformation in DHCPv6: NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. "Time Configuration Options for DHCPv6", A Vijayabhaskar, 10-MAY-02, This document describes the options for Time related configurationinformation in DHCPv6: NTP Servers and IEEE 1003.1 POSIX Timezone specifier. "Considerations for the use of the Host Name option", Carl Smith, T. Lemon, 28-FEB-02, This document clarifies the use of the DHCP Host Name option. Theprimary point of this clarification addresses the use of the optionby clients to request proxy DNS updates by DHCP servers. "DHCP Options for Internet Storage Name Service", Josh Tseng, 27-AUG-02, This document describes the DHCP option to allow iSNS clientsdevices using DHCP to automatically discover the location of theiSNS server. iSNS provides discovery and management capabilities foriSCSI and Fibre Channel (FCP) storage devices in an enterprise-scaleIP storage network. iSNS provides intelligent storage managementservices comparable to those found in Fibre Channel networks,allowing a commodity IP network to function in a similar capacity asa storage area network. "Client Preferred Prefix option for DHCPv6", A Vijayabhaskar, 24-JUN-02, This document describes the Client Preferred Prefix option by whichthe 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", T. Lemon, Mark Stapp, 25-JUN-02, The DHCP Relay Agent Information Option RFC3046[1] conveysinformation between a DHCP Relay Agent and a DHCP server. Thisspecification defines a new authentication suboption for that optionwhich supports source entity authentication and data integrity forthat option. The authentication suboption contains a payload derivedfrom the option used in DHCP Authentication RFC3118[2]. Differentiated Services (diffserv) ---------------------------------- "Differentiated Services Quality of Service Policy Information Base", Keith McCloghrie, Mike Fine, 17-JUN-02, This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control of resources implementing the Differentiated Services Architecture. These provisioning classes can be used with other none Differentiated Services provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage. Distributed Management (disman) ------------------------------- "Alarm MIB", D. Romascanu, S. Chisholm, 29-AUG-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 definingand storing alarms. "Alarm Report Control MIB", D. Perkins, A. Huynh, K. Lam, 03-SEP-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 controlling the reporting of alarm conditions. "Event MIB", Bob Stewart, Ramanathan Kavasseri, 04-SEP-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 that can be used tomanage and monitor MIB objects and take action through events.The Event MIB provides the ability to monitor MIB objects on thelocal system or on a remote system and take simple action when atrigger condition is met. "Distributed Management Expression MIB", Bob Stewart, Ramanathan Kavasseri, 04-SEP-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 managingexpressions of MIB objects. The results of these expressions becomeMIB objects usable like any other MIB object, such as for the testcondition for declaring an event. DNS Extensions (dnsext) ----------------------- "Extensions to DNS (EDNS1)", P Vixie, 15-AUG-02, This document specifies a number of extensions within the ExtendedDNS framework defined by [EDNS0], including several new extendedlabel types and the ability to ask multiple questions in a singlerequest. "DNS Zone Transfer Protocol Clarifications", Andreas Gustafsson, 05-MAR-02, In the Domain Name System, zone data is replicated amongauthoritative DNS servers by means of the 'zone transfer' protocol,also known as the 'AXFR' protocol. This memo clarifies, updates, andadds missing detail to the original AXFR protocol specification inRFC1034. "GSS Algorithm for TSIG (GSS-TSIG)", S. Kwan, James Gilroy, Praerit Garg, L. Esibov, Randy Hall, Jeff Westhead, 05-FEB-02, The TSIG protocol provides transaction level authentication for DNS.TSIG is extensible through the definition of new algorithms. Thisdocument specifies an algorithm based on the Generic Security ServiceApplication Program Interface (GSS-API) (RFC2743). "A DNS RR for encoding DHCP information (DHCID RR)", T. Lemon, Mark Stapp, Andreas Gustafsson, 21-JUN-02, It is possible for multiple DHCP clients to attempt to update thesame DNS FQDN as they obtain DHCP leases. Whether the DHCP server orthe 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 unambiguouslyassociate domain names with the DHCP clients to which they refer.This memo defines a distinct RR type for this purpose for use byDHCP clients and servers, the 'DHCID' RR. "DNS Security Document Roadmap", S. Rose, 06-SEP-02, DNS Security (DNSSEC)technology is composed of extensions to theDomain Name System (DNS) protocol that provide data integrity andauthentication to security aware resolvers and applications throughthe use of cryptographic digital signatures. Several documents existto describe these extensions and the implementation-specific detailsregarding specific digital signing schemes. The interrelationshipbetween these different documents is discussed here. A briefoverview of what to find in which document and author guidelines forwhat to include in new DNS Security documents, or revisions toexisting documents, is described. "Applicability Statement for DNS MIB Extensions", Rob Austein, 30-OCT-00, More than six years after the DNS Server and Resolver MIB extensionsbecame proposed standards, there still has not been any significantdeployment of these MIB extensions. This note examines the reasonswhy these MIB extensions were never deployed, and recommends retiringthese MIB extensions by moving them to Historical status. "Handling of Unknown DNS RR Types", Andreas Gustafsson, 02-JUL-02, Extending the Domain Name System with new Resource Record typescurrently requires changes to name server software. This documentspecifies the changes necessary to allow future DNS implementationsto handle new RR types transparently. "Linklocal Multicast Name Resolution (LLMNR)", B. Aboba, D. Thaler, L. Esibov, 27-AUG-02, Today, with the rise of home networking, there are an increasing numberof ad-hoc networks operating without a DNS server. In order to allowname resolution in such environments, Link-Local Multicast NameResolution (LLMNR) is proposed. LLMNR supports all current and futureDNS formats, types and classes, while operating on a separate port fromDNS, and with a distinct resolver cache. "Redefinition of DNS AD bit", O. Gudmundsson, B. Wellington, 28-JUN-02, Based on implementation experience, the RFC2535 definition of theAuthenticated Data (AD) bit in the DNS header is not useful. Thisdraft changes the specification so that the AD bit is only set onanswers where signatures have been cryptographically verified or theserver is authoritative for the data and is allowed to set the bit bypolicy. "Obsoleting IQUERY", David Lawrence, 23-JUL-02, The IQUERY method of performing inverse DNS lookups, specified inRFC 1035, has not been generally implemented and has usually beenoperationally disabled where it has been implemented. Both reflecta general view in the community that the concept was unwise andthat the widely-used alternate approach of using PTR queries andreverse-mapping records is preferable. Consequently, this documentdeprecates the IQUERY operation and updates RFC 1035 to declare itentirely obsolete. "Delegation Signer Resource Record", O. Gudmundsson, 01-JUL-02, The delegation signer (DS) resource record is inserted at a zone cut(i.e., a delegation point) to indicate that the delegated zone isdigitally signed and that the delegated zone recognizes the indicatedkey as a valid zone key for the delegated zone. The DS RR is amodification to the DNS Security Extensions definition, motivated byoperational considerations. The intent is to use this resource recordas an explicit statement about the delegation, rather than relying oninference.This document defines the DS RR, gives examples of how it is used andthe implications of this record on resolvers. This change is notbackwards compatible with RFC 2535.This document updates RFC1035, RFC2535, RFC3008 and RFC3090. "DNSSEC Opt-in", M. Kosters, D. Blacka, R. Arends, 01-JUL-02, In RFC 2535, delegations to unsigned subzones are cryptographicallysecured. Maintaining this cryptography is not practical ornecessary. This document describes an "DSA KEYs and SIGs in the Domain Name System (DNS)", Donald Eastlake, 31-MAY-02, A standard method for storing US Government Digital SignatureAlgorithm keys and signatures in the Domain Name System is describedwhich utilizes DNS KEY and SIG resource records. "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", Donald Eastlake, 31-MAY-02, A standard method for storing Diffie-Hellman keys in the Domain NameSystem is described which utilizes DNS KEY resource records. "DNS Security Introduction and Requirements", D. Massey, M. Larson, S. Rose, R. Arends, 25-JUL-02, The Domain Name System Security Extensions (DNSSEC) provide dataorigin authentication and data integrity. This document introducesthese extensions and describes their capabilities and limitations.The services that the security extensions provide and do not provideare discussed. Lastly, the group of documents that describe the DNSsecurity extensions and their interrelationships is discussed. "Elliptic Curve KEYs in the DNS", Donald Eastlake, R Schroeppel, 03-JUN-02, A standard method for storing elliptic curve cryptographic keys inthe Domain Name System is described which utilizes DNS KEY resourcerecord. "TKEY Secret Key Renewal Mode", Masaya Nakayama, Y Kamite, 15-MAY-02, This document defines a new mode in TKEY [RFC2930] and proposes anatomic method for changing secret keys used for TSIG [RFC2845]periodically. Originally, TKEY provides methods of setting up sharedsecrets other than manual exchange, but it cannot control timing ofkey renewal very well though it can add or delete shared keysseparately. This proposal is a systematical key renewal procedureintended for preventing signing DNS messages with old and non-safekeys permanently. "Limiting the Scope of the KEY Resource Record out", D. Massey, S. Rose, 11-SEP-02, This document limits the Domain Name System KEY resource record toonly keys used by the Domain Name System Security Extensions(DNSSEC). The original KEY resource record used sub-typing to storeboth DNSSEC keys and arbitrary application keys. Storing both DNSSECand application keys with the same record type is a mistake. Thisdocument removes application keys from the KEY record by redefiningthe Protocol Octet field in the KEY Resource Record Data. As aresult of removing application keys, all but one of the flags in theKEY record become unnecessary and are redefined. Three existingapplication key sub-types are changed to reserved, but the format ofthe KEY record is not changed. This document updates RFC 2535. "Threat Analysis Of The Domain Name System", Derek Atkins, Rob Austein, 28-FEB-02, Although the DNS Security Extensions (DNSSEC) have been underdevelopment for most of the last decade, the IETF has never writtendown the specific set of threats against which DNSSEC is designed toprotect. Among other drawbacks, this cart-before-the-horse situationhas made it difficult to determine whether DNSSEC meets its designgoals, since its design goals are not well specified. This noteattempts to document some of the known threats to the DNS, and, indoing so, attempts to measure to what extent (if any) DNSSEC is auseful tool in defending against these threats. "Resource Records for DNS Security Extensions", R. Arends, 01-JUL-02, The DNS Security Extensions (DNSSEC) introduce four resource records:the KEY, DS, SIG, and NXT resource records. This document definesthe purpose and the RDATA format for each of these records. Thisdocument is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are acollection of new resource records and protocol modifications thatprovide source authentication for the DNS. This document obsoletesRFC 2535 and incorporates changes from all updates to RFC 2535. "The DISCOVER opcode", Bill Manning, P Vixie, E. Guttman, 15-APR-02, The QUERY opcode in the DNS is designed for unicast. With thedevelopment of multicast capabilities in the DNS, it is desireableto have a more robust opcode for server interactions since a singlerequest may result in replies from multiple responders. So DISCOVERis defined to deal with replies from multiple responders.As such, this document extend the core DNS specifications to allowclients to have a method for coping with replies from multipleresponders. Use of this new opcode may facilitate DNS operations inmodern networking topologies. A prototype of the DISCOVER opcodewas developed as part of the TBDS project, funded under DARPA grantF30602-99-1-0523. "KEY RR Key Signing (KS) Flag", Olaf Kolkman, 04-SEP-02, The Introduction of the DS [1] record has introduced the concept ofKEY signing and zone signing keys. In general, KEY signing keys arethe keys that are pointed to by DS records and are the secure entrypoints to a zone. The key signing keys only sign the KEY RRset atthe apex of a zone, zone signing keys sign all data in a zone. Wepropose a flag to distinguish the KEY signing key from other keys inthe KEY RR set during DNSSEC operations. "DNS Extensions to support IP version 6", C. Huitema, S. Thomson, 11-SEP-02, This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). Thechanges include a new resource record type to store an IPv6 address,a new domain to support lookups based on an IPv6 address, and updateddefinitions of existing query types that return Internet addresses aspart of additional section processing. The extensions are designedto be compatible with existing applications and, in particular, DNSimplementations themselves.This document updates RFC 1886 [5]. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152 [6]. Domain Name Server Operations (dnsop) ------------------------------------- "Requiring DNS IN-ADDR Mapping", D. Senie, 05-MAR-02, Mapping of addresses to names has been a feature of DNS. Many sites,implement it, many others don't. Some applications attempt to use itas a part of a security strategy. The goal of this document is toencourage proper deployment of address to name mappings, and provideguidance for their use. "IP Addresses that should never appear in the public DNS", Philip Hazel, 06-FEB-02, This document specifies an Internet Best Current Practice for theInternet Community. It has two themes. Firstly, it reinforces theprohibition in [RFC 1918] about the appearance of private IPaddresses in publicly visible DNS records, and extends thediscussion to include IPv6 addresses. "IPv4-to-IPv6 migration and DNS name space fragmentation", Johan Ihren, 05-MAR-02, This memo documents some problems forseen in transitioning from aIPv4-only DNS hierarchy via a long period of mixture to anIPv6-mostly situation sometime in the future. The mixture period isexpected to be very long, and hence design choices should very muchtake this into account, rather than just regard the transition as arelatively short period of pain. "Identifying an Authoritative Name Server", David R. Conrad, 03-MAY-02, A standardized mechanism to determine the identity of a name serverresponding to a particular query would be useful, particularly as adiagnostic aid. This document describes an identification conventionused in one widely deployed implementation of the DNS protocol andproposes a slight modification to that convention aimed at addressingsome implementation concerns. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "Requirements for Inter-operable Internet EDI", Rik Drummond, T Harding, C. Shih, 09-APR-01, This document is a functional specification, discussing the requirements for inter-operable EDI, with sufficient backgroundmaterial 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", Rik Drummond, T Harding, C. Shih, 05-APR-02, This document describes how to exchange structured business datasecurely using SMTP transport for Electronic Data Interchange,(EDI - either the American Standards Committee X12 or UN/EDIFACT,Electronic Data Interchange for Administration, Commerce andTransport), XML or other data used for business to business datainterchange. The data is packaged using standard MIMEcontent-types. Authentication and privacy are obtained by usingCryptographic Message Syntax (S/MIME) or OpenPGP security bodyparts. Authenticated acknowledgements make use ofmultipart/signed replies to the original SMTP message. "HTTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", Dick Brooks, Rik Drummond, Dale Moberg, David Fischer, 22-APR-02, This document describes how to exchange structured business datasecurely using HTTP transport for Electronic Data Interchange,(EDI - either the American Standards Committee X12 or UN/EDIFACT,Electronic Data Interchange for Administration, Commerce andTransport), XML or other data used for business to business datainterchange. The data is packaged using standard MIMEcontent-types. Authentication and privacy are obtained by usingCryptographic Message Syntax (S/MIME) or OpenPGP security bodyparts. Authenticated acknowledgements make use ofmultipart/signed replies to the HTTP POST requests.This document extends the procedures and payload packaging optionsof AS1 in the following ways: HTTPS may be used to obtain data,privacy both synchronous and asynchronous reply procedures are,described multipart/form-data packaging may be used, a generalizedmultipart/report format is added to the MDN format of AS1, repliesmay include a multipart/mixed payload that contains both theacknowledgement and an additional EDI payload.This document is intended to be read in conjunction with AS1 andthe referenced RFCs defining the MIME and cryptographicpackaging that are used to obtain secure, authenticated, andacknowledged transport. Entity MIB (entmib) ------------------- "Entity Sensor Management Information Base", Andy Bierman, 15-AUG-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for extending the Entity MIB[RFC2737] to provide generalized access to information related tophysical sensors, which are often found in networking equipment (such aschassis temperature, fan RPM, power supply voltage). "Entity MIB (Version 3)", Keith McCloghrie, Andy Bierman, 25-JUN-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects used for managing multiplelogical and physical entities managed by a single SNMP agent. Telephone Number Mapping (enum) ------------------------------- "Number Portability in the GSTN: An Overview", Michael Foster, Tom McGarry, James Yu, 27-JUN-02, This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. "The E.164 to URI DDDS Application", M. Mealling, Patrik Faltstrom, 05-JUL-02, This document discusses the use of the Domain Name System (DNS) forstorage of E.164 numbers. More specifically, how DNS can be used foridentifying available services connected to one E.164 number. Itspecifically obsoletes RFC 2916 to bring it in line with the DynamicDelegation Discovery System (DDDS) Application specification found inthe document series specified in RFC WWWW. It is very important tonote that it is impossible to read and understand this documentwithout reading the documents discussed in RFC WWWW. "Extensible Provisioning Protocol E.164 Number Mapping", S. Hollenbeck, 28-AUG-02, This document describes an Extensible Provisioning Protocol(EPP) extension mapping for the provisioning and management of E.164numbers representing domain names stored in a shared centralrepository. Specified in XML, this mapping extends the EPP domainname mapping to provide additional features required for theprovisioning of E.164 numbers. "ENUM Usage Scenarios", Steven Lind, 10-JUN-02, This document provides illustrations of the use of ENUM [2] functionality within the larger context of service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a 'direct dial' basis. Some details are also provided for calls made using the ITU-defined 'Global Services' [3,4,5]. The impact of number portability within the call scenarios is discussed. The objective of this document is to identify areas where gaps exist in the provision of services and suggest where protocol extensions for ENUM, SIP, TRIP, etc. are needed. The document does not propose that the examples represent the only or best approach for interworking between the PSTN and IP-based networks. Evolution of SNMP (eos) ----------------------- "SNMP Extended Protocol MIB", S. Chisholm, 29-AUG-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 SNMP protocol extensions supported byan SNMP entity. "SNMP Bulk Data Transfer Extensions", D. Battle, Bryan Levin, 07-MAR-02, This document describes a set of extensions (protocol operations andtextual conventions) to the existing SNMP framework architecture[RFC2571]. These extensions provide mechanisms for efficient bulkretrieval of virtual SNMP tables that are user-defined in terms ofsimilarly-instanced column entries from existing MIB tables. Internet Fax (fax) ------------------ "A Simple Mode of Facsimile Using Internet Mail", Jun Murai, Hiroyuki Ohno, K. Toyoda, Dan Wing, 27-NOV-01, This specification provides for 'simple mode' carriage of facsimiledata using Internet mail. Extensions to this document will follow.The current specification employs standard protocols and file formatssuch 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", G Parsons, James Rafferty, L. McIntyre, Dennis Venable, Robert Buckley, 27-NOV-01, 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 andinteroperability testing. "Implementers Guide for Facsimile Using Internet Mail", Dan Wing, Vivian Cancio, Mike Moldovan, Hiroshi Tamura, 14-JAN-02, This document is intended for the implementers of software which usesemail to send to facsimiles using RFC 2305 and 2532. This is aninformational document and its guidelines do not supersede thereferenced documents. "Timely Completion for Internet Messaging Services", G. Klyne, D. Crocker, 06-NOV-01, This specification provides a way to request timely completion forInternet mail delivery, for services such as facsimile and voicemessaging. Traditional Internet mail uses a _postal_ mail model,with normal delivery having an indeterminate gap between deliveryinto a mailbox and processing by the recipient. Timely completionadds a timelines service feature and extends delivery processingall the way to the recipient. This specification provides adeterministic service quality response, while preserving most ofthe traditional roles and responsibilities of the agents involvedin email transfers. "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", G Parsons, James Rafferty, 16-MAY-02, This document describes the registration of the MIME sub-type image/tiff. The baseline encoding of TIFF (Tag Image File Format) is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. "Internet FAX Gateway Functions", Katsuhiko Mimura, K Yokoyama, T Satoh, C Kanaide, 28-MAR-02, An Internet FAX Gateway provides functions which translate facsimilebetween the general switched telephone network (GSTN) the Internet.This document provides information on recommended behaviors for Internet FAX Gateways Functions for email-based Internet fax. In this context, an Offramp means facsimile data transmission to theGSTN from the Internet, and onramp means facsimile data transmission to Internet from the GSTN. This document covers the delivery-process of the data among equipment which may include Internet Fax terminals,PCs on the Internet and FAX terminal on GSTN. "Guideline of optional services for Internet FAX Gateway", Ken Watanabe, Katsuhiko Mimura, K Yokoyama, T Satoh, C Kanaide, 26-MAR-02, An Internet FAX Gateway provides functions which translate facsimilebetween the general switched telephone network (GSTN) the Internet.This document provides information on guideline of optional servicesand some examples for an Internet FAX Gateway classified as an onrampgateway and an offramp gateway.So this document does not intend to specify the actions that ifax offramp and onramp Gateways conform to. "SMTP Service Extension for Content Negotiation", K. Toyoda, D. Crocker, 02-AUG-02, This document defines a content negotiation serviceextension for SMTP [ESMTP1, ESMTP2] whereby an SMTPclient may request information about contentcapabilities of the target device or system that isserviced by an SMTP server. The SMTP server may reportthe target's content capabilities back to the client.This process emulates a classic facsimile start-of-session capabilities negotiation, although it can be used for a broad range of email-based scenarios. This serviceextension is primarily intended for 'direct', one-hop,originator/recipient SMTP transfers, although relayed scenarios through multiple SMTP servers are permitted. "Tag Image File Format Fax eXtended (TIFF-FX) -image/tiff-fx MIME Sub-type Registration", G Parsons, James Rafferty, L. McIntyre, 27-NOV-01, This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax [TIFF-FX] and its extensions. Forwarding and Control Element Separation (forces) -------------------------------------------------- "Netlink as an IP Services Protocol", Jamal Hadi Salim, 07-JUN-02, This document describes Linux Netlink, which is used in Linux bothas an intra-kernel messaging system as well as between kernel anduser space. This document is intended as informational in the con-text of prior art for the ForCES IETF working group. The focus ofthis document is to describe Netlink from a perspective of a protocolbetween a Forwarding Engine Component (FEC) and a Control PlaneComponent (CPC), the two components that define an IP service.The document ignores the ability of Netlink as a intra-kernel mes-saging system, as an inter-process communication scheme (IPC), oras a configuration tool for other non-networking or non-IP networkservices (such as decnet, etc.). "Requirements for Separation of IP Control and Forwarding", H. Khosravi, T. Anderson, 29-JUL-02, 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", Mark Handley, Alan Crouch, 20-JUN-02, The ForCES protocol defines a standard framework and mechanismfor the interconnection between Control Elements andForwarding Engines in IP routers and similar devices. In thisdocument we describe the applicability of the ForCES model andprotocol. We provide example deployment scenarios andfunctionality, as well as document applications that would beinappropriate for ForCES. "ForCES Architectural Framework", Lily Yang, 10-SEP-02, This document defines the architectural framework for ForCES network elements (NE), and identifies the associated entities and the interaction among them. This framework is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES-REQ]. Extensions to FTP (ftpext) -------------------------- "Extensions to FTP", Robert Elz, Paul Hethmon, 02-APR-02, This document specifies new FTP commands to obtain listings of remotedirectories in a defined format, and to permit restarts ofinterrupted data transfers in STREAM mode. It allows character setsother than US-ASCII, and also defines an optional virtual filestorage structure. "UTF-8 Option for FTP", Gregory Lundberg, 24-MAY-02, This document specifies an extension to the File Transfer Protocol(FTP) which provides for inter-operation between existingimplementations and those supporting the exchange of UTF-8 encodedpathnames, and clarifies certain issues involved with UTF-8 encoding.It introduces a new option, UTF-8, negotiated by use of the OPTScommand. Through use of this option, the user informs the server ofits willingness to accept UTF-8 encoded pathnames. The proposedextension requires that neither party transmit UTF-8 encodedpathnames without having first successfully negotiated this option. "FTP Data Connection Assurance", Gregory Lundberg, 24-MAY-02, This document specifies an extension to the File Transfer Protocol(FTP) by which a user and server can exchange data port connectioninformation which may then be used to provide connection assurance.Two new commands are introduced. Through use of these commands andtheir replies, the user and server exchange information allowingverification of the socket addresses for a data connection prior toactual data transmission over the connection.Implementation of this extension is RECOMMENDED. Geographic Location/Privacy (geopriv) ------------------------------------- "Geopriv requirements", Jorge Cuellar, John Morris, Deirdre Mulligan, 25-JUN-02, Location-based services, navigation applications, emergency services,management of equipment in the field, and other location-dependentservices need geographic location information about a target (user,resource or other entity). There is a need to securely gather andtransfer location information for location services, protecting theprivacy of the individuals involved.This document describes the requirements for the geopriv LocationObject (used to transfer location data and perhaps some otherinformation) and for further IETF protocols that use this LocationObject as an embedded protocol. We focus on authorization, integrityand privacy requirements. General Switch Management Protocol (gsmp) ----------------------------------------- "Requirements for the Dynamic Partitioning of Switching Elements", J. Buerkle, T. Anderson, 25-JUL-02, This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. "Requirements for adding optical Support to GSMPv3", Avri Doria, 05-JUL-02, This memo provides an overview of additional requirements on the GSMPprotocol. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Power Ethernet (DTE Power via MDI) MIB", D. Romascanu, Avi Berger, 02-JUL-02, 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 InterfacesMIB [RFC2665] with a set of objects for managing a power EthernetPowered Device (PD) and/or Power Source Equipment (PSE). "Definitions of Managed Objects for the Ethernet-like Interface Types", J. Flick, 13-MAY-02, This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community.This memo obsoletes RFC 2665 'Definitions of Managed Objects for theEthernet-like Interface Types'. This memo updates thatspecification by including management information useful for themanagement of 10 Gigabit per second (Gb/s) Ethernet interfaces.Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, newtypes of cabling and interfaces, and new features. This evolutionmay require changes in the managed objects in order to reflect thisnew functionality. This document, as with other documents issued bythis working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised,or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernettechnology.Distribution of this memo is unlimited. Please forward comments tohubmib@ietf.org. "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", J. Flick, 13-MAY-02, This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community.This memo obsoletes RFC 2668, 'Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs)'. This memo extends thatspecification by including management information useful for themanagement of 10 gigabit per second (Gb/s) MAUs. This memo alsoobsoletes RFC 1515, 'Definitions of Managed Objects for IEEE 802.3Medium Attachment Units (MAUs)'.Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, newtypes of cabling and interfaces, and new features. This evolutionmay require changes in the managed objects in order to reflect thisnew functionality. This document, as with other documents issued bythis working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised,or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernettechnology.Distribution of this memo is unlimited. Please forward comments tohubmib@ietf.org. "Definition of Managed Objects for the Ethernet WAN Interface Sublayer", Mike Ayers, 07-MAY-02, This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP basedinternets. In particular, it defines objects for managing theEthernet Wide Area Network (WAN) Interface Sublayer (WIS).The MIB module defined in this memo is an extension of the SONET/SDHInterface MIB and is implemented in conjunction with it and with theEthernet-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", J. Flick, C.M. Heard, 27-AUG-02, This memo recommends that RFC 1643 be reclassified as an Historicdocument and provides the supporting motivation for thatrecommendation. Internet Architecture Board (iab) --------------------------------- "Security Mechanisms for the Internet", J. Schiller, Steve Bellovin, 28-JUN-02, Security must be built into Internet Protocols for those protocols tooffer their services securely. Many security problems can be tracedto improper implementations. However, even a proper implementationwill have security problems if the fundamental protocol is itselfexploitable. Exactly how security should be implemented in aprotocol will vary, because of the structure of the protocol itself.However, there are many protocols for which standard Internetsecurity mechanisms, already developed, may be applicable. Theprecise one that is appropriate in any given situation can vary. Wereview a number of different choices, explaining the properties ofeach. "IETF ICANN Protocol Support Organization Appointments Procedures", Leslie Daigle, 08-JAN-02, This document specifies the process by which the IETF appoints its 2representatives to ICANN's Protocol Support Organization's ProtocolCouncil (PSO-PC). Additionally, the process for selecting candidatesfor the PSO's appointments to the ICANN Board of Directors isspecified. This process specification reflects 2 years of IETFexperience with ICANN, the PSO-PC and the PSO organization, sincetheir inception in 1999. "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", Leslie Daigle, 02-JUL-02, As a result of the nature of network address translation middleboxes(NATs), communicating endpoints that are separated by one or moreNATs do not know how to refer to themselves using addresses that arevalid in the addressing realms of their (current and future) peers.Various proposals have been made for 'UNilateral Self-Address Fixing(UNSAF)' processes. These are processes whereby some originatingendpoint attempts to determine or fix the address (and port) bywhich it is known to another endpoint -- e.g., to be able to useaddress data in the protocol exchange, or to advertise a publicaddress from which it will receive connections.This document outlines the reasons for which these proposals can beconsidered at best as short term fixes to specific problems, and thespecific issues to be carefully evaluated before creating an UNSAFproposal. "Recent Changes in the Architectural Principles of the Internet", B. Carpenter, Rob Austein, 18-FEB-02, In 1996, the IAB published RFC 1958, entitled 'ArchitecturalPrinciples of the Internet.' The Internet has grown and evolvedsince then, and this document records the impact of this evolution onthe principles laid down previously. This first draft is issued fordiscussion by the IETF community. "General Architectural and Policy Considerations", Sally Floyd, 03-SEP-02, This document suggests general architectural and policy questions tobe addressed in our work in the IETF. We note that this documentcontains questions to be addressed, as opposed to guidelines orarchitectural principles to be followed.Changes from draft-iab-considerations-01.txt:* Added a discussion on overloading.* Added a discussion on complexity, robustness, and fragility.* Added a section on Internationalization. "Guidelines for Writing RFC Text on Security Considerations", E. Rescorla, Brian Korver, 09-AUG-02, All RFCs are required by [RFC 2223] to contain a Security Considera-tions section. The purpose of this is both to encourage documentauthors to consider security in their designs and to inform thereader of relevant security issues. This memo is intended to provideguidance to RFC authors in service of both ends.This document is structured in three parts. The first is a combina-tion security tutorial and definition of common terms; the second isa series of guidelines for writing Security Considerations; the thirdis a series of examples. Inter-Domain Multicast Routing (idmr) ------------------------------------- "Distance Vector Multicast Routing Protocol", T. Pusateri, 17-MAY-01, DVMRP is an Internet routing protocol that provides an efficientmechanism for connection-less datagram delivery to a group of hostsacross an internetwork. It is a distributed protocol that dynamicallygenerates IP Multicast delivery trees using a technique calledReverse Path Multicasting (RPM) [Deer90]. This document is an updateto Version 1 of the protocol specified in RFC 1075 [Wait88]. "Internet Group Management Protocol, Version 3", S. Deering, Bill Fenner, Brad Cain, A. Thyagarajan, I Kouvelas, 23-MAY-02, This document specifies Version 3 of the Internet Group ManagementProtocol, IGMPv3. IGMP is the protocol used by IPv4 systems to reporttheir IP multicast group memberships to neighboring multicast routers.Version 3 of IGMP adds support for 'source filtering', that is, theability for a system to report interest in receiving packets *only* fromspecific source addresses, or from *all but* specific source addresses,sent to a particular multicast address. That information may be used bymulticast routing protocols to avoid delivering multicast packets fromspecific sources to networks where there are no interested receivers.This document obsoletes RFC 2236. "IGMP Multicast Router Discovery", Brad Cain, Shantam Biswas, Brian Haberman, 01-FEB-02, The concept of IGMP snooping requires the ability to identify the location of multicast routers. Since IGMP 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. "Distance Vector Multicast Routing Protocol Applicability Statement", T. Pusateri, 17-MAY-01, This document provides a framework for the use of Distance VectorMulticast Routing Protocol (DVMRP) Version 3 within a multicastrouting domain. It is an interior gateway protocol designed to beused within an autonomous system. "Socket Interface Extensions for Multicast Source Filters", D. Thaler, 03-JUL-02, IGMPv3 for IPv4 adds the capability for applications to expresssource filters on multicast group memberships, which allowsreceiver applications to determine the set of senders (sources)from which to accept multicast traffic. This capability alsosimplifies support of one-to-many type multicast applications. Itis expected that in the future, the same capability will beavailable in IPv6 as well.This document specifies new socket options and ioctl commands tomanage source filters for IP Multicast group memberships. It alsodefines the socket structures to provide input and outputarguments to these new APIs. These extensions are designed toprovide access to the source filtering features, while introducinga minimum of change into the system and providing completecompatibility for existing multicast applications. Internationalized Domain Name (idn) ----------------------------------- "Nameprep: A Stringprep Profile for Internationalized Domain Names", Paul Hoffman, Marc Blanchet, 27-JUN-02, This document describes how to prepare internationalized domain namelabels in order to increase the likelihood that name input and namecomparison work in ways that make sense for typical users throughout theworld. This profile of the stringprep protocol is used as part of asuite of on-the-wire protocols for internationalizing the DNS. "Internationalizing Domain Names In Applications (IDNA)", Paul Hoffman, Patrik Faltstrom, Adam Costello, 03-SEP-02, Until now, there has been no standard method for domain names to usecharacters outside the ASCII repertoire. This document definesinternationalized domain names (IDNs) and a mechanism called IDNA forhandling them in a standard fashion. IDNs use characters drawn from alarge repertoire (Unicode), but IDNA allows the non-ASCII characters tobe represented using only the ASCII characters already allowed inso-called host names today. This backward-compatible representation isrequired in existing protocols like DNS, so that IDNs can be introducedwith no changes to the existing infrastructure. IDNA is only meant forprocessing domain names, not free text. "Transitional Reflexive ASE - IDN Transition (IDNX)", Edmon Chung, David Leung, 05-JUL-02, This document, while sharing a similar concept, is an overhaul of TRACE-00 and describes a strategy for domain name server operators to prepare and transition their services for multilingual domain names (IDN – Internationalized Domain Names). The TRACE-01 or IDNX (IDN Transition) approach accepts that users with non-IDN aware applications will be attempting to access multilingual domain names. Hence it is the registry or domain operator's responsibility to provide an IDN solution that resolves these issues to make it a seamless transition experience for technically unsophisticated users. In essence, the IDNX approach embraces a complementary server-side implementation to smooth the transition. IDNX ready domain servers should be backward compatible, and successfully resolve IDN requests sent via non-IDN aware applications, whether they are formatted in local encoding, UTF-8 or an identifiable variant; as well as forward compatible, and be able to resolve ACE requests. "Internationalized Domain Names in URIs", M. Duerst, 05-JUL-02, This document proposes to upgrade the definition of URIs (RFC 2396)[RFC2396] to work consistently with internationalized domain names. "Punycode:An encoding of Unicode for use with IDNA", Adam Costello, 23-MAY-02, Punycode is a simple and efficient transfer encoding syntax designedfor use with Internationalized Domain Names in Applications [IDNA].It uniquely and reversibly transforms a Unicode string [UNICODE]into an ASCII string [ASCII]. ASCII characters in the Unicodestring are represented literally, and non-ASCII characters arerepresented by ASCII characters that are allowed in host name labels(letters, digits, and hyphens). This document defines a generalalgorithm called Bootstring that allows a string of basic codepoints to uniquely represent any string of code points drawn froma larger set. Punycode is an instance of Bootstring that usesparticular parameter values specified by this document, appropriatefor IDNA. Inter-Domain Routing (idr) -------------------------- "A Border Gateway Protocol 4 (BGP-4)", Tony Li, Y. Rekhter, 08-JAN-02, The Border Gateway Protocol (BGP) is an inter-Autonomous Systemrouting protocol. It is built on experience gained with EGP asdefined in RFC 904 [1] and EGP usage in the NSFNET Backbone asdescribed in RFC 1092 [2] and RFC 1093 [3]. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", J. Burruss, Susan Hares, J Johnson, S. Willis, J. Chu, 01-MAR-02, This memo is an extension to the SNMP MIB. The origin of this memois from RFC 1269 'Definitions of Managed Objects for the BorderGateway Protocol (Version 3)', which was updated to support BGP-4 inRFC 1657. This memo fixes errors introduced when the MIB wasconverted to use the SNMPv2 SMI, as well as updates references to thecurrent SNMP framework documents. "Cooperative Route Filtering Capability for BGP-4", Y. Rekhter, Enke Chen, 02-MAY-02, This document defines a BGP-based mechanism that allows a BGP speakerto send to its BGP peer a set of route filters that the peer woulduse to constrain/filter its outbound routing updates to the speaker. "Graceful Restart Mechanism for BGP", John Scudder, Y. Rekhter, S Sangli, Enke Chen, Rex Fernando, 29-MAY-02, This document proposes a mechanism for BGP that would help minimizethe negative effects on routing caused by BGP restart. An End-of-RIBmarker is specified and can be used to convey routing convergenceinformation. A new BGP capability, termed 'Graceful RestartCapability', is defined which would allow a BGP speaker to expressits ability to preserve forwarding state during BGP restart. Finally,procedures are outlined for temporarily retaining routing informationacross a TCP transport reset.The mechanisms described in this document are applicable to allrouters, both those with the ability to preserve forwarding stateduring BGP restart and those without (although the latter need toimplement only a subset of the mechanisms described in thisdocument). "BGP support for four-octet AS number space", Quaizar Vohra, Enke Chen, 02-MAY-02, Currently the Autonomous System number is encoded in BGP [BGP] as atwo-octets field. This document describes extensions to BGP to carrythe Autonomous System number as a four-octets field. "BGP Extended Communities Attribute", Y. Rekhter, Dan Tappan, Srihari Sangli, 10-MAY-02, This document describes an extension to BGP [BGP-4] which may be usedto provide flexible control over the distribution of routinginformation. "Aspath Based Outbound Route Filter for BGP-4", Susan Hares, K. Patel, 30-APR-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", Susan Hares, W. Tackabury, Jeffrey Haas, 06-MAR-02, This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in TCP/IP-based internets. "Dynamic Capability for BGP-4", E. Chen, Srihari Sangli, 05-APR-02, This document defines a new BGP capability termed 'DynamicCapability', which would allow the dynamic update of capabilitiesover an established BGP session. This capability would facilitatenon-disruptive capability changes by BGP speakers. "Subcodes for BGP Cease Notification Message", E. Chen, V Gillet, 07-MAY-02, This document defines several subcodes for the BGP Cease NOTIFICATIONmessage that would provide more information to aid network operatorsin co-relating network events and diagnosing BGP peering issues. "Protection of BGP Sessions via the TCP MD5 Signature Option", A. Heffernan, 05-MAR-02, This memo describes a TCP extension to enhance security for BGP. Itdefines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment,incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the waydescribed in this paper significantly reduces the danger from certainsecurity attacks on BGP "Multiprotocol Extensions for BGP-4", D. Katz, Y. Rekhter, T. Bates, R. Chandra, 26-APR-02, Currently BGP-4 is capable of carrying routing information only forIPv4. This document defines extensions to BGP-4 to enable it to carryrouting information for multiple Network Layer protocols (e.g., IPv6,IPX, etc...). The extensions are backward compatible - a router thatsupports the extensions can interoperate with a router that doesn'tsupport the extensions. "Capabilities Advertisement with BGP-4", John Scudder, R. Chandra, 25-APR-02, Currently BGP-4 requires that when a BGP speaker receives an OPENmessage with one or more unrecognized Optional Parameters, thespeaker must terminate BGP peering. This complicates introduction ofnew capabilities in BGP.This document defines new Optional Parameter, called Capabilities,that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiringthat BGP peering be terminated.This document obsoletes RFC2842. "AS-wide Unique BGP Identifier for BGP-4", E. Chen, J. Yuan, 13-SEP-02, To accommodate situations where the current requirements for the BGPIdentifier are not met, this document relaxes the definition of theBGP Identifier to be a 4-octet unsigned, non-zero integer, andrelaxes the 'uniqueness' requirement so that only AS-wide uniquenessof the BGP Identifiers is required. These revisions to the base BGPspecification 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 Internetinfrastructure. The security of this option relies heavily on thequality of the keying material used to compute the MD5 signature.This document addresses the security requirements of that keyingmaterial. Intrusion Detection Exchange Format (idwg) ------------------------------------------ "Intrusion Detection Mesage Exchange Requirements", Mark Wood, Michael Erlinger, 27-AUG-02, The purpose of the Intrusion Detection Exchange Format Working Group(IDWG) is to define data formats and exchange procedures for sharinginformation 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 acommunication mechanism, including the rationale for thoserequirements where clarification is needed. Scenarios are used toillustrate some requirements. "Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition", David Curry, Hervé Debar, 21-JUN-02, The purpose of the Intrusion Detection Message Exchange Format(IDMEF) is to define data formats and exchange procedures for sharinginformation 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 informationexported by intrusion detection systems, and explains the rationalefor using this model. An implementation of the data model in theExtensible Markup Language (XML) is presented, an XML Document TypeDefinition is developed, and examples are provided. "The TUNNEL Profile", Darren New, 24-AUG-01, This memo describes a BEEP profile that allows a BEEP peer to serveas an application-layer proxy. It allows authorized users to accessservices through a firewall. "The Intrusion Detection Exchange Protocol (IDXP)", John White, Benjamin Feinstein, Gregory Matthews, 18-JUN-02, This memo describes the Intrusion Detection Exchange Protocol (IDXP),an application-level protocol for exchanging data between intrusiondetection entities. IDXP supports mutual-authentication, integrity,and confidentiality over a connection-oriented protocol. Theprotocol provides for the exchange of IDMEF messages, unstructuredtext, and binary data. The IDMEF message elements are described inthe Intrusion Detection Message Exchange Format (IDMEF) [2], acompanion document of the Intrusion Detection Exchange Format (IDWG)working group of the IETF. Internet Emergency Preparedness (ieprep) ---------------------------------------- "IEPS Requirement Statement", F. Baker, 25-FEB-02, The requirements for an Internet Emergency Preference Schemecomparable to the US Government Emergency Telecommunications Serviceare explored. "Emergency Telecommunications Service in Evolving Networks", Hal Folts, 25-FEB-02, This white paper presents the functional requirements, features, and objectives for the Emergency Telecommunications Service (ETS) in newly emerging telecommunication networks. The ETS is an extension of the International Emergency Preference Scheme (IEPS) of the ITU-T Recommendation E.106 [1] and includes additional provisions for multimedia services through an packet-based telecommunications environment. "Framework for Supporting IEPS in IP Telephony", K Carlberg, Ian Brown, 26-JUN-02, This document presents a framework for supporting authorizedemergency related communication within the context of IP telephony.We present a series of objectives that reflect a general view of howauthorized emergency service, in line with the InternationalEmergency Preparedness Scheme (IEPS), should be realized withintoday's IP architecture and service models. From these objectives,we present a corresponding set of functional requirements, whichprovide a more specific set of recommendations regarding existingIETF protocols. Finally, we present two scenarios that act asguiding models for the objectives and functions listed in thisdocument. These, models, coupled with an example of an existingservice in the PSTN, contribute to a constrained solution space. "A Security Framework for Emergency Communications", Ian Brown, 28-JUN-02, The Public Switched Telephone Network includes several mechanismsthat increase the probability of completion for telephone calls madeby authorised disaster relief personnel during emergencies such ashurricanes or terrorist attacks. This memo describes the securityrequirements of providing this functionality in private and public IPnetworks, and how these requirements can be met using existingprotocols. It also specifies which enhancements are necessary tothese protocols to allow enhanced functionality such as roamingaccess. "Requirements for Emergency Telecommunication Capabilities in the Internet", Hal Folts, Cory Beard, 19-JUN-02, This document outlines requirements that need to be met in IP-based networks to enable and support communications for National Security/Emergency Preparedness (NS/EP) operations. It provides a basis from which an emergency telecommunications service can be negotiated and provides a set of requirements that should be met for acceptable emergency telecommunication capabilities for disaster recovery operations. The focus here is on network requirements, rather than requirements for particular applications. The requirements are general, functional, and are intended to provide wide latitude in implementation options for service providers. "Recommended Packet Marking Policy", F. Baker, 24-JUL-02, This paper summarizes a recommended correlation of applications toDifferentiated Service Code Points. There is no intrinsicrequirement that individual DSCPs correspond to given applications,but as a policy it is useful if they can be applied consistently. "Diffserv Reflexive DSCP", F. Baker, Rei Atarashi, 25-JUN-02, In reviewing the specific use of the Differentiated ServicesArchitecture for supporting the Internet Emergency PreparednessSystem, we found what we believe is a general issue. This is thateven though a client or peer can connect to a server or peer with apredictable DSCP value, the response does not have a predictable DSCPvalue. We consider the issues, and recommend an approach toapplication policy regarding the DSCP. "Terms of Reference for an Emergency Telecommunications Service", Ian Brown, 31-JUL-02, An Emergency Telecommunications Service gives authorised emergencypersonnel a higher probability of successful communication underhigh network load conditions. This document explains the differentterms and acronyms used in defining and implementing this service,and is intended to be used as a common basis for negotiations whenemergency service providers are contracting with telecommunicationsoperators to provide the service. It can also be used in procurementof and tendering for ETS provision. "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol", H. Schulzrinne, 15-AUG-02, This document summarizes requirements for prioritizing access tocircuit-switched network, end system and proxy resources foremergency preparedness communications using the Session InitiationProtocol (SIP). Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION", M. Crispin, Ken Murchison, 24-JUN-02, This document describes an experimental server-based sortingextension to the IMAP4rev1 protocol, as implemented by the Universityof Washington's IMAP toolkit. This extension provides substantialperformance improvements for IMAP clients which offer sorted views.A server which supports this extension indicates this with acapability name of 'SORT'. Client implementations SHOULD accept anycapability name which begins with 'SORT' as indicating support forthe extension described in this document. This provides for futureupwards-compatible extensions.At the time of this document was written, the IMAP Extensions WorkingGroup (IETF-IMAPEXT) was considering upwards-compatible additions tothe SORT extension described in this document, tenatively called theSORT2 extension. "IMAP4 ACL extension", A Melnikov, 02-JUL-02, The ACL extension of the Internet Message Access Protocol [IMAP4]permits access control lists to be manipulated through the IMAPprotocol. "IMAP ANNOTATE Extension", Randall Gellens, Cyrus Daboo, 06-MAR-02, The ANNOTATE extension to the Internet Message Access Protocol[IMAP4] permits clients and servers to maintain 'metadata' formessages stored in an IMAP4 mailbox. "INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION", M. Crispin, Ken Murchison, 24-JUN-02, This document describes the server-based threading extension to theIMAP4rev1 protocol. This extension provides substantial performanceimprovements for IMAP clients which offer threaded views.A server which supports this extension indicates this with more ormore capability names consisting of 'THREAD-' followed by a supportedthreading algorithm name as described in this document. Thisprovides for future upwards-compatible extensions. Instant Messaging and Presence Protocol (impp) ---------------------------------------------- "Common Presence and Instant Messaging (CPIM)", D. Crocker, 14-AUG-02, Semantics and data formats for common services of Instant Messagingand online Presence, independent of underlying transferinfrastructure, are described. The CPIM profile meets therequirements specified in RFC 2779 using a minimalist approachallowing interoperation of a wide range of IM and Presence systems "Common Presence and Instant Messaging Message Format", Derek Atkins, Graham Klyne, 20-FEB-02, This memo defines the mime type 'message/cpim', a message format forprotocols that conform to the Common Profile for Instant Messaging(CPIM) specification. "Common Presence and Instant Messaging (CPIM)Presence Information Data Format", S Fujimoto, H Sugano, 24-MAY-02, This memo specifies the Common Presence and Instant Messaging (CPIM)Presence Information Data Format (PIDF) as a common presence dataformat for CPIM-compliant Instant Messaging and Presence protocols,and also defines a new media type 'application/cpim-pidf+xml' torepresent the XML MIME entity for PIDF. IP over Cable Data Network (ipcdn) ---------------------------------- "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 DOCSIS Cable Modem Termination Systems for Subscriber Management", W. Sawyer, 07-MAR-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, it defines a set of managedobjects for SNMP-based management of DOCSIS-compliant[16] Cable ModemTermination Systems. These managed objects facilitate protection ofthe cable network from misuse by subscribers.This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should beaddressed to the working group's mailing list at ipcdn@terayon.comand/or the authors. "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", M StJohns, 08-JUL-02, This memo is a draft revision of the standards track RFC-2669.Please see 'Revision Descriptions' below for a description ofchanges. This document or its successor will obsolete RFC-2669 whenaccepted. "Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces", Richard Woundy, David Raftus, 18-JUN-02, 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 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. IP Flow Information Export (ipfix) ---------------------------------- "Requirements for IP Flow Information Export", Juergen Quittek, 01-AUG-02, This memo defines requirements for the export of measured IP flowinformation out of routers, traffic measurement probes andmiddleboxes. "Architecture Model for IP Flow Information Export", Ganesh Sadasivan, K Norseth, 24-JUN-02, This memo defines the architecture, for the export of measured IPflow information out of an IPFIX device to a collector, per therequirements defined in [2]. "IPFIX Data Model Data Model for IP Flow Information Export", P. Calato, K Norseth, 26-FEB-02, This document defines an information and daqta model forscalable monitoring, measuring and exporting IP flow informationto collectors. IP over Optical (ipo) --------------------- "Impairments And Other Constraints On Optical Layer Routing", Angela Chiu, 06-MAR-02, 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. "IP over Optical Networks: A Framework", B. Rajagopalan, 10-JUN-02, The Internet transport infrastructure is moving towards a model ofhigh-speed routers interconnected by optical core networks. Thearchitectural choices for the interaction between IP and opticalnetwork layers, specifically, the routing and signaling aspects, arematuring. At the same time, a consensus has emerged in the industryon utilizing IP-based protocols for the optical control plane. Thisdocument defines a framework for IP over Optical networks,considering both the IP-based control plane for optical networks aswell as IP-optical network interactions (together referred to as 'IPover optical networks'). "Carrier Optical Services Requirements", Yong Xue, 01-JUL-02, This Internet Draft describes the major carrier's service requirements for the automatic 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 and will be addressed in a separate document. "Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols", Osama Aboul-Magd, 04-MAR-02, This draft describes the main architectural principles of the automatic switched optical networks (ASON) work that has recently been approved by the ITU-T [2,3]. ASON architecture defines a set of reference points (interfaces) that allows ASON clients to request network services across those reference points. "Optical Inter Domain Routing Considerations", Greg Bernstein, 28-FEB-02, 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, 28-JUN-02, InfiniBand Architecture (IBA) specifies a high speed, channelbased, switched fabric architecture to deliver scalableperformance 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)", Bill Swortwood, Sean Harnedy, 15-MAY-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 Subnet Management Agents (SMA). "Definition of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management", Sean Harnedy, 15-MAY-02, This memo describes Textual Conventions and OBJECT-IDENTITIESused for managing IPOVERIB networks. "IP over InfiniBand(IPoIB) Architecture", Vivek Kashyap, 04-FEB-02, InfiniBand is a high speed, channel based interconnect betweensystems and devices. "IP link and multicast over InfiniBand networks", J. Chu, Vivek Kashyap, 20-JUN-02, This document specifies a method for setting up IP subnets andmulticast services over InfiniBand(TM) networks. Discussions in thisdocument are applicable to both IPv4 and IPv6, unless explicitlyspecified. A separate document will cover unicast and encapsulationof IP datagrams over InfiniBand networks. "IP encapsulation and address resolution over InfiniBand networks", J. Chu, Vivek Kashyap, 28-MAY-02, This document specifies the frame format for transmission ofIP and ARP packets over InfiniBand networks. Unless explicitlyspecified, the term 'IP' refers to both IPv4 and IPv6. Theterm 'ARP' refers to all the ARP protocols/op-codes such asARP/RARP. This document also describes the method of formingIPv6 link-local addresses, and the content of thesource/target link layer address option used in Neighboursolicitation and advertisement, router advertisement, routerredirect and router solicitation on IPv6 over InfiniBand. "DHCP over InfiniBand", Vivek Kashyap, 27-AUG-02, An InfiniBand network uses a link-layer addressing scheme thatis 20-bytes long. This is larger than the 16-bytes reserved forthe hardware address in DHCP/BOOTP message. The aboveinequality imposes restrictions on the use of the DHCP messagefields when used over an IP over InfiniBand(IPoIB) network.This document describes the use of DHCP message fields whenimplementing DHCP over IPoIB. "Definitions of Managed Objects for Infiniband Channel Adapters (CA)", Sean Harnedy, 28-JUN-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 Channel Adapters (CA). Internet Printing Protocol (ipp) -------------------------------- "Internet Printing Protocol: Requirements for IPP Notifications", T. Hastings, R. Bergman, R deBry, 23-JUL-01, This document is one of a set of documents which together describeall aspects of a new Internet Printing Protocol (IPP). IPP is anapplication level protocol that can be used for distributed printingon the Internet. There are multiple parts to IPP, but the primaryarchitectural components are the Model, the Protocol and an interfaceto Directory Services. This document provides a statement of therequirements for notifications as part of an IPP Service. "Internet Printing Protocol (IPP): IPP Event Notifications and Subscriptions", T. Hastings, R. Herriot, 03-JUL-02, This document describes an OPTIONAL extension to the InternetPrinting Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).This extension allows a client to subscribe to printing relatedEvents. Subscriptions are modeled as Subscription Objects. TheSubscription Object specifies that when one of the specified Eventsoccurs, the Printer sends an asynchronous Event Notification to thespecified Notification Recipient via the specified Push or PullDelivery Method (i.e., protocol).A client associates Subscription Objects with a particular Job byperforming the Create-Job-Subscriptions operation or by submitting aJob with subscription information. A client associates SubscriptionObjects with the Printer by performing a Create-Printer-Subscriptionsoperation. Four other operations are defined for SubscriptionObjects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. "Internet Printing Protocol(IPP): Job and Printer Administrative Operations", T. Hastings, R. Bergman, T. Hastings, 23-JUL-01, This document specifies the following 16 additional OPTIONALoperations for use with the Internet Printing Protocol/1.0 (IPP)[RFC2565, RFC2566] and IPP/1.1 [RFC2910, RFC2911] "Internet Printing Protocol (IPP): The 'collection' attribute syntax", T. Hastings, R. Herriot, R deBry, Kirk Ocke, Peter Zehler, 23-JUL-01, This document specifies an OPTIONAL attribute syntax called'collection' for use with the Internet Printing Protocol/1.0(IPP) [RFC2565, RFC2566], IPP/1.1 [RFC2911, RFC2910]. A'collection' is a container holding one or more named values,which are called 'member' attributes. "Internet Printing Protocol (IPP): Job and Printer Set Operations", T. Hastings, R. Herriot, R. Bergman, T. Hastings, 06-SEP-01, This document specifies 3 additional OPTIONAL operations for use withthe Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], andIPP/1.1 [RFC2911, RFC2910]. The end user, operator, andadministrator Set-Job-Attributes and Set-Printer-Attributesoperations are used to modify IPP Job objects and Printer objects,respectively. The third administrator Get-Printer-Supported-Valuesoperation returns values that the IPP Printer will accept for settingits 'xxx-supported' attributes. "Internet Printing Protocol (IPP): The 'mailto:' Delivery Method for Event Notifications", T. Hastings, R. Herriot, Carl-Uno Manros, Henrik Holst, 23-JUL-01, This document describes an extension to the Internet PrintingProtocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910].This document specifies the 'mailto' Delivery Method for use with the'IPP Event Notifications and Subscriptions' specification [ipp-ntfy].When IPP Notification [ipp-ntfy] is supported, the Delivery Methoddefined in this document is one of the RECOMMENDED Delivery Methodsfor Printers to support. "Internet Printing Protocol (IPP):The 'indp' Delivery Method for Event Notifications and Protocol/1.0", T. Hastings, Hugo Parra, 23-JUL-01, This document describes an extension to the Internet PrintingProtocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910].This document specifies the 'indp' Delivery Method and Protocol/1.0for use with the 'IPP Event Notifications and Subscriptions'specification [ipp-ntfy]. When IPP Notification [ipp-ntfy] issupported, the Delivery Method defined in this document is one of theRECOMMENDED Delivery Methods for Printers to support. "Internet Printing Protocol (IPP): Job Progress Attributes", T. Hastings, R. Bergman, H. Koki, 23-JUL-01, This document defines four new Job Description attributes formonitoring job progress to be registered as OPTIONAL extensions toIPP/1.0 [RFC2566] and IPP/1.1 [RFC2911]. "Internet Printing Protocol (IPP): Printer Installation Extension", T. Hastings, Hugo Parra, Ted Tronson, 23-JUL-01, This document describes an OPTIONAL extension to the InternetPrinting Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911,RFC2910]. Various client platforms require that some setting up takeplace at the workstation before the client can properly submit jobsto a specific printer. "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", R. Herriot, T. Hastings, 03-JUL-02, This document describes an extension to the Internet PrintingProtocol/1.1: Model and Semantics (RFC 2911, RFC 2910). Thisdocument specifies the 'ippget' Delivery Method for use with the'Internet Printing Protocol (IPP): Event Notifications andSubscriptions' specification. When IPP Notification [ipp-ntfy] issupported, the Delivery Method defined in this document is theREQUIRED Delivery Method for clients and Printers to support. TheyMAY support additional Delivery Methods.The 'ippget' Delivery Method is a Pull Delivery Method. When anEvent occurs, the Printer saves the Event Notification for a periodof time called the Event Life. The Notification Recipient fetches(pulls) Event Notifications using the Get-Notifications operation.If the Notification Recipient has selected the Event Wait Mode optionto wait for additional Event Notifications, the Printer continues toreturn Event Notifications to the Notification Recipient as Get-Notification responses as Events occur using the connectionoriginated by the Notification Recipient.Either the Notification Recipient or the Printer can terminate EventWait Mode without closing the connection. "Internet Printing Protocol/1.1: IPP URL Scheme", R. Herriot, I. McDonald, 21-MAY-02, This memo defines the 'ipp' URL (Uniform Resource Locator) scheme.This memo updates IPP/1.1: Encoding and Transport (RFC 2910), byexpanding and clarifying Section 5 'IPP URL Scheme' of RFC 2910. An'ipp' URL is used to specify the network location of a print servicethat supports the IPP Protocol (RFC 2910), or of a network resource(for example, a print job) managed by such a print service. IP Performance Metrics (ippm) ----------------------------- "IP Packet Delay Variation Metric for IPPM", Philip Chimento, Carlo Demichelis, 27-AUG-02, This memo refers to a metric for variation in delay of packets acrossInternet paths. The metric is based on the difference in the One-Way-Delay of selected packets. This difference in delay is called 'IPPacket Delay variation.'The metric is valid for measurements between two hosts both in thecase that they have synchronized clocks and in the case that they arenot synchronized. We discuss both in this draft. "Network performance measurement for periodic streams", A Morton, G. Grotefeld, V Raisanen, 29-AUG-02, This memo describes a periodic sampling method and relevant metricsfor assessing the performance of IP networks. First, the memomotivates periodic sampling and addresses the question of its valueas an alternative to Poisson sampling described in RFC 2330. Thebenefits include applicability to active and passive measurements,simulation of constant bit rate (CBR) traffic (typical of multimediacommunication, or nearly CBR, as found with voice activitydetection), and several instances where analysis can be simplified.The sampling method avoids predictability by mandating random starttimes and finite length tests. Following descriptions of thesampling method and sample metric parameters, measurement methodsand errors are discussed. Finally, we give additional information onperiodic measurements including security considerations. "A One-way Active Measurement Protocol", Benjamin Teitelbaum, Matthew Zekauskas, Stanislav Shalunov, 30-AUG-02, The IETF IP Performance Metrics (IPPM) working group has proposeddraft standard metrics for one-way packet delay [RFC2679] and loss[RFC 2680] across Internet paths. Although there are now severalmeasurement platforms that implement collection of these metrics[SURVEYOR], [RIPE], there is not currently a standard that wouldpermit initiation of test streams or exchange of packets to collectsingleton metrics in an interoperable manner.With the increasingly wide availability of affordable globalpositioning system (GPS) and CDMA based time sources, hostsincreasingly have available to them very accurate timesources--either directly or through their proximity to NTP primary(stratum 1) time servers. By standardizing a technique forcollecting IPPM one-way active measurements, we hope to create anenvironment where IPPM metrics may be collected across a far broadermesh of Internet paths than is currently possible. One particularlycompelling vision is of widespread deployment of open OWAMP serversthat would make measurement of one-way delay as commonplace asmeasurement of round-trip time using an ICMP-based tool like ping.Additional design goals of OWAMP include being hard to detect andmanipulate, security, logical separation of control and testfunctionality, and support for small test packets.OWAMP test traffic is hard to detect, because it is simply a streamof UDP packets from and to negotiated port numbers with potentiallynothing static in the packets (size is negotiated, too).Additionally, OWAMP supports an encrypted mode, that further obscuresthe traffic, at the same time making it impossible to altertimestamps undetectably.Security features include optional authentication and/or encryptionof control and test messages. These features may be useful toprevent unauthorized access to results or man-in-the-middle attackerswho attempt to provide special treatment to OWAMP test streams or whoattempt to modify sender "A One-way Active Measurement Protocol Requirements", Benjamin Teitelbaum, Stanislav Shalunov, 30-AUG-02, With growing availability of good time sources to network nodes, itbecomes increasingly possible to measure one-way IP performancemetrics with high precision. To do so in an interoperable manner, acommon protocol for such measurements is required. This documentspecifies requirements for a one-way active measurement protocol(OWAMP) standard. The protocol can measure one-way delay, as well asother unidirectional characteristics, such as one-way loss. "IPPM metrics registry", Emile Stephan, 27-JUN-02, This memo defines a registry of the IPPM working group metrics. It provides 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, 21-JUN-02, 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. "Reordering Metric for IPPM", Alfred Morton, 21-JUN-02, This memo defines a simple metric to determine if a network hasmaintained packet order. It provides motivations for the new metric,suggests a metric definition, and discusses the issues associatedwith measurement. The memo includes sample metrics to quantify theextent of reordering in several useful dimensions. Some examples ofevaluation using the various sample metrics are included. "One-Way Metric Applicability Statement", Merike Kaeo, Henk Uijterwaal, 28-JUN-02, Active traffic measurements are starting to become more widely used toascertain network performance characteristics. All active measurementsystems have the capability to measure one-way delay and one-way lossmetrics, as defined in RFC2679 [1] A One- way Delay Metric for IPPM andRFC 2680 [2] A One-way Packet Loss Metric for IPPM, respectively. Toensure that the resulting numbers have some meaning, we attempt tocharacterize how the measurements are taken and what would ensure thatthe end numbers are indeed meaningful. This document describes anapplicability statement (formerly known as best current practices) formeasuring the one-way delay and one-way loss metrics in operationalnetworks. IP Storage (ips) ---------------- "Fibre Channel Over TCP/IP (FCIP)", E Rodriguez, M. Rajagopal, R Weber, 28-AUG-02, Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow theinterconnection of islands of Fibre Channel storage area networksover IP-based networks to form a unified storage area network in asingle Fibre Channel fabric. FCIP relies on IP-based networkservices to provide the connectivity between the storage areanetwork islands over local area networks, metropolitan areanetworks, or wide area networks. "iSCSI", Julian Satran, 06-SEP-02, The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. "Bootstrapping Clients using the iSCSI Protocol", P. Sarkar, C. Sapuntzakis, D. Missimer, 28-JUN-02, The Small Computer Systems Interface (SCSI) is a popular family ofprotocols for communicating with I/O devices, especially storagedevices. iSCSI is a proposed transport protocol for SCSI thatoperates on top of TCP[12]. This memo describes a standard mechanismto enable clients to bootstrap themselves using the iSCSI protocol.The goal of this standard is to enable iSCSI boot clients to obtainthe information to open an iSCSI session with the iSCSI boot server,assuming this information is not available. "Internet Storage Name Service (iSNS)", Josh Tseng, Kevin Gibbons, 12-AUG-02, This document specifies the iSNS protocol, which is used forinteraction between iSNS servers and iSNS clients in order tofacilitate automated discovery, management, and configuration ofiSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNSprovides intelligent storage discovery and management servicescomparable to those found in Fibre Channel networks, allowing acommodity IP network to function in a similar capacity as a storagearea network. iSNS also facilitates a seamless integration of IPand Fibre Channel networks, due to its ability to emulate FibreChannel fabric services, and manage both iSCSI and Fibre Channeldevices. iSNS thereby provides value in any storage networkcomprised of iSCSI devices, Fibre Channel devices, or anycombination thereof. "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Charles Monia, 02-AUG-02, This document specifies an architecture and gateway-to-gatewayprotocol for the implementation of fibre channel fabricfunctionality over an IP network. This functionality is providedthrough TCP protocols for fibre channel frame transport and thedistributed fabric services specified by the fibre channelstandards. The architecture enables internetworking of fibrechannel devices through gateway-accessed regions having the faultisolation properties of autonomous systems and the scalability ofthe IP network. "iSCSI Naming and Discovery", M Bakke, 28-JUN-02, This document provides examples of iSCSI [7] name construction anddiscussion of discovery of iSCSI resources (targets) by iSCSIinitiators. This document complements the iSCSI protocol draft.Flexibility is the key guiding principle behind this document. Thatis, an effort has been made to satisfy the needs of both smallisolated environments, as well as large environments requiringsecure/scalable solutions. "FC Frame Encapsulation", M. Rajagopal, Milan Merhar, Charles Monia, R Weber, Franco Travostino, Michael O'Donnell, 06-MAY-02, This is the ips (IP Storage) working group draft describing thecommon Fibre Channel frame encapsulation format and a procedure forthe measurement and calculation of frame transit time through the IPnetwork. This specification is intended for use by any IETF protocolthat encapsulates Fibre Channel (FC) frames. This draft describes aframe header containing information mandated for encapsulating,transmitting, de-encapsulating, and calculating the transit times ofFC frames. "Finding iSCSI Targets and Name Servers Using SLP", M Bakke, 05-MAR-02, The iSCSI protocol provides a way for hosts to access SCSI devicesover an IP network. This document defines the use of the ServiceLocation Protocol (SLP) by iSCSI hosts, devices, and name services,along with the SLP service type templates that describe the services they provide. "Definitions of Managed Objects for iSCSI", M Bakke, Jim Muchow, Tom McSweeney, Marjorie Krueger, 01-JUL-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 a client using theiSCSI (SCSI over TCP) protocol. It is meant to match the latestversion of iSCSI defined in [ISCSI]. "Definition of Managed Objects for FCIP", S Akkala, 23-JAN-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 a FCIP device, asdefined in [FCIP]. This MIB is defined such that it can be viewed asan extension to the existing FC Management Framework Integration MIB,as specified in [FCMGMT]. "Finding FCIP Entities Using SLP", Dave Peterson, 14-AUG-02, The FCIP protocol [FCIP] provides a method for the tunneling of FibreChannel frames over an IP network. This document defines the use ofService Location Protocol, version 2 (SLPv2) [RFC2608], by FCIPEntities to discover one another, and provides the appropriatetemplates describing their services. "Securing Block Storage Protocols over IP", B. Aboba, 27-AUG-02, This document discusses how to secure block storage and storagediscovery protocols running over IP. "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", Josh Tseng, Kevin Gibbons, Charles Monia, Tom McSweeney, 20-MAY-02, This memo defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internetcommunity. In particular, it defines a basic set of managedobjects for SNMP-based monitoring and management of the InternetStorage Name Service (iSNS).This memo specifies a MIB module in a manner that is compliant tothe SMIv2. The set of objects is consistent with the SNMPframework and existing SNMP standards.This memo is a product of the IP Storage (IPS) working groupwithin the Internet Engineering Task Force. Comments aresolicited and should be addressed to the working group's mailinglist at ips@ece.cmu.edu and/or the authors. "Definitions of Managed Objects For iFCP", Josh Tseng, Kevin Gibbons, Charles Monia, Franco Travostino, 29-AUG-02, This memo defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internetcommunity. In particular, it defines a basic set of managedobjects for SNMP-based monitoring and management of the InternetFibre Channel Protocol (iFCP).This memo specifies a MIB module in a manner that is compliant tothe SMIv2. The set of objects is consistent with the SNMPframework and existing SNMP standards.This memo is a product of the IP Storage (IPS) working groupwithin the Internet Engineering Task Force. Comments aresolicited and should be addressed to the working group's mailinglist at ips@ece.cmu.edu and/or the authors. "Definition of Managed Objects for SCSI Entities", M Bakke, 03-JUL-02, 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, 28-JUN-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for informantion related toFibre Channel. "String Profile for iSCSI Names", M Bakke, 28-JUN-02, The iSCSI protocol provides a way for hosts to access SCSI devicesover an IP network. The iSCSI end-points, called initiators andtargets, each have a globally-unique name that must be transcribable,as well as easily compared.This document describes how to prepare internationlized iSCSI namesto increase the likelihood that name input and comparison work inways that make sense for typical users throughout the world. "Definitions of Managed Objects for User Identity Authentication", M Bakke, Jim Muchow, 01-JUL-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 user identities and thenames, addresses, and credentials required to authenticate them, foruse with various protocols. This draft was motivated by the need forthe configuration of authenticated user identities for the iSCSIprotocol [ISCSI], but has been extended to be useful for otherprotocols that have similar requirements. It is important to notethat this MIB provides only the set of identities and the means toauthenticate them; it is the responsibility of other MIBs making useof this one to tie them to authorization lists. "FC Frame Encapsulation WG Last Call", R Weber, 09-APR-02, This ips (IP Storage) working group draft contains all the workinggroup last call comments received regarding:draft-ietf-ips-fcencapsulation-06.txtThe proposed disposition of each comment also is recorded in thisdraft. "FCIP 1st WG Last Call", R Weber, 14-MAY-02, This ips (IP Storage) working group draft contains all the workinggroup last call comments received regarding:draft-ietf-ips-fcovertcpip-09.txtThe proposed disposition of each comment also is recorded in thisdraft. "Responses to iFCP Rev. 10 Last Call Comments", Josh Tseng, Charles Monia, Franco Travostino, 23-MAY-02, This document is a compilation of responses to review commentsreceived for revision 10 if the iFCP specification [IFCP] during thepreliminary last call period from 3/4/2002 to 3/18/2002. IP Security Protocol (ipsec) ---------------------------- "IP Encapsulating Security Payload (ESP)", Stephen Kent, 02-JUL-02, This document describes an updated version of the EncapsulatingSecurity Payload (ESP) protocol, which is designed to provide a mixof security services in IPv4 and Ipv6. ESP is used to provideconfidentiality, data origin authentication, connectionlessintegrity, an anti-replay service (a form of partial sequenceintegrity), and limited traffic flow confidentiality. This documentis based upon RFC 2406 (November 1998). Section 7 provides a briefreview of the differences between this document and RFC 2406.Comments should be sent to Stephen Kent (kent@bbn.com). "Additional ECC Groups For IKE", Daniel Brown, S Blake-Wilson, Yuri Poeluev, Margaret Salter, 24-JUL-02, This document describes new ECC groups for use in IKE [IKE] inaddition to the Oakley groups included therein. These groups aredefined to align IKE with other ECC implementations and standards,and in addition, many of them provide higher strength than theOakley groups. It should be noted that this document is notself-contained. It uses the notations and definitions of [IKE]. "The AES Cipher Algorithms and Their Use With IPsec", R. Glenn, Sheila Frankel, Scott Kelly, 28-JUN-02, This document describes the use of the AES Cipher Algorithm in CipherBlock Chaining Mode, with an explicit IV, as a confidentiality mecha-nism within the context of the IPsec Encapsulating Security Payload(ESP). "More MODP Diffie-Hellman groups for IKE", Tero Kivinen, Markku Kojo, 07-JAN-02, This document defines new MODP groups for the IKE [RFC-2409] protocol.It documents the well know and used 1536 bit group 5, and also definesnew 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups. Theselection of the primes for theses groups follows the criteria estab-lished by Richard Schroeppel as described in [RFC-2412]. "On the Use of SCTP with IPsec", Steve Bellovin, 06-FEB-02, This document describes functional requirements for IPsec [RFC2401]and IKE [RFC2409] to facilitate their use for securing SCTP[RFC2960] traffic. "IPsec-NAT Compatibility Requirements", B. Aboba, William Dixon, 26-AUG-02, Perhaps the most common use of IPsec is in providing virtual privatenetworking capabilities. One very popular use of VPNs is to providetelecommuter access to the corporate Intranet. Today NATs are widelydeployed in home gateways, as well as in other locations likely to beused by telecommuters, such as hotels. The result is that IPsec-NATincompatibilities have become a major barrier to deployment of IPsec inone of its principal uses. This draft describes known incompatibilitiesbetween NAT and IPsec, and describes the requirements for addressingthem. "Negotiation of NAT-Traversal in the IKE", Tero Kivinen, 25-JUN-02, This document describes how to detect one or more NATs between IPsechosts, and how to negotiate the use of UDP encapsulation of the IPsecpackets through the NAT boxes in IKE. "UDP Encapsulation of IPsec Packets", Ari Huttunen, 12-JUN-02, This draft defines methods to encapsulate and decapsulate ESP packets inside UDP packets for the purpose of traversing NATs.ESP encapsulation as defined in this document is capable of beingused in both IPv4 and IPv6 scenarios.The encapsulation is used whenever negotiated using IKE, as defined in [Kiv02]. The design choices are documented in [Dixon00]. "Security Properties of the IPsec Protocol Suite", Andrew Krywaniuk, 03-JUL-02, This document describes the 'security properties' of the IPsecarchitecture and protocols, including ESP, AH, and IKE.By documenting these properties, we aim to provide a guide for userswho wish to understand the abilities and limitations of the IPsecprotocol suite. We also hope to provide motivation for future work inthis area. "Propsal for the IKEv2 Protocol", Charlie Kaufman, Dan Harkins, 25-APR-02, This document describes version 2 of the IKE (Internet Key Exchange)protocol. IKE performs mutual authentication and establishes an IKEsecurity association that can be used to efficiently establish SAsfor ESP, AH and/or IPcomp. This version greatly simplifies IKE byreplacing the 8 possible phase 1 exchanges with a single exchangebased on either public signature keys or shared secret keys. Thesingle exchange provides identity hiding, yet works in 2 round trips(all the identity hiding exchanges in IKE v1 required 3 round trips).Latency of setup of an IPsec SA is further reduced from IKEv1 byallowing setup of an SA for ESP, AH, and/or IPcomp to be piggybackedon the initial IKE exchange. It also improves security by allowingthe Responder to be stateless until it can be assured that theInitiator can receive at the claimed IP source address. This versionalso presents the entire protocol in a single self-containeddocument, in contrast to IKEv1, in which the protocol was describedin ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407)documents. "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", Sheila Frankel, Howard Herbert, 07-JUN-02, A Message Authentication Code (MAC) is a key-dependent one way hashfunction. One popular way to construct a MAC algorithm is to use ablock cipher in conjunction with the Cipher-Block-Chaining (CBC) modeof operation. The classic CBC-MAC algorithm, while secure for mes-sages of a pre-selected fixed length, has been shown to be insecureacross messages of varying lengths such as the type found in typicalIP datagrams. This memo specifies the use of AES in CBC mode with aset of extensions to overcome this limitation. This new algorithm isnamed AES-XCBC-MAC-96. "The HMAC-SHA-256-96 Algorithm and Its Use With IPsec", Sheila Frankel, Scott Kelly, 28-JUN-02, This document describes the use of the HMAC algorithm in conjunctionwith the SHA-256 algorithm as an experimental authentication mecha-nism within the context of the IPsec AH and ESP protocols. This algo-rithm is intended to provide data origin authentication and integrityprotection. Given the current lack of practical experience withSHA-256, implementations based on this document will be experimentalin nature, and implementation is not required in order to claim com-pliance with the IPsec proposed standards. The version of the HMAC-SHA-256 authenticator described in this document specifies truncationto 128 bits, and is therefore named HMAC-SHA-256-128. "Just Fast Keying (JFK)", Steve Bellovin, William Aiello, 03-JUL-02, This draft discusses JFK, a key management protocol. "Design Rationale for IKEv2", Dan Harkins, 26-FEB-02, This document describes the reasons for the design choices in IKEv2,the protocol described in draft-ietf-ipsec-ikev2-01.txt. Thisdocument describes why certain features are supported, and explainsthe modifications between the second draft of IKEv2 and the first. Itdescribes both the changes we chose to make and the changes that weconsidered but chose not to make. The changes are minor and mostlybased on feedback received from the first draft. "IP Authentication Header", Stephen Kent, 02-JUL-02, This document describes an updated version of the IP AuthenticationHeader (AH), which is designed to provide authentication services inIPv4 and IPv6. This document is based upon RFC 2402 (November 1998)[KA98c]. Section 7 provides a brief review of the differencesbetween this document and RFC 2402. "Son-of-IKE Requirements", C. Madson, 29-MAR-02, Various proposals have been made for updating the IKE protocol. This effort has been known as 'Son of IKE (SOI)'. One thing that is missing from the discussion is an evaluation of the scope of SOI, identifying which problems it should solve. Sections of this document discuss various scenarios that are considered important for SOI. Once this scoping is done, it becomes easier to specify the requirements of the protocol. This document also discusses protocol, policy and security requirements for SOI, along with recommendations for protocol improvement in such areas as modularity, extensibility, protocol convergence and simplicity, which are important regardless of the scope of SOI. "Revised Use of Identity in Successors to IKE", Paul Hoffman, 01-MAY-02, There is an opportunity in successor-to-IKE to fix two major problemsthat have plagued IKEv1: a misunderstanding about what is identity, andhaving to send certificates every time because you don't know if theother party already has your certificate. This proposal covers bothtopics at once because it turns out that they are related. "Features of Proposed Successors to IKE", Paul Hoffman, 03-JUN-02, This document describes many features of the proposals for the successorto IKEv1. The purpose of the document is to help the IPsec Working Groupdecide which features they want for the next protocol. The documentfocuses on how those features are instantiated in two proposals, IKEv2and JFK, but other ideas for features and options are also included.Most of the material in this document comes from many of the authors ofthe JFK and IKEv2 proposals.This document is meant to help the Working Group choose which featuresit finds important for the successor to IKE. It should be short-livedand is not expected to become an RFC.This document is meant to help the Working Group choose which featuresit finds important for the successor to IKE. It should be short-livedand is not expected to become an RFC. "The Internet IP Security PKI Profile of ISAKMP and PKIX", E. Rescorla, Brian Korver, 21-JUN-02, ISAKMP and PKIX both provide frameworks that must be profiled foruse in a given application. This document provides a profile ofISAKMP and PKIX that defines the requirements for using PKItechnology in the context of IPsec. The document complimentsprotocol specifications such as IKE, which assume the existence ofpublic key certificates and related keying materials, but which donot address PKI issues explicitly. This document addresses theseissues. "Extended Sequence Number Addendum to IPsec DOI for ISAKMP", Stephen Kent, 03-JUL-02, This document describes extensions to the Internet IP Security Domainof Interpretation for ISAKMP [DOI] that are needed to supportnegotiation of whether or not a Security Association will useExtended (64-bit) Sequence Numbers. (See [AH] and [ESP] for adescription of Extended Sequence Numbers.)Comments should be sent to Stephen Kent (kent@bbn.com). "Using AES Counter Mode With IPsec ESP", R. Housley, 23-JUL-02, This document describes the use of AES Counter Mode, with an explicitinitialization vector, as an IPsec Encapsulating Security Payloadconfidentiality mechanism. IP Security Policy (ipsp) ------------------------- "IPsec Configuration Policy Model", Lee Rafalow, Jamie Jason, Eric Vyncke, 09-AUG-02, This document presents an object-oriented information model of IPsec 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 the IP Security protocol [COMP, ESP, AH]. 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. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) [PCIM] and on the Policy Core Information Model Extensions (PCIMe) [PCIME]. "Security Policy Protocol", Luis Sanchez, Matt Condell, 29-JAN-02, This document describes a protocol for discovering, accessing andprocessing security policy information of hosts, subnets or networksof a security domain. The Security Policy Protocol defines how thepolicy information is exchanged, processed, and protected by clientsand servers. The protocol is extensible and flexible. It allows theexchange of complex policy objects between clients and servers. "IP Security Policy Requirements", Angelos Keromytis, Luis Sanchez, Matt Blaze, Michael Richardson, 09-AUG-02, This document describes the problem space and solution requirementsto develop an IP Security Policy configuration and managementframework. The IP Security Policy architecture provides a scalable,decentralized framework for managing, discovering and negotiating thehost and network security policies that govern access, authorization,authentcation, confidentiality, data integrity, and other IP Securityproperties. This documents highlights such architectural componentsand presents their functional requirements. "IPSec Policy Information Base", Avri Doria, David Arneson, Jamie Jason, Cliff Wang, Markus Stenberg, Man Li, 07-AUG-02, This document specifies a set of policy rule classes (PRC) for configuring IPsec policy at IPsec-enabled devices (e.g., security gateways). Instances of these classes reside in a virtual information store called the IPsec Policy Information Base (PIB). The COPS protocol [5] with extensions for provisioning [6] is used to transmit this IPsec policy information to IPsec-enabled devices. The PRCs defined in this IPsec PIB are intended for use by the COPS-PR IPsec client type. These PRCs are in addition to any other PIBs that may be defined for the IPsec client type, as well as the PRCs defined in the Framework PIB [9]. "IPsec Policy Configuration MIB", Michael Baer, 25-JUN-02, This document defines a configuration MIB for IPsec [IPSEC]/IKE[IKE] policy. It does not define MIBs for monitoring the state of anIPsec device. It does not define MIBs for configuring other policyrelated actions. The purpose of this MIB is to allow administratorsto be able to configure policy with respect to the IPsec/IKEprotocols. However, some of the packet filtering and matching ofconditions to actions is of a more general nature than IPsec only.It is possible to add other packet transforming actions to this MIBif those actions needed to be performed conditionally on filteredtraffic. IP Security Remote Access (ipsra) --------------------------------- "DHCPv4 Configuration of IPSEC Tunnel Mode", B. Aboba, B. Patel, V. Gupta, Scott Kelly, 02-JUL-01, In many remote access scenarios, a mechanism for making the remote hostappear to be present on the local corporate network is quite useful.This may be accomplished by assigning the host a 'virtual' address fromthe corporate network, and then tunneling traffic via IPSec from thehost's ISP-assigned address to the corporate security gateway. In IPv4,Dynamic Host Configuration Protocol (DHCP) provides for such remote hostconfiguration. This draft explores the requirements for hostconfiguration in IPSec tunnel mode, and describes how DHCPv4 may beleveraged for configuration. "Requirements for IPsec Remote Access Scenarios", Scott Kelly, Sankar Ramamoorthi, 27-MAR-02, IPsec offers much promise as a secure remote access mechanism.However, there are a significant number of remote access scenarios,each having some shared and some unique requirements. A thoroughunderstanding of these requirements is necessary in order toeffectively evaluate the suitability of a specific set of mechanismsfor any particular remote access scenario. This document enumeratesthe requirements for a number of common remote access scenarios. "PIC, A Pre-IKE Credential Provisioning Protocol", B. Aboba, H. Krawczyk, Yaron Sheffer, 13-FEB-02, This document presents a method to bootstrap IPSec authentication via an 'Authentication Server' (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the legacy user authentication. IP Telephony (iptel) -------------------- "CPL: A Language for User Control of Internet Telephony Services", H. Schulzrinne, Jonathan Lennox, 16-JAN-02, The Call Processing Language (CPL) is a language that can be used todescribe and control Internet telephony services. It is designed tobe implementable on either network servers or user agent servers. Itis meant to be simple, extensible, easily edited by graphicalclients, and independent of operating system or signalling protocol.It is suitable for running on a server where users may not be allowedto execute arbitrary programs, as it has no variables, loops, orability to run external programs.This document is a product of the IP Telephony (IPTEL) working groupof the Internet Engineering Task Force. Comments are solicited andshould be addressed to the working group's mailing list atiptel@lists.research.bell-labs.com and/or the authors. "Management Information Base for Telephony Routing over IP (TRIP)", Dave Walker, J Jiang, David Zinman, 28-MAY-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 a set of managed objects that are usedto manage for Telephony Routing over IP (TRIP) [RFC3219] devices.Since TRIP [RFC3219] is modeled after the Border Gateway Protocol(BGP-4) [RFC1771], the managed objects for TRIP are also modeledafter RFC1657 - Definitions of Managed Objects for the FourthVersion of the Border Gateway Protocol (BGP-4) using SMIv2[RFC1657]. "Usage of TRIP in Gateways for Exporting Phone Routes", Manjunath Bangalore, 07-JUN-02, This document describes a new application of the Telephony Routingover IP (TRIP) protocol. TRIP was engineered as a tool for inter-domain exchange of telephone routing information. However, it canalso be used as a means for gateways and soft switches to exporttheir routing information to a Location Server (LS), which may beco-resident with a proxy or gatekeeper. This LS can then manage thosegateway resources. We discuss the motivations for this application,and then show how a subset of TRIP is needed for this application. IP Version 6 Working Group (ipv6) --------------------------------- "IPv6 Node Information Queries", M. Crawford, 20-MAY-02, This document describes a protocol for asking an IPv6 node to supplycertain network information, such as its hostname or fully-qualifieddomain name. IPv6 implementation experience has shown that directqueries for a hostname are useful, and a direct query mechanism forother information has been found useful in serverless environmentsand for debugging. "A flexible method for managing the assignment of bites of an IPv6 address block", Marc Blanchet, 30-AUG-02, This document proposes a method to manage the assignment of bits ofan IPv6 address block or range. When an organisation needs to makean address plan for its subnets or when an ISP needs to make anaddress plan for its customers, this method enables the organisationto postpone the final decision on the number of bits to partition inthe address space they have. It does it by keeping the bits aroundthe borders of the partition to be free as long as possible. Thisscheme is applicable to any bits addressing scheme using bits withpartitions in the space, but its first intended use is for IPv6. Itis a generalization of RFC1219 and can be used for IPv6 assignments. "Advanced Sockets API for IPv6", Erik Nordmark, M Thomas, Richard Stevens, T. Jinmei, 19-APR-02, A separate specification [RFC-2553] contain changes to the socketsAPI to support IP version 6. Those changes are for TCP and UDP-basedapplications and will support most end-user applications in usetoday: Telnet and FTP clients and servers, HTTP clients and servers,and the like.But another class of applications exists that will also be run underIPv6. We call these 'advanced' applications and today this includesprograms such as Ping, Traceroute, routing daemons, multicast routingdaemons, router discovery daemons, and the like. The API featuretypically used by these programs that make them 'advanced' is a rawsocket to access ICMPv4, IGMPv4, or IPv4, along with some knowledgeof the packet header formats used by these protocols. To provideportability for applications that use raw sockets under IPv6, somestandardization is needed for the advanced API features.There are other features of IPv6 that some applications will need toaccess: interface identification (specifying the outgoing interfaceand determining the incoming interface) and IPv6 extension headersthat are not addressed in [RFC-2553]: The Routing header (sourcerouting), Hop-by-Hop options, and Destination options. This documentprovides API access to these features too. "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", A. Conta, S. 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). "Default Address Selection for IPv6", Richard Draves, 07-AUG-02, This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. "IP Version 6 Addressing Architecture", B. Hinden, S. Deering, 28-AUG-02, This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressingmodel, text representations of IPv6 addresses, definition of IPv6unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses. "IPv6 Scoped Address Architecture", Erik Nordmark, S. Deering, A. Onoe, Brian Zill, T. Jinmei, Brian Haberman, 10-JUN-02, This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. "Basic Socket Interface Extensions for IPv6", R. Gilligan, W. Stevens, J. Bound, S. Thomson, J. McCann, 26-JUL-02, The de facto standard application program interface (API) for TCP/IPapplications is the 'sockets' interface. Although this API wasdeveloped for Unix in the early 1980s it has also been implemented ona wide variety of non-Unix systems. TCP/IP applications writtenusing the sockets API have in the past enjoyed a high degree ofportability and we would like the same portability with IPv6applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a newsocket address structure to carry IPv6 addresses, new addressconversion functions, and some new socket options. These extensionsare designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing aminimum of change into the system and providing completecompatibility for existing IPv4 applications. Additional extensionsfor advanced IPv6 features (raw sockets and access to the IPv6extension headers) are defined in another document [4]. "Well known site local unicast addresses for DNS resolver", D. Thaler, A Durand, Jun-Ichiro itojun Hagino, 14-JUN-02, This documents specifies a method for nodes to find a DNS resolverwith minimum configuration in the network and without running adiscovery protocol on the nodes. "Default Router Preferences, More-Specific Routes and Load Sharing", B. Hinden, Richard Draves, 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 itojun Hagino, K Ettican, 03-JUL-02, The memo tries to identify the problems and issues in the use of IPv6anycast [Hinden, 1998] defined as of today. The goals of the draft are(1) to understand the currently-defined IPv6 anycast better, (2) toprovide 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 designteam. "IPv6 Host to Router Load Sharing", B. Hinden, 10-JAN-02, This document defines a change to IPv6 Neighbor Discovery that IPv6hosts can use to load share their outgoing traffic between multipledefault routers. "Recommendations for IPv6 in 3GPP Standards", Margaret Wasserman, 26-APR-02, This document contains recommendations from the InternetEngineering Task Force (IETF) IPv6 Working Group to the ThirdGeneration Partnership Project (3GPP) community regarding the useof IPv6 in the 3GPP standards. Specifically, this documentrecommends that the 3GPP:1. Specify that multiple prefixes may be assigned to eachprimary PDP context,2. Require that a given prefix must not be assigned to morethan one primary PDP context, and3. Allow 3GPP nodes to use multiple identifiers within thoseprefixes, including randomly generated identifiers.The IPv6 Working Group supports the use of IPv6 within 3GPP andoffers these recommendations in a spirit of open cooperationbetween the IPv6 Working Group and the 3GPP community. Since theoriginal publication of this document as an Internet-Draft, the3GPP has adopted the primary recommendations of this document. "IPv6 Flow Label Specification", B. Carpenter, A. Conta, S. Deering, J Rajahalme, 11-SEP-02, This document specifies the usage of the IPv6 Flow Label field, therequirements for IPv6 source nodes labeling flows, and therequirements for flow state establishment methods.The usage of the Flow Label field enables efficient IPv6 flowclassification based only on IPv6 main header fields in fixedpositions. "IPv6 for Some Second and Third Generation Cellular Hosts", Jari Arkko, 07-JUN-02, As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making IPv6 mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. The document lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. "Link Scoped IPv6 Multicast Addresses", Myung-Ki Shin, Jung-Soo Park, Yong-Jin Kim, 05-JUL-02, This document specifies an extension to the multicast addressingarchitecture 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", J. Loughney, 05-JUL-02, This document defines requirements for IPv6 nodes. It is expectedthat IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to functionwell and interoperate in a large number of situations anddeployments. "IP Forwarding Table MIB", Margaret Wasserman, 28-AUG-02, This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internetcommunity. In particular, it describes managed objects related tothe forwarding of Internet Protocol (IP) packets, in an IP versionindependent manner. "Management Information Base for the Transmission Control Protocol (TCP)", Bill Fenner, 02-JUL-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 implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. "Management Information Base for the Internet Protocol (IP)", Shawn Routhier, 03-JUL-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects used for implementations of theInternet Protocol (IP) in an IP version independent manner. "Management Information Base for the User Datagram Protocol (UDP)", Bill Fenner, 08-JUL-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects used for implementations of theUser Datagram Protocol (UDP) [4] in an IP version independent manner.It is intended to obsolete RFC 2013 and RFC 2454. "Multi-link Subnet Support in IPv6", C. Huitema, D. Thaler, 08-JUL-02, Bridging multiple links into a single entity has severaloperational advantages. A single subnet prefix is sufficient tosupport multiple physical links. There is no need to allocatesubnet numbers to the different networks, simplifying management.This document introduces the concept of a 'multilink subnet',defined as a collection of independent links, connected byrouters, but sharing a common subnet prefix. It then specifiesthe behavior of multilink subnet routers so that no changes tohost behavior are needed. "Generic Packet Tunneling in IPv6 Specification", A. Conta, S. Deering, 23-JUL-02, This document defines the model and generic mechanisms for IPv6encapsulation of Internet packets, such as IPv6 and IPv4. The modeland mechanisms can be applied to other protocol packets as well, suchas AppleTalk, IPX, CLNP, or others. "Scoped Address Extensions to the IPv6 Basic Socket API", R. Gilligan, 26-JUL-02, This document specifies a set of extensions to the basic IPv6 socketsAPI for the support of scoped addresses. IS-IS for IP Internets (isis) ----------------------------- "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", D. Katz, Rajesh Saluja, 16-APR-02, The IS-IS routing protocol (ISO 10589) requires reliable protocols atthe link layer for point-to-point links. As a result, it does not usea three-way handshake when establishing adjacencies on point-to-pointmedia. This paper defines an backward-compatible extension to theprotocol that provides for a three-way handshake. It is fullyinteroperable with systems that do not support the extension.Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.This extension has been implemented by multiple router vendors; thispaper is provided as information to the Internet community in orderto allow interoperable implementations to be built by other vendors. "Management Information Base for IS-IS", Jeff Parker, 14-AUG-02, This document describes a management information base for the IS-ISRouting protocol, as described in ISO 10589 [2], when it is used toconstruct routing tables for IP networks, as described in RFC 1195[RFC1195].This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community.This memo is based on an IETF draft by Chris Gunner [1]. Thisversion has been modified to include MIB-II syntax, to excludeportions of the protocol that are not relevant to IP, such as theES-IS protocol, and to add management support for current practice. "IS-IS Cryptographic Authentication", R. Atkinson, Tony Li, 05-JUL-01, This document describes the authentication of IS-IS PDUs using theHMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensionsto support IPv4 described in [3]. The base specification includes anauthentication mechanism that allows for multiple authenticationalgorithms. The base specification only specifies the algorithm forcleartext passwords. "IS-IS extensions for Traffic Engineering", Tony Li, Henk Smit, 20-AUG-01, This document describes extensions to the IS-IS protocol to supportTraffic Engineering [1]. The IS-IS protocol is specified in [2],with extensions for supporting IPv4 specified in [3].This document extends the IS-IS protocol by specifying newinformation that a Intermediate System (IS) [router] can place inLink State Protocol Data Units (LSPs). This information describesadditional information about the state of the network that is usefulfor traffic engineering computations. "Routing IPv6 with IS-IS", Chris Hopps, 02-APR-01, This draft specifies a method for exchanging IPv6 routing informationusing the IS-IS routing protocol [0]. The method utilizes the samemechanisms described in RFC 1195 [1]. This is accomplished by adding2 new TLVs and defining their use. These new TLVs are patterned fromthe ones described in 'IS-IS extensions for Traffic Engineering' [2].Just as in RFC 1195 [1] with IPv4 and OSI, this method allows one toroute both IPv4 and IPv6 using a single intra-domain routingprotocol. "IS-IS Extensions in Support of Generalized MPLS", Y. Rekhter, K. Kompella, 28-AUG-02, This document specifies encoding of extensions to the IS-IS routingprotocol in support of Generalized Multi-Protocol Label Switching. "M-ISIS: Multi Topology (MT)Routing in IS-IS", Naiming Shen, Nischal Sheth, Tony Przygienda, 03-JUL-02, This draft describes an optional mechanism within ISIS used todayby many ISPs for IGP routing within their clouds. This draftdescribes how to run within a single ISIS domain a set ofindependent IP topologies that we call Multi-Topologies (MTs).This MT extension can be used for variety of purposes such as anin-band management network ``on top'' of the original IGP topology,maintain separate IGP routing domains for isolated multicast orIPv6 islands within the backbone, or force a subset of an addressspace 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 Ethernettechnology, providing a means to carry large MTU packets withoutfragmentation over a high-speed broadcast network. "Restart signaling for ISIS", M. Shand, 24-MAY-02, 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. "Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit", M. Shand, S. Previdi, A. Hermelin, 28-AUG-02, This document describes a mechanism that allows a system to originatemore than 256 LSP fragments, a limit set by the original IntermediateSystem to Intermediate System (IS-IS) Routing protocol, as describedin ISO 10589. This mechanism can be used in IP-only, OSI-only, anddual routers. "Recommendations for Interoperable IP Networks using IS-IS", Jeff Parker, 20-JUN-02, In theory, there is no difference between theory and practice.But in practice, there is.Jan L.A. van de SnepscheutThis document discusses a number of differences between the IS-ISprotocol as described in ISO 10589 [1] and RFC 1195 [3] and theprotocol as it is deployed today. These differences are discussed asa service to those implementing, testing, and deploying the IS-ISProtocol to route IP traffic. "IS-IS Automatic Encapsulation", Philip Christian, 25-JUL-02, 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 thattype of packet. "A Policy Control Mechanism is IS-IS Using Administrative Tags", S. Previdi, Brad Neal, Christian Martin, 27-AUG-02, This document describes an extension to the IS-IS protocol to addoperational capabilities that allow for ease of management andcontrol over IP prefix distribution within an IS-IS domain. The IS-IS protocol is specified in [1], with extensions for supporting IPv4specified in [2] and further enhancements for Traffic Engineering [4]in [3] and [6].This document enhances the IS-IS protocol by extending theinformation that a Intermediate System (IS) [router] can place inLink State Protocol Data Units (LSPs) as specified in [2]. Thisextension will provide operators with a mechanism to control IPprefix distribution throughout multi-level IS-IS domains.Additionally, the information can be placed in LSPs that have TLVs asyet undefined, if this information is used to convey the same meaningin these future TLVs as it is used in the currently defined TLVs. "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. Kerberized Internet Negotiation of Keys (kink) ---------------------------------------------- "Kerberized Internet Negotiation of Keys (KINK)", M Thomas, J Vilhuber, 16-AUG-02, The Kerberized Internet Negotiation of Keys protocol (KINK) defines alow-latency, computationally inexpensive, easily managed, andcryptographically sound protocol to set up and maintain IPsecsecurity associations using Kerberos authentication. KINK reuses manyISAKMP Quick Mode payloads to create, delete and maintain IPsecsecurity associations which should lead to substantial reuse ofexisting IKE implementations. Kerberos WG (krb-wg) -------------------- "Public Key Cryptography for Initial Authentication in Kerberos", C. Neuman, J. Wray, B. Tung, J. Trostle, M. Hur, A. Medvinsky, S. Medvinsky, 12-SEP-02, This document defines extensions (PKINIT) to the Kerberos protocolspecification (RFC 1510 [1]) to provide a method for using publickey cryptography during initial authentication. The methodsdefined specify the ways in which preauthentication data fields anderror data fields in Kerberos messages are to be used to transportpublic key data. "Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB)", B. Aboba, G. Zorn, J. Trostle, Michael Swift, 06-SEP-01, This document defines extensions to the Kerberos protocolspecification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism(RFC 1964 [2]) that enables a client to obtain Kerberos tickets forservices where the KDC is not accessible to the client, but isaccessible to the application server. Some common scenarios wherelack of accessibility would occur are when the client does not havean IP address prior to authenticating to an access point, the clientis unable to locate a KDC, or a KDC is behind a firewall. Thedocument specifies two protocols to allow a client to exchange KDCmessages (which are GSS encapsulated) with an IAKERB proxy instead ofa KDC. "Distributing Kerberos KDC and Realm Information with DNS", Ken Hornstein, Jeffrey Altman, 29-JUL-02, Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-col [RFC????] describe any mechanism for clients to learn criticalconfiguration information necessary for proper operation of the pro-tocol. Such information includes the location of Kerberos key dis-tribution centers or a mapping between DNS domains and Kerberosrealms.Current Kerberos implementations generally store such configurationinformation in a file on each client machine. Experience has shownthis method of storing configuration information presents problemswith out-of-date information and scaling problems, especially whenusing cross-realm authentication.This memo describes a method for using the Domain Name System[RFC1035] for storing such configuration information. Specifically,methods for storing KDC location and hostname/domain name to realmmapping information are discussed. "Kerberos Set/Change Password: Version 2", John Brezak, J. Trostle, Michael Swift, Bill Gossman, 31-MAY-01, This proposal specifies a Kerberos (RFC 1510 [3]) change/set passwordprotocol and a Kerberos change/set key protocol. The protocolconsists of a single request and reply message. The request messageincludes both AP-REQ and KRB-PRIV submessages; the new password iscontained in the KRB-PRIV submessage which is encrypted in thesubsession key from the AP-REQ. "Kerberos KDC LDAP Schema", J Griffith, J. Trostle, D. Skibbie, 30-MAY-02, This document defines a schema for storing attributes used by implementations of Kerberos Version 5 Key Distribution Center (KDC) service in a directory that implements the Lightweight Directory Access Protocol (LDAP) Version 3. The directory must implement the LDAP Version 3 protocol as defined in RFC 2251 [2], RFC 2252 [3], RFC 2253 [4], RFC 2256 [5], 2829 [6], and 2830[7]. The schema defined in this document is referred to as the 'KDC LDAP schema.'The KDC LDAP schema includes definitions for attributes defining a realm, a realm policy, principals, and principal policies. The KDC LDAP schema does not include definitions for attributes used to store keys. "Encryption and Checksum Specifications for Kerberos 5", Kenneth Raeburn, 06-MAY-02, This document describes a framework for defining encryption andchecksum mechanisms for use with the Kerberos protocol [Kerb],defining an abstraction layer between the Kerberos protocol andrelated protocols, and the actual mechanisms themselves. Severalmechanisms are also defined in this document. Some are taken fromRFC 1510, modified in form to fit this new framework, andoccasionally modified in content when the old specification wasincorrect. New mechanisms are presented here as well. This documentdoes NOT indicate which mechanisms may be considered 'required toimplement' or deprecated.Comments should be sent to the editor, or to the IETF Kerberosworking group (ietf-krb-wg@anl.gov). "The Kerberos Network Authentication Service (V5)", C. Neuman, 27-FEB-02, This document provides an overview and specification of Version 5 of theKerberos 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. "Stringprep Profile for Kerberos UTF-8 Strings", Jeffrey Altman, 27-FEB-02, This document describes how to prepare UTF-8 stringsin order to increase the likelihood that name input and name comparisonwork in ways that make sense for typical users throughout the world. This is a profile of the stringprep protocol developed in the IDN working group. "Keys Extension for the Kerberos KDC LDAP Schema", J Griffith, J. Trostle, D. Skibbie, 31-MAY-02, This document defines a Keys Extension Schema. The Keys ExtensionSchema extends the KDC LDAP schema defined in the work in progressIETF document so thatkey attributes used by implementations of Kerberos Version 5 Key Distribution Center (KDC) service can be stored in a directory that implements the Lightweight Directory Access Protocol (LDAP)Version 3. The directory must implement the LDAP Version 3 protocol as defined in RFC 2251 [2], RFC 2252 [3], RFC 2253 [4], RFC 2256 [5], 2829 [6], and 2830 [7]. 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 duringsession or control connection establishment to provide additionalnode and port information for accounting and debugging use. "Layer-Two Tunneling Protocol (L2TP) Extensions for PPP Link Control P[rotocol (LCP) Negotiation", William Palter, W. Mark Townsley, 09-AUG-02, This document defines extensions to the Layer Two Tunneling Protocol(L2TP) for enhanced support of link-specific Point to Point Protocol(PPP) options. PPP endpoints typically have direct access to thecommon physical media connecting them and thus have detailedknowledge about the media that is in use. When the L2TP is used, thetwo PPP peers are no longer directly connected over the same physicalmedia. Instead, L2TP inserts a virtual connection over some or allof the PPP connection by tunneling PPP frames over a packet switchednetwork such as IP. Under some conditions, an L2TP endpoint may needto negotiate PPP Link Control Protocol (LCP) options at a locationwhich may not have access to all of the media information necessaryfor proper participation in the LCP negotiation. This documentprovides a mechanism for communicating desired LCP options betweenL2TP endpoints in advance of PPP LCP negotiation at the far end of anL2TP tunnel, as well as a mechanism for communicating the negotiatedLCP options back to where the native PPP link resides. "L2TP Header Compression ('L2TPHC')", A. Valencia, 05-JUL-02, The Layer 2 Tunneling Protocol ('L2TP') [RFC2661] defines amechanism for tunneling PPP sessions over arbitrary media. Thereexists a class of specific media applications for which protocoloverhead may be optimized, and where such reduction results inimproved operation. This document describes the solution spaceaddressed, its underlying motivations, and the protocol modificationsrequired. The enhancement to the L2TP protocol is called L2TP HeaderCompression, or 'L2TPHC'. "L2TP IP Differentiated Services Extension", Ken Peirce, P. Calhoun, Danny McPherson, Wei Luo, 25-MAR-02, The Layer Two Tunneling Protocol (L2TP) provides a standard methodfor tunneling PPP packets. The current specification provides noprovisions for supporting Differentiated Services (diffserv) over theL2TP control connection or subsequent data sessions. As a result, nostandard mechanism currently exists within L2TP to provide L2TPprotocol negotiations for service discrimination. "L2TP Multicast Extension", Gilles Bourdon, 01-AUG-02, The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] 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, 01-JUL-02, L2TP Active Discovery Relay for PPPoE describes a method for relay ofPPPoE Active Discovery and Service Selection over the reliable L2TPcontrol channel. Two new L2TP control message types and associatedPPPoE-specific AVPs are defined. This relay mechanism providesenhanced integration of a specific feature in the PPPoE tunnelingprotocol with L2TP. "Layer Two Tunneling Protocol (Version 3)'L2TPv3'", J Lau, W. Mark Townsley, 03-JUL-02, This document describes the Layer Two Tunneling Protocol (L2TP).L2TP tunnels Layer 2 packets across an intervening network in a waythat is as transparent as possible to both end-users andapplications. "L2TP Tunnel Switching", Ly Loi, Reinaldo Penno, S McGeown, Vipin Jain, Marc Eaton-Brown, 15-APR-02, L2TP 'Tunnel Switching' or 'Multihop' is the process of forwarding an L2TP tunneled data link from the logical termination point of one L2TP session onto another at an L2TP-aware intervening node. This action has the affect of directing a session, or groups of sessions, based on L2TP or tunneled data link characterisics. This document will provide some examples of where this technique might be useful in various network environments, offer guidelines to Tunnel Switch implementors, and define associated tunnel switching nomenclature, and provide protocol extensions to help facilitate tunnel switching. "Frame-Relay Pseudo-Wire Extensions for L2TP", W. Mark Townsley, 01-JUL-02, The Layer 2 Tunneling Protocol [L2TPv3] defines an extensibletunneling protocol suitable for Pseudowire Emulation Edge to Edge(PWE3) applications. This document describes the specifics of how touse the L2TP control plane for Frame-Relay Pseudo-Wires, includingPVC creation, deletion, and line status change notification. "L2TP IANA Considerations Update", W. Mark Townsley, 09-AUG-02, This document describes updates to the IANA considerations for theLayer Two Tunneling Protocol. "Fail Over extensions for L2TP", Reinaldo Penno, Keyur Parikh, 06-MAY-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 controlconnection 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. "V.92 Modem-On-Hold signalling on L2TP", Ignacio Goyret, 01-JUL-02, The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanismfor tunneling PPP [STD51] sessions.One of the features introduced by V.92 [V92] is the ability of theclient modem to put the call on hold. The L2TP base protocol doesnot provide any means to signal this event. This document describesa method used to indicate when a client modem has gone on-hold. "HDLC Pseudo-Wire over L2TPv3", W. Mark Townsley, 26-JUN-02, Specifics for HDLC Pseudowire emulation over L2TPv3 are described inthis document. "Layer Two Tunneling Protocol : ATM Access Network Extensions", B. Sales, Paolo Crivellari, Yves T''Joens, 26-JUN-02, L2TP [RFC2661] specifies a protocol for tunnelling PPP packets overpacket based networks and over IP networks in particular. L2TP[RFC2661] supports remote access by ISDN and PSTN networks. Thisdocument augments the procedures described in [RFC2661] to furthersupport ATM SVC or PVC based access networks. The extensions definedwithin this document allow for asymmetric bi-directional callestablishment and service selection in the ATM access network. "Layer Two Tunneling Protocol (Version 3) 'L2TPv3'Management Information Base", Walter Klausberger, Jed Lau, 27-JUN-02, This document describes a portion of the Management Information Base(MIB) to manage the Layer Two Tunneling Protocol, Version 3 (L2TPv3). LDAP (v3) Revision (ldapbis) ---------------------------- "LDAP:String Representation of Distinguished Names", Kurt Zeilenga, 26-AUG-02, The X.500 Directory uses distinguished names (DNs) as primary keys toentries in the directory. This document defines the stringrepresentation used in the Lightweight Directory Access Protocol(LDAP) to transfer distinguished names. The string representation isdesigned to give a clean representation of commonly used distinguishednames, while being able to represent any distinguished name. "LDAP: The Protocol", J. Sermersheim, 28-JUN-02, 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). "Lightweight Directory Access Protocol (v3):Technical Specification", J. Hodges, R. Morgan, 20-MAY-02, This document specifies the set of RFCs comprising LDAPv3, and addressesthe 'IESG Note' attached to RFCs 2251 through 2256. "LDAP: String Representation of Search Filters", T. Howes, M. Smith, 09-AUG-02, LDAP search filters are transmitted in the LDAP protocol using abinary representation that is appropriate for use on the network.This document defines a human-readable string representation of LDAPsearch filters that is appropriate for use in LDAP URLs and in otherapplications "LDAP: Authentication Methods and Connection Level Security Mechanism", Rod Harrison, 06-MAR-02, This document describes LDAPv3 authentication methods and connectionlevel security mechanisms that are required of all conforming LDAPv3server implementations and makes recommendations for combinations ofthese mechanisms to be used in various deployment circumstances. "LDAP: Uniform Resource Locator", T. Howes, M. Smith, 09-AUG-02, This document describes a format for an LDAP Uniform Resource Locator(URL). An LDAP URL describes an LDAP search operation that is usedto retrieve information from an LDAP directory, or, in the context ofan LDAPv3 referral or reference, an LDAP URL describes a servicewhere an LDAP operation may be progressed. "IANA Considerations for LDAP", Kurt Zeilenga, 02-AUG-02, This document provides procedures for registering extensible elementsof LDAP (Lightweight Directory Access Protocol). The document alsoprovides guidelines to IANA (Internet Assigned Numbers Authority)describing conditions under which new values can be assigned "A Summary of the X.500(2nd edition) User Schema for use with LDAPv3", Kathy Dally, 04-MAR-02, This document provides an overview of the attribute types and objectclasses defined by the ISO/IEC JTC1 and ITU-T committees in the IS0/IEC 9594 and X.500 documents, in particular those intended for use by directory clients. This is the most widely used schema for LDAP/X.500 directories, and many other schema definitions for white pages objects use it as a basis. This document does not cover attributes used for the administration of X.500 directory servers, nor does it include attributes defined by other ISO/ITU-T documents. "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", Kathy Dally, 04-MAR-02, The Lightweight Directory Access Protocol (LDAP) [Prot] provides for exchanging AttributeValue fields in protocol. This document defines a set of syntaxes for LDAP, and the rules by which attribute values of these syntaxes are represented in the LDAP protocol. The syntaxesdefined in this document are used by this and other documents to define attribute types. In addition, this document defines the set of attribute syntaxes, which LDAP servers support, and other schema elements (required and optional) that are common to all LDAP servers. "LDAP: Technical Specification Road Map", Kurt Zeilenga, 25-FEB-02, The Lightweight Directory Access Protocol (LDAP) is an Internetprotocol for accessing distributed directory services which act inaccordance with X.500 data and service models. This document providesa roadmap of the LDAP Technical Specification. "LDAP: Directory Information Models", Kurt Zeilenga, 12-AUG-02, The Lightweight Directory Access Protocol (LDAP) is an Internetprotocol for accessing distributed directory services which act inaccordance with X.500 data and service models. This documentdescribes the X.500 Directory Information Models. LDAP Extension (ldapext) ------------------------ "The Java LDAP Application Program Interface", Rob Weltman, Christine Tomlinson, Steven Sonntag, 02-JUL-02, 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 Extensions for Scrolling View Browsing of Search Result", David Boreham, Jim Sermersheim, Asaf Kashi, 06-AUG-02, This document describes a Virtual List View control extension for the Lightweight Directory Access Protocol (LDAP) Search operation. This control is designed to allow the 'virtual list box' feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. The control allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value. "X.509 Authentication SASL Mechanism", Steve Kille, 24-FEB-00, This document defines a SASL [1] authentication mechanism based on X.509strong authentication [3], providing two way authentication. Thismechanism is only for authentication, and has no effect on the protocolencodings and is not designed to provide integrity or confidentialityservices. "LDAP Control for a Duplicate Entry Representation of Search Results", J. Sermersheim, 11-SEP-02, This document describes a Duplicate Entry Representation controlextension for the LDAP Search operation. By using the control withan LDAP search, a client requests that the server return separateentries for each value held in the specified attributes. Forinstance, if a specified attribute of an entry holds multiplevalues, the search operation will return multiple instances of thatentry, each instance holding a separate single value in thatattribute. "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. "A Taxonomoy of Methods for LDAP Clients Finding Servers", Roland Hedberg, Ryan Moats, 03-JUL-01, There are several different methods for a LDAP client to find a LDAPserver. This draft discusses these methods and provides pointers forinterested parties to learn more about implementing a particularmethod. "Discovering LDAP Services with DNS", A. Hopkins, Michael Armijo, L. Esibov, R. Morgan, 12-JUN-02, A Lightweight Directory Access Protocol (LDAP) request must bedirected to an appropriate server for processing. This documentspecifies a method for discovering such servers using information inthe Domain Name System. "Lightweight Directory Access Protocol over UDP/IP", Roland Hedberg, Leif Johansson, 11-MAY-01, This memo describes modifications to LDAP version 3[1] to allowtransport of a subset of the LDAP protocol over UDP/IP. LDAP Duplication/Replication/Update Protocols (ldup) ---------------------------------------------------- "LDUP Update Reconciliation Procedures", Steven Legg, A Payne, 04-MAR-02, This document describes the procedures used by Lightweight DirectoryAccess Protocol (LDAP) directory servers or X.500 directory serversto reconcile updates performed by autonomously operating directoryservers in a distributed, replicated directory service, using theLDAP Duplication/Replication/Update protocols. "LDAPv3 Replication Requirements", Ryan Moats, E. Stokes, R. Weiser, Richard Huber, 01-APR-02, This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) [RFC2251]. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. "LDAP Replication Architecture", Ed Reed, U. Srinivasan, 06-MAR-02, 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. "General Usage Profile for LDAPv3 Replication", Ryan Moats, Gerald Maziarski, Richard Huber, 02-JUL-02, Support for replication in LDAP directory systems is often one of thekey factors in the decision to deploy them. But replication bringsdesign constraints along with its benefits.We discuss some of the factors that should be taken into considerationwhen designing a replicated directory system. Both programming andarchitectural/operational concerns are addressed. "LDAP Client Update Protocol", M. Smith, O. Natkovich, R Megginson, J. Parham, 12-JUN-02, This document defines the 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", Rick Huber, Ryan Moats, John McMeeking, 18-FEB-02, 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. Multicast & Anycast Group Membership (magma) -------------------------------------------- "Socket Interface Extensions for Multicast Source Filters", Bill Fenner, D. Thaler, B. Quinn, 03-JUL-02, IGMPv3 for IPv4 adds the capability for applications to expresssource filters on multicast group memberships, which allowsreceiver applications to determine the set of senders (sources)from which to accept multicast traffic. This capability alsosimplifies support of one-to-many type multicast applications. Itis expected that in the future, the same capability will beavailable in IPv6 as well.This document specifies new socket options and ioctl commands tomanage source filters for IP Multicast group memberships. It alsodefines the socket structures to provide input and outputarguments to these new APIs. These extensions are designed toprovide access to the source filtering features, while introducinga minimum of change into the system and providing completecompatibility for existing multicast applications. "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Rolland Vida, 14-JUN-02, This document specifies Version 2 of the Multicast Listener Discoveryprotocol, MLDv2. MLD is the protocol used by an IPv6 router todiscover the presence of multicast listeners (that is, nodes wishingto receive multicast packets) on its directly attached links, and todiscover specifically which multicast addresses are of interest tothose neighboring nodes.MLDv2 is derived from version 3 of IPv4's Internet Group ManagementProtocol, 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. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to links where there are no interested listeners. When compared to IGMPv3, one important difference to note is that MLDv2 uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. "IGMPv3 and Multicast Routing Protocol Interaction", J. Martin, Brian Haberman, 05-MAR-02, The definition of IGMPv3 requires new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 messages necessitates that multicast routing protocols manage and utilize the information. This document will describe how IGMPv3 and multicast routing protocols interact. "IGMP and MLD snooping switches", Frank Solensky, Morten Christensen, 03-JUL-02, This memo describes the requirements for IGMP and MLD snoopingswitches. The requirements for IGMPv2 snooping switches are basedon best current practices. IGMPv3 and MLDv2 snooping are also cov­ered in this draft although we are not aware of any such implemen­tations at the time of writing. Areas which are of relevance toIGMP and MLD snooping switches, such as link layer topology changesand Ethernet specific encapsulation issues are also considered.Interoperability issues that arise betweed different versions ofIGMP are not discussed in this document. Interested readers aredirected to [IGMPv3] for a thorough description of problem area.This document is intended as an accompanying document to the IGMPv3and MLDv2 specifications. "Multicast Router Discovery SSM Range Option", I Kouvelas, 26-FEB-02, This document defines the Multicast Router Discovery optionfor advertising the configured Source Specific Multicastdestination address range. "IPv4 Multicast Source Notification of Interest Protocol (MSNIP)", Bill Fenner, 26-FEB-02, This document discusses the Multicast Source InterestNotification Protocol (MSNIP). MSNIP is an extension toIGMPv3 that provides membership notification services forsources of multicast traffic. "Internet Group Management Protocol MIB", Julian Chesterfield, 28-JUN-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 objects used for managing the Internet Group Management Protocol (IGMP). Multicast-Address Allocation (malloc) ------------------------------------- "Multicast Address Allocation MIB", D. Thaler, 03-JUL-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects used for managing multicastaddress allocation. Mobile Ad-hoc Networks (manet) ------------------------------ "The Zone Routing Protocol (ZRP) for Ad Hoc Networks", Zygmunt Haas, Marc Pearlman, Prince Samar, 12-AUG-02, This document describes the Zone Routing Protocol (ZRP) framework, a hybrid routing framework suitable for a wide variety of mobile ad-hocnetworks, especially those with large network spans and diversemobility patterns. Each node proactively maintains routes within alocal region (referred to as the routing zone). Knowledge of therouting zone topology is leveraged by the ZRP to improve theefficiency of a globally reactive route query/reply mechanism. The proactive maintenance of routing zones also helps improve the qualityof discovered routes, by making them more robust to changes in networktopology. The ZRP can be configured for a particular network by properselection of a single parameter, the routing zone radius. "Ad Hoc On Demand Distance Vector (AODV) Routing", S. Das, C. Perkins, E. Royer, 03-JUL-02, The Ad hoc On-Demand Distance Vector (AODV) routing protocolis intended for use by mobile nodes in an ad hoc network. Itoffers quick adaptation to dynamic link conditions, low processingand memory overhead, low network utilization, and determinesunicast routes to destinations within the ad hoc network. It usesdestination 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 withclassical distance vector protocols. "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks", D. Johnson, Dave Maltz, Y Hu, Jorjeta Jetcheva, 22-FEB-02, The Dynamic Source Routing protocol (DSR) is a simple and efficientrouting protocol designed specifically for use in multi-hop wirelessad hoc networks of mobile nodes. DSR allows the network to becompletely self-organizing and self-configuring, without the needfor any existing network infrastructure or administration. Theprotocol is composed of the two mechanisms of 'Route Discovery'and 'Route Maintenance', which work together to allow nodes todiscover and maintain source routes to arbitrary destinations in thead hoc network. The use of source routing allows packet routingto be trivially loop-free, avoids the need for up-to-date routinginformation in the intermediate nodes through which packets areforwarded, and allows nodes forwarding or overhearing packets tocache the routing information in them for their own future use. Allaspects of the protocol operate entirely on-demand, allowing therouting packet overhead of DSR to scale automatically to only thatneeded to react to changes in the routes currently in use. Thisdocument specifies the operation of the DSR protocol for routingunicast IP packets in multi-hop wireless ad hoc networks. "Optimized Link State Routing Protocol", Philippe Jacquet, Thomas Clausen, 05-MAR-02, This document describes the Optimized Link State Routing (OLSR)protocol for mobile ad hoc networks. The protocol is an optimizationof the pure link state algorithm tailored to the requirements of amobile wireless LAN. The key concept used in the protocol is that ofmultipoint relays (MPRs) [1], [2]. "Topology Broadcast based on Reverse-Path Forwarding (TBRPF)", Mark Lewis, F. Templin, Bhargav Bellur, Richard Ogier, 07-MAR-02, TBRPF is a proactive, link-state routing protocol designed for mobilead-hoc networks, which provides hop-by-hop routing along minimum-hoppaths to each destination. Each node running TBRPF computes a sourcetree (providing paths to all reachable nodes) based on partialtopology information stored in its topology table, using amodification of Dijkstra's algorithm. "Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks", Mario Gerla, 17-JUN-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 dynamicallyelected 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 outsideits scope, a node will direct the packet to the landmark corresponding to the group ID of such destination. Once the packetapproaches 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 sizeand 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 inwhich group behavior applies and high mobility renders traditional routing schemes inefficient. "Fisheye State Routing Protocol (FSR) for Ad Hoc Networks", Mario Gerla, 24-JUN-02, The Fisheye State Routing (FSR) algorithm for ad hoc networks introduces the notion of multi-level 'scope' to reduce routing update overhead in large networks. A node stores the Link State for every destination in the network. It periodically broadcasts the Link State update of a destination to its neighbors with a frequency that depends on the hop distance to that destination (i.e., the 'scope' relative to that destination). State updates corresponding to far away destinations are propagated with lower frequency than those for close by destinations. From state updates,nodes construct the topology map of the entire network and compute efficient routes. The route on which the packet travels becomes progressively more accurate as the packet approaches its destination. FSR resembles Link State routing in that it propagatesLink State updates. However, the updates are propagated as aggregates, periodically (with period dependent on distance) insteadof being flooded individually from each source. FSR leads to major reduction in link O/H caused by routing table updates. It enhances scalability of large, mobile ad hoc networks. "The Interzone Routing Protocol (IERP) for Ad Hoc Networks", Zygmunt Haas, Marc Pearlman, Prince Samar, 05-JUL-02, This document describes the Interzone Routing Protocol (IERP), thereactive routing component of the Zone Routing Protocol (ZRP). IERP adapts existing reactive routing protocol implementations totake advantage of the known topology of each node's surrounding R-hop neighborhood (routing zone), provided by the Intrazone Routing Protocol (IARP). The availability of routing zone routes allows IERP to suppress route queries for local destinations. When a global route discovery is required, the routing zone based bordercast service can be used to efficiently guide route queries outward, rather than blindly relaying queries from neighbor toneighbor. Once a route has been discovered, IERP can use routingzones to automatically redirect data around failed links. Similarly, suboptimal route segments can be identified and trafficre-routed along shorter paths. "The Intrazone Routing Protocol (IARP) for Ad Hoc Networks", Zygmunt Haas, Marc Pearlman, Prince Samar, 05-JUL-02, This document describes the Intrazone Routing Protocol (IARP), alimited scope proactive routing protocol used to improve theperformance of existing globally reactive routing protocols. Witheach node monitoring changes in its surrounding R-hop neighborhood(routing zone), global route discoveries to local destinations can beavoided. When a global route search is needed, the IARP's routingzones can be used to efficiently guide route queries outwards (viabordercasting) rather than blindly relaying queries from neighborto neighbor. The proactive maintenance of routing zones also helpsimprove the quality of discovered routes, by making them more robustto changes in network topology. Once routes have been discovered,IARP's routing zone offers enhanced, real-time, route maintenance.Link failures can be bypassed by multiple hop paths within therouting zone. Similarly, suboptimal route segments can be identifiedand traffic re-routed along shorter paths. "The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks", Zygmunt Haas, Marc Pearlman, Prince Samar, 05-JUL-02, The Bordercast Resolution Protocol (BRP) provides the bordercastingpacket delivery service used to support network querying applications.The BRP uses a map of an extended routing zone, provided by the local proactive Intrazone Routing Protocol (IARP), to construct bordercast(multicast) trees, along which query packets are directed. Within thecontext of the hybrid ZRP, the BRP is used to guide the route requestsof the global reactive Interzone Routing Protocol (IERP). The BRPemploys special query control mechanisms to steer route requests awayfrom areas of the network that have already been covered by the query.The combination of multicasting and zone based query control makesbordercasting an efficient and tunable service that is more suitablethan flood searching for network probing applications like route discovery. MBONE Deployment (mboned) ------------------------- "Anycast RP mechanism using PIM and MSDP", Dino Farinacci, David Meyer, D. Kim, Hank Kilmer, 30-MAY-01, This document describes a mechanism to allow for an arbitrary numberof RPs per group in a single shared-tree PIM-SM domain.This memo is a product of the MBONE Deployment Working Group (MBONED)in the Operations and Management Area of the Internet EngineeringTask Force. Submit comments to or theauthors. "Source-Specific Protocol Independent Multicast in 232/8", Robert Rockell, Greg Shepherd, D Meyer, 25-FEB-02, IP Multicast group addresses in the 232/8 (232.0.0.0 to232.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 definesoperational recommendations to ensure source-specific behavior withinthe 232/8 range. "IPv4 Automatic Multicast Without Explicit Tunnels (AMT)", D. Thaler, L Vicisano, 08-APR-02, Automatic Multicast Tunneling (AMT) allows multicast communicationamongst isolated multicast-enabled sites or hosts, attached to anetwork which has no native multicast support. It also enablesthem to exchange multicast traffic with the native multicastinfrastructure (MBone) and does not require any manualconfiguration. AMT uses an encapsulation interface so that nochanges to a host stack, or applications, are required, allprotocols (not just UDP) are handled, and there is no additionaloverhead in core routers. "Multicast Source Discovery Protocol Deployment Scenarios", Mike McBride, 22-FEB-02, This document describes best current practices for intra-domain andinter-domain MSDP deployment. "IPv4 Multicast Best Current Practice", Bill Nickless, 05-MAR-02, This document describes best current practices for IPv4 multicast deployment, both within and between PIM Domains and Autonomous Systems. "IANA Guidelines for IPv4 Multicast Address Assignments", Zaid Albanna, 01-APR-02, This memo provides guidance for the IANA in assigning IPv4 multicastaddresses. "Unicast-Prefix-based IPv4 Multicast Addresses", D. Thaler, 03-JUL-02, This specification defines an extension to the multicastaddressing architecture of the IP Version 4 protocol. Theextension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicastaddresses at the same time as unicast prefixes, network operatorswill be able to identify their multicast addresses without needingto run an inter-domain allocation protocol. "Internet Multicast Gap Analysis from the MBONED Working Group for the IESG", David Meyer, Bill Nickless, 30-JUL-02, An overview of IP multicast as deployed in the Internet today, from the perspective of the MBONED working group. Existing infrastructure is examined critically. Suggestions for possible improvement of the overall architecture are presented for the IESG. Media Gateway Control (megaco) ------------------------------ "MEGACO MIB", Matt Holdrege, I Akramovich, C Brown, 14-MAY-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 protocol operating on Media Gateways and Media Gateway Controllers. The current version of this document is identical to the previous version: it has been re-submitted to re-establish its presence in the IETF archives. "Megaco/H.248 NAS Package", R. Subramaniam, J Mitchell, t Taylor, Alan Whitton, 09-APR-02, This document is intended to satisfy the requirements in section 11.2.5 of the Megaco/H.248 requirements document. It defines five packages: - the base NAS package contains properties and events supported by all NAS terminations; - the NAS Incoming package contains properties and events supported by NAS terminations involved in calls initiated by the circuit network; - the NAS Outgoing package contains properties supported by NAS terminations involved in calls outgoing to the circuit network; - the NAS Control package contains an event supported by a NAS Control termination, which allows the MG to indicate a request to initiate a data connection to a terminal served by the switched circuit network; - the NAS ROOT package contains properties supported by an MG which is also capable of supporting at least the NAS and NAS Incoming packages. "Gateway Control Protocol Version 1", Christian Groves, Marcello Pantaleo, 28-MAY-02, This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document is intended to replace RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document has undergone ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it will be published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. "The Megaco/H.248v2 Gateway Control Protocol, version 2", Marcello Pantaleo, 01-MAR-02, This document describes the second version of the general-purpose gateway control protocol standardized as Megaco in the IETF and as Recommendation H.248 in the ITU-T. "Megaco/H.248 Call flow examples", Madhubabu Brahmanapally, Prerepa Viswanadham, Krishna Gundamaraju, 20-MAR-02, This draft illustrates the usage of Megaco (version 1) protocol 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. Middlebox Communication (midcom) -------------------------------- "STUN - Simple Traversal of UDP Through Network Address Translators", J. Rosenberg, C. Huitema, R. Mahy, J. Weinberger, 27-AUG-02, Simple Traversal of UDP Through NATs (STUN) is a lightweight protocolthat allows applications to discover the presence and types ofNetwork Address Translators (NATs) and firewalls between them and thepublic Internet. It also provides the ability for applications todetermine the public IP addresses allocated to them by the NAT. STUNworks with many existing NATs, and does not require any specialbehavior from them. As a result, it allows a wide variety ofapplications to work through existing NAT infrastructure "Middlebox Communications (MIDCOM) Protocol Evaluation", M. Barnes, 04-SEP-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. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP Source-Filters", Ross Finlayson, B. Quinn, 03-JUL-02, This document describes how to adapt the Session Description Protocol(SDP) to express one or more source addresses as a source filter forone or more destination 'connection' addresses. It defines the syntaxand semantics for an SDP 'source-filter' attribute that may referenceeither IPv4 or IPv6 address(es) as either an inclusive or exclusivesource list for either multicast or unicast destinations. In particular,an inclusive source-filter can be used to specify a Source-Specific Multicast ('SSM') session.Receiver applications are expected use the SDP source-filterinformation to identify traffic from legitimate senders and discardtraffic from illegitimate senders. Applications and hosts may alsoshare the source-filter information with network elements (e.g., withrouters using IGMPv3) so they can potentially perform the trafficfiltering operation further 'upstream,' closer to the source(s). "SDP: Session Description Protocol", V. Jacobson, C. Perkins, Mark Handley, 28-MAY-02, This memo defines the Session Description Protocol (SDP). SDPis intended for describing multimedia sessions for thepurposes of session announcement, session invitation, andother forms of multimedia session initiation. "Grouping of media lines in SDP", H. Schulzrinne, Goran Eriksson, G. Camarillo, Jan Holler, 28-FEB-02, This document defines two SDP attributes: 'groupe' and 'mid'. Theyallow to group together several 'm' lines for two differentpurposes: for lip synchronization and for receiving media from asingle flow (several media streams), encoded in different formatsduring a particular session, in different ports and host interfaces. "Connection-Oriented Media Transport in SDP", David Yon, 25-JUL-02, 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", J. Ott, Carsten Bormann, Dirk Kutscher, 08-JUL-02, This document defines a language for describing multimedia sessionswith respect to configuration parameters and capabilities of endsystems. This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the workinggroup's mailing list at confctrl@isi.edu and/or the authors. "RTCP attribute in SDP", C. Huitema, 28-FEB-02, 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 SDP and RTSP", Jari Arkko, 26-JUN-02, This document defines general extensions for SDP and RTSP to carrythe security information needed by a key management protocol, inorder to secure the media. These extensions are presented as aframework, to be used by one or more key management protocols. Assuch, its use is meaningful only when it is completed by the keymanagement protocol in use.General guidelines are also given on how the framework should be usedtogether with SIP and RTSP. "SDPng Transition", C. Perkins, J. Ott, 05-JUL-02, The Session Description Protocol (SDP) is today widely used in theInternet to announce as well as negotiate multimedia sessions andexchange capabilities. Having originally been designed for sessionannouncements only, as opposed to announcements and capabilitiesnegotiation announcements, native SDP lacks numerous features to beapplicable in many session scenarios. Numerous extensions have beendeveloped to circumvent SDP's shortcomings -- but they have alsorepeatedly shown its inherent limitations. A successor protocol --termed 'SDPng' for the time being -- is developed to address theaforementioned needs of Internet applications in a more structuredmanner. With the huge installed base of SDP-based applications, amigration path needs to be developed to move from SDP to SDPng overtime. This document outlines how this migration can be achieved: ingeneral as well as for the various IETF control protocols thatpotentially make use of SDP and SDPng.This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the workinggroup's mailing list at mmusic@ietf.org and/or the authors. "Real Time Streaming Protocol (RTSP)", H. Schulzrinne, 10-JUN-02, 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-levelprotocol 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. Sourcesof data can include both live data feeds and stored clips. This pro-tocol is intended to control multiple data delivery sessions, providea means for choosing delivery channels such as UDP, multicast UDP andTCP, and provide a means for choosing delivery mechanisms based uponRTP (RFC 1889). IP Routing for Wireless/Mobile Hosts (mobileip) ----------------------------------------------- "Mobility Support in IPv6", C. Perkins, D. Johnson, Jari Arkko, 05-JUL-02, This document specifies how the IPv6 Internet operates with mobilecomputers. Without specific support for mobility in IPv6 [11],packets destined to a mobile node would not be able to reach it whilethe mobile node is away from its home link. In order to continuecommunication in spite of its movement, a mobile node could changeits IP address each time it moves to a new link, but the mobilenode would then not be able to maintain transport and higher-layerconnections when it changes location. Mobility support in IPv6 isparticularly important, as mobile computers are likely to account fora majority or at least a substantial fraction of the population ofthe Internet during the lifetime of IPv6.The protocol defined in this document, known as Mobile IPv6, allowsa mobile node to move from one link to another without changing themobile node's IP address. A mobile node is always addressable byits 'home address', an IP address assigned to the mobile node withinits home subnet prefix on its home link. Packets may be routed tothe mobile node using this address regardless of the mobile node'scurrent point of attachment to the Internet. The mobile node mayalso continue to communicate with other nodes (stationary or mobile)after moving to a new link. The movement of a mobile node away fromits home link is thus transparent to transport and higher-layerprotocols and applications. "Mobile IPv4 Regional Registration", C. Perkins, Gabriel Montenegro, P. Calhoun, 07-MAR-02, Using Mobile IP, a mobile node registers with its home agent eachtime it changes care-of address. If the distance between thevisited network and the home network of the mobile node is large,the signaling delay for these registrations may be long. We proposea new kind of 'regional' registration, i.e., registration local tothe visited domain. Regional registrations reduce the number ofsignaling messages to the home network, and reduce the signalingdelay when a mobile node moves from one foreign agent to another,within the same visited domain. "AAA Registration Keys for Mobile IP", C. Perkins, P. Calhoun, 07-MAR-02, AAA servers, such as RADIUS and DIAMETER, are in use within theInternet today to provide authentication and authorization servicesfor dial-up computers. Mobile IP requires strong authenticationbetween the mobile node and its home agent. When the mobile nodeshares a security association with its home AAA server, however, itis possible to use that security association to create derivativesecurity associations between the mobile node and its home agent,and again between the mobile node and the foreign agent currentlyoffering connectivity to the mobile node. This document specifiesextensions to the Mobile IP Registration Reply packet that can beused to create such security information at the mobile node. "Hierarchical MIPv6 mobility management (HMIPv6)", C. Castelluccia, K. Malki, H. Soliman, L. Bellier, 05-JUL-02, This draft introduces some extensions for MIPv6 and neighbourdiscovery to allow for the introduction of a hierarchical MIPv6mobility management model. The proposed hierarchical mobilitymanagement for MIPv6 will reduce the amount of signalling to CNs andthe HA and may also improve the performance of MIPv6 in terms ofhandoff speed. Moreover, HMIPv6 is well-suited to implement accesscontrol and handoffs between different access technologies. "Fast Handovers for Mobile IPv6", C. Perkins, George Tsirtsis, M Khalil, G Dommety, K. Malki, Alper Yegin, 27-MAR-02, Mobile IPv6 describes how a Mobile Node can change its point of attachment from one AR to another, a process referred to as handover. During this process, there is a time period during which the Mobile Node is unable to send or receive IPv6 packets. This time period is referred to as handover latency. "Low latency Handoffs in Mobile IPv4", K. Malki, 01-JUL-02, Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffsbetween subnets served by different Foreign Agents. In certain cases,the latency involved in these handoffs can be above the thresholdrequired 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 twomethods is described. The described techniques allow greater supportfor real-time services on a Mobile IPv4 network by minimising theperiod of time when a Mobile Node is unable to send or receive IPpackets due to the delay in the Mobile IP Registration process. "Registration Revocation in Mobile IPv4", S. Glass, M Chandra, 12-SEP-02, This document defines a Mobile IPv4 Registration Revocation mechanismwhereby either mobility agent participating in providing Mobile IPservices to the same mobile node can notify the other mobility agent(or co-located mobile node) of the termination of either a single, ormultiple mobility bindings, and for this notification to beacknowledged. Furthermore, if desired, a signaling mechanism alreadydefined by the base Mobile IP protocol [1] is leveraged as a way toinform the mobile node of the revocation of this binding. "Requirements of a QoS Solution for Mobile IP", Hemant Chaskar, 30-JUL-02, Mobile IP ensures correct routing of packets to mobile node as themobile node changes its point of attachment to the Internet.However, it is also required to provide proper QoS forwardingtreatment to mobile node's packet stream at the intermediate nodesin the network, so that QoS-sensitive IP services can be supportedover Mobile IP. This document describes requirements for an IP QoSmechanism for its satisfactory operation with Mobile IP. "The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised", Ravindra Rathi, 04-SEP-02, This memo defines the Management Information Base (MIB) for use withnetwork management protocols in TCP/IP-based internets. Inparticular, it describes managed objects used for managing the MobileNode, Foreign Agent and Home Agent of the Mobile IP Protocol.This memo is intended to update and possibly obsolete RFC 2006,however, it is designed to be backward compatible. "Localized Mobility Management Requirements", Carl Williams, 03-JUL-02, This document describes requirements for Localized MobilityManagement (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 toreduce the amount of latency in binding updates sent to the HomeAgent and, for route-optimization, Correspondent Nodes, uponCare of Address change. In addition, LMM seeks to reduce theamount of signaling over the global Internet when a mobilenode 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", C. Perkins, P. Calhoun, 22-MAY-02, Mobile IP, as originally specified, defines an authenticationextension (the Mobile-Foreign Authentication extension) bywhich a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replayprotection for the foreign agent, and does not allow for the useof existing techniques (such as CHAP) for authenticating portablecomputer devices. In this specification, we define extensions forthe Mobile IP Agent Advertisements and the Registration Requestthat allow a foreign agent to use a challenge/response mechanism toauthenticate the mobile node. "Mobile IP NAT/NAPT Traversal using UDP Tunnelling", S. Vaarala, H. Levkowetz, 25-JUL-02, Mobile IP's datagram tunnelling is incompatible with Network AddressTranslation (NAT). This document presents extensions to the MobileIP protocol and a tunnelling method which permits mobile nodes usingMobile IP to operate in private address networks which are separatedfrom the public internet by NAT devices. The NAT traversal is basedon using the Mobile IP Home Agent UDP port for encapsulated datatraffic. "Nonfinal Mobility Header for Mobile IPv6", F. Dupont, C. Perkins, 15-APR-02, This document specifies operations to allow inclusion of data alongwith a mobility header (from Mobile IPv6) containing a Binding Updateor Binding Acknowledgement message. In this way, smoother handoversand reduced jitter and bandwidth utilization can be achieved.Interactions with IPsec-based verification of mobility messages aredescribed; basically, establishment of such IPsec-based methodspreclude the use of the mobility header specified in this document,unless simple modifications to IPsec (outside the scope of thisdocument) can be utilized. "AAA NAI for Mobile IPv4 Extension", Fredrik Johansson, T. Johansson, 30-MAY-02, When a mobile node moves between two foreign networks it has to bereauthenticated. If the home network has multiple AAA servers thereauthentication request may not be received by the same AAAH asprevious authentication requests.In order for the new AAAH to be able to forward the request to thecorrect HA it has to know the identity of the HA. This documentdefines an extension that enables the HA to pass its identity to themobile node which can in turn pass it to the AAA server when changingpoint of attachment. This document specifies a NAI extension thatcan carry these NAIs. "Problem Statement and Requirements for Mobile IPv4 Traversal Across IPsec-based VPN Gateways", Alpesh Patel, 27-AUG-02, Mobile IP [1] agents are being deployed in enterprise networks, to enable mobile users with network mobility across wired and wireless LANs while roaming inside the enterprise firewall. With the growing deployment of multi-subnetted IEEE 802.11 networks (referred as hot spots) in public places such as hotels, airports, and convention centers, and wireless WAN data networks such as GPRS, the need for enabling mobile users to maintain their transport connections and constant reachability while connecting back to their target 'home' networks protected by Virtual Private Network (VPN) technology is increasing. This implies that Mobile IP and VPN technologies have to coexist and co-function in order to provide mobility and security to the enterprise mobile users. The goal of this draft is threefold. The first is to describe possible deployment scenarios for Mobile IP and VPN in enterprise and operator environments. The second is to identify example usage scenarios for enterprise users roaming outside the 'home' network (e.g., corporate Intranet), and articulate the problems resulting from Mobile IP and VPN coexistence. The third is to specify a set of framework requirements to evaluate proposed solutions, supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN Gateways. Hereafter, a 'VPN' term in this draft refers to an IPsec-based VPN Gateway. Multiprotocol Label Switching (mpls) ------------------------------------ "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", Joan Cucchiara, James Luciani, Hans Sjostrand, 20-AUG-01, 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 MultiprotocolLabel Switching, Label Distribution Protocol (LDP). "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base", A Viswanathan, C Srinivasan, Thomas Nadeau, 07-JAN-02, This memo defines a portion of the Management InformationBase (MIB) for use with network management protocols inthe Internet community. In particular, it describesmanaged objects for Multiprotocol Label Switching (MPLS)based traffic engineering. "Multiprotocol Label Switching (MPLS) Label Switch Router (LSR)Management Information Base", A Viswanathan, C Srinivasan, Thomas Nadeau, 07-JAN-02, This memo defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internetcommunity. In particular, it describes managed objects formodeling a Multiprotocol Label Switching (MPLS) Label SwitchRouter (LSR). "Improving Topology Data Base Accuracy with LSP Feedback in CR-LDP", Bilel Jamoussi, Don Fedyk, E Mannie, D Skalecki, 04-JUN-02, 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", Y. Rekhter, K. Kompella, 11-SEP-02, To improve scalability of Generalized Multi-Protocol Label Switching(GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) bycreating a hierarchy of such LSPs. A way to create such a hierarchyis by (a) a Label Switching Router (LSR) creating a TrafficEngineering Label Switched Path (TE LSP), (b) the LSR forming aforwarding adjacency (FA) out of that LSP (by advertising this LSP asa Traffic Engineering (TE) link into the same instance of ISIS/OSPFas the one that was used to create the LSP), (c) allowing other LSRsto use FAs for their path computation, and (d) nesting of LSPsoriginated by other LSRs into that LSP (by using the label stackconstruct).This document describes the mechanisms to accomplish this. "Framework for MPLS-based Recovery", Fiffi Hellstrand, Vishal Sharma, 12-SEP-02, Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling, support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", A Viswanathan, C Srinivasan, Thomas Nadeau, 07-JAN-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 defining ForwardingEquivalent Class (FEC) to Next Hop Label Forwarding Entry (NHLFE)mappings and corresponding actions for use with Multiprotocol LabelSwitching (MPLS). "Fault Tolerance for the Label Distribution Protocol (LDP)", P. Brittain, A. Farrel, 30-JUL-02, MPLS systems will be used in core networks where systemdowntime must be kept to an absolute minimum. Many MPLSLSRs may, therefore, exploit Fault Tolerant (FT) hardwareor software to provide high availability of the corenetworks.The details of how FT is achieved for the variouscomponents of an FT LSR, including LDP, CR-LDP, theswitching hardware and TCP, are implementation specific.This document identifies issues in the CR-LDPspecification [2] and the LDP specification [4] that makeit difficult to implement an FT LSR using the current LDPand CR-LDP protocols, and proposes enhancements to theLDP specification to ease such FT LSR implementations.The extensions described here are equally applicable toCR-LDP. "Multi Protocol Label Switching Label Distribution Protocol Query Message Description", E Mannie, Antonela Paraschiv, 07-MAY-02, This document describes the encoding and procedures for three newLabel Distribution Protocol (LDP) messages: Query Message, Query-Reply Message and Partial Query-Reply Message (the last one is almostidentical to the Query-Reply message; therefore all references to theQuery-Reply messages imply the Partial Query-Reply messages as well,unless otherwise specified). A Lable Edge Router (LER) sends a Querymessage when it needs to find out information about a Label SwitchedPath (LSP). The Query message is sent for an established LSP. TheQuery message can be used for LDP LSPs as well as for Constraint-Based Label Switched Paths (CR-LSPs). The queried data is encodedinto the Query-Reply messages. "Signalling Unnumbered Links in CR-LDP", Alan Kullberg, Y. Rekhter, K. Kompella, 24-JUL-02, Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) doesn't provide support for unnumbered links.This document defines procedures and extensions to Constraint-RoutingLabel Distribution Protocol (CR-LDP), one of the MPLS TE signallingprotocols, that are needed in order to support unnumbered links. "Signalling Unnumbered Links in RSVP-TE", Y. Rekhter, K. Kompella, 24-JUL-02, Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) doesn't provide support for unnumbered links.This document defines procedures and extensions to Extensions to RSVPfor Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TEsignalling protocols, that are needed in order to support unnumberedlinks. "Definitions of Textual Conventions and OBJECT-IDENTITIES for Multi-Protocol Label Switching (MPLS)Management", Thomas Nadeau, 07-JAN-02, This memo describes Textual Conventions and OBJECT-IDENTITIES common to the Management Information Bases(MIBs) for managing Multiprotocol Label Switching (MPLS)networks. "Link Bundling in MPLS Traffic Engineering", Lou Berger, Y. Rekhter, K. Kompella, 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 resourceused by a Label Switched Path (LSP). Such cases are handled by usingthe link bundling construct which is described in this document. "Link Bundling Management Information Base", Martin Dubuc, 02-JUL-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 modeling link bun-dling as described in the Link Bundling in MPLS Traffic EngineeringInternet Draft. "Multiprotocol Label Switching (MPLS) Management Overview", C Srinivasan, A. Farrel, Thomas Nadeau, 11-JUN-02, An assortment of management Information Bases (MIBs) hasbeen developed to help model and manage the various aspectsof Multiprotocol Label Switching (MPLS) networks. TheseMIBs are defined in separate drafts and RFCs that focus onthe specific areas of responsibility of their MIBs.This memo describes the management architecture for MPLSand indicates the inter-relationships between the differentMIBs used for MPLS network management. "Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032)", B Akyol, Puneet Agarwal, 20-JUN-02, This document describes TTL processing in hierarchical MPLS networks. It updates rfc-3032 'MPLS Label Stack Encoding'. TTL processing in both pipe and uniform model hierarchical tunnels are specified with examples for both 'push' and 'pop' cases. The document also complements rfc-3270 'MPLS Support of Differentiated Services' and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. "Graceful Restart Mechanism for LDP", Y. Rekhter, M. Leelanivas, R. Aggarwal, 11-SEP-02, This document describes a mechanism that helps to minimize thenegative effects on MPLS traffic caused by Label Switching Router's(LSR's) control plane restart, and specifically by the restart of itsLabel Distribution Protocol (LDP) component, on LSRs that are capableof preserving the MPLS forwarding component across the restart.The mechanism described in this document is applicable to all LSRs,both those with the ability to preserve forwarding state during LDPrestart and those without (although the latter need to implement onlya subset of the mechanism described in this document). Supporting (asubset of) the mechanism described here by the LSRs that can notpreserve their MPLS forwarding state across the restart would notreduce the negative impact on MPLS traffic caused by their controlplane restart, but it would minimize the impact if their neighbor(s)are capable of preserving the forwarding state across the restart oftheir control plane and implement the mechanism described here.The mechanism makes minimalistic assumptions on what has to bepreserved across restart - the mechanism assumes that only the actualMPLS forwarding state has to be preserved; the mechanism does notrequire any of the LDP-related state to be preserved across therestart.The procedures described in this document apply to downstreamunsolicited label distribution. Extending these procedures todownstream on demand label distribution is for further study. "Graceful Restart Mechanism for BGP with MPLS", Y. Rekhter, R. Aggarwal, 13-FEB-02, [1] describes a mechanism for BGP that would help minimize thenegative effects on routing caused by BGP restart. This documentextends this mechanism to also minimize the negative effects on MPLSforwarding when BGP is used to carry MPLS labels [2]. The mechanismdescribed in this document is agnostic with respect to the types ofthe addresses carried in the BGP NLRI. As such it works inconjunction with any of the address famililies that could be carriedin BGP (e.g., IPv4, IPv6, etc...) "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Ping Pan, 26-FEB-02, This document describes the use of RSVP [RSVP, RSVP-TE] to establishbackup LSP tunnels for local repair of LSP tunnels. "Detecting Data Plane Liveliness in MPLS", K. Kompella, 27-MAR-02, This document describes a simple and efficient mechanism that can beused to detect data plane failures in MPLS LSPs. There are two parts tothis document: information carried in an MPLS 'echo request' and 'echoreply' for the purposes of fault detection and isolation; and mechanismsfor transporting the echo reply. "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, 01-JUL-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", K. Kompella, Benjamin Black, 01-JUL-02, Proper functioning of RFC 1191 path MTU detection requires that IProuters have knowledge of the MTU for each link to which they areconnected. As currently specified, LDP does not have the ability tosignal the MTU for an LSP to ingress LSRs. In the absence of thisfunctionality, the MTU for each LSP must be statically configured bynetwork operators or by equivalent, off-line mechanisms.This document specifies extensions to the LDP label distributionprotocol in support of LSP MTU signalling. Multicast Security (msec) ------------------------- "The Group Domain of Interpretation", M Baugher, 28-JUN-02, This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The 'GDOI' incorporates the definition of a Phase 1 SA of the Internet DOI, and proposes new payloads and exchanges according to the ISAKMP standard. 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.Comments on this document should be sent to msec@securemulticast.org. "Group Key Management Architecture", M Baugher, 01-MAR-02, 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. "GSAKMP Light", H. Harney, A. Colegrove, A Schuett, 30-JUL-02, A protocol specification must balance two often conflicting goals:to produce as general a protocol as possible, and to produce asimple protocol. The Group Secure Association Key ManagementProtocol (GSAKMP) is a general protocol for creating and managingcryptographic groups on a network. This document describesthe GSAKMP-Light (GL) profile, a way to shorten the number ofmessages exchanged during secure group establishment. The GSAKMPprotocol assumed that group members joining a secure group hadno information about the specific security mechanisms used by thegroup (for example, the key length, encryption protocol, etc).GSAKMP-Light provides a profile for the case where group membershave been previously notified of these security mechanisms, usedfor joining a group, during the group announcement or invitation.This simplification removes 2 messages from the group establishmentportion of the GSAKMP protocol, eliminates the need for initiatinga unicast security association, and removes the need for manyof the optional fields of individual messages. The profiledoes not sacrifice any of the security properties of the fullprotocol. To facilitate the transmission of security mechanismsettings during session invitation or announcement, this documentalso describes a useful default set of security algorithms andconfigurations, Security Suite 1. Full specification of this suiteallows an entire set of algorithms and settings to be describedto prospective group members in a concise manner. Future securitysuites can be defined as needed. "MIKEY: Multimedia Internet KEYing", Jari Arkko, 29-AUG-02, Security protocols for real-time multimedia applications have startedto appear. This has brought forward the need for a key managementsolution to support these protocols. Such a solution has to besuitable to be used in the context of conversational multimedia in aheterogeneous environment.This document describes a key management scheme that can be used forreal-time applications (both for peer-to-peer communication and groupcommunication), and shows how it may work together with protocolssuch as SIP and RTSP. In particular, its use to support the SecureReal-time Transport Protocol, [SRTP], is described in detail. "HMAC-authenticated Diffie-Hellman for MIKEY", Martin Euchner, 30-AUG-02, 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 (DH-HMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. Message Tracking Protocol (msgtrk) ---------------------------------- "Message Tracking Model and Requirements", Tony Hansen, 04-APR-02, Customers buying enterprise message systems often ask: Can I trackthe messages? Message tracking is the ability to find out the path thata particular message has taken through a messaging system and thecurrent routing status of that message. This document provides a modelof message tracking that can be used for understanding the Internet-widemessage infrastructure and to further enhance those capabilities toinclude message tracking, as well as requirements for proposed messagetracking solutions. "SMTP Service Extension for Message Tracking", Tony Hansen, Eric Allman, 05-JUN-02, The Message Tracking Models and Requirements document [RFC-TRACK-MODEL] discusses the models that message tracking solutions could fol-low, along with requirements for a message tracking solution that can beused with the Internet-wide message infrastructure. This memo definesan extension to the SMTP service that provides a message tracking solu-tion that satisfies those requirements. Using the model document's ter-minology, it uses active enabling and active requests with requestreferrals. "Message Tracking Query Protocol", Tony Hansen, 20-MAY-02, Customers buying enterprise message systems often ask: Can I trackthe messages? Message tracking is the ability to find out the path thata particular message has taken through a messaging system and thecurrent routing status of that message. This document describes theMessage 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", Tony Hansen, Eric Allman, 05-JUN-01, This memo defines an extension to the SMTP service whereby aclient may mark a message for future tracking. "The Message/Tracking-Status MIME Extension", Eric Allman, 05-JUN-01, Message Tracking is expected to be used to determine thestatus of undelivered e-mail upon request. Tracking is used inconjunction with Delivery Status Notifications [RFC-DSN-SMTP] andMessage Disposition Notifications [RFC-MDN]; generally, a messagetracking request will be issued only when a DSN or MDN has not beenreceived within a reasonable timeout period.This memo defines a MIME [RFC-MIME] content-type for messagetracking status in the same spirit as RFC 1894, 'An ExtensibleMessage Format for Delivery Status Notifications' [RFC-DSN-STAT].It is to be issued upon a request as described in 'MessageTracking Query Protocol' [DRAFT-MTRK-MTQP]. This memo definesonly the format of the status information. An extension to SMTP[RFC-ESMTP] to label messages for further tracking and requesttracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. Site Multihoming in IPv6 (multi6) --------------------------------- "Requirements for IPv6 Site- Multihoming Architectures", Benjamin Black, Vijay Gill, Joe Abley, 11-JUN-02, Site-multihoming, i.e. connecting to more than one IP serviceprovider, is an essential component of service for many sites whichare part of the Internet. Existing IPv4 site-multihoming practices,described in a companion draft [1], provides a set of capabilitiesthat must be accommodated by the adopted site-multihomingarchitecture in IPv6, and a set of limitations that must be overcome,relating in particular to scalability. Network File System Version 4 (nfsv4) ------------------------------------- "NFS version 4 Protocol", Spencer Shepler, 09-SEP-02, NFS version 4 is a distributed file system protocol which owesheritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813].Unlike earlier versions, the NFS version 4 protocol supportstraditional file access while integrating support for file lockingand the mount protocol. In addition, support for strong security(and its negotiation), compound operations, client caching, andinternationalization have been added. Of course, attention has beenapplied to making NFS version 4 operate well in an Internetenvironment. Next Generation Transition (ngtrans) ------------------------------------ "An overview of the Introduction of IPv6 in the Internet", Wim Biemolt, 04-MAR-02, This document is a guide to the introduction of IPv6 in the IPv4 based Internet or Intranets. Several general issues to start IPv6 networking in a predominantly IPv4 world are discussed, such as IPv6addresses, IPv6 DNS and routing issues. Short descriptions are givenof the different translation and migration tools and mechanisms thattranslate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The remainder of this document describes how IPv6 can be introduced in various environments, such as ISPs, Internet Exchanges and end user environments. Suggestions are given on the use of the different translation and migration tools in each environment. "Dual Stack Transition Mechanism (DSTM)", J. Bound, 05-JUL-02, During the initial deployment of IPv6, hosts in native IPv6 networkswill need to maintain connectivity with hosts and/or applications whocan only be reached through IPv4. The Dual Stack Transition Mechanism(DSTM) provides a method to assure this connectivity based on the useof IPv4-over-IPv6 tunnels and the temporal allocation of a globalIPv4 address to hosts requiring such communication. This documentdefines the processes and architecture required for this transitionmechanism. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", Philip Nesser II, 28-MAR-02, This document seeks to document all usage of IPv4 addresses in currentlydeployed IETF documented standards. In order to successfully transitionfrom 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. "Connecting IPv6 Domains across IPv4 Clouds with BGP", Tri Nguyen, Gerard Gastaud, F Le Faucheur, D. Ooms, Jeremy De Clercq, Stuart Prevost, 14-JAN-02, This document explains how to interconnect IPv6 islands over an IPv4cloud, including the exchange of IPv6 reachability information usingBGP. Two approaches will be explained, both requiring a Dual StackMP-BGP-speaking edge router per IPv6 island. The hosts in the IPv6islands can use native IPv6 addresses. "Support for Multicast over 6to4 Networks", D. Thaler, 03-JUL-02, 6to4 Tunneling allows isolated IPv6 domains or hosts, attached toan IPv4 network which has no native IPv6 support, to communicatewith other such IPv6 domains or hosts with minimal manualconfiguration. This document defines support for IPv6 Multicastover 6to4 networks. "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", D. Thaler, Tim Gleeson, Mohit Talwar, F. Templin, 19-APR-02, This document specifies the Intra-Site Automatic Tunnel AddressingProtocol (ISATAP) that connects IPv6 hosts and routers (nodes) withinIPv4 sites. ISATAP is a transition mechanism that enables incrementaldeployment of IPv6 by treating the site's IPv4 infrastructure as aNon-Broadcast Multiple Access (NBMA) link layer for IPv6. ISATAPmechanisms use an IPv6 interface identifier format that embeds anIPv4 address - this enables automatic IPv6-in-IPv4 tunneling within asite, whether the site uses globally assigned or private IPv4addresses. The new interface identifier format can be used with bothlocal and global unicast IPv6 prefixes - this enables IPv6 routingboth locally and globally. ISATAP mechanisms introduce no impact onrouting table size and require no special IPv4 services (e.g., IPv4multicast). "SMTP operational experience in mixed IPv4/IPv6 environements", Motonori Nakamura, Jun-Ichiro itojun Hagino, 02-JUL-02, This document lists operational requirements for IPv6 SMTP andIPv6-capable MX DNS records. As IPv6 SMTP servers are deployed, it hasbecome apparent that certain configurations are necessary inIPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTPoperation. This document clarifies the problems that exist in thetransition period between IPv4 SMTP and IPv6 SMTP. It also definesoperational requirements for stable IPv4/v6 SMTP operation. "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)", Kazuaki Tsuchiya, Hidemitsu Higuchi, Sunao Sawada, Shinji Nozaki, 28-JUN-02, In the stage of the transition from IPv4 to IPv6 it is necessarythat IPv4 nodes and IPv6 nodes can communicate directly. This memoproposes a mechanism which enables such direct communication formulticast, in addition to that for unicast defined in [SIIT] and[NAT-PT]. "Moving in a Dual Stack Internet", Shiao Tsao, 01-MAR-02, This document provides an analysis of the requirements to support mobility in a dual stack network. In this document, combinations of IPv4, IPv6, and dual stack mobile node moving in IPv4, IPv6, anddual stack networks are listed and the requirements to support mobility under different network and mobile node configurations areinvestigated. This document aims to reassess next generation transition (NGTRANS) tools from the point of view of mobility. "Dual Stack Hosts using 'Bump-in-the-API' (BIA)", Seungyun Lee, 29-APR-02, This document specifies a mechanism of dual stack hosts using atechnique called 'Bump-in-the-API'(BIA) which allows for the hosts tocommunicate with other IPv6 hosts using existing IPv4 applications. Thegoal of this mechanism is the same as that of the Bump-in-the-stackmechanism [BIS], but this mechanism provides the translation methodbetween the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achievedwithout IP header translation. "NGtrans IPv6 DNS operational requirements and roadmap", Alain Durand, Johan Ihren, 06-MAR-02, This document describes IPv6 DNS operational requirements anddeployment roadmap. It is the result of discussion from members ofthe IPv6, NGtrans, DNSops and DNSext working groups. The DNS islooked as a critical part of the Internet infrastructure and is usedfor much more purposes than name to address resolution. Thus asmooth operation of the DNS is critical in the IPv6 transition. "Teredo: Tunneling IPv6 over UDP through NATs", C. Huitema, 14-AUG-02, We propose here a service that enables nodes located behind one orseveral IPv4 NATs to obtain IPv6 connectivity by tunneling packetsover UDP; we call this the Teredo service. Running the servicerequires the help of 'Teredo servers' and 'Teredo relays'; theTeredo servers are stateless, and only have to manage a smallfraction of the traffic between Teredo clients; the Teredo relaysact as IPv6 routers between the Teredo service and the 'native' IPv6Internet. "Interaction of transition mechanisms", A Baudot, 02-JUL-02, This document discusses the interaction of transition mechanisms that can be involved during the transition phase where both IPv4 and IPv6 will be concurrently used. On one hand, several transition mechanisms have been defined to solve particular transition issues. On the other hand, one can face multiple transition issues and may have to use several transition mechanisms. Since an applicability scope is attached to each transition mechanism, specifying where the mechanism applies, i.e. host, domain or global, this memo aims at identifying cases where multiple transition mechanisms may be involved within the same scope, and what the interaction effects among them can be. "MIME TYPE definition for tunnels", J Paugh, Alain Durand, 26-FEB-02, Tunnels are very common in the Internet. They are often used todeploy new technologies such as multicast or IPv6 when the underlyinginfrastructure is not ready to natively support those new protocols.Virtual Private Network are also often build using IP in IP tunnels.This document describe a MIME type that provide configurationinformation for tunnels. "Dual Stack Transition Mechanism (DSTM) Overview", J. Bound, 19-JUN-02, The initial deployment of IPv6 will require a tightly coupled use ofIPv4 addresses to support the interoperation of IPv6 and IPv4 withinan IPv6-only Network. Nodes will still need to communicate with IPv4nodes that do not have a dual IP layer supporting both IPv4 and IPv6.The Dual Stack Transition Mechanism (DSTM) is based on the use ofIPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-onlynetwork and provides a method to allocate a temporary IPv4 Address toIPv6/IPv4 nodes. DSTM is also a way to avoid the use of NetworkAddress Translation for early adopter IPv6 deployment. "ISATAP Transition Scenario for Enterprise/Managed Networks", Tim Gleeson, F. Templin, 26-JUN-02, This document discusses application of the Intra-Site AutomaticTunnel Addressing Protocol (ISATAP) as a transition tool forenterprise/managed networks. The enterprise/manged network problemspace is described, and the ISATAP transition scenario forenterprise/managed network environments is presented. "Unmanaged Networks Transition Scope", C. Huitema, 12-SEP-02, In order to evaluate the suitability of transition mechanisms, weneed to define the environment or scope in which these mechanismshave to be used. One specific scope is the "Transition Mechanisms for IPv6 Hosts and Routers", R. Gilligan, Erik Nordmark, 24-JUL-02, This document specifies IPv4 compatibility mechanisms that can beimplemented by IPv6 hosts and routers. These mechanisms includeproviding complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4routing infrastructures. They are designed to allow IPv6 nodes tomaintain complete compatibility with IPv4, which should greatlysimplify the deployment of IPv6 in the Internet, and facilitate theeventual transition of the entire Internet to IPv6. NNTP Extensions (nntpext) ------------------------- "Network News Transport Protocol", Stan Barber, 08-JAN-02, The Network News Transport Protocol has been in use in the Internet for a decade and remains one of the most popular protocols (by volume) in use today. This memo 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. 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, 03-JUL-02, 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 atthe time of publication. Individual Submissions (none) ----------------------------- "Wrapping MIME Objects: Application/MIME", Dave Crocker, 25-JUN-02, MIME is a general-purpose mechanism for labeling andaggregating objects into complex hierarchies. Some MIMEobjects are discrete objects. If placed within another MIMEhierarchy, they need to appear as a leaf node in thecontaining hierarchy, rather than seeming to be continuationsof that hierarchy. This specification defines Content-typeApplication/MIME to provide an encapsulation mechanism forarbitrary MIME structures. This facilitates their treatmentas a single unit, rather than causing them to be treated aspart of any containing MIME hierarchy. "Printer MIB v2", R. Bergman, I. McDonald, 06-AUG-02, This document provides definitions of models and manageable objectsfor printing environments. The objects included in this MIB apply tophysical, as well as logical entities within a printing device. Thisdocument obsoletes RFC 1759. "Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson, Martin Carpenter, Volker Wiegand, 02-APR-02, This document describes a mechanism that can be used by FTP clientsand servers to implement security and authentication using the TLSprotocol defined by [RFC-2246] and the extensions to the FTP protocoldefined by [RFC-2228]. It describes the subset of the extensionsthat are required and the parameters to be used; discusses some ofthe policy issues that clients and servers will need to take;considers some of the implications of those policies and discussessome expected behaviours of implementations to allow interoperation.This document is intended to provide TLS support for FTP in a similarway to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817]. "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. "DHCP Options for Locating LDAP Servers", L. Howard, Leif Hedstrom, Dieter Siegmund, 08-MAY-02, This document defines a new DHCP option for delivering configurationinformation to LDAP (Lightweight Directory Access Protocol) clients.The information returned is represented as LDAP URLs, as specified inthe LDAPv3 URL draft[1].The DHCP client may use the URLs returned by the DHCP server tolocate an LDAP server for the client's network. The URL may includethe TCP port of the LDAP server, and the distinguished name whichidentifies the base object for searching. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", M. Crispin, 10-JUN-02, The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)allows a client to access and manipulate electronic mail messages ona server. IMAP4rev1 permits manipulation of mailboxes (remotemessage folders) in a way that is functionally equivalent to localfolders. IMAP4rev1 also provides the capability for an offlineclient to resynchronize with the server (see also [IMAP-DISC]).IMAP4rev1 includes operations for creating, deleting, and renamingmailboxes; checking for new messages; permanently removing messages;setting and clearing flags; [RFC-2822] and [MIME-IMB] parsing;searching; and selective fetching of message attributes, texts, andportions thereof. Messages in IMAP4rev1 are accessed by the use ofnumbers. These numbers are either message sequence numbers or uniqueidentifiers.IMAP4rev1 supports a single server. A mechanism for accessingconfiguration information to support multiple IMAP4rev1 servers isdiscussed in [ACAP].IMAP4rev1 does not specify a means of posting mail; this function ishandled by a mail transfer protocol such as [SMTP]. "Handle System Overview", Larry Lannom, Sam Sun, 02-JUL-02, 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. "LDAP Proxied Authentication Control", Rob Weltman, 03-MAY-02, This document defines the Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control. The Proxied Authorization Control allows a client to request that an operation be processed under a provided authorization identity [AUTH] instead of as the current authorization identity associated with the connection. "Common Internet Message Header Fields", J. Palme, 06-SEP-02, This memo contains tables of commonly occurring headerfields in headings of e-mail messages. The documentcompiles information from other RFCs such as RFC 822, RFC1036, RFC 1123, RFC 2156, RFC 1496, RFC 1766, RFC 2183, RFC1864, RFC 2421 and RFC 2045. A few commonly occurringheader fields which are not defined in RFCs are alsoincluded. For each header field, the memo gives a shortdescription and a reference to the RFC in which the headerfield is defined.The latest, revised version of this document can be foundat URLhttp://www.dsv.su.se/jpalme/ietf/mail-headers/. The versionat thatURL may be more recent than the version published as anRFC.Another list of headers can be found at URLhttp://www.cs.tut.fi/~jkorpela/headers.html [28] "Printer Finishing MIB", R. Bergman, H. Lewis, 06-AUG-02, This document defines a printer industry standard SNMP MIB for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB does not apply to a Finisher Device that is not connected to a Printer System. "The 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 ofthe Synchronized Multimedia Integration Language (SMIL 1.0 and SMIL2.0). SMIL allows ntegrating a set of independent multimedia objectsinto a synchronized multimedia presentation. "MDN profile for IMAP", Alexey Melnikov, 12-APR-02, Message Disposition Notification [MDN], also known as'acknowledgements' or 'receipt notifications' is one of the widelyused features of X.400 and the proprietary 'LAN-based' messagingsystems. [MDN] defines how this functionality may be supported byInternet Mail, however it doesn't describe how multiple Mail UserAgents (MUAs) may use MDN together with the Internet Message AccessProtocol [IMAP4].This document describes the Best Current Practice of using MDN with IMAP4] and should be considered as guidelines for implementers ofthe Internet Message Access Protocol [IMAP4] that want to add MDNsupport to their products. "Documenting Special Use IPv4 Address Blocks", Bill Manning, 28-MAY-02, This document lists most of the existent special use prefixes from the IPv4 space that have been registered with the IANA and now RIRs and provides some suggestions for operational procedures when these prefixes are encountered. This document does not address IPv4 space that is not registered with the IANA/RIRs for special use or address space that is reserved for future delegation in the operational Internet. Notice is given to prefixes that manufacturers have co-opted. "Per Hop Behaviors Based on Dynamic Packet States", F. Baker, Hui Zhang, Y Bernet, Ion Stoica, 08-JAN-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, distributedalgorithms can be devised to implement services with flexibility,utilization, and assurance levels similar to those that can be provided with per flow mechanisms. "SNMP over TCP Transport Mapping", J. Schoenwaelder, 23-MAY-02, This memo defines a transport mapping for using the Simple NetworkManagement Protocol (SNMP) over TCP. The transport mapping can beused with any version of SNMP. This document extends the transportmappings defined in RFC 1906 "The VND Tree for URL Scheme Names", Ian King, 24-JUL-00, This document describes the vnd scheme namespace, or 'tree,' whichprovides for vendor-specific URL scheme namespaces with relaxedregistration requirements, which can be used with no concern forname collision. The namespace also implicitly providesidentification of the originator of the URL scheme, in the eventothers become interested in the scheme. "Support for Language Translation in E-Mail and Netnews", J. Palme, 28-MAY-02, This memo specifies extensions to e-mail and netnewsstandards, to allow for the submission of translations ofmessages, not only at initial submission time, but also atlater time, and made by other translators than the originalauthor of the message. Three new e-mail/netnews headerfields are proposed, 'Content-Translation-Of', 'Content-Translator' and 'Translation-Request'. "Geographic registration of HTML documents", A. Daviel, Felix Kaegi, 25-APR-01, This memo describes a method of registering HTML documents with aspecific geographic location through means of embedded META tags. Thecontent of the META tags gives the geographic position of theresource described by the HTML document in terms of Longitude,Latitude and optionally Elevation in a simple, machine-readablemanner. This information may be used for automated resource discoveryby means of an HTML indexing agent or search engine. "IETF Meeting Network Infrastructure Lore", N Bourbaki, 13-JUN-02, Creating and running the 'terminal room' for an IETF meeting istantamount to building, running, and dismantling a small computercenter. Although this is a well-known area of operations, the uniqueenvironment and its ephemeral nature warrant passing on the lore in amildly organized fashion. It is expected that this document will beupdated regularly. However, it is not clear that this will ever bepublished as an RFC.As the IETF can ill afford failure of this service, it is assumedthat the host and organizers have the experience and resources tobuild such environments, understand power facilities, cabling, WANand LAN building, workstation provisioning, staffing, etc. So thisdocument does not attempt to detail how to build computer facilitiesor carry out prudent project management. Rather it concentrates onthe unique aspects of the IETF 'terminal room'. "Handle System Namespace and Service Definition", Larry Lannom, Sam Sun, Sean Reilly, 02-JUL-02, 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 a detailed description of the Handle System namespace, data and service model, as well as its operation and authentication protocol. It assumes that readers are familiar with the basic concepts of the Handle System as introduced in the overview document. "IP over MIME", Donald Eastlake 3rd, 29-JAN-02, The MIME encoding of IP packets is standardized so they canconveniently be sent via MAIL, HTTP, etc. This may be convenient fortransmitting packets for analysis or for creating application leveltunnels. "LDAP Authorization Identity Bind Control", M. Smith, M. Wahl, Rob Weltman, 03-MAY-02, This document defines a way for an LDAP [LDAPv3] server to return the identity assumed by a client on binding using the LDAP Control mechanism . "Secure Remote Password SASL Mechanism", Keith Burdis, Raif Naffah, 12-AUG-02, This document describes a SASL mechanism based on the Secure RemotePassword protocol. This mechanism performs mutual authenticationand can provide a security layer with replay detection, integrityprotection and/or confidentiality protection. "IP Multicast in Differentiated Services Networks", Roland Bless, Klaus Wehrle, 05-JUL-02, This document presents some of the problems which will arise when IPMulticast is used in DiffServ networks without taking specialprecautions into account for supplying multicast services. Althoughthe basic DS forwarding mechanisms also work with IP Multicast, somefacts have to be considered which are related to the provisioning ofmulticast resources. The presented problems mainly lead tosituations in which other service users are affected adversely intheir experienced quality. In order to retain the benefits of theDiffServ approach, a quite simple and scalable solution for thoseproblems is required, not resulting in additional complexity orcosts related to forwarding mechanisms in a DiffServ domain "SKiCal - an extension of iCalendar", Greg FitzPatrick, Niclas Hjelm, Par Lannero, 14-JAN-02, This Memo defines the SKiCal format.SKiCal is a machine-readable format for the interchange of enhancedyellow-page directory listings. SkiCal expands the traditionalproperty-set of name, address, telephone number and businesscategory, adding structured information about people, places,things, activities and the conditions and terms for interaction withresources. "LDAP Bulk Update/Replication Protocol", J. Sermersheim, Rod Harrison, Yulin Dong, 06-MAR-01, The LDAP Bulk Update/Replication Protocol (LBURP) described in thisdocument allows an LDAP client (a genuine client or an LDAP serveracting as a client) to perform a bulk update to a replica on an LDAPserver. The protocol groups a set of update operations using theLDAP framed protocol requests defined in [FRAMING] to notify theclient that the update operations in the framed set are related.The update operations within the framed set are LDAPv3 extendedoperations each encapsulating a sequence number and one or moreLDAPv3 update operations. The sequence number allows the server toprocess the update operations in the proper order even when they aresent asynchronously by the client, and the update operations can begrouped within the extended request to maximize the efficiency ofclient-server communication.The protocol may be used to initialize all of the entries in an LDAPreplica or to incrementally update the existing entries in an LDAPreplica. It is suitable for client utilities that need toefficiently initialize a replica with many entries or efficientlymake a substantial set of update changes to a replica. It is alsosuitable as a protocol for replication between a single masterreplica and its slave replicas. "The Microsoft Windows 2000 RC4-HMAC Kerberos encryption type", John Brezak, Michael Swift, 02-MAY-02, The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES based encryption types. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong crypto (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. The Microsoft Windows 2000 implementation of Kerberos contains new encryption and checksum types for two reasons: for export reasons early in the development process, 56 bit DES encryption could not be exported, and because upon upgrade from Windows NT 4.0 to Windows 2000, accounts will not have the appropriate DES keying material to do the standard DES encryption. Furthermore, 3DES is not available for export, and there was a desire to use a single flavor of encryption in the product for both US and international products. As a result, there are two new encryption types and one new checksum type introduced in Microsoft Windows 2000. "Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network", Y Xu, 17-MAY-01, This document defines extensions to the Mobile IP protocol [1] toallow mobility management for the interface between a radio networkand a packet data network in the third generation cdma2000 network.Mobile IP requires link layer connectivity between the Mobile Nodeand the Foreign Agent. This draft proposes a protocol for achievingthis when the physical layer terminating at a point distant from theFA. In particular, this protocol applies to cdma2000 networks wherethe physical layer terminates at a Radio Network Node (RNN) and theFA resides inside a separate Packet Data Serving Node (PDSN). ThePDSN is responsible for establishing, maintaining, and terminatingthe link layer to the Mobile Node. A RNN is responsible for relayingthe link layer protocol between a Mobile Node and its correspondingPDSN.The interface between the RNN and the PDSN is called the RPinterface. This interface requires mobility management for handlinghandoff from one RNN to another without interrupting end to endcommunication. It also requires the support of the link layerprotocol encapsulation. "Mesh-enhanced Service Location Protocol", H. Schulzrinne, E. Guttman, W. Zhao, 28-AUG-02, This document presents the Mesh-enhanced Service Location Protocol(mSLP). mSLP enhances SLP with a scope-based fully-meshed peeringDirectory Agent (DA) architecture. Peer DAs exchange new serviceregistrations in shared scopes via anti-entropy and directforwarding. mSLP improves the reliability and consistency of SLP DAservices, and simplifies Service Agent (SA) registrations in systemswith multiple DAs. mSLP is backward compatible with SLPv2 and can bedeployed incrementally. "Quick Transaction Protocol - QTP", Michael Cox, Allan Cornish, Ian Palmer, Angus Telfer, Cliff Wignell, Robert Neill, Cameron Young, 11-JAN-02, QTP is a simple protocol for multiplexing short-duration connectionsover an arbitrary transport service such as UDP. QTP is an openstandard to allow dial-up Credit Authorization Terminals (CAT) orPoint-Of-Sale (POS) terminals to connect into IP hosts.These transactions require fast connection times, efficientconcentration of many sessions, fault tolerant operation, and theability to transfer access network addressing (called and callingnumbers) along with transaction data. "EAP GSS Authentication Protocol", B. Aboba, D. Simon, 08-APR-02, The Extensible Authentication Protocol (EAP) provides a standardmechanism for support of multiple authentication methods, includingpublic key, smart cards, One Time Passwords, and others.This document describes the EAP GSS protocol, which enables the use ofGSS-API mechanisms within EAP. As a result, any GSS-API mechanismproviding initial authentication can be used with EAP GSS. "Transport of Layer 2 Frames Over MPLS", L Martini, 12-AUG-02, This document describes methods for transporting the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,Ethernet, and providing a SONET circuit emulation service across anMPLS network. "Cisco Systems' Simple Certificate Enrollment Protocol (SCEP)", C. Madson, Andy Nourse, X Liu, David McGrew, 16-MAY-02, This document specifies the Cisco Simple Certificate EnrollmentProtocol, a PKI communication protocol which leverages existingtechnology by using PKCS#7 and PKCS#10. SCEP is the evolution of theenrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc.It now enjoys wide support in both client and CA implementations "Logical Analysis of the Binary Representation and the IP Specifications for the IPv7 and IPv8 Addressing Systems", Eugene Terrell, 25-MAR-02, The Information Age Revolution established by the Internet, as viewedthrough its World Wide Popularity, ushered not only a need for additional IP Addresses, which serve the ever growing needs and demands of every individual in the World today. Will also be viewed, through the resolution of the IP addressing problem, as the impetus fueling the Revolution in the whole of the Mathematical and Engineering Sciences as well. "A Protocol for Remotely Managing Sieve Scripts", Tim Martin, 22-JUL-02, Sieve scripts allow users to filter incoming email. Message storesare commonly sealed servers so users cannot log into them, yet usersmust be able to update their scripts on them. This documentdescribes a protocol 'sieve' for securely managing Sieve scripts ona remote server. This protocol allows a user to have multiplescripts, and also alerts a user to syntactically flawed scripts.This an interim measure as it is hoped that eventually Sieve scriptswill be stored on ACAP. This document is intended to proceed on theexperimental track. "Telnet Forwarding of X Windows Session Data", Jeffrey Altman, Peter Runestig, 11-APR-02, This document describes a mechanism via which X Window System client applications may have their communications with the X WindowsSystem server forwarded across a Telnet communications channel. Thisis desireable when the Telnet session is established through a Firewallor Network Address Translator which does not allow arbitrary connectionsto be created from the host machine to the client machine; or when theTelnet session is using an authenticated and encrypted channel and thatsame security is desired for the X Window System session data. Authorization to communicate across the tunnel is provided to the X Windows System client via use of X Display access control data. "Netnews Administration System (NAS)", Philipp Grau, Vera Heinau, Heiko Schlichting, 20-SEP-01, The Netnews Administration System (NAS) is a framework to simplifythe administration and usage of network news (also known as Netnews)on the Internet. Data for the administration of newsgroups andhierarchies are kept in a distributed hierarchical database and areavailable through a client-server-protocol. "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 exchangesymmetric keys need to make the public keys resistant to somepredetermined level of attack. That level of attack resistance is thestrength of the system, and the symmetric keys that are exchanged mustbe at least as strong as the system strength requirements. The threequantities, system strength, symmetric key strength, and public keystrength, must be consistently matched for any network protocol usage.While it is fairly easy to express the system strength requirements interms of a symmetric key length and to choose a cipher that has a keylength equal to or exceeding that requirement, it is harder to choose apublic key that has a cryptographic strength meeting a symmetric keystrength requirement. This document explains how to determine thelength of an asymmetric key as a function of the length of a symmetrickey. Some rules of thumb for estimating equivalent resistance tolarge-scale attacks on various algorithms are given. The document alsoaddresses how changing the sizes of the underlying large integers(moduli, group sizes, exponents, and so on) changes the time to use thealgorithms for key exchange. "INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION", M. Crispin, 10-JAN-02, This document describes the multiappending extension to the [IMAP]protocol. This extension provides substantial performanceimprovements for IMAP clients which upload multiple messages at atime to a mailbox on the server.A server which supports this extension indicates this with acapability name of 'MULTIAPPEND'. "LDAP Schema for NDS", J. Sermersheim, 17-MAY-02, This document defines the [LDAPV3] schema descriptions and non-standard syntaxes used by Novell Directory Services (referred tohere as NDS). The ObjectClassDescription, AttributeTypeDescription,SyntaxDescriptionm and syntaxes defined in this document are uniqueto NDS and are meant to compliment those defined in [RFC2252],[RFC2256] and other RFCs and Internet Drafts. "Usage of TRIP in Gateways for Exporting Phone Routes", J. Rosenberg, Hussein Salama, Manjunath Bangalore, 05-DEC-01, This document describes a new application of the Telephony Routingover IP (TRIP) protocol. TRIP was engineered as a tool for inter-domain exchange of telephone routing information. However, it canalso be used as a means for gateways and soft switches to exporttheir routing information to a Location Server (LS), which may beco-resident with a proxy or gatekeeper. This LS can then manage thosegateway resources. We discuss the motivations for this application,the reasons why other mechanims, such as the SIP REGISTER method, arenot appropriate, and then show how a minimal subset of TRIP is neededfor this application. "Use of IPsec Transport Mode for Dynamic Routing", J. Touch, L Eggert, 28-JUN-02, This document addresses the use of IPsec to secure the virtual linksof an overlay network. It addresses how IPsec tunnel mode canconflict with dynamic routing in an overlay, due to the dependence ofboth the security association (SA) and the IP tunnel encapsulationheader on the header of the overlay packet.This document proposes an alternative where IP tunnel encapsulationoccurs as a separate initial step, based on a routing lookup on theoverlay packet. This is followed by IPsec transport mode processingon the resulting (tunneled) IP packet with an SA determined throughan security association database (SAD) match on the tunnel header.The result is compatible with dynamic routing in the overlay.This document discusses this alternative and its impact on IPsec. Itaddresses issues raised with IPsec tunnel mode IP encapsulation anddecapsulation (Appendix A), and interactions with the Internet KeyExchange (IKE).This document is a product of the X-Bone and DynaBone projects atUSC/ISI [5][6]. Comments are solicited and should be addressed to theauthors. "AAA for IPv6 Network Access", C. Perkins, Thomas Eklund, Patrik Flykt, 07-MAR-02, IPv6 nodes (clients) need a way to offer credentials to the AAAinfrastructure in order to be granted access to the local network.For IPv6, it will be more efficient and thus reasonable to expectsuch access controls to be exerted by IPv6 routers, possibly aspart of performing their role as DHCPv6 relays. Routers and DHCPv6servers are expected to work in conjunction with AAA servers todetermine whether or not the client's credentials are valid. Routerscan exert such network access control by the device of carefullycontrolling entries in their packet filter and Neighbor Cache. "RSVP Proxy", Y Bernet, Nitsan Elfassy, Silvano Gai, D Dutt, 07-MAR-02, RSVP has been extended in several directions [POLICY], [RSVP-APPID],[DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened theapplicability of RSVP characterizing it as a signaling protocolusable both inside and outside the Integrated Services [INTSERV]model.With the addition of the 'Null Service Type' [NULLSERV], RSVP isalso being adopted by mission critical applications that require someform of prioritized service, but cannot quantify their resourcerequirements. In cases where RSVP cannot travel end-to-end, theseapplications may still benefit from reservations that are not trulyend-to-end, but that are 'proxied' by a network node on the data pathbetween 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 nodeoriginates the Resv message on behalf of the receiver(s) identifiedby the Path message. "RTCP Reporting Extensions", Ramon Caceres, Kevin Almeroth, Timur Friedman, Kamil Sarac, 04-MAR-02, This document defines the XR (extended report) RTCP packet type, forcarrying information beyond that which is contained in the SR (senderreport) and RR (receiver report) packets that are defined in the RTPspecification. Within their 'reception report blocks', SR and RRpackets are limited to reporting six specified statistics on anygiven data source. "Sieve -- Subaddress Extension", Ken Murchison, 03-JUL-02, On email systems that allow for 'subaddressing' or 'detailedaddressing' (eg, 'ken+sieve@example.org'), it is sometimes desirableto make comparisons against these sub-parts of addresses. This draftdefines an extension to the Sieve mail filtering language that allowsusers 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 mechanismwhich is more powerful than a simple exact match, a substring matchor a glob-style wildcard match. The regular expression matchingmechanism defined in this draft should allow users to isolate justabout any string or address in a message header or envelope. "Generalized NAI (GNAIE) Extension for Mobile IPv4", P. Calhoun, Emad Qaddoura, Haseeb Akhtar, M Khalil, 09-OCT-01, The Mobile IP Extensions Rationalization (MIER) specification definesa new extension header format, that is intended to extend the MobileIP extension address space. This document defines the GeneralizedNetwork Access Identifier (NAI) extension, which SHOULD be used byany Mobile IP extension specifying an extension containing an NAI. "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. "GENERAL NETWORK PROTOCOL (GNP)", Max Wildgrube, 20-MAY-02, This specification describes an all-purpose platform independentnetworking protocol for use to realize client/server (or similar)applications.User and administration messages are transformed into a specialnetwork format (see [SDXF]).This format is self-describing and cpu-independent. "IEEE 802.1X RADIUS Usage Guidelines", B. Aboba, Paul Congdon, 19-JUN-02, IEEE 802.1X enables authenticated access to IEEE 802 media, includingEthernet, Token Ring, and 802.11 wireless LANs. Although RADIUS supportis optional within IEEE 802.1X, it is expected that many IEEE 802.1XAuthenticators will function as RADIUS clients.This document provides suggestions on RADIUS usage by IEEE 802.1XAuthenticators. An earlier version of this specification is included ina non-normative Appendix of the IEEE 802.1X specification. It iscurrently being revised within IEEE 802.1aa and is being presented tothe IETF for informational purposes. "Itinerant Internet Protocol", S Cvetkovic, Chern Yap, 18-JUN-02, This document specifies a protocol that allows any IP node tocommunicate with other IP nodes in the mobile environment without anyfundamental changes to TCP/IP. Any mobile aware nodes are able tocommunicate with one another with standard IP routing. Mobileawareness is achieved by means of address updates through a querymechanism. Backward compatibility capability is supported via themeans of one or more anchoring points that are put in place. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 15-MAY-02, This memo describes a Secure Internet Live Conferencing (SILC)protocol which provides secure conferencing services over insecurenetwork channel. SILC is IRC [IRC] like protocol, however, it isnot equivalent to IRC and does not support IRC. Strong cryptographicmethods 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 AuthenticationProtocols [SILC3] and SILC Commands [SILC4]. "SILC Packet Protocol", Pekka Riikonen, 15-MAY-02, This memo describes a Packet Protocol used in the Secure Internet LiveConferencing (SILC) protocol specified in the Secure Internet LiveConferencing, Protocol Specification Internet Draft [SILC1]. Thisprotocol describes the packet types and packet payloads which definesthe contents of the packets. The protocol provides secure binary packetprotocol that assures that the contents of the packets are secured andauthenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 15-MAY-02, This memo describes two protocols used in the Secure Internet LiveConferencing (SILC) protocol specified in the Secure Internet LiveConferencing, Protocol Specification internet-draft [SILC1]. TheSILC Key Exchange (SKE) protocol provides secure key exchange betweentwo parties resulting into shared secret key material. The protocolis based on Diffie Hellman key exchange algorithm and its functionalityis derived from several key exchange protocols. SKE uses best partsof the SSH2 Key Exchange protocol, Station-To-Station (STS) protocoland the OAKLEY Key Determination protocol [OAKLEY].The SILC Connection Authentication protocol provides user levelauthentication used when creating connections in SILC network. Theprotocol is transparent to the authentication data which means that itcan be used to authenticate the user with, for example, passphrase(pre-shared- secret) or public key (and certificate). "LDAPv3: All Operational Attributes", Kurt Zeilenga, 04-JUN-02, X.500 [X.500] provides a mechanism for clients to request alloperational attributes be returned with entries provided in responseto a search operation. This mechanism is often used by clients todiscover which operatinal attributes are present in an entry. LDAP[RFC2251] does not provide a similar mechanism to clients. "LDAPv3: Grouping of Related Operations", Kurt Zeilenga, 02-JUL-02, This document provides a general mechanism for grouping related LDAP(Lightweight Directory Access Protocol) operations. Grouping ofoperations can be used to support replication, proxies, and high leveloperations such as transactions "A Framework for the delivery of MPEG-4 over IP-based Protocols", D. Singer, Y Lim, 04-MAR-02, This document forms an umbrella specification for the carriage andoperation of MPEG-4 multimedia sessions over IP-based protocols,including RTP, RTSP, and HTTP, among others. It addresses IPMulticast as well.It also serves to document the standard MIME types associated withMPEG-4 files. "Extensions to the 'tel' URL to Support Number Portability and Freephone Service", James Yu, 28-AUG-02, 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. "SIP-H.323 Interworking Requirements", Alan Johnston, David Wang, Karunesh Singh, H Schulzrinne, Hemant Agrawal, Vipin Palawat, Radhika Roy, Charles Agboh, 01-APR-02, This document describes the requirements for the logical entity known asthe SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow theinterworking between the SIP(Session Initiation Protocol) and H.323 protocols. "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", E. Rosen, P. Pillay-Esnault, P. Psenak, 31-JUL-02, [VPN] describes a method of providing a VPN service. That methodallows a variety of different protocols to be used as the routingprotocol between the Customer Edge (CE) router and the Provider Edge(PE) router. However, it does not fully specify the procedures whichmust be implemented within the Provider's network when OSPF is usedas the PE/CE routing protocol. This document provides thatspecification. "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", A. 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. "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)", T Ernst, C. Castelluccia, Ludovic Bellier, H Lach, Alexis Olivereau, 20-MAR-02, This draft addresses the problems of routing datagrams to nodeslocated behind the mobile router (MR) that connects a mobile network(MONET) to the Internet, in IPv6. Mobile IPv6 [MIPv6], the solutionto support host mobility, is unable to support an entire network thatchanges its point of attachment. "Randomness Requirements for Security", Steve Crocker, J. Schiller, Donald Eastlake, 29-JUL-02, Security systems today are built on strong cryptographic algorithmsthat foil pattern analysis attempts. However, the security of thesesystems is dependent on generating secret quantities for passwords,cryptographic keys, and similar quantities. The use of pseudo-randomprocesses to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems mayfind it easier to reproduce the environment that produced the secretquantities, searching the resulting small set of possibilities, thanto locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivatedadversary is surprisingly difficult. This document points out manypitfalls in using traditional pseudo-random number generationtechniques for choosing such quantities. It recommends the use oftruly random hardware techniques and shows that the existing hardwareon many systems can be used for this purpose. It providessuggestions to ameliorate the problem when a hardware solution is notavailable. And it gives examples of how large such quantities needto be for some applications. "Security Framework for Explicit Multicast", B. Sales, O. Paridaens, D. Ooms, 01-JUL-02, This document describes the general issues related to securingexplicit multicast traffic. Explicit multicast is a mechanism aimingat providing multicast services for small groups of users. Thedistinctive characteristics of explicit multicast is that the senderspecifies the list of receivers. This document reviews and discussessecurity issues related to the explicit IP multicast model, henceproviding a general framework for securing explicit multicast IPtraffic as described in [1]. "ENUM Call Flows for VoIP Interworking", Steven Lind, 05-MAR-02, This document provides illustrations of the use of ENUM [2] functionality within the larger context of service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a 'direct dial' basis. Some details are also provided for calls made using the ITU-defined 'Global Services' [3,4,5]. The impact of number portability within the call scenarios is discussed. The objective of this document is to identify areas where gaps exist in the provision of services and suggest where protocol extensions for ENUM, SIP, TRIP, etc. are needed. "Providing Quality of Service Indication by the BGP-4 Protocol: the QOS_NLRI attribute", Christian Jacquenet, Geoffrey Cristallo, 05-MAR-02, 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. "Policy-based Accounting", Georg Carle, Sebastian Zander, Tanja Zseby, 15-AUG-02, This document describes policy-based accounting which is an approachto provide flexibility to accounting architectures. Accountingpolicies describe the configuration of an accounting architecture ina standardized way. They are used to instrument the accountingarchitecture and can be exchanged between AAA entities in order toshare configuration information.This document describes building blocks and message sequences forpolicy-based accounting in the generic AAA architecture [RFC2903].Examples are given for the usage of accounting policies in differentscenarios. Furthermore it is shown how accounting components can beintegrated into the AAA authorization framework [RFC2904]. Thisdocument does not propose a language for the description ofaccounting policies. It is rather assumed that a suitable policylanguage can be chosen from existing or upcoming standards. "Calling Line Identification for Voice Mail Messages", G Parsons, Janusz Maruszak, 08-APR-02, This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. "AAA Requirements for IP Telephony/Multimedia", P. Calhoun, Matt Holdrege, James Kempf, Henrik Basilier, T. Johansson, Jaakko Rajaniemi, 06-MAR-02, The AAA Working Group has been defining requirements for NetworkAccess in Inter-Domain (roaming) networks, including requirementsfrom the Mobile IP and NASREQ Working Groups. Some of theserequirements were input from work done in the 3rd Generation wirelessSDOs. These same SDO's have a need to tie their IP IntelligentServers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to theirAAA infrastructure. "Voice Messaging Client Behaviour", G Parsons, G 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, 17-JUN-02, Lightweight Directory Access Protocol (LDAP) update operations haveatomic properties upon individual entries. However, it is oftendesirable to update two or more entries as one atomic action, atransaction. Transactions are necessary to support a number ofapplications including resource provisioning and informationreplication. This document defines an LDAP extension to supporttransactions. "H.323 URL scheme definition", Orit Levin, 08-NOV-01, H.323 Specification [3] and H.225.0 [4] together define a system and aset of protocols for multimedia communications services over PacketBased Networks (PBN). H.225.0 [4] messages define means for carryingany standard URL (Uniform Resource Locators) in order to specify sourceand destination, involved in the call. Starting from H.323v.4 [3],H.323 URL is defined and maintained as a part of this ITU-Tspecification. "Base Encodings of Data", S. Josefsson, 13-MAY-02, This draft describes the commonly used base 64, base 32, and base 16encoding schemes. It also discusses the use of line-feeds in encodeddata, use of padding in encoded data, use of non-alphabet charactersin 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 ablock cipher with 128-bit block size and 128-, 192-, and 256-bitkeys. The algorithm description is presented together with keyscheduling part and data randomizing part. "An analysis of IPv6 anycast", Jun-Ichiro itojun Hagino, K Ettikan, 01-MAR-01, The memo tries to identify the problems and issues in the use of IPv6anycast [Hinden, 1998] defined as of today. The goals of the draft are(1) to understand the currently-defined IPv6 anycast better, (2) toprovide 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 designteam. "Address Prefix Based Outbound Route Filter for BGP-4", S Sangli, Enke Chen, 04-APR-02, This document defines a new Outbound Router Filter type for BGP,termed 'Address Prefix Outbound Route Filter', that can be used toperform address prefix based route filtering. This ORF-type supportsprefix length or range based matching, wild-card based address prefixmatching, as well as the exact address prefix matching for addressfamilies. "Universal Service Protocol", Timur Shemsedinov, Marina Shemetilo, 12-JUN-02, This document contains the description of call and response packetsof USP protocol. The protocol is the maximally generalized way ofthe complex hierarchical information coding, in its basis theprinciples of object analysis and modeling are fixed. The protocolis not assigned to any specific service and gives only basicdeveloping rules of any service protocols, however USP was developedas RPC protocol. Packets of the latter should be multipartstructures similar to MIME or XML, but with support of a multilevelenclosure and other expansions. Unfortunately, the majority of themodern protocols represent the information differently, it is causedby the fact that they were created by the independent developers, atdifferent time and for different operational systems. The protocolssimplification to a common format of representation of theinformation will essentially enable to facilitate development of thenew protocols and new servers, besides it will remove problemsconnected with any incompatibility, and will increase speed ofinformation processing. I am distinctly aware of all complexitiesconnected with USP implementation, but standardization always bringsmore benefits, than problems. It was obvious in the case with SNMPand MIB. "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. "Use of SRV records in conjuction with HTTP and URLs", M. Andrews, Thor Kottelin, 07-FEB-02, The combined use of SRV records for HTTP along with URIs is not asstraight forward as it would appear at first glance. This documentlooks at the issues involved and recommends solutions. "Diversion Indication in SIP", S Levy, J Yang, Bryan Byerly, 04-JUN-02, This document proposes an extension to the Session InitiationProtocol (SIP). This extension provides the ability forthe called SIP user agent to identify from whom the callwas diverted and why the call was diverted.The extension defines a new general header, Diversion, whichconveys the diversion information from other SIP user agentsand proxies to the called user agent.This extension allows enhanced support for various features,including Unified Messaging, Third-Party Voicemail, and Automatic CallDistribution (ACD). SIP user agents and SIP proxies which receivediversion information may use this as supplemental information forfeature invocation decisions. "EtherIP: Tunneling Ethernet Frames in IP Datagrams", R. Housley, S. Hollenbeck, 29-JUL-02, This document describes EtherIP, an early tunneling protocol, toprovide informational and historical context for the assignment of IPprotocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media accesscontrol frames in IP datagrams so that non-IP traffic can traverse anIP internet. The protocol is very lightweight, and it does notprovide protection against infinite loops. "Telnet Authentication Option", Theodore Ts'o, Jeffrey Altman, 15-APR-02, This document describes the authentication option to the telnet [1]protocol as a generic method for negotiating an authentication typeand mode including whether encryption should be used and ifcredentials should be forwarded. While this document summarizescurrently utilized commands and types it does not define a specificauthentication type. Separate documents are to be published definingeach authentication type.This document updates a previous specification of the telnetauthentication option, RFC 2941 [2], to allow the AUTHENTICATION option to be used in conjunction with the START_TLS option [5]. "Telnet Authentication: Kerberos Version 5", Theodore Ts'o, Jeffrey Altman, 15-APR-02, This document describes how Kerberos Version 5 [1] is used with thetelnet protocol. It describes an telnet authentication suboption tobe used with the telnet authentication option [2]. This mechanismcan also used to provide keying material to provide dataconfidentiality services in conjunction with the telnet encryptionoption [3]. This document updates a previous specification of the TelnetAuthentication Kerberos 5 method, RFC 2942 [4], to allow Kerberos 5Telnet authentication to be used in conjunction with the START_TLSoption [5]. "Telnet Authentication: SRP", Tom Wu, Jeffrey Altman, 15-APR-02, This document specifies an authentication scheme for the Telnetprotocol under the framework described in [1], using the SecureRemote Password Protocol (SRP) authentication mechanism. Thespecific mechanism, SRP-SHA1, is described in [RFC2945].This document updates a previous specification of the TelnetAuthentication SRP method, RFC 2944, to allow SRP Telnet authenticationto be used in conjunction with the START_TLS option [2]. "An XML format for mail and other messages", Graham Klyne, 09-APR-02, This document describes a coding of email and other messages inXML. This coding is intended for use by XML applications thatexchange information about such messages. "DHCP Domain Search Option", B. Aboba, S. Cheshire, 15-JAN-02, This document defines a new DHCP option which is passed from the DHCPServer to the DHCP Client to specify the domain search list used whenresolving hostnames using DNS. "NHNS - Netnews Hierarchy Names System", Daniel Diaz, 29-AUG-02, This document is focused on and describes one of the projects supported and carried out by the RIPE NetNews Working Group. NHNS is a system and service based on a DNS-like structure that has been discussed, developed and deployed under the umbrella of the RIPE NetNews Working Group. This is an update on the draft version published in October 2000. "LDAP & X.500 Component Matching Rules", Steven Legg, 19-APR-02, The syntaxes of attributes in a Lightweight Directory Access Protocolor X.500 directory range from simple data types, such as text string,integer, or boolean, to complex structured data types, such as thesyntaxes of the directory schema operational attributes. Thematching rules defined for the complex syntaxes, if any, usually onlyprovide the most immediately useful matching capability. Thisdocument defines generic matching rules that can match any userselected component parts in an attribute value of any arbitrarilycomplex attribute syntax. "Support for IPv6 in SDP", G. Camarillo, Adam Roach, Sean Olson, 14-JAN-02, This document describes the use of IPv6 addresses [1] in conjunction with the Session Description Protocol (SDP) [2]. Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. "The Tel URI for Telephone Calls", H. Schulzrinne, Antti Vaha-Sipila, 18-JUN-02, This document is a revision of RFC 2806.This document specifies the URI (Uniform Resource Identifier) schemes'tel' for specifying the address of a terminal in the phone network.The tel URI is service-independent and describes voice calls (phonecalls, answering machines and voice messaging systems), facsimile(telefax) calls and data calls, for landline, ISDN and mobilesubscribers. "Handle System Protocol (ver 2.0) Specification", Larry Lannom, Sam Sun, Sean Reilly, Jason Petrone, 02-JUL-02, 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 specifies the protocol used between handle system clients and servers for handle resolution and administration. The document assumes that readers are familiar with the basic concepts of the Handle System as introduced in the 'Handle System Overview' [1], as well as the data model and service definition given in the 'Handle System Namespace and Service Definition' document [2]. "Service Level Specification Semantics and Parameters", Danny Goderis, 25-FEB-02, This document identifies the basic information to be included inService Level Specifications (SLS, [RFC 2475], [DS-TERMS]) whenconsidering the deployment of value-added IP service offerings overthe Internet. Such IP service offerings can be provided together witha given quality of service (QoS), which is expected to be defined insuch SLS, from a technical perspective. Since these IP services arelikely to be provided over the whole Internet, their correspondingQoS will be based upon a set of technical parameters that bothcustomers and services providers will have to agree upon. From thisperspective, this draft aims at listing (and promoting a standardformalism for) a set of basic parameters which will actually composethe elementary contents of an SLS. "Dynamic Authorization Extensions to Remote Authentication Dial-In User Service (RADIUS)", B. Aboba, D Mitton, G Dommety, M Chiba, M Eklund, 28-AUG-02, This document describes the current practices for allowing dynamicchanges to a user session as implemented by network access server products providing the Remote Authentication Dial-In User Service.Namely it documents the current methods for disconnecting and changing data filters applicable to a user session. "Name Pattern Package for Megaco", Brian Rosen, 02-JUL-02, To construct meaningful audits of terminations while controlling the amount of data sent in response to the audits, it would be very helpful if the MGC understood the way terminations were named in the MG. This package provides a method for obtaining the naming pattern for terminations in an MG "A COPS client-type for IP traffic engineering", Christian Jacquenet, 17-JUN-02, This draft specifies a COPS (Common Open Policy Service, [2])client-type designed for the enforcement of IP Traffic Engineering (IP TE) policies within IP networks. The usage of this IP TE COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes (COPS-PR, [3]). "Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)", Rajesh Kumar, 26-AUG-02, This document describes an ATM package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. As an informational Internet-Draft, this document provides information for the Internet community. It does not specify an Internet standard of any kind. It extends the Media Gateway Control Protocol (MGCP) that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. "Role of the Domain Name System", John Klensin, 19-JUN-02, The original function and purpose of the DNS is reviewed, andcontrasted with some of the functions into which it is being forcedtoday and some of the newer demands being placed upon it or suggestedfor it. A framework for an alternative to placing these additionalstresses on the DNS is then outlined. This document and thatframework are not a proposed solution, only a strong suggestion thatthe time has come to begin thinking more broadly about the problemswe are encountering and possible approaches to solving them.A mailing list has been initiated for discussion of this draft, itssuccessors, and closely-related issues at ietf-irnss@lists.elistx.com.See http://lists.elistx.com/archives/ for subscription and archivalinformation. "ECDSA with XML-Signature Syntax", S. Blake-Wilson, Yongge Wang, Gregor Karlinger, 23-JUL-02, This document specifies how to use ECDSA (Elliptic Curve DigitalSignature Algorithm) with XML Signatures [XMLDSIG]. The mechanismspecified provides integrity, message authentication, and/or signerauthentication 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, wheredigital objects of interest are like pieces of paper, and the'protocol' point of view where objects of interest are compositedynamic 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 themmay be clarified and reduced. "Definition of an Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", M. Smith, 27-FEB-02, Uniform Resource Identifiers (URIs) are widely used to specify thelocation of Internet resources. This document defines an attributetype and an auxiliary object class to allow URIs, including URLs, tobe stored in LDAP and X.500 directory entries in a standard way. "Multi-area MPLS Traffic Engineering", Y. Rekhter, K. Kompella, J Vasseur, Ting Chung, 14-MAY-02, An ISIS/OSPF routing domain may consists of multiple areas. Thisdocument postulates a set of mechanisms, and then outlines how thesemechanisms could be used to establish/maintain Traffic EngineeringLSPs that span multiple areas. "The MAP Security Domain of Interpretation for Internet Security Association and Key Management Protocol", R Blom, Jari Arkko, 31-MAY-02, The Mobile Application Part (MAP) protocol is a signaling protocolfor cellular networks. The MAP Security (MAPSEC) protocol providesa secure way to transport MAP messages. To use MAPSEC, however,Security Associations (SAs) are needed. This document defines howsuch SAs can be created automatically. We use the InternetSecurity Association and Key Management Protocol (ISAKMP) as aframework for managing SAs and establishing keys. The frameworkcan be specialized to a particular task. Such a specialization iscalled a Domain of Interpretation (DOI), and this document definesthe MAPSEC DOI. This specialization is very similar to theInternet Key Exchange protocol and the ISAKMP specialization forIP Security, except that non-IP protocols are being negotiated. "Multicast in MPLS/BGP VPNs", Eric Rosen, 13-AUG-02, [RFC2547bis] describes a method of providing a VPN service. Itspecifies the protocols and procedures which must be implemented inorder for a Service Provider to provide a unicast VPN. This documentextends that specification by describing the protocols and procedureswhich a Service Provider must implement in order to support multicasttraffic in a VPN, assuming that PIM [PIMv2] is the multicast routingprotocol used within the VPN, and the the SP network can provide PIMas well. "Terminology Used in Internationalization in the IETF", Paul Hoffman, 28-JAN-02, This document provides a glossary of terms used in the IETF whendiscussing internationalization. The purpose is to help framediscussions of internationalization in the various areas of the IETF andto help introduce the main concepts to IETF participants. "XML encoding for SMS messages", Juha Koponen, Teemu Ikonen, Lasse Ziegler, 15-APR-02, Short Message Service (SMS) messages have become very popular amongmobile phone users. However, the service providing is stillrelatively awkward. This draft presents an encoding and a simpleprotocol for describing and submitting SMS messages over theInternet. The protocol is aimed to be used between service providersand SMS gateways. The SMS messages are encoded in XML and thecorresponding Document Type Definition (DTD) for the messagestructure is described "SDP Simple Capability Declaration", F. Andreasen, 01-MAR-02, This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. "List of the Current BGP Documents", Y. Rekhter, Enke Chen, 05-APR-02, This document lists the most recent RFCs and Internet Drafts that arerelated to the BGP protocol and its applications. It is expectedthat this document will be updated on a on-going basis. "Framework for EPIC", R. Price, 01-MAR-02, This draft describes an optional enhancement to the ROHC profilespecified in EPIC-LITE [2] for the robust compression of protocolheaders. "IMAP4 Binary Content Extension", Lyndon Nerenberg, 18-JAN-02, This memo defines the BINARY extension to the Internet MessageAccess Protocol [IMAP4rev1]. It provides a mechanism for IMAP4clients and servers to exchange message body data without using aMIME content-transfer-encoding. "An IETF URN Sub-namespace for Registered Protocol Parameters", L. Masinter, M. Mealling, G. Klyne, T Hardie, 02-MAY-02, This document describes a new sub-delegation for the 'ietf' URNnamespace for registered protocol items. The 'ietf' URN namespace isdefined in RFC 2648 as a root for persistent URIs that refer to IETF-defined resources. "The IETF XML Registry", M. Mealling, 02-JUL-02, This documenet describes an IANA maintained registry for IETFstandards which use XML related items such as Namespaces, DTD,Schemas, and RDF Schemas. "Distributed Route Exchangers", C.Y. Lee, A. Celer, G. Ash, S. Ghanti, 03-JUL-02, The current link state routing protocols flood link states to allrouters so that routers have the information required to compute theshortest paths to route packets on a hop by hop basis. However, forthe purpose of establishing MPLS paths, constraint path computationis only performed at certain nodes, for instance, at the node wherepath setup is triggered or at the head-end of a loosely routedsegment that crosses a network (or area) boundary. In addition, itnot possible to have all required constraints present in all nodes ina network, nor is it always feasible for nodes setting up paths tocompute the constraint paths themselves, a notable example is when apath traverses network or area boundary. These reasons motivate asolution using a 'subset' of routers (called route exchangers), tocollect constraint information and exchange it with other routeexchangers. Route exchangers store traffic engineering link statesand other types of constraint information and compute on demand, theexplicit routes required by routers establishing paths. Hence, linkstate information need only be distributed to the subset of nodesthat help compute constraint paths in the network. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", L Martini, 12-NOV-01, This document describes methods for encapsulating the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,Ethernet for transport across an MPLS network. "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", Jim Martin, Brian Haberman, 13-MAY-02, The expansion of the IP address space provided by IPv6 makes it both possible and reasonable to allocate entire subnets to environments that had been previously limited to a few individual IP addresses. Other protocols such as Neighbor Discovery and Stateless Address Autoconfiguration allow hosts within those subnets to be automatically configured. The router between this subnet and the upstream world requires just one more piece to make this process automatic, a network prefix. This document describes a mechanism for the automated delegation of an IPv6 network prefix. It allows routers to request either a specific prefix or any prefix. Upon authorizing the request the delegating router then returns a prefix and a lifetime for the use of the prefix. Optionally, the delegating and requesting routers can exchange routing protocol information. "Number Portability Administration in the U.S.", Michael Foster, Tom McGarry, James Yu, 27-JUN-02, 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, 06-MAY-02, One of the latest trends attacking Internet security is theincreasing prevalence of Denial of Service (DoS) attacks. DoSattacks target system and/or network resources and seek toprevent valid access by consuming resources. Internet ServiceProviders (ISPs) need to be equipped and ready to assist intracing these attacks with tools and procedures in place beforethe occurrence of a DoS attack. This paper proposes a proactiveinter-network communication method as well as an SNMP-basedtracing mechanism that can be used by ISPs to identify thesource(s) of an attack. SNMP flows as described in RFC2720,implemented on routers or monitoring devices could be used totrace attacks coordinated by a Network Management System thatwould also provide a communication mechanism across networkborders. It is imperative that ISPs have quick communicationmethods defined to enable neighboring ISPs to assist in trackinga security incident across the Internet. This proposal makesuse of current standards for traffic and performance management,which could be extended for DoS incident handling. Policyguidelines for handling these incidents are recommended and canbe used by Internet Service Providers (ISPs) and extended to their clients in conjunction with the technical recommendations. "Crankback Routing Extensions for MPLS Signaling", A. Iwata, G. Ash, A. Farrel, Norihito Fujita, Simon Marshall-Unitt, 28-JUN-02, This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling.Recently, several routing protocol extensions foradvertising resource information in addition to topologyinformation have been proposed for use in distributedconstraint-based routing. In such a distributed routingenvironment, however, the information used to compute aconstraint-based path may be out of date. This meansthat LSP setup requests may be blocked by links or nodeswithout sufficient resources.This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retriedon an alternate path that detours around the blocked linkor node upon a setup failure. "Pragmatic General Multicast(PGM) Reliable Transport Protocol Management Information Base (MIB)", Luna Petrova, 11-JUN-02, This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Pragmatic General Multicast (PGM) Reliable Transport protocol. "Cisco Systems Router-port Group Management Protocol (RGMP)", Ishan Wu, Toerless Eckert, 05-JUN-02, This draft documents RGMP, a protocol developed by Cisco Systemsthat is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where thepackets may be needed.RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. "A Configuration Schema for LDAP Based Directory User Agents", L. Howard, Bob Joslin, M Ansari, 07-MAR-02, This document describes a mechanism for global configuration ofsimilar directory user agents. This document proposes a schema forconfiguration of these DUAs that may be discovered using the Light-weight Directory Access Protocol [RFC2251]. "Network Data Management Protocol Version 4", Harald Skardal, 20-MAY-02, 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. "Domain Name System URI Scheme and MIME Media Types", S. Josefsson, 13-MAY-02, This draft describes a URI scheme for DNS resources and MIME media types for DNS data. "Tracing Requirements for Generic Tunnels", David Meyer, Ron Bonica, K. Kompella, David Meyer, 07-JUN-02, This document specifies requirements for a generic route tracingapplication. The application must provide all functionality that'traceroute' [RFC 2151] currently provides. It also must provideenhanced capabilities with regard to tunnel tracing (e.g., tracingthrough IP-in-IP tunnels, tracing through MPLS LSPs). "Internationalizing the DNS -- A New Class", John Klensin, 20-JUN-02, Several mechanisms have been proposed for placing multilingual names(more properly, names normally written in non-ASCII character sets)into the DNS or addressing the need for multilingual access to theInternet in other ways. Most of them involve, to one extent oranother, workarounds to the current system. This document proposes a'go back and fix it' approach, replacing the 'IN' Class in the DNS withone that is not limited to ASCII from its initial definitions. Some ofthe deployment issues, politics, and other drawbacks are also brieflydiscussed. "Explicit Multicast (Xcast) Basic Specification", R. Boivie, 01-JUL-02, Multicast has become increasingly important with the emergence ofnetwork-based applications such as IP telephony and videoconferencing. The Internet community has done a significant amount ofwork 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 sensethat they can support very large multicast groups, there arescalability issues when a network needs to support a very largenumber of distinct multicast groups. "Path Request and Path Reply Message", Barry Hass, C.Y. Lee, S Ganti, Venkata Naidu, 07-MAR-02, This memo 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) "Secure MPLS - Encryption and Authentication of MPLS payloads", O. Paridaens, 25-JUL-02, This document specifies a mechanism for securing the MPLS dataplane, ie securing any data carried over MPLS. This work is splitinto two aspects: use of IKE to establish the required securityassociation for secure MPLS and definition of the encapsulationformats required for the encryption and authentication of MPLSpayloads. Extensions, under the form of a new Domain ofInterpretation, are defined for the use of IKE to set up SecurityAssociations for secure MPLS. "Media Gateway Control Protocol (MGCP) Version 1.0", F Andreasen, B Foster, 30-MAY-02, This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control 'intelligence', and a media gateway which contains the media functions, e.g. conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. "Forwarding MAC Frames over MAPOS", M. Maruyama, Takahiro Sajima, Osamu Okamoto, 11-JAN-02, This memo documents a method for forwarding MAC frames over a MAPOSnetwork. MAPOS is a multiple access protocol for transmission ofnetwork-protocol datagrams, encapsulated in High-Level Data LinkControl (HDLC) frames, over SONET/SDH [1]. This memo describes amethod for forwarding MAC frames over a MAPOS network, thus providinga way to unify MAPOS network environment and MAC-based LANenvironment. "Basic MGCP Packages", B Foster, F. Andreasen, 28-AUG-02, 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, 05-AUG-02, This specification describes an LDAP (Lightweight Directory AccessProtocol) extended operation to cancel (or abandon) an outstandingoperation. Unlike the LDAP Abandon operation but like the X.511 DAPAbandon operation, this operation has a response which provides anindication of its outcome. "The DISCOVER opcode", Bill Manning, P Vixie, E. 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 desireableto have a more robust opcode for server interactions since a singlerequest may result in replies from multiple responders. So DISCOVERis defined to deal with replies from multiple responders.As such, this document extend the core DNS specifications to allowclients to have a method for coping with replies from multipleresponders. Use of this new opcode may facilitate DNS operations inmodern networking topologies. A prototype of the DISCOVER opcodewas developed as part of the TBDS project, funded under DARPA grantF30602-99-1-0523. "Explicit Multicast Extension (Xcast+) Supporting Receiver Initiated Join", J Lee, 26-MAR-02, Explicit Multicast (Xcast) is a newly proposed multicast scheme tosupport a very large number of small multicast groups. CurrentXcast specification mentions its data plane only, and does notspecify a control plane. Therefore, this document describes anenhanced scheme for the support of receiver initiated join inexplicit multicast, named Xcast extension (Xcast+), whichcomplements the existing Xcast. "Megaco/H.248 Basic CAS Packages", Vikas Bajaj, Michael Brown, Kevin Boyle, Kushanava Laha, B. Foster, Wendy Bothwell, 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]. "MF Tone Generation and Detection Packages", Michael Brown, Kevin Boyle, Wendy Bothwell, Keven Chapman, 04-MAR-02, This document provides multi-frequency (MF) tone generation and MFtone detection packages for Megaco/H.248. "A Framework for Virtual Metropolitan Internetworks (VMI)", Tissa Senevirathne, 22-FEB-02, In this document we present framework for VPLS (Virtual Private LAN services) and point-to-point Layer 2 VPN services. These two models are collectively referred to as VMI (Virtual Metropolitan Internetworks). "Inverse ARP over Unidirectional Virtual Circuits", Juha Heinanen, 02-MAR-01, This memo describes operation of an Inverse Address ResolutionProtocol (InARP) over unidirectional virtual circuits such as MPLSLSPs. "Diameter Accounting Extensions", G. Zorn, P. Calhoun, Jari Arkko, 05-MAR-01, The Diameter protocol provides Authentication, Authorization andAccounting for network access technologies, such as NASREQ,ROAMOPS and Mobile IP. This extension describes how accountingrecords can be securely transmitted over the Diameter protocol.When combined with the Strong Security extension, accountingrecords MAY traverse intermediate proxies in a secure fashion andis compatible with the referral broker model. This extensionallows real-time accounting transfers. "Diameter Framework Document", P. Calhoun, 05-MAR-01, Current Internet Service Providers (ISPs) scale their networks byusing the RADIUS protocol, which provides user Authentication,Authorization and Accounting (AAA) of Dial-up PPP clients. The recentwork done in the Roaming Operations (ROAMOPS) Working Group was toinvestigate whether RADIUS could be used in a roaming network, andconcluded that RADIUS was ill-suited for inter-domain purposes. "Effects of ICMPv6 on IKE and IPsec Policies", Jari Arkko, 25-JUN-02, The ICMPv6 protocol provides many functions which in IPv4 were eithernon-existent or provided by lower layers. IPv6 architecture also makesit possible to secure all IP packets using IPsec, even ICMPv6 mes-sages. IPsec architecture has a Security Policy Database that speci-fies which traffic is protected, and how. It turns out that the speci-fication of policies in the presence of ICMPv6 traffic is hard. Soundlooking policies may easily lead to loops: The establishment of secu-rity requires ICMPv6 messages which can't be sent since securityhasn't been established yet. The purpose of this draft is to informsystem administrators and IPsec implementors in which manner they canhandle the ICMPv6 messages. Common understanding of the way that thesemessages are handled is also necessary for interoperability, in casevendors hardcode such rules in to products. "Manual SA Configuration for IPv6 Link Local Messages", Jari Arkko, 25-JUN-02, This draft discusses the use of manually configured IPsec SAs to pro-tect ICMPv6 messages such as router discovery and address resolutionon the local link. IPsec SAs are generally identified by the triple. For the ICMPv6 messages config-uring the SAs requires some effort, however, since there are multipleknown destination addresses plus a number of addresses that depend onthe physical link addresses. This draft describes the security impli-cations of protecting or not protecting the link local ICMPv6 mes-sages, lists the SAs that must be configured manually, and discussessome approaches for reducing configuration effort. "Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", J. Palme, 10-JAN-02, The memo 'MIME Encapsulation of Aggregate Documents, suchas HTML (MHTML)' [RFC 2557] specifies how to send packagedaggregate HTML objects in MIME format. This memo is anaccompanying informational document, intended to be an aidto developers. This document is not an Internet standard.Issues discussed are implementation methods, cachingstrategies, problems with rewriting of URIs, makingmessages suitable both for mailers which can and whichcannot handle Multipart/related and handling recipientswhich do not have full Internet connectivity. "LMTP Service Extension for Ignoring Recipient Quotas", Lawrence Greenfield, Ken Murchison, 10-JUN-02, This memo defines an extension to the LMTP service whereby a clientmay ask the server to ignore a recipient's quotas when delivering amessage. "TDM over IP", M. Riegel, Motty Anavi, Y. Stein, 26-JUN-02, 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. "IPVPN Policy Information Model", Mahadevan Iyer, 01-MAR-02, This document specifies the object oriented information model for representing policy information associated with the provisioning of IP VPN services, that include the configuration information related to the setup of the IP VPN connectivity, and may also include the configuration information related to the activation of the following elementary functions: firewall, address translation, quality of service, encryption. "Host-based Anycast using MLD", D. Thaler, Brian Haberman, 08-MAY-02, This specification defines extended uses of the Multicast Listener Discovery protocol to support hosts participating in anycast groups. The extensions presented in this document allow hosts to notify the routing system of membership changes in an anycast group. "Secure MPLS Domain of Interpretation for ISAKMP", O. Paridaens, 25-JUL-02, This document defines the Secure MPLS Domain of Interpretation forISAKMP. Presented in the discussion are various definitions neededto fully define the parameters required by SMPLS. The discussionclosely follows the IPSec DOI and where appropriate cross-referencesare made to IPSec DOI. "SASL in HTTP/1.1", Robert Zuccherato, Alexey Melnikov, Magnus Nystrom, 02-JUL-02, This memo suggest the use of SASL [RFC2222] as a framework to enablethe use of strong authentication mechanisms in http/1.1 [RFC2616],and defines one approach to accomplish this. "Definitions of Managed Objects for Network Address Translators (NAT)", Pyda Srisuresh, Cliff Wang, R Rohit, Rajiv Raghunarayan, Nalinaksh Pai, 03-JUL-02, This memo defines an SMIv2 Management Information Base (MIB) fora device implementing traditional NAT [17] function. This may beused for configuration as well as monitoring of a device capable oftraditional NAT function "Requirements for a Resource Update Protocol", M. Hamilton, D. Li, Ian Cooper, Mike Dahlin, 04-MAR-02, This document provides guidelines for the development of a WebResource Update Protocol to facilitate cache coherence in Webintermediary systems such as caching proxies and surrogates. Such aprotocol is useful to maintain consistency in an environment whereperiodic revalidation is unacceptable in terms of performance and/orcache consistency. "A Context Transfer Framework for Seamless Mobility", C. Perkins, R. Koodli, 03-SEP-02, Mobile nodes enhance the performance of their connectionsacross wireless media by establishing various kinds of state(context), in order to use the available bandwidth securely andeconomically. During handover from one access router to another, abandwidth-constrained mobile node needs to have state informationpassed from the previous router to the new one. This documentproposes a framework for control structures that enable authorizedcontext transfers. We demonstrate how the proposed framework couldbe applied during handovers so that the applications running onthe mobile node could operate with minimal disruption, by reducinglatency and packet losses "A Framework for Purpose Built Keys (PBK)", S. Bradner, A. Mankin, J. Schiller, 13-SEP-02, This memo considers the need to authenticate the source of a networkcommunication where the actual identity of the source is notimportant but it is important to be sure that the source can not bespoofed and that successive messages in the communication come fromthe same source. This memo defines the use of specially generatedpublic/private key pairs, known as Purpose Built Keys (PBKs), toprovide this assurance. This memo is not a full specification of aPBK protocol, but rather a model or framework for development of PBKin applications. "BGP4 router ID for IPv6 only routers", F. Dupont, Alain Durand, 15-JAN-02, BGP4 [1] uses a 32 bit field to identify router (the so called'router-IDs'). In IPv4 domain, an IPv4 address of the routeris typically used in this field.In an IPv6 routing domain, routers may very well not have any IPv4Addresses. This document provides a simple way to form a globallyUnique ID in such a case. "MPLS Multicast Traffic Engineering", D. Ooms, 01-MAR-02, There are several reasons for operators to construct multicast treesby another means than multicast routing protocols. This documentlists these reasons and describes 2 ways of building a multicasttraffic-engineered tree: root-initiated tree and leaf-initiated tree.Finally it defines extensions to CR-LDP to support MPLS multicasttraffic engineering. "EAP SIM Authentication", H. Haverinen, 01-JUL-02, 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 encryption keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication. "Layer 1 Activation Management for ISDN Q.921-User Adaptation Layer (IUA)ISDN Layer 1 Activation Adaptation Layer (IL1A)", K Morneault, Jan Bouwen, 18-FEB-02, This Internet Draft proposes an extension to the ISDN Q.921-User Adaptation (IUA) [1] layer for the exchange of layer 1 activation messages between a Media Gateway Controller and an ISDN Access Gateway. This extension is necessary to support ISDN Basic Rate Access (BRA). "The AES Cipher Algorithm in the SNMP's User-based Security Model", Keith McCloghrie, Uri Blumenthal, Fabio Maino, 02-JUL-02, This document describes a set of symmetric encryption protocols that supplement the protocols described in the User-based Security Model (USM) [RFC2574], which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture [RFC2571]. The symmetric encryption protocols described in this document are based on the AES cipher algorithm [FIPS-AES], used in Cipher FeedBack Mode (CFB), with key size of 128 (mandated), 192, and 256 bits. "RTP Payload Format for MPEG-4 FlexMultiplexed Streams", D. Curet, 05-JUL-02, MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data.This document describes a payload format for transporting MPEG-4 synchronised and multiplexed data using RTP. Several services provided by RTP are beneficial for MPEG-4 encoded and multiplexed data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. "Multimedia Conferencing Requirements for SIP Based Systems", Orit Levin, 07-MAR-02, This document outlines requirements for SIP-based entities essential for participation and optional hosting of multimedia conferencing. The requirements are grouped in two categories: point-to-point primitives and conferencing (i.e. 'beyond two participants') primitives. A separate document will suggest the mapping of the requirements to corresponding protocols' primitives. "Analysis of the Security of the MPLS Architecture", Michael Behringer, 20-JUN-02, This document analyses the security of the MPLS architecture, 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 MPLS is examined with respect to these requirements.The analysis shows that MPLS networks can be equally secured as traditional layer-2 networks such as ATM and Frame Relay. "IMAP4 Channel Transport Mechanism", Lyndon Nerenberg, Steve Hole, B. Leiba, 19-JUN-02, IMAP4 is being used to serve rich media content in environmentsthat extend beyond traditional text-based e-mail. One example is acellular telephone that can retrieve and send MIME-encoded audiodata through IMAP4. While this type of content can be exchangednatively using IMAP4, some applications will work better if themessage content can be manipulated using schemes external to theIMAP4 connection. In our cellular telephone example, it might bepreferable for the telephone client to retrieve the audio datausing RTSP. This specifications defines a mechanism for an IMAP4client to request message content from a server through an externalscheme. "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", J. Kunze, R. Rodgers, 27-AUG-02, The ARK (Archival Resource Key) is a scheme intended to facilitatethe persistent naming and retrieval of information objects. Itcomprises an identifier syntax and three services. An ARK has fourcomponents:[http://NMAH/]ark:/NAAN/Namean optional and mutable Name Mapping Authority Hostport part (NMAH,where 'hostport' is a hostname followed optionally by a colon andport number), the 'ark:' label, the Name Assigning Authority Number(NAAN), and the assigned Name. The NAAN and Name together form theimmutable persistent identifier for the object. ".xxx Considered Dangerous", Donald Eastlake, Declan McCullagh, 10-MAY-02, Periodically there are proposals to require the use of a special toplevel name or an IP address bit to flag 'adult' or 'safe' material orthe like. This document explains why this is an ill considered idea. "Security Issues in Mobile IP", S. Glass, 07-MAR-02, Mobile IP is designed to provide IP services to roaming nodes, allowing them access to services, and enabling other nodes to reach them, as if they were on their home domain. By definition this functionality must be deployed on multiple subnets, and in many cases across domains, and while services which enable Mobile IPMUST be present on a subnet in order for a mobile node to have thisreachability, deploying Mobile IP can introduce some securityissues which may need to be addressed, by any network administratoroverseeing Mobile IP subnets. "SM2 -- A Session Management Capable SASL Mechanism", Dave Taylor, Raif Naffah, 23-JUL-02, This document describes a family of SASL mechanisms capable ofre-using cryptographic parameters (SASL Security Context) negotiatedin a prior exchange "Hebrew Character Encoding for Internet Messages", H. Nussbacher, Y. Bourvine, 05-SEP-02, This document describes the encoding used in electronic mail [RFC822]for transferring Hebrew. The standard devised makes use of MIME[RFC2045] and ISO-8859-8.This memo is based on the Israeli standard IS-1904 and is compatiblewith it.Revision note: The change over RFC1555 is that the defaultdirectionality in a composed Hebrew message was changed to Implicitfrom Visual, and a receiving entity needs to understand both visualand implicit messages. Explicit directionality has been removed, asit was never used. "NAS packages for MGCP", R. Subramaniam, B. Foster, 04-FEB-02, This document contains two MGCP packages that define the signaling interface for data calls between a Call Agent and a Network Access Server (NAS). "Simple Authentication and Security Layer (SASL)", A Melnikov, 08-APR-02, SASL provides a method for adding authentication support with anoptional security layer to connection-based protocols. It alsodescribes a structure for authentication mechanisms. The result isan abstraction layer between protocols and authentication mechanismssuch that any SASL-compatible authentication mechanism can be usedwith any SASL-compatible protocol.This document describes how a SASL authentication mechanism isstructured, how a protocol adds support for SASL, defines theprotocol for carrying a security layer over a connection, and definesthe EXTERNAL SASL authentication mechanism. "LDAP Intermediate Response", Kurt Zeilenga, R Harrison, 02-APR-01, This document extends LDAPv3 to provide a general mechanism fordefining single-request/multiple-response operations by defining anddescribing the IntermediateResponse message. "AES Companion Hash Definitions (SHA256, SHA384, SHA512) for OTP", Philip Nesser II, 02-APR-01, 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 definitionsfor the MD4, MD5 and SHA1 hashes, while this document definestechniques for using the AES hashes. "Feature Discovery in LDAP", Kurt Zeilenga, 05-AUG-02, The Lightweight Directory Access Protocol (LDAP) is an extensibleprotocol with numerous elective features. This document introduces ageneral mechanism for discovery of elective features and extensionswhich cannot be discovered using existing mechanisms. "LDAPv3: All Operational Attributes", Kurt Zeilenga, 05-AUG-02, The Lightweight Directory Access Protocol (LDAP) supports a mechanismfor requesting the return of all user attributes but does not alloperational attributes. This document describes an LDAP extensionwhich clients may use to request the return of all operationalattributes. "Sieve Extension: Relational Tests", Wolfgang Segmuller, 15-MAY-02, This document describes the RELATIONAL extension to the Sieve mailfiltering language [SIEVE]. This extension allows relationaloperators on field values and on the number of entities in headerfields and addresses. "SMB Filesharing URL Scheme", Christopher Hertel, 23-JUL-02, The Server Message Block (SMB) protocol is one of the most widelyused network filesystem protocols in existence. This documentdescribes a format for an SMB Uniform Resource Locator. The SMB URLcan be used to indicate SMB workgroups, servers, shares, files,inter-process communications pipes, print queues, and devices; theobjects in the SMB network filesystem space. "SUCV Identifiers and Addresses", Gabriel Montenegro, C. Castelluccia, 05-JUL-02, This document addresses the identifier ownership problem. Itdoes so by using characteristics of Statistic Uniqueness andCryptographic Verifiability (SUCV) of certain entities whichthis document calls SUCV Identifiers (SUCV ID's). This notealso proposes using these SUCV characteristics in relatedentities called SUCV Addresses in order to severely limitcertain classes of denial of service attacks and hijackingattacks. SUCV addresses are particularly applicable to solve the'address ownership' problem that severely undermines confidencein mechanisms like Binding Updates in Mobile IP for IPv6. "Converting LDAP/X.500 Distinguished Names to DNS Domain Names to Support Server Location", Skip Slone, 13-DEC-01, A Lightweight Directory Access Protocol (LDAP) request must be directed to an appropriate server for processing. This document specifies an extension to the Domain Name System (DNS) and specifies a method for discovering such servers using information in DNS. This document complements and enhances previously specified methods of locating an appropriate server in that it works for distinguished names constructed with or without the 'dc' attribute type. The DNS extension is specified as an AVA Resource Record. The method of discovering servers queries DNS for AVA records to resolve a DN to a fully qualified domain name, then queries DNS for SRV records to complete the location process. "Additional XML Security URIs", Donald Eastlake, 14-JAN-02, A number of algorithm and keying information identifying URIsintended for use with XML Digital Signatures and XML Encryption aredefined. "Resource Management in Diffserv (RMD) Framework", Lars Westberg, 11-FEB-02, This draft presents the work on the framework for the ResourceManagement in Diffserv (RMD) designed for edge-to-edge resourcereservation in a Differentiated Services (Diffserv) domain. The RMDextends the Diffserv architecture with new resource reservationconcepts and features. Moreover, this framework enhances the LoadControl protocol described in [WeTu00]. "Resource Management in Diffserv On DemAnd (RODA) PHR", Lars Westberg, 11-FEB-02, The purpose of this draft is to present the Resource Management inDiffserv (RMD) On DemAnd (RODA) Per Hop Reservation (PHR) protocol.The RODA PHR protocol is used on a per-hop basis in a DifferentiatedServices (Diffserv) domain and extends the Diffserv Per Hop Behavior(PHB) with resource provisioning and control. "Megaco/H.248 Enhanced Analog Line Packages", M. 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 "Dynamic Diffie Hellman based Key Distribution for Mobile IPv6", Stefano Faccin, Franck Le, 04-JAN-02, Mobile IP [1] requires several security associations: the Mobile Nodemust share a security association with its Home agent and itsCorrespondent Nodes to send the binding update; these messages mustbe authenticated to prevent potential denial of service attacks [2].The MN and the Home Agent can have a static security association,established at the configuration time, but the case of theCorrespondent Node is more complex since it cannot be assumed thatthe MN and the CN have any pre-established security association. "LDAPv3: A Collection of User Schema", Kurt Zeilenga, 17-MAY-02, This document provides a collection of user schema elements for usewith LDAP (Lightweight Directory Access Protocol) from both ITU-TRecommendations for the X.500 Directory and COSINE and Internet X.500pilot projects. "Collective Attributes in LDAP", Kurt Zeilenga, 26-AUG-02, X.500 collective attributes allow common characteristics to be sharedbetween collections of entries. This document summarizes the X.500information model for collective attributes and describes use ofcollective attributes in LDAP (Lightweight Directory Access Protocol).This document provides schema definitions for collective attributesfor use in LDAP. "Conventions for the use of the Session Description Protocol (SDP)for Digital Circuit Connections", Tom Taylor, 08-APR-02, This document describes conventions for using the Session Description Protocol (SDP) for controlling digital circuits. These conventions describe - circuit addressing conventions for use on the SDP 'c=' line - content of the 'm=' line(s) for digital circuits - attributes to convey the parameters contained within the Bearer Capability, Low Layer Compatibility, and High Layer Compatibility Information Elements of ITU-T Recommendation Q.931. These conventions have been defined for use in media gateway control, particularly in support of NAS operation, but may also be used by IP-based call signalling schemes (SIP, BICC) to control media exchange over digital circuits. "MPLS Support of Differentiated Services using E-LSP", Biswajit Nandy, Nabil Seddigh, S Ganti, 21-JUN-02, The current DS-TE (Diffserv Traffic Engineering) approach can only beused with a single OA (Ordered Aggregate) per E-LSP or with L-LSP. Itcannot be used to carry multiple OAs per E-LSP.This document motivates reasons where it is desirable to carrymultiple OAs per E-LSP. In addition, the document proposes RSVP-TEand CR-LDP extensions to facilitate signalling of multiple trafficparameters for a single E-LSP. "SILC Commands", Pekka Riikonen, 15-MAY-02, This memo describes the commands used in the Secure Internet LiveConferencing (SILC) protocol, specified in the Secure Internet LiveConferencing, Protocol Specification Internet Draft [SILC1]. TheSILC Commands are very important part of the SILC protocol. Usuallythe commands are used by SILC clients to manage the SILC session, butalso SILC servers may use the commands. This memo specifies detailedcommand messages and command reply messages. "The MIME Application/Vnd.pwg-multiplexed Content-Type", R. Herriot, 08-APR-02, The Application/Vnd.pwg-multiplexed content-type, like theMultipart/Related content-type, provides a mechanism for representingobjects that consist of multiple components. An Application/Vnd.pwg-multiplexed entity contains a sequence of chunks. Each chunk containsa MIME message or a part of a MIME message. Each MIME messagerepresents a component of the compound object, just as a body part ofa Multipart/Related entity represents a component. With aMultipart/Related entity, a body part and its reference in some otherbody part may be separated by many octets. With anApplication/Vnd.pwg-multiplexed entity, a message and its referencein some other message can be made quite close by chunking the messagecontaining the reference. For example, if a long message containsreferences to images and the producer does not know of the need foreach image until it generates the reference, thenApplication/Vnd.pwg-multiplexed allows the consumer to process thereference to the image and the image before it consumes the entirelong message. This ability is important in printing and scanningapplications. This document defines the Application/Vnd.pwg-multiplexed content-type. It also provides examples of its use. "iSCSI CRC/Checksum Considerations", Julian Satran, Matt Wakeley, Vincente Cavanna, Dafna Sheinwald, Pat Thaler, 16-APR-02, Cyclic redundancy check (CRC) codes [Peterson] are shortened cyclic codes used for error detection. A number of CRC codes have been adopted in standards: ATM, IEC, IEEE, CCITT, IBM-SDLC, and more [Baicheva]. The most important expectation from this kind of code is a very low probability for undetected errors. The probability of undetected errors in such codes has been, and still is, subject to extensive studies that have included both analytical models and simulations. Those codes have been used extensively in communications and magnetic recording as they demonstrate good 'burst error' detection capabilities, but are also good at detecting several independent bit errors. Hardware implementations are very simple and well known; their simplicity has made them popular with hardware developers for many years. However, algorithms and software for effective implementations of CRC are now also widely available [Williams]. The probability of undetected errors depends on the polynomial selected to generate the code, the error distribution (error model), and the data length. In this memo, we attempt to give some estimates for the probability of undetected errors to facilitate the selection of an error detection code for iSCSI. We will also attempt to compare CRCs with other checksum forms (Fletcher, Adler, weighted checksums), as permitted by available data. "Explicit Multicast over Ethernet", J Lee, 22-JAN-02, Explicit multicast(Xcast)[XCST] is a new kind of Internet multicastand complements the Host Group Model multicast in the sense ofmulticast benefits. Xcast encodes addresses of destinations withinits packet and requires neither any routing information exchangenor state management. Xcast routing utilizes legacy unicast routinginformation managed at every node and is expected to haveperformance good enough for small size multicast groups. "Handle System Overview", Larry Lannom, Sam Sun, 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. "APEX Endpoint Servers", D. New, 20-AUG-01, This memo describes a convention for providing an equivalent to a'well-known port' facility for services provisioned independently ofthe relaying mesh. This provides the ability to contact servers notassociated with specific users. "Requirements and framework for ATM network interworking over MPLS", G Koleyni, 21-JAN-02, Generic requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) have been described in [2]. This draft lists ATM specific requirements and provides encapsulation format and semantics for connecting ATM edge networks through a core packet network using IP, L2TP or MPLS. This basic application of ATM interworking will allow ATM service providers to take advantage of new technologies in the core to provide ATM multi-services. "EAP AKA Authentication", Jari Arkko, H. Haverinen, 01-JUL-02, This document specifies an Extensible Authentication Protocol (EAP)mechanism for authentication and session key distribution using theUMTS AKA authentication mechanism. AKA is based on symmetric keys,and runs in a UMTS Subscriber Identity Module, a smart card likedevice. AKA provides also backward compatibility to GSMauthentication, making it possible to use EAP AKA for authenticatingboth GSM and UMTS subscribers. "Delay-Tolerant Network Architecture: The Evolving Interplanetary Internet", Vint Cerf, 27-AUG-02, This document describes an architecture for delay-tolerant networks,and is a generalization of the architecture designed for theInterplanetary Internet: a communication system to provide Internet-like services across interplanetary distances in support of deepspace exploration. This generalization addresses networks whoseoperational characteristics make conventional networking approachesbecome either unworkable or impractical. We define a message-basedoverlay that exists above the transport layer of the networks onwhich it is hosted. The draft presents an architectural overviewfollowed by discussions of services, topology, routing, security,reliability and state management. It concludes with a discussion ofend-to-end information exchange, including an example. "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)", P Pate, 25-JAN-02, This document describes a framework for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of circuits (such asT1, E1, T3, E3 and SONET/SDH) and services (such as ATM and FrameRelay) over packet switched networks (PSNs) using IP or MPLS. Itpresents an architectural framework for pseudo wires (PWs), definesterminology, specifies the various protocol elements and theirfunctions, overviews some of the services that will be supported anddiscusses how PWs fit into the broader context of protocols. "The application/ogg Media Type", Linus Walleij, 10-MAY-02, The Ogg Bitstream Format aims at becoming a general freely-availablestandard for transporting multimedia content across computingplatforms and networks. The intention of this document is to definethe media type application/ogg to refer to this kind of content whentransported across the Internet. It is the intention of the OggBitstream Format developers that it be usable without intellectual property concerns. "A BGP/GMPLS Solution for Inter-Domain Optical Networking", Yangguang Xu, 18-JUN-02, Current CCAMP works focus on intra-domain control plane. This document focuses on inter-domain control plane. It views the overall network as a collection of administrative domains, partitioned by operators according to administrative, technological or geographical considerations. This document specifies a BGP/GMPLS based inter-domain solution for setting up circuit LSPs(Label Switched Paths) that span multiple administrative domains. A few extensions and modifications are proposed to BGP in order to disseminate appropriate topology information and calculate end-to-end circuit paths. GMPLS signaling is also extended for the inter-domain connection operations. The solution specified in this draft is fundermental for inter-domain operations and can be used as a base for various applications, e.g. OVPN. It is also very flexible and scalable. "A Search-based access model for the DNS", John Klensin, 05-JUL-02, This memo discusses strategies for supporting 'DNS searching' --finding of names in the DNS, or references that will ultimately pointto DNS names, by a mechanism layered above the DNS itself thatpermits fuzzy matching, selection that uses attributes or facets, anduse of descriptive terms. Demand for these facilities appear to beincreasing with growth in the Internet (and especially the web) andwith requirements to move beyond the restricted subset of ASCII namesthat have been the traditional contents of DNS 'Class=IN'. Thisdocument proposes a three-level system for access to DNS names inwhich the upper two levels involve search, rather than lookup(exactly known target), functions. It also discusses some of theissues and challenges in completing the design of, and deploying,such a system. "IUA (RFC 3057) Outstanding Issues", K Morneault, 28-FEB-02, This document captures problems and issues discovered on the SIGTRANmailing 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, issuesthat 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. "The Hashed URI", Clive Feather, 18-JAN-02, There are situations where it is desirable to determine whether twoURIs 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. "Network Address Translation with Sub-Address(NATS)", Kuniaki Kondo, 28-MAR-02, Networks which are using IPv4 addresses are using the addresstranslation technologies such as NAT at end-networks for variousreasons. However, those technologies sometimes prevent two-waytransparently communications.This document will define a way to enhance address translationtechnologies such as NAT. This way will be able to communicatetransparently by adding a sub-address to IPv4.This enhancement will be called 'NATS'(Network Address Translationwith Sub-Address) in this document. "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", Greg Vaudreuil, 09-AUG-02, The Multipart/Report MIME content-type is a general 'family' or 'container' type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the SMTP extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and this document describing a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. "Enhanced Mail System Status Codes", Greg Vaudreuil, 04-SEP-02, This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. The in combination with other information provided in the DSN delivery report, these codes facilitate media and language independent rendering of message delivery status. "An Extensible Message Format for Delivery Status Notifications", Keith Moore, Greg Vaudreuil, 09-AUG-02, This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called 'LAN-based' systems), the DSN 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 and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support 'tunneling' of foreign notifications through Internet mail. "Controlling the redistribution of BGP routes", Olivier Bonaventure, 01-MAR-02, This document proposes the redistribution extended community. Thisnew extended community allows a router to influence how a specificroute should be redistributed towards a specified set of eBGPspeakers. Several types of redistribution communities are proposed. "XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0", Kevin Zhang, Eitan Elkin, 30-AUG-02, This document defines the CRANE protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and BSS/OSS. The protocol is developed to address the critical needs for exporting high volume of accounting data from NE’s with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. "Procedural Footnote Language Version 1.0", Daniel Myers, 21-MAR-02, This document sets out the proper syntax and usage of the ProceduralFootnote Language (PFL) - a system of adding structured footnoteobjects to a text file. "SMTP Service Extension for Delivery Status Notifications", Keith Moore, 12-SEP-02, This memo defines an extension to the SMTP service, which allows an SMTPclient to specify (a) that delivery status notifications (DSNs) shouldbe generated under certain conditions, (b) whether such notificationsshould return the contents of the message, and (c) additionalinformation, to be returned with a DSN, that allows the sender toidentify both the recipient(s) for which the DSN was issued, and thetransaction in which the original message was sent. "Selection and Sort Extension for SLP", W. Zhao, 30-AUG-02, This document defines the Selection and Sort Extension for theService Location Protocol. These extensions allow a User Agent torequest that the URL entries in a Service Reply be bounded to thespecified number, or be sorted according to the specified sort keylist. Using these two extensions together can facilitate discoveringthe best match. "An IP Traffic Engineering Policy Information Base", Christian Jacquenet, Mohammed Boucadair, 17-JUN-02, This draft specifies a set of Policy Rule Classes (PRC) for the enforcement of an IP traffic engineering policy by COPS-PR ([2])-capable routers. Instances of such classes reside in a virtual information store, which is called the IP Traffic Engineering Policy Information Base (IP TE PIB). The corresponding IP TE policy provisioning data are intended for use by the COPS-PR IP TE Client-Type([3]), and they will complement the PRC classes that have been defined in the Framework PIB ([4]). "Voice-Band Data Media Format", Rajesh Kumar, F. Andreasen, B. Foster, 05-MAR-02, Voice-band data (fax and modem) traffic can often require different processing and as such, the ability to specify a different payload type when passing this type of traffic is important. This document defines a MIME type, audio/vbd for voiceband data media, and a specific 'fmtp' parameter for specifying the underlying encoding. "Diameter Base Protocol MIB", H Li, M Eklund, Jay Koehler, 01-MAR-02, The Diameter base protocol is intended to provide a AAA framework forMobile-IP [17, 18] , NASREQ [16] and ROAMOPS [21]. This draft defines the Management Information Base (MIB) module whichdescribes the minimum amount of objects needed to manage theimplementation of the Diameter base protocol. "Requirements for Network Data Management Protocol Version 5", Harald Skardal, 10-FEB-02, This document describes the proposed requirements for NDMP version 5. This document assumes NDMP version 4 as a starting point. The requirements focus on improved clarity and interoperability, enabling a richer set of data management applications, and broadening the scope of NDMP to become a true Internet protocol. This increased scope increases the need for improved security mechanisms. "Resource Reservation Issues in Cellular Radio Access Networks", David Partain, 20-JUN-02, This memo describes resource management issues that are relevant tothe use of IP transport in cellular radio access networks (RANs).The document describes the particular characteristics of these kindsof networks, the requirements applicable to a resource reservationscheme in a cellular RAN, and provides a brief analysis of theapplicability of existing solutions to this problem space. "Layer 2 VPNs Over Tunnels", K. Kompella, 20-JUN-02, Virtual Private Networks (VPNs) based on Frame Relay or ATM circuitshave been around a long time. While these VPNs work well, the costsof maintaining separate networks for Internet traffic and VPNs andthe administrative burden of provisioning these VPNs have led ServiceProviders to look for alternative solutions. In this document, wepresent a VPN solution where from the customer's point of view, theVPN is based on Layer 2 circuits, but the Service Provider maintainsand manages a single MPLS-based network for IP, MPLS IP VPNs, andLayer 2 VPNs. "GMPLS Signaling Extension to Control the Conversion between Contiguous and Virtual Concatenation for SONET and SDH", E Mannie, D. Papadimitriou, 07-JUN-02, This document is a companion to the GMPLS extensions for SONET and SDH control [GMPLS-SONET-SDH]. It defines a way to control and negotiate the use of converters between contiguous and virtual concatenation in SONET and SDH networks. A new flag in the Requested Contiguous Concatenation (RCC) field is proposed for that purpose. "IPv6 addressing and Stream Control Transmission Protocol", S. Deering, Randall Stewart, 11-APR-02, Stream Control Transmission Protocol [RFC2960] provides transparentmulti-homing to its upper layer users. This multi-homing isaccomplished through the passing of address parameters in theinitial setup message used by SCTP. In an IPv4 network all addressesare passed with no consideration for their scope and routeablility.In a IPv6 network special considerations MUST be made to properlybring up associations between SCTP endpoints that have IPv6[RFC2460] addresses bound within their association. This documentdefines those considerations and enumerates general rulesthat an SCTP endpoint MUST use in formulating both the INIT andINIT-ACK chunks. "Simple Explicit Multicast (SEM)", Ali Boudani, Bernard Cousin, 21-JAN-02, In this document, we propose a new multicast protocol called SEM (Simple Explicit Multicast) or simple Xcast[1]. This protocol uses an efficient method to construct the multicast tree and deliver multicast packets. In order to construct the multicast tree, this protocol usesthe same mecanism as Xcast+[2]. For the delivery of multicast packets it uses the mechanism of branching routers similar to the mechanism used in REUNITE I[3] and REUNITE II[4]. "GMPLS Signalling Extensions for G.709 Optical Transport Networks Control", D. Papadimitriou, D Papadimitriou, 08-MAR-02, This document is a companion to the Generalized MPLS (GMPLS)signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. Itdescribes the G.709 [ITUT-G709] technology specific informationneeded to extend GMPLS signalling to control Optical TransportNetworks (OTN); it also includes the so-called pre-OTNdevelopments. "Traffic Engineering Extensions to OSPF and ISIS for GMPLS Control of G.709 Optical Transport Networks", D Papadimitriou, Germano Gasparini, Gert Grammel, 11-JUN-02, This document introduces the traffic engineering extensions requiredin existing IGP protocols to support sub-sequent signalling forLabel Switched Path (LSP) when using Generalized MPLS signalling asdefined in [GMPLS-SIG] and [GMPLS-G709] for G.709 Optical TransportNetworks (see [GMPLS-G709]). In particular, using [GMPLS-RTG] asguideline, it specifies the GMPLS routing extensions to OSPF and IS-IS protocols for G.709 Optical Transport Networks (OTN).Based on the Traffic Engineering (TE) extensions defined in [OSPF-TE] and [ISIS-TE], the proposed approach supports link bundling asdefined in [MPLS-BDL] and defines several new sub-TLVs for OpticalTransport Network (OTN) control by extending those proposed in[GMPLS-OSPF] and [GMPLS-ISIS]. The proposed encoding does notpreclude any further integration in these documents that the currentone intends to complement. "A grammar for Policies in a Generic AAA Environment", Arie Taal, 05-MAR-02, In this document a formal language is presented to describe poli-cies in the context of a generic AAA environment. We confine thediscussion to so called Driving Policies. A Driving Policy deter-mines the behavior of an AAA Server when it is confronted with aspecific message type of the AAA protocol. "An IPv6 Provider-Independent Global Unicast Address Format", Tony Hain, 06-MAR-02, 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, 06-MAR-02, 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. "IMAP Extension for Conditional STORE operation", Steve Hole, Alexey Melnikov, 02-JUL-02, Often, multiple IMAP clients need to coordinate changes to a commonIMAP mailbox. Examples include different clients for the same user,and multiple users accessing shared mailboxes. These clientsneed a mechanism to synchronize state changes for messages within themailbox. They must be able to guarantee that only one client can changemessage state (e.g., message flags or annotations) at any time. Anexample of such an application is use of an IMAP mailbox as a messagequeue with multiple dequeueing clients.The Conditional Store facility provides a protected update mechanism formessage state information that can detect and resolve conflicts betweenmultiple writers. "Auto-Discovery of VPLS Membership and Configuration Using BGP-MP", Loa Andersson, Tissa Senevirathne, 20-MAY-02, Membership and configuration discovery is a key component in Layer 2VPN infrastructure. This document presents use of BGP-MP extensionsfor VPLS Membership and configuration discovery. More specifically,this document adapts generic VPN discovery methods presented in [2]for VPLS Membership and Configuration discovery. "The 'tag' URI scheme and URN namespace", Tim Kindberg, Sandro Hawke, 02-AUG-02, This document describes the 'tag' Uniform Resource Identifier (URI)scheme and the 'tag' Uniform Resource Name (URN) namespace, foridentifiers that are unique across space and time. Tag URIs (alsoknown as 'tags') are distinct from most other URIs in that they areintended for uses that are independent of any particular method forresource location or name resolution. A tag URI may be used purely asan entity identifier. It may also be presented to services forresolution into a web resource or into one or more further URIs, butno particular resolution scheme is implied or preferred by a tag URIitself. Unlike UUIDs or GUIDs such as 'uuid' URIs and 'urn:oid' URIs,which also have some of the above properties, tag URIs are designedto be tractable to humans. Furthermore, they have many of thedesirable properties that 'http' URLs have when used as identifiers,but none of the drawbacks. "COPS Usage for SLS negotiation (COPS-SLS)", Thi Nguyen, 05-JUL-02, This document describes the use of the Common Open Policy Service(COPS) protocol for supporting Service Level Specification (SLS)negotiation (COPS-SLS). The COPS protocol [COPS] has been defined by the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be used in this memo to communicate SLS information between customer and provider. COPS-SLS can be used at different interfaces such as vertically between a service provider and a network provider or horizontally between network providers in order to decide if the network guarantees a service level for a traffic stream. This version presents COPS-SLS as a candidate protocol for the interface between the Resource Control Domain (RCD) and the Service Control Domain (SCD), according to [SESSION-AUTH] vocabulary. It enables an SCD tovertically reserve RCD resource for its customers. Once resource has been reserved in the RCD, the media session establishment, together with the horizontal resource reservation, follows the steps described in the [AUTHSESSION] framework. Moreover, the respective PDPs have to verify that all the media streams being accepted lie within the bounds of the resource reserved in the RCD by the SCD. "About Unicode Consortium Procedures, Policies, Stability, and Public Access", R McGowan, 21-FEB-02, This memo describes various internal workings of the UnicodeConsortium for the benefit of participants in the IETF. It isintended solely for informational purposes. Included are discussionsof how the decision-making bodies of the consortium work and whattheir procedures are, as well as information on public access to thecharacter encoding & standardization processes. "MGCP Bulk Audits Package", F. Andreasen, D. Auerbach, B. Foster, 28-AUG-02, This document describes an 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. "Considerations from the Service Management Research Group (SMRG) on QoS in the IP Network", Sid Nag, Michael Eder, Hemant Chaskar, 22-JUL-02, The guiding principles in the design of IP network management were simplicity and no centralized control. The best effort service paradigm was a result of the original management principles and the other way around. New methods to distinguish the service given to one set of packets or flows relative to another are well underway. However, as IP networks evolve the management approach of the past may not apply to the QoS-capable network envisioned by some for the future. We examine some of the areas of impact that QoS is likely to have on management and look at some questions that remain to be addressed. "A Model for Context Transfer in IEEE 802", B. Aboba, T. Moore, 08-APR-02, The IEEE 802 Inter-Access Point Protocol (IAPP), under developmentwithin the IEEE 802.11 TgF working group, supports the transfer ofcontext between access points implementing IEEE 802 technology. Thisdocument describes how IAPP can be used to support transfer ofauthentication, authorization and accounting (AAA) context betweendevices supporting IEEE 802.1X network port authentication. Thisspecification is currently being developed within the IEEE 802.11 TgFworking group and is being presented to the IETF for informationalpurposes. "MIME Type Registrations for JPEG 2000", D. Singer, 20-JUL-01, This document serves to register and document the standard MIME typesassociated with JPEG 2000 files, Motion JPEG 2000 files, and Multi-layer JPEG 2000 files "Quality of Service Extension to IRML", Chan Ng, 19-FEB-02, The Intermediary Rule Markup Language (IRML) [2] is an XML-based language that can be used to describe service-specific execution rules for network edge intermediaries under the Open Pluggable Edge Services (OPES) framework, as described in [3] and [4]. This memo illustrates examples of employing the IRML for Quality of Service (QoS) policing and control, and proposes a QoS sub-system extension to IRML for better QoS support in the OPES framework. "Connecting IPV6 islands within a same IPV4 AS", Geoffrey Cristallo, 01-MAR-02, This draft proposes a mechanism that allows an incremental deploymentof IPv6 inside an IPv4 AS. It aims at automatically set up tunnels,using EGP standard capabilities, in order to gradually introduce IPv6connectivity within an initially IPv4 AS. From a scope point of view,this technique must be considered as an intermediary between ISATAP andinterdomain techniques ([6to4], [BGP-tunnel]). "Expanded Simulation Models for IntServ and DiffServ with MPLS", Mark Pullen, 07-MAR-02, This document describes detailed models for analysis of proposedprotocols for Quality of Service (QoS) delivery with IPv4 (includingmulticast). 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, andMPLS. This Internet-Draft is intended to form the basis for an Informational RFC that extends the previous RFC2490. "IP measurement MIB", Emile Stephan, 01-FEB-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 a registry of the IPPM working group metrics and specifies the objects used for managing IPPM metrics measures, for pushing alarms and for reporting the measures results. "Pseudo Wire (PW) Management Information Base", S. Park, 01-MAR-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 of Pseudo Wire (PW) services on a general Packet Switched Net (PSN). "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Management Information Base Using SMIv2", Dave Danenberg, 03-JUN-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 an adaptation of SONET/SDH circuits over a Packet Switch Network (PSN). "Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks", Jerry Ash, 18-JUN-02, Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101]. The problem addressed is to enable link-state protocols to a) gracefully recover from massive loss of topology database information, and b) respond gracefully to network overloads and failures. This contribution proposes specific additional considerations for network congestion control/failure recovery. Candidate mechanisms are proposed for control of network congestion and failure recovery, in particular we initially propose to investigate the following mechanisms:a) throttle new connection setups, topology-state updates, and Hello updates based on automatic congestion control mechanisms, b) special marking of critical control messages (e.g., Hello andtopology-state-update Ack) so that they may receive prioritized processing,c) database backup, in which a topology database could be automatically recovered from loss based on local backup mechanisms, and d) hitless restart, which allows routes to continue to be used if there is an uninterrupted data path, even if the control path is interrupted due to a failure.We propose that the OSPF and ISIS working groups include the candidatemechanisms in an evaluation of congestion control/failure recovery for OSPF and ISIS networks. "Whois Domain Data using the Lightweight Directory Access Protocol (LDAP)", A Newton, 01-JUL-02, Domain registration data has typically been exposed to the generalpublic via whois for administrative purposes. This documentdiscusses the application of the Lightweight Directory AccessProtocol (LDAP) and well-known LDAP types to make available Domainregistration data. "Simple Notification and Alarm Protocol (SNAP)", Noam Shapira, 01-JUL-02, This memo suggests a protocol for messaging notification inwhich 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 messagearrived, mailbox is full, etc.). The protocol aims to provide theend-user with unified notification of events occurring on differentmessaging systems.A mailing list has been established to discuss this draft andpromote the issue of Notification to RFC. To subscribe, sendemail with 'subscribe snap' to majordomo@lists.neystadt.orgor using web at http://www.neystadt.org/cgi-bin/majordomo. "Supporting Optimized Handover for IP Mobility -Requirements for Underlying Systems", Alper Yegin, 02-JUL-02, A critical factor in achieving good performance for IP mobility protocols is the design of L2 handover. Handover occurs when a Mobile Node moves from one radio Access Point to another. If the new radio Access Point is associated with a new subnet, a change in routing reachability may occur and require L3 protocol action on the part of the Mobile Node or Access Routers. If no change in subnet occurs, the Access Point may still need to take some action to inform the Access Router about a change in on-link reachability. In either case, prompt and timely information from L2 to the parties involved about the sequencing of handover can help optimize handover at the IP level. This draft discusses requirements for an L2 handover protocol or API to support optimized handover. "Multicast Router-Switch Protocol (MRSP)", Tony Ballardie, Chris Fletcher, 28-JAN-02, MRSP is a layer 2 protocol that runs over Ethernet. Together withminor enhancements to PIM-SM [PIM] and PIM-SSM [SSM] it can be usedto build uni-directional multicast forwarding state in EthernetSwitches that interconnect IP multicast routers. "Application of Integrated Services on Wireless Accesses", Brian Williams, Gabor Fodor, Fredrik Persson, 28-JAN-02, We consider a scenario wherein a QoS enabled application uses anIntegrated Services based API (IntServ). Where the networkinterface is over a cellular wireless access network, we examine thefeasibility of the radio management function to establishappropriate spectrum efficient bearers to support the requestedservice. "Proposal on new service parameters (wireless hints) in the controlled load integrated service", Brian Williams, Gabor Fodor, Fredrik Persson, 28-JAN-02, This report is the sequel of previous work [WI-INTSERV], where themajor issues related to establishing radio bearers suitable forIntegrated Services (IntServ) over wireless access networks ingeneral were identified and discussed. "Definitions for Textual Conventions and OBJECTCT-IDENTITIES for Pseudo-Wires Management", A. Malis, Dave Danenberg, Thomas Nadeau, S. Park, 28-FEB-02, This memo describes Textual Conventions and OBJECT-IDENTITIES usedfor managing Pseudo-Wire services "Light-weight Flow Accounting Protocol Specification Vrsion 5.0", M. MacFaden, P. Calato, 25-JUL-02, The Lightweight Flow Accounting Protocol (LFAP) is an operationsand management protocol that provides detailed information aboutIPv4 and Ipv6 packets traversing a network element. The primaryfunction of LFAP is the reliable delivery of large volumes ofpacket header derived information from a network element, termedConnection Control Entity (CCE) to a Flow Accounting Server (FAS)of current or historical flows for billing, capacity planningsecurity, or traffic engineering purposes. "Light-weight Flow Accounting Protocol Data Definition Specification Version 5.0", M. MacFaden, P. Calato, 25-JUL-02, The Light-weight Flow Accounting Protocol Data DefinitionSpecification defines the data which may be sent via the Light-weight Flow Accounting Protocol transport. LFAP transport and LFAPData Definition, allow an external Flow Accounting Service (FAS) torecord flow accounting information from a Connection Control Entity(CCE), allowing flexible Flow Accounting Services to be deployed bya vendor or customer without changes to, or undue burden on, theCCE.Specifically, this document specifies the data that may beexchanged between the CCE and the external FAS. Using LFAP, a FAScan maintain details of current or historical flows for billing,capacity planning and other purposes "Domain Name Auto-Registration for Plugged-in IPv6 Nodes", Hiroshi Kitamura, 03-JUL-02, This document describes a scheme of 'Domain Name Auto-Registrationfor Plugged-in IPv6 Nodes' mechanism that makes it possible toregister 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-basedaddresses are too complicated to remember, there are strongrequirements to use logical names that are easy to remember insteadof IPv6 addresses to specify IPv6 nodes and to register domain nameinformation of plugged-in IPv6 nodes automatically.In order to meet the requirements, a mechanism is proposed as one ofthe IPv6 auto-configuration (plug and play) functions. After theAddress Autoconfiguration [ADDR-AUTO] has been executed, it works asa succeeding plug and play mechanism.This document clarifies problems that we meet when we apply theDynamic Updates in the DNS [DYN-DNS] to automatic domain nameinformation registration mechanisms. This document proposes theDomain Name Auto-Registration mechanism as a solution to theseproblems. "COPS client-type for Active Networks", Yacine Mghazli, Oliver Marce, 05-JUL-02, This draft specifies a COPS (Common Open Policy Service, [COPS]) client-type designed for the enforcement of policy of Active IP Networks (AN) based on Extensible Routers (ER). The usage of this AN COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes (COPS-PR, [COPS-PR]). "Assigning Experimental and Testing Numbers Considered Useful", Thomas Narten, 28-JUN-02, When experimenting with or extending protocols, it is often necessaryto use some sort of protocol number or constant in order to actuallytest or experiment with the new function, even when testing in aclosed environment. For example, to test a new DHCP option, one needsan option number to identify the new function. This documentrecommends that when writing IANA Considerations sections, authorsshould consider assigning a small range of numbers forexperimentation purposes that implementers can use when testingprotocol extensions or other new features. This document reservessome ranges of numbers for experimentation purposes in specificprotocols where the need to support experimentation has beenidentified. "Publicly Verifiable Nomcom Random Selection", Donald Eastlake, 28-NOV-01, This document describes a method for making random selections in sucha way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases. "Generic RTP Payload Format for Time-lined Static Media", Magnus Westerlund, 08-JAN-02, This Internet Draft discusses an RTP payload format for time-linedstatic media. 'Time-lined static media' means static media objectslike pictures and text extended by timing information. Applicationsthat would benefit from such a payload format are for instanceslideshow streaming and streaming of subtitled video and audio. Wediscuss the important requirements for a payload format and propose aspecification that suits those requirements. "Service Lookup System (SLS)", M. Mealling, Leslie Daigle, 03-JUL-02, Developing technology to allow for truly internationalized Internetidentifiers is proving a hard nut to crack within the framework ofthe existing DNS. At the same time, the DNS continues to do anexcellent job at serving its original mandate for providing efficientmappings between machine-readable labels and network resources. Whatis not clear is whether the existing DNS can be transformed into aservice that can handle the more human oriented identificationservices it is now being asked to provide. This document embraces,extends and complements a proposal by John Klensin to address therequirements for a directory layer above the existing DNS that canbetter solve these problems. The discussion concludes by proposing astrawman called the Service Lookup System (SLS). "Opportunistic Encryption using The Internet Key Exchange (IKE)", D. Hugh Redelmeier, Michael Richardson, 28-AUG-02, This document describes opportunistic encryption (OE) using theInternet Key Exchange (IKE) and IPsec. Each system administratoradds new resource records to his or her Domain Name System (DNS) tosupport opportunistic encryption. The objective is to allowencryption for secure communication without any pre-arrangementspecific 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 squareof the number of systems to a linear dependence, and it becomespossible to make secure communication the default even when thepartner 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 isreduced from the square of the number of systems to a lineardependance. Second, it becomes possible to make secure communicationthe default, even when the partner is not known in advance.This document is offered up as an Informational RFC. "Filters for Mobile IP Bindings (NOMAD)", N. Fikouras, 31-JUL-02, In Mobile IP, a mobile node that maintains simultaneous bindings willreceive at each registered care-of address a duplicate copy of every datagram from every active flow. However, a mobile node with multiple points of attachment may wish to receive different flows at each one. The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishment (registration, binding update). In this manner, a mobile node may select for each flow the most appropriate point of attachment. In order not to violate layer independence, the filtering of individual flows or groups of them is managed through flow description components made available by existing approaches to QoS support. "Per-flow movement in MIPv6", C. Castelluccia, K. Malki, H. Soliman, 05-JUL-02, The aim of this draft is to introduce a new extension to MIPv6 toallow hosts to direct inbound flows individually to certain preferredinterfaces. This extension to MIPv6 allows multi-homed hosts to takefull advantage of the diverse access technologies that they may beconnected to and direct their traffic according to internal policiesspecified by the users or applications. "A Framework for MPLS User Plane OAM", David Allan, Mina Azad, 23-MAY-02, This Internet draft discusses many of the issues associated withuser plane OAM for MPLS. The goal being to provide tools to perform'in service' maintenance of LSPs. Included in this discussion issome of the implications of MPLS architecture on the ability tosupport fault, diagnostic and performance management OAMapplications, potential solutions for distinguishing user plane OAM,and a summary of what the authors believe can be achieved.This framework is predicated on requirements described in [HARRISON- REQ]. "RSVP Path computation request and reply messages", J Vasseur, 21-JUN-02, This document describes extensions to RSVP-TE to support a new message type called a 'Path computation' message. This message is tobe used between an LSR and a Path Computation Server, which may be an LSR or a centralized path computation tool. An RSVP Path Computation Request message is used by the head-end LSR to send its request to the Path Computation Server. The Path Computation Server in turn sends an RSVP Path Computation Reply message containing either: - a positive reply, containing one or more paths, if the request can be satisfied. - a negative reply if no path obeying the requested constraints can be found. The Path Computation Server may also optionally suggest new constraint values for which one or several paths could be found. There are many situations where a Path Computation Server may be used. A typical example is in the context of Inter-area MPLS TE. A head-end LSR could request that a Path Computation Server compute one or more paths obeying a specified set of constraints for a TE LSP spanning multiple areas. The path computation server could be a centralized path computation server or an ABR. Another example is the use of a Path Computation Server to compute diversely routed paths between two end points. This may be useful in the context of MPLS TE LSP Path protection or GMPLS LSP Path protection. The computation of Multi-constraints paths requires intensive CPU resources, and may be yet another usage example. Lastly, those protocol extensions could be used as a 'UNI' like protocol between a CE (Customer Edge equipment) and a PE (Provider Edge equipment) where the CE is not part of the PE's IGP domain. "RTP retransmission framework", David Leon, Victor Varsa, 05-MAR-02, RTP retransmission is an effective packet loss recovery scheme forreal-time applications with relaxed delay bounds. "Internet General Packet Radio Service (IGPRS) Service Description", Hossam Afifi, 01-MAR-02, We describe a protocol architecture for the integration of MobileIPv6 into the GPRS architecture (UMTS version). The goal of thisarchitecture is to provide mobility management and authenticationto native IP protocols through the legacy cellular signaling "Universal Emergency Address for SIP-based Internet Telephony", H. Schulzrinne, 29-MAY-02, This document defines a universal emergency SIP URL, sip:sos@domain,that allows SIP user agents to contact the local emergency number. "The SLP Service and Remote Discovery in SLP", W. Zhao, 26-MAR-02, This document describes remote discovery in the Service LocationProtocol (SLP) via DNS SRV. It defines the 'service:slp' template andthe name of DNS SRV RR for the SLP service, describes the usage ofGateway Directory Agents, and gives the steps for a User Agent todiscover desired services in a remote DNS domain. "S/MIME Gateway Protocol", B. Ramsdell, 03-JUL-02, In addition to desktop-to-desktop security, S/MIME can be used forserver-to-server encryption between cooperating domains. This documentwill describe a method for implementing server-to-server (gateway)encryption with S/MIME. "Tunnel Setup Protocol (TSP)A Control Protocol to Setup IPv6 or IPv4 Tunnels", Marc Blanchet, 05-JUL-02, This document proposes a control protocol to setup tunnels between aclient and a tunnel server or broker. It provides a framework forthe negociation of tunnel parameters between the two entities. It isa generic TCP protocol based on simple XML messaging. This frameworkprotocol enables the negociation of any kind of tunnel, and isextensible to support new parameters or extensions. The first targetapplication is to setup IPv6 over IPv4 tunnels which is one of thetransition mechanism identified by the ngtrans and ipv6 workinggroups. This IPv6 over IPv4 tunnel setup application of the genericTSP protocol is defined by a profile of the TSP protocol, in acompanion document. "Datagram Congestion Control Protocol (DCCP)", Mark Handley, Sally Floyd, Jitendra Padhye, Eddie Kohler, 03-JUL-02, This document specifies the Datagram Congestion ControlProtocol (DCCP), which implements a congestion-controlled,unreliable flow of datagrams suitable for use by applicationssuch as streaming media. "Profile for DCCP Congestion Control ID 3:TFRC Congestion Control", Sally Floyd, Jitendra Padhye, Eddie Kohler, 03-JUL-02, This document contains the profile for Congestion ControlIdentifier 3, TCP-friendly rate control (TFRC), in theDatagram Congestion Control Protocol (DCCP). DCCP implementsa congestion-controlled unreliable datagram flow suitable foruse by applications such as streaming media. The TFRC CCID isused by applications that want a TCP-friendly send rate,possibly with Explicit Congestion Notification (ECN), whileminimizing abrupt rate changes. "Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control", Sally Floyd, Eddie Kohler, 28-MAY-02, This document contains the profile for Congestion ControlIdentifier 2, TCP-like Congestion Control, in the DatagramCongestion Control Protocol (DCCP) [DCCP]. DCCP implements acongestion-controlled, unreliable flow of datagrams suitablefor use by applications such as streaming media. The TCP-likeCongestion Control CCID is used by senders who are able toadapt to the abrupt changes in the congestion window typicalof the AIMD (Additive Increase Multiplicative Decrease)congestion control in TCP. TCP-like Congestion Control isparticularly useful for senders who would like to takeadvantage of the available bandwidth in an environment withrapidly changing conditions "IPv6 over IPv4 profile for Tunnel Setup Protocol (TSP)", Marc Blanchet, 05-JUL-02, This document proposes a tunnel profile to setup IPv6 over IPv4tunnels to be used with the Tunnel Setup Protocol (TSP) [8]. "Dynamic Service Negotiation Protocol (DSNP)", Jyh-Cheng Chen, 10-JUN-02, This memo presents the specification of Dynamic Service NegotiationProtocol (DSNP). DSNP is a protocol to negotiate the SLS (ServiceLevel Specification) in IP layer. It can be used for servicenegotiation from host to network, network to host, and network tonetwork. The automated negotiation makes service negotiationefficient in terms of time, cost, and correctness, etc. The dynamicnegotiation not only allows users to adapt their needs dynamically,but also let providers better utilize the network. The DSNPmessages and packet formats are detailed. DSNP can be used in bothwireline and wireless networks. It is, however, particularlyuseful in mobile environment. To demonstrate the usefulness ofDSNP, a reference wireless QoS architecture is presented.Exemplary applications are illustrated. "SIP Event Packages for Call Leg and Conference State", J. Rosenberg, H. Schulzrinne, 07-MAR-02, This document defines two new event packages for the SIP Eventsarchitecture, along with two new data formats used in notificationsfor those packages. The first is a call-leg package, and the secondis a conference package. The call-leg package allows users tosubscribe to another user, an receive notifications about the changesin state of call legs that the user is involved in. "Simultaneous Bindings for Mobile IPv6 Fast Handoffs", K. Malki, H. Soliman, 01-JUL-02, Fast Handover for Mobile IPv6 [1] and Bidirectional Edge TunnelHandover [2] describe protocols to minimise the amount of servicedisruption when performing layer-3 handoffs. This draft extends theFast Handover protocol with a simultaneous bindings function and theBETH capabilities with a bicasting function to minimise packet lossat the MN. Traffic for the MN is therefore bicast or n-cast for ashort period to its current location and to one or more locationswhere the MN is expected to move to shortly. This removes the timingambiguity regarding when to start sending traffic for the MN to itsnew point of attachment followng a Fast Handover and allows thedecoupling of layer-2 and layer-3 handoffs. It also saves the MNperiods of service disruption in the case of ping-pong movement. "Diameter Mobile IPv6 Application", Stefano Faccin, 12-SEP-02, Mobile IPv6 capable mobile nodes can roam between networks thatbelong to their home service provider as well as others. Roaming inforeign networks is enabled as a result of the service level androaming agreements that exist between operators. One of the keyprotocols that allows this kind of a roaming mechanism to be enabledis Diameter. This Internet Draft specifies a new application toDiameter that enables Mobile IPv6 roaming in networks other than itshome. "Basic Network Media Services with SIP", E. Burger, Jeff Van Dyke, Walter O'Connor, Andy Spitzer, 02-JUL-02, In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, conferencing, and transcoding 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. "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Michael Roe, 04-MAR-02, This memo describes three protocols that may be used forauthenticating binding updates in mobile IPv6. "The Simple Proof Supporting the Findaings from the Logical Analysis of the Binary System Which disposes the Logical Dispute fostered by Modern Interpretation for Counting in Binary Notation", Eugene Terrell, 14-DEC-01, The simple proof outlined in this presentation, regarding theLogical Analysis of the Binary System, and the argumentconcerning the Logical Derivation of the New Method forEnumeration, which disputes the Modern Interpretation forthe Binary System, as being illogical and incorrect. "Internet Protocol, Version 64 (IPv64) Specification", Arturo Azcorra, 12-APR-02, This document specifies an IPv6 protocol extension that allows IPv6 packets to be backward compatible with IPv4. An IPv6 packet encapsulated in IPv4 in this way (called IPv64) would be processed as native IPv6 by IPv6 routers, and at the same time, in case there is an IPv4-only router in the path, it will be processed as IPv4. Consequently, it is possible to have native end-to-end IPv6 communication, with IPv6 processing at IPv6 routers, through a path that contains some IPv4-only routers. Protocol conversion from/to IPv6 to/from IPv64 is made at edge routers, and therefore the advantages of IPv64 are achieved with standard native IPv6 hosts "Assignment of the 'OAM Alert Label' for MPLS Operation and Maintenance (OAM) functions", H Ohta, 13-SEP-02, This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'OAM Alert Label' that is used by user-plane MPLS Operation and Maintenance (OAM) functions for identification of MPLS OAM packets. "Protected EAP Protocol (PEAP)", G. Zorn, D. Simon, A. Palekar, S. Josefsson, H. Andersson, 13-SEP-02, The Extensible Authentication Protocol (EAP), defined in RFC 2284,provides for support of multiple authentication methods. While EAP wasoriginally created for use with PPP, it has since been adopted for usewith IEEE 802.1X 'Network Port Authentication'.Since its deployment, a number of weaknesses in EAP have becomeapparent. These include lack of protection of the user identity,notification messages or the EAP negotiation; no standardized mechanismfor key exchange; no built-in support for fragmentation and reassembly;no support for acknowledged success/failure indications; and lack ofsupport for fast reconnect.By wrapping the EAP protocol within TLS, Protected EAP (PEAP) addressesthese deficiencies. Any EAP method running within PEAP is provided withbuilt-in support for key exchange, session resumption, acknowledged andprotected result exchange, and fragmentation and reassembly. "Datatypes for WebDAV properties", Julian Reschke, 25-JUN-02, This specification extends the Web Distributed Authoring Protocol(WebDAV) to support datatyping on property values. Protocol elementsare defined to let clients and servers specify the type of aproperty, and to instruct the WebDAV method PROPFIND to returndatatype information.Distribution of this document is unlimited. Please send comments tothe Distributed Authoring and Versioning (WebDAV) working group atw3c-dist-auth@w3.org, which may be joined by sending a message withsubject '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/. "Cryptographic Message Syntax for MP3/MPEG I, II, and III Secure MPEG (SMPEG)", Jahanzeb Khan, Manish Gaur, 17-AUG-01, This document describes a 'cryptographic message syntax for representing encrypted MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as 'MP3')'. "The HTTP header for the Platform for Privacy Preferences 1.0 (P3P1.0)", Ran Lotenberg, Massimo Marchiori, 05-FEB-02, The Platform for Privacy Preferences 1.0[4] (P3P1.0) specificationdescribes how to associate a privacy policy with each URI request.Such associations are contained in a so-called policy referencefile. This draft describes a new HTTP response header whichindicates the location of such policy reference file. This header isintended to be a part of the P3P1.0 framework and should be treatedin the full context of the P3P1.0 specification[4]. "'duri' and 'tdb': URN namespaces based on dated URIs", L. Masinter, 25-APR-02, This document defines two namespaces of URNs, based on using atimestamp with an (encoded) URI. The results are namespaces in whichnames are readily assigned, offer the persistence of reference thatis required by URNs, but do not require a stable authority to assignthe name. The first namespace ('duri') is used to refer to URI-identified resources as they appeared at a particular time. Thesecond namespace ('tdb') is useful as a way of creating URNs thatrefer to physical objects or even abstractions that are notthemselves networked resources.The definition of these namespaces may reduce the need to define newURN namespaces merely for the purpose of creating stable identifiers. "Message Disposition Notification", Tony Hansen, Greg Vaudreuil, 16-APR-02, 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", H. Schulzrinne, W. Zhao, 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 gatewayservice, and discusses the different usage scenarios and theapplicability of SLP for the Internet telephony gateway location. "Using Serial Item and Contribution Identifiers as Unifirm Resource Names", Juna Hakala, 07-AUG-02, This document discusses how Serial Item and Contribution Identifiers (SICIs; persistent and unique identifiers for serial issues and contributions such as articles) can be supported within the URN framework and the syntax for URNs defined in RFC 2141 [Moats]. Much of the discussion below is based on the ideas expressed in RFC 2288 [Lynch]. Chapter 5 contains a URN namespace registration request modelled according to the template in RFC 2611 [Daigle et al.]. "Storing application public keys in the DNS", J. Schlyter, 13-FEB-02, This document specifies a new DNS RR type for applications to storepublic keys in. Experience with DNSSEC has indicated that mixing DNSkeys and application keys is a bad idea in many regards. The new RRexpands certain fields based on experience from early DNSSECdeployment. "DHCP Options for Service Location Protocol", E. Guttman, 13-AUG-02, The Dynamic Host Configuration Protocol provides a framework forpassing configuration information to hosts on a TCP/IP network.Entities using the Service Location Protocol need to find out theaddress of Directory Agents in order to transact messages. Anotheroption provides an assignment of scope for configuration of SLP Userand Service Agents. This document simplifies and clarifies RFC 2610. "The SIP Negotiate Method", Sriram Parameswar, Brian Stucker, 16-APR-02, There is a need to negotiate a multitude of parameters, settings, and algorithms when setting up sessions using Session Initiated Protocol (SIP). While SIP itself provides mechanisms for negotiation of these parameters on a per-session basis through theuse of the INVITE method, it does not provide a ready mechanismfor meta-session negotiation. The closest mechanism provided is the REGISTER method, however, this method is directed towards the registrar alone, and cannot be used to conduct negotiation of parameters between any two arbitrary SIP nodes. "Multihoming issues in the Stream Control Transmission Protocol", Lode Coene, 20-FEB-02, This document describes issues of the Stream Control TransmissionProtocol (SCTP)[RFC2960] in regard to multihoming on theInternet. It explores cases where through situations in theinternet, single points-of-failure can occur even when usingmultihoming and what the impact is of multihoming on the routingtables of the host. "Using DNS for VPN Discovery", James Luciani, 05-MAR-02, Virtual private networks are becoming a common service offered by service providers. There are many technologies over which to implement a VPN service, ranging from IPSec to GRE to MPLS. A common requirement of the VPN methodologies 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 means for site discovery that is independent of any signaling protocol. "TDM Service Specification for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", Ron Cohen, P Pate, S. Park, 22-JAN-02, This document describes the service-specific implementation andrequirements for Pseudo-Wires Emulation Edge-to-Edge (PWE3) of TDMcircuits. It discusses the emulation of circuits (such as T1, E1, T3and E3) over packet networks using IP, L2TP or MPLS. "Bounding Longest Match Considered", T Hardie, Russ White, 13-DEC-01, Some ASes currently use length-based filters to manage the size ofthe routing table they use and propagate. This draft explores analternative to length-based filters which allows for more automaticconfiguration and which provides for better redundancy.Rather than use a filter, this draft proposes a method of modifyingthe BGP longest match algorithm by setting a bound on the prefixlengths eligible for preference. A bound would operate on longprefixes when covering route announcements are available; in certaincircumstances it would cause a router to prefer an aggregate over amore specific route announcement. "COPS applicability as the MIDCOM protocol", C. Aoun, 10-MAY-02, This draft discusses the applicability of the COPS protocol as the MIDCOM protocol, in the context of the current protocol evaluations within the MIDCOM working group. It discusses the architectural similarities between COPS and Midcom and how COPS meets most of the MIDCOM protocol requirements. "Quota and Size Properties for DAV Collections", Claudia Warner, Lisa Dusseault, 08-JAN-02, 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. "SMQP: Simple Message Queue Protocol", J Tegen, 23-JUL-02, 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. "Applicability of MEGACO to Middlebox Control", Tom Taylor, C. Aoun, S. Sen, 13-MAY-02, This draft discusses the applicability of the Megaco/H.248 device control protocol [1] as the Middlebox communication protocol. It discusses the architectural similarities between Megaco and Midcom and how Megaco meets most of the key requirements for the Midcom protocol. Modeling the underlying Middlebox resources (such as, filters, policy rules etc) as separate elements from the Megaco entities allows the usage of the protocol as-is, satisfying some of the resource access control requirements. Minimal extensions in the form of new Termination/Package definition (without impacting the base protocol) are sought for Midcom. The Midcom protocol profile and other extensions/packages will be specified in a separate internet draft. "TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Sasha Vainshtein, 27-JUN-02, This document describes a method for encapsulating TDM digital signals defined in the plesiochronous digital hierarchy (PDH) as a pseudo-wire (PW) over various packet-switched networks (PSN). In this regard it complements similar work for SONET/SDH circuits. Proposed PW encapsulation uses RTP for clock recovery and leverages it for application state signaling between Customer Edge (CE) devices. "HTTP Authentication: SPNEGO Access Authentication", John Brezak, 01-MAR-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. "SONET/SDH Circuit Emulation over Packet (CEP)", A. Malis, S. Park, 17-JUN-02, Generic requirements and framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3-FW]. This draft provides encapsulation formats and semantics for connecting SONET/SDH edge networks through a packet network using IP or MPLS. This basic application of SONET/SDH interworking will allow service providers to take advantage of new technologies in the core in order to provide traditional SONET/SDH services. "PWE3: ATM service description", John Fischer, 06-MAR-02, Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)have been described in [6]. This draft lists ATM specificrequirements and provides encapsulation formats and semantics forconnecting ATM edge networks through a core packet network using IP,L2TP or MPLS. This basic application of ATM interworking will allowATM service providers to take advantage of new technologies in thecore in order to provide ATM multi-services. "Security Considerations for 6to4", P. Savola, 04-MAR-02, The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4tunneling to interconnect IPv6 networks. The architecture includesRelay Routers and Routers, which accept and decapsulate IPv4 trafficfrom anywhere. There aren't many constraints on the embedded IPv6packets, 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 Relays asreflectors. This document discusses these issues and tries tosuggest enhancements to alleviate the problems. "RTTP: Properties of a real-time protocol", Dimitar Aleksandrov, 07-JAN-02, The purpose of this document is to provide ideas for real-time communications in Internet. This document doesn't expand any pre-defined standards or practices, it also doesn't conform ones. This document contains a separate idea for real-time data delivery. "Registration procedures for message header fields", J Mogul, Mark Nottingham, Graham Klyne, 10-JUN-02, This specification defines registration procedures for the messageheader fields used by Internet mail, HTTP, news and otherapplications.Please send comments to . To subscribe, send amessage with body 'subscribe' to . "Preparation of Internationalized Strings ('stringprep')", Paul Hoffman, Marc Blanchet, 31-JUL-02, This document describes a framework for preparing Unicode text stringsin order to increase the likelihood that string input and stringcomparison work in ways that make sense for typical users throughout theworld. The stringprep protocol is useful for protocol identifier values,company and personal names, internationalized domain names, and othertext strings.This document does not specify how protocols should prepare textstrings. Protocols must create profiles of stringprep in order to fullyspecify the processing options. "Frame Relay Transport and Encapsulatiion over Psevdo-Wires", A. Malis, P Pate, Ravi Bhat, Nishit Vasavada, Claude Kawa, 15-APR-02, This document defines frame relay pseudo-wire specific aspects. A frame relay pseudo wire exists between network edge nodes and support as faithfully as possible an instance of a frame relay service. A frame relay pseudo-wire is a mechanism that allows frame relay protocol control information and payload to be carried over IP or MPLS Packet Switched Networks. "STUN - Simple Traversal of UDP Through NATs", J. Rosenberg, C. Huitema, R. Mahy, J. Weinberger, 07-MAR-02, Simple Traversal of UDP Through NATs (STUN) is a lightweight protocolthat allows applications to discover the presence and types ofNetwork Address Translators (NATs) and firewalls between them and thepublic Internet. It also provides the ability for applications todetermine the public IP addresses allocated to them by the nat. STUNworks with nearly all existing NATs, and does not require any specialbehavior from them. As a result, it allows a wide variety ofapplications to work through existing NAT infrastructure. The STUNprotocol is very simple, being almost identical to echo. "Towards a Network-friendlier Midcom", Melinda Shore, 28-JUN-02, While IP was designed around the notion that the network would beinvisible to the applications that run on them, an increasinglycomplex service environment along with the compartmentalization of'policy' into administrative domains has led to a proliferation oftypes of middleboxes for policy enforcement, and those middleboxesare interfering with applications. Applications now need to influ-ence the behavior of middleboxes, but violating network layeringprinciples by establishing explicit communication channels fromapplications to network-layer middleboxes introduces a new set ofproblems related to topology and discovery as well as consequentproblems that ripple out from those. This paper is an introductoryexamination of whether or not there is a better way. "Computing the CHECKIN URI in WebDAV versioning", Julian Reschke, 06-MAY-02, In many cases, a versioning-aware client might want todisplay/include the URI of the version it's editing while it's beingedited. For instance, an editor might include this as metainformation, or the author of a document might want to know the URIof the version before it's checked in. A well-known example is theW3C way of referring to document versions in recommendations: itcontains references to 'the current version', to 'this version' andto the 'previous version'. Something like this is currentlyimpossible with WebDAV versioning [RFC3253], as the version URI isdetermined at the time of CHECKIN.Distribution of this document is unlimited. Please send comments tothe WebDAV versioning (delta-V) mailing list at ietf-dav-versioning@w3.org, which may be joined by sending a message withsubject '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/. "Midcom-unaware NAT/Firewall Traversal", Pat Sollee, S. Sen, Sean March, 03-MAY-02, Bundled session applications such as FTP, H.323, SIP and RTSP, which use a signaling/control connection to establish a data/media flow, are usually broken, en-route, by Middleboxes such as NAT. Midcom proposes to solve this problem by allowing the Middlebox to be controlled through a generalized control interface by an application-aware entity called Midcom Agent. Since ubiquitous deployment of Midcom is still a few years away, an interim solution is needed to allow applications traverse NAT and Firewalls seamlessly without the help of embedded Application Layer Gateways (ALG). In this draft, a pre-Midcom solution framework is developed. A solution for the problem of NAT/FW traversal is needed both for the signaling and media/data paths. Two key components of the proposed solution are: (1) a Signaling Proxy server on the signaling path, and (2) a Media Proxy server on the media path. The Signaling server interacts with the Media server through a control interface. Although the primary applicability of this framework is shown for real-time RTP/UDP-based SIP multimedia sessions, these concepts should be generally applicable to other types of data sessions established through a control connection. "Including additional properties in WebDAV PROPFIND/allprop requests", Julian Reschke, Stefan Eissing, 29-AUG-02, Recent specifications extending the Web Distributed AuthoringProtocol (WebDAV) restrict the set of properties returnedautomatically upon a PROPFIND/allprop request. This specificationdefines a method to add specific properties to the set of propertiesreturned upon PROPFIND/allprop. "Host-Centric IPv6 Multihoming", C. Huitema, Richard Draves, 27-JUN-02, A way to solve the issue of site multihoming is to have a separatesite prefix for each connection of the site, and to derive as manyaddresses for each hosts. This approach to multi-homing, which wecall Host-Centric IPv6 Multihoming, has the advantage of minimalimpact on the inter-domain routing fabric, since each site prefix canbe aggregated within the larger prefix of a specific provider;however, it opens a number of issues, which we will discuss in thismemo, including the problem created by the interaction betweeningress filtering and multihoming, which we analyze in detail. Wethen propose a set of specific solutions that enable host centricmultihoming, and we review how these solutions meet the requirementsof IPv6 site multihoming. "3GPP requirements on SIP", Miguel Garcia, 04-MAR-02, The 3rd Generation Partnership Project (3GPP) has selected SIP [3] as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IM CN Subsystem). "ICAP the Internet Content Adaptation Protocol", Alberto Cerpa, Jeremy Elson, 07-JUN-02, ICAP, the Internet Content Adaption Protocol, is a protocol aimedat providing simple object-based content vectoring for HTTPservices. ICAP is, in essence, a lightweight protocol forexecuting a 'remote procedure call' on HTTP messages. That is, itallows ICAP clients to pass HTTP messages to ICAP servers for somesort of transformation or other processing ('adaptation'). Theserver executes its transformation service on messages and sendsback responses to the client, usually with modified messages.Typically, the adapted messages are either HTTP requests or HTTPresponses. "Security of IPv6 Routing Header and Home Address Options", P. Savola, 04-MAR-02, All IPv6 nodes must be able to process Routing Header [IPV6] and HomeAddress [MIPV6] Options. With these, packet filter access lists canbe tricked (among other things) as the destination and sourceaddresses, respectively, are being rewritten as the packet traversesthe network. Some of the security considerations of these featuresare analyzed, and a few possible solutions presented. "LMP, LDP and RSVP Extensions for Optical UNI Signaling", B. Rajagopalan, 10-JUN-02, The Optical Interworking Forum (OIF) has defined extensions to theLink Management Protocol (LMP), the Label Distribution Protocol(LDP) and the Resource reServation Protocol (RSVP) for optical UserNetwork Interface (UNI) signaling. These extensions consist of a setof new messages and data objects. This draft describes theseextensions. "Centralized Key Management and Distribution for Dynamic Muliticast Groups: Scalabilility Issues", Radhakrishna Sampigethaya, Mingyan Li, Radha Poovendran, Carlos Berenstein, 25-APR-02, We present our work on efficient scalable solutions to the hierarchicalkey management and distribution problem for secure multicast sessions.We take two rooted-tree based schemes that solve hierarchical keymanagement and distribution problem and then present ways of makingthese schemes more efficient by reducing the tree center key storagewith an upper bound on key update communication. The objective ofimproving efficiency is posed as a constrained optimization problem,which we further reduce to a fixed-point equation and find solutions.We also provide a tree design algorithm, which allows the designer tospecify an upper key update communication bound and construct anefficient tree with minimal center storage while maintaining pre-existing logarithmic scalability in time and space requirements. Thechoice of update communication bound as a design factor is the recentdevelopment of multicast communication applications, which have energyor bandwidth as constraints, and these in turn being directly relatedto communication bounds. "Requirements for Virtual Private LAN Services (VPLS)", Waldemar Augustyn, 28-FEB-02, This draft describes service requirements related to emulating a virtual private LAN segment over an IP or MPLS network infrastructure. The service is called VPLS. It is a class of Provider Provisioned Virtual Private Network [2]. "Threats Introduced by Rserpool and Requirements for Security in response to Threats", Maureen Stillman, 01-MAR-02, This Internet draft is an attempt to describe security threatsagainst the Rserpool protocol. This draft presents requirements fora security solution to thwart these threats in environments where itis likely to be deployed. The threats and requirements identifiedherein and the document should be considered as work in progress. "CLDAP to Historical Status", Kurt Zeilenga, 24-APR-02, The Connection-less Lightweight Directory Access Protocol (CLDAP)technical specification, RFC 1798, was published in 1995 as a ProposedStandard. This document discusses the reasons why the CLDAP technicalspecification has not been furthered on the Standard Track. Thisdocument recommends that RFC 1798 be moved to Historic status. "LDAPv2 to Historical Status", Kurt Zeilenga, 26-AUG-02, This document recommends the retirement of version 2 of theLightweight Directory Access Protocol (LDAPv2) and dependentspecifications, and discusses the reasons for doing so. This documentrecommends RFC 1777, 1778, 1779, 1781, and 2559 be moved to Historicstatus. "Subentries in LDAP", Kurt Zeilenga, 26-AUG-02, In X.500 directories, subentries are special entries used to holdinformation associated with a subtree or subtree refinement. Thisdocument adapts X.500 subentries mechanisms for use with LightweightDirectory Access Protocol (LDAP). "The Dublin Core Metadata Element Set", J. Kunze, 16-APR-02, Defines fifteen metadata elements for resource description in across-disciplinary information environment:Title Contributor SourceCreator Date LanguageSubject Type RelationDescription Format CoveragePublisher Identifier RightsThis document contains the same text as ANSI/NISO Z39.85-2001. Itdiffers from that standard only where formatting requirements of thepresent publishing medium require it. This document supersedesInternet RFC 2413, which was the first published version of theDublin Core. "Diameter Credit Control Application", Harri Hakala, 09-SEP-02, 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. "FYI on Questions and Answers Answers to Commonly asked 'Experienced Internet User' Questions", G. Malkin, W. Houser, Ray Plzak, 05-MAR-02, This memo provides information to the experienced Internet user thatwants to know more. The term 'experienced user' is used todifferentiate this user from the new users addressed by FYI4. Theterm experienced is relative. "Emergency Telecommunications Service in Evolving Networks", H Folts, Hal Folts, 01-FEB-02, This white paper presents the functional requirements, features, and objectives for the Emergency Telecommunications Service (ETS) in newly emerging telecommunication networks. The ETS is an extension of the International Emergency Preference Scheme (IEPS) of the ITU-T Recommendation E.106 [1] and includes additional provisions for multimedia services through an packet-based telecommunications environment. "LDP-based Signaling for L2VPNs", E. Rosen, 03-SEP-02, [MARTINISIG] specifies a way of using LDP [RFC3036] to set up andmaintain pseudowires [PWE3-FR]. It requires that each endpoint haveapriori knowledge of the IP address other endpoint, and that bothendpoints have apriori knowledge of a common 32-bit pseudowireidentifier. While this is adequate for the case in which pseudowiresare provisioned individually within a single Service Provider'snetwork, there are a variety of PPVPN provisioning models [L2VPN-FW]for which it is not adequate. In particular it is not adequate if itis desired to provision a pseudowire at only one endpoint, or if itis desired to use auto-discovery mechanisms to provision a mesh ofpseudowires. It also is not adequate for inter-provider VirtualPrivate LAN Services (VPLS), or for distributed VPLS. The currentdraft extends [MARTINISIG] so that LDP-based signaling can be usedfor these cases. "The application/rss+xml Media Type", Mark Nottingham, 24-OCT-01, This document specifies the Media Type for the RSS format. RSSallows lists of information to be exchanged in an XML-based format. "The W7 Stream Cipher Algorithm", Stephen Thomas, 16-MAY-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. "Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3)", Tricci So, 06-MAR-02, This document describes the Psuedo Wire (PW) service specific implementation to support 802.3 and 802.1Q/VLAN Ethernet emulated services. An Ethernet PW allows Ethernet Protocol Data Units (PDUs) to be carried over Packet Switched Networks (PSNs) using IP, L2TP or MPLS transport. This will enable Service Providers to leverage their existing PSN to offer Ethernet services. "SOAP Extensions: Basic and Digest Authentication", R. Salz, Robert Cunnings, 23-JAN-02, This memo defines SOAP Extensions which implement a basic accessauthentication mechanism and a digest access authenticationmechanism for use in request/response message exchange patterns.These mechanisms are adaptations of the corresponding mechanismsdefined in RFC 2617. "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture", Michael Chen, P Menezes, 07-MAR-02, Service Providers offer Virtual Private LAN Service (VPLS), also known as Transparent LAN Service (TLS), as part of their Layer 2 VPN offering. VPLS simulates an Ethernet Virtual 802.1d bridge for given set of customers across metro or wide area networks. "Offline Traffic Engineering in a Large ISP Setting", Chris Liljenstolpe, 14-AUG-02, This document is in response to a request made by the TrafficEngineering Working Group for a set of Best Current Practices from asample of the ISP engineering community. It reflects the currenttraffic engineering principles and practices that Cable & Wirelessuses for its global 'packet' networks (including IP and MPLS) atthe time of publication. It will also identify some of the historythat has lead to the specific principles and practices as well assome of the trade-offs between these methods and other possibleapproaches. It is not intended to be a detailed engineering guide or'how-to' document. "A Proposed Frame Relay Encapsulation for PWE3", Stewart Bryant, Lloyd Wood, George Wilkie, 05-MAR-02, This draft describes a pseudo-wire emulation edge-to-edge (PWE3)frame relay encapsulation that conforms to the PWE3 Protocol Layeringproposed by Bryant et al [LAYER], and discuses the services requiredfrom the underlaying PWE3 layers. "Definitions of Managed Objects for Service Location Protocol (SLP MIB)", I. McDonald, M Bakke, 06-MAR-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 as set of managed objects that supportmonitoring (but not configuration) of Service Location ProtocolVersion 2 (SLPv2) [RFC2608] [RFC3111] directory agents (DAs), serviceagents (SAs), and user agents (UAs). "IPv6 Hostname auto-registration Procedure", K Ettikan, Sanjay Rao, 22-MAY-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. "DNS as X.509 PKIX Certificate Storage", Leif Johansson, J. Schlyter, 10-JUN-02, A major problem facing PKIX deployment and implementation is theproblem of constructing certificate paths for input to the pathvalidation algorithm. This draft describes the use of the DNS as acertificate store and it's implication for path validation in PKIX. "RP Relocation in PIM-SM Multicast", J Atwood, Ritesh Mukherjee, 01-JUL-02, The Protocol Independent Multicast-Sparse Mode (PIM-SM) protocoluses a core-based tree to forward multicast datagrams to members ofa multicast group. Currently there is no method for relocating thecore or Rendezvous Point (RP) for a group. Administratively chosenRP's lead to low performance as the sources and receivers in themulticast group join and leave the group.This draft presents a mechanism for dynamically relocating the RP toa position that minimizes the tree cost and improves performance. "Requirements for dynamic tunnel configuration", Christian Jacquenet, 17-JUN-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. From this standpoint, this document complements the statements introduced by RFC 3139 ([2]). "The Internet Resource Query Service and the WHOIS Resource Schema", Eric Hall, A Newton, 12-FEB-02, This document describes an architectural framework for locating and retrieving information about network resources, using LDAPv3 for the data-formatting and query-processing services. This document also defines LDAP schema and processing rules for four Internet resource types: DNS domains, IPv4 addresses, IPv6 address, and AS numbers. The framework specified in this document allows additional documents to define additional Internet resource types and their handling rules. "FTP/TLS Friendly Firewalls", P. Ford-Hutchinson, 19-JUN-02, This document discusses some of the issues with running FTP, securedwith TLS as defined in [FTP-TLS], through firewalls. FTP is known tobe a bit of a problem for firewalls (see [RFC-1579] for a discussionof normal FTP and firewalls). Some of the problems have been fixedby adding intelligence into the firewall. With secured FTP, wherethe control connection is encrypted, some of these techniques fail.Whilst this document confines itself to issues of FTP over TLS, theissues will probably be relevant for most secured FTP protocols thatconform to [RFC-2228]. Some of the discussions will also be relevantto any protocol that firewalls do clever things with. "Service Location Protocol, Version 2", E. Guttman, James Kempf, 10-JAN-02, The Service Location Protocol provides a scalable framework for thediscovery and selection of network services. Using this protocol,computers using the Internet need little or no static configurationof network services for network based applications. This isespecially important as computers become more portable, and usersless tolerant or able to fulfill the demands of network systemadministration. This document updates SLPv2, adding clarificationsand removing features which were neither widely implemented or deemeduseful. "EAP-SKE authentication and key exchange protocol", L. Salgarelli, 16-APR-02, This note describes EAP Shared Key Exchange (SKE), a method forauthentication of Mobile Nodes (MN) and generation of a persession, per node EAP Master Secret. The method applies toscenarios where a Mobile Node (MN) is in a foreign network such asa public 802.11 or 802.3 network that uses Home-AAA and Foreign-AAAservices. The method requires presence of a pre-deployedcryptographically secure shared key on the MN and its Home-AAAserver, and use of the 802.1x standard [1], ExtensibleAuthentication Protocol (EAP) [2] messages, and RADIUS [3]authentication servers. The protocol can easily be extended tosupport the migration from RADIUS to DIAMETER [4]. "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Anwar Siddiqui, 05-MAR-02, 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[RFC2819]. In particular, it describes managed objects used forrealtime application monitoring that reflects 'a specific end user'sapplication Quality of Service (QOS) related parameters' on a'specific IP end point "Geopriv requirements", Jorge Cuellar, J Morris, John Morris, Deirdre Mulligan, 09-MAY-02, Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependentservices need geographic location information about a target (user,resource or other entity). There is a need to securely gather andtransfer location information for location services, protecting theprivacy of the individuals involved.This document describes the requirements for the geopriv LocationObject (used to transfer location data and perhaps some otherinformation) and for further IETF protocols that use this LocationObject as an embedded protocol. We focus on authorization, integrityand privacy requirements. "Pseudo Wire (PW) over MPLS PSN Management Information Base", S. Park, 01-MAR-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 MIB module for PW operation over Multi-Protocol Label Switching (MPLS) [MPLSArch] Label Switch Router (LSR). "IPv4 Address Conflict Detection", S. Cheshire, 28-AUG-02, When two hosts on the same link attempt to use the same IPv4 addressat the same time (except in rare special cases where this has beenarranged by prior coordination) problems ensue for one or both hosts.This document describes (i) a simple precaution that a host can takein advance to help prevent this misconfiguration from happening, and(ii) if this misconfiguration does occur, a simple mechanism by whicha host can passively detect after-the-fact that it has happened, sothat the host may respond to rectify the problem. "Common Elements of GSER Encodings", Steven Legg, 26-AUG-02, The Generic String Encoding Rules (GSER) describe a human readabletext encoding for an ASN.1 value of any ASN.1 type. Specificationsmaking use of GSER may wish to provide an equivalent ABNF descriptionof the GSER encoding for a particular ASN.1 type as a convenience forimplementors. This document supports such specifications byproviding equivalent ABNF for the GSER encodings for ASN.1 typescommonly occuring in Lightweight Directory Access Protocol (LDAP)syntaxes. "The EAP Session Key Problem", B. Aboba, 14-FEB-02, This document describes the issues involved in key derivation by EAPmethods and provides guidelines for generation and usage of EAP keys. "An Effective Solution for Multicast Scalability:The MPLS Multicast Tree (MMT)", Jean-Marie Bonnin, Ali Boudani, Bernard Cousin, 01-JUL-02, A multicast router should keep forwarding state for every multicasttree passing through it. The number of forwarding states grows withthe 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 alsothe advantages of our approach, and conclude that it is feasible andpromising. Finally, we analytically evaluate our approach. "Protocol Layering in PWE3", Stewart Bryant, Danny McPherson, W. Mark Townsley, Lloyd Wood, 01-MAR-02, This draft proposes a unified protocol layering approach for pseudo-wire emulation edge-to-edge (PWE3). It adopts the principle that PWE3should be a single transport type operating over a common packet-switched network (PSN) service model using, wherever possible,existing IETF protocols. The draft defines the protocol layeringmodel for pseudo-wires (PW), guidelines for the design of a specificencapsulation type, and the service requirements of the underlyingPSN tunneling mechanism. "Generalized Multiprotocol Label Switching (GMPLS)Traffic Engineering Management Information Base", Thomas Nadeau, 24-JAN-02, This memo defines an experimental portion of theManagement Information Base (MIB) for use with networkmanagement protocols in the Internet community. Inparticular, it describes managed objects forMultiprotocol Label Switching (MPLS) [RFC3031] andGeneralized Multiprotocol Label Switching (GMPLS)[GMPLSArch] based traffic engineering. "Generalized Multiprotocol Label Switching (GMPLS)Label Switch Router Management Information Base", Thomas Nadeau, 24-JAN-02, This memo defines a portion of the Management InformationBase (MIB) for use with network management protocols inthe Internet community. In particular, it describesmanaged objects for Multiprotocol Label Switching (MPLS)and Generalized Multiprotocol Label Switching (GMPLS)Label Switched Routers (LSRs). "Definition of Textual Conventions and BJECT-IDENTITIES for Generalized Multiprotocol Label Switching (GMPLS) Management", Thomas Nadeau, 24-JAN-02, This memo describes Textual Conventions and OBJECT-IDENTITIES common to the Management Information Bases(MIBs) for managing Generalized Multiprotocol LabelIt supplements [TCMIB] which describes TextualConventions and OBJECT-IDENTITIES common to theManagement Information Bases (MIBs) for managingMultiprotocol Label Switching (MPLS) networks. "Generalized Multiprotocol Label Switching (GMPLS) Label Management Information Base", Thomas Nadeau, 24-JAN-02, This memo defines an experimental portion of theManagement Information Base (MIB) for use with networkmanagement protocols in the Internet community. Inparticular, it describes managed objects defining labelfor Multiprotocol Label Switching (MPLS) [RFC3031] andGeneralized Multiprotocol Label Switching (GMPLS)[GMPLSArch] Label Switching Routers (LSRs). "Capsulated Network Address Translation with Sub-Address(C-NATS)", Kuniaki Kondo, 26-JUN-02, Many home user networks or enterprise networks are using the addresstranslation technology (NAT[1]) at the boundary of their end-networksfor various reasons.One disadvantage of the use of the address translation technology isthat it might disable two-way transparent communication.This document specifies the enhancement of the address translationtechnology, which it adds 'sub-address' to current IP address space toenable NAT inside/outside hosts to setup transparent communication inboth direction through enhanced NAT routers.This enhancement is called 'C-NATS' (Capsulated Network AddressTranslation with Sub-Address) and the word 'NATS' used in thisdocument implies 'C-NATS'. "V.92 Modem-On-Hold signalling on L2TP", Ignacio Goyret, 26-MAR-02, The Layer 2 Tunneling Protocol [L2TP] defines a mechanism fortunneling PPP [PPP] sessions.One of the features introduced by V.92 [V92] is the ability of theclient modem to put the call on hold. The L2TP base protocol doesnot provide any means to signal this event. This document describesa method used to indicate when a client modem has gone on-hold. "Host-based IPv6 Multicast Addresses Allocation", Jung-Soo Park, 22-FEB-02, This document specifies an extension to the multicast addressingarchitecture of the IPv6 protocol. The extension allows for singinterface-ID to allocate multicast addresses. When the link-localunicast address is configured at each interface of host, interfaceID is uniquely determined. By delegating multicast addresses atthe same time as interface ID, each host can identify theirmulticast addresses automatically at Layer 1 without needing to runan intra- or inter-domain allocation protocol in the serverlessenvironments. "Text string notation for Dial Sequences and GSTN / E.164 addresses", Claudio Allocchio, 07-AUG-02, This memo describes the full set of notations needed to representin a text string a Dial Sequence. A Dial Sequence is normallycomposed by Dual Tone Multi Frequency (DTMF) elements [1] plus separators and the additional 'actions' (such as 'wait fordialtone', '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. Global Switched Telephone Numbers (GSTN) / E.164 addresses (commonly called 'telephone numbers') [2] are a subset of a Dial Sequence, and thus use the same set of notations. "A Clustering Architecture for Replicating Managed Objects", Glenn Keeni, Aldri dos Santos, Elias Duarte, 19-JUN-02, This memo defines a portion of the Management Information Base (MIB)for replicating managed objects. In particular, it describes a set of objects that are used for supporting object replication based on an clustering architecture. "Language Tags and Ranges in LDAP", Kurt Zeilenga, 01-MAR-02, It is often desirable to to be able to indicate the natural languageassociated with values held in a directory and to be able to query thedirectory for values which fulfill the user's language needs. Thisdocument details the use of Language Tags and Ranges in theLightweight Directory Access Protocol (LDAP). "LDAP 'Who am I?' Operation", Kurt Zeilenga, 05-AUG-02, This specification provides a mechanism for Lightweight DirectoryAccess Protocol (LDAP) clients to obtain the authorization identitywhich the server has associated with the user or application entity.This mechanism is specified as an LDAP extended operation called theLDAP 'Who am I?' operation "Dual Stack deployment using DSTM and neighbour discovery", Gerard Gastaud, Damien Galand, Philippe Bereski, Gilles Diribarne, 01-MAR-02, Today IPv6 nodes are generally dual stacked. With its automaticconfiguration of tunnel end points, [DSTM] is an appealingtransition mechanism, provided that an efficient dynamic allocationof IPv4 address process is available. "Data Compression For Content Network Advertisement Protocol (CNAPComp)", Reinaldo Penno, A Barbir, Delphine Kaplan, 19-FEB-02, The draft specifies a data compression encapsulation protocol to be used to compress the data packets of the Content Network Advertisement Protocol (CNAP). The CNAP is a protocol intended to facilitate the interconnection of Content Networks. CNAP is a simple advertisement protocol that advertises content as well as content network coverage information. The CNAP protocol is described in [15]. "A Framework for Service Personalization", A Barbir, 01-JUL-02, 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, 01-JUL-02, 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. "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", Farid Adrangi, Prakash Iyer, 13-JUN-02, Multi-subnetted IEEE 802.11 WLAN networks are being widely deployed in Enterprise Intranets –(in many cases requiring a VPN tunnel to connect back and access Intranet resources), and public areas such as airports, coffee shops, convention centers and shopping malls. Many of these WLAN networks also employ NAT to translate between non-routable and routable IPv4 care-of (point of attachment) addresses. WWAN networks such as those based on GPRS, 1xRTT and eventually EDGE, 1xEV, CDMA2000 and UMTS are also starting to see deployment. These deployments are paving the way for applications and usage scenarios requiring TCP/IP session persistence and constant reachability while connecting back to a secured (VPN protected), target “home” network. This in turn drives the need for a mobile VPN solution that is multi-vendor interoperable, providing seamless access with persistent VPN sessions - through NAT gateways when needed. This draft proposes a solution framework that enables efficient, seamless operation of Mobile IPv4 when combined with an IPsec-based VPN and supporting NAT traversal when needed. The solution has no link layer dependencies and can be applied to other 802.3-compatible wired and wireless physical media as well. "IP Header Compression over PPP", M. Engan, 01-JUL-02, This document describes an option for negotiating the use of headercompression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compressionmay be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in [RFC2507], [RFC2508] and [RFCYYYY]. "MRCP: Media Resource Control Protocol", Saravanan Shanmugham, 22-JUL-02, The Media Resource Control Protocol(MRCP), is an application level protocol to control 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", H. Schulzrinne, James Polk, 08-JAN-02, This document defines a new SIP header field for communicationsresource priority, called 'Resource-Priority'. This header fieldinfluences the behavior of gateways and SIP proxies. It does notinfluence the forwarding behavior of IP routers. "Requirements for Assured Service Capabilities in Voice over IP", Don Choi, Michael Pierce, 22-APR-02, Assured Service refers to the set of capabilities used to ensure thatmission critical communications are setup and remain connected. Thismemo describes the requirements for such capabilities in support ofspecific networks such as those used by the US military andgovernment. "Signaled Telephony Events in the Session Initiation Protocol(SIP)", R. Mahy, 02-JUL-02, This document demonstrates a way for interested SIP User Agents whichare not a party to the media of a call or session, to receive SIPevent notifications when signaled digits, or other specifictelephony-related events are detected. This is useful for a varietyof applications that monitor calls for a specific event (e.g.: a longpound, special sequence of digits, or a fax signal) and--only then--take an active role in the monitored calls. "Using SIP to Support NP and Freephone Service", James Yu, 17-JUN-02, 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. "Application Aspects of IPv6 Transition", Myung-Ki Shin, 01-MAR-02, The document specifies application aspects of IPv6 transition. AsIPv6 is deployed, there are some problems that the applicationdevelopers and the administrators face. This draft clarifies theproblems occurred in transition periods between IPv4 applicationsand IPv6 applications. It also propose guidelines to implement andchoose the suitable application under the various transitionenvironments. This document does not try to define any newprotocol. The proposals contained in this document are based onthe work of the Ngtrans working group. "The IPv6 Payload Header", F. Dupont, 05-MAR-02, This draft describes a method by which many IPv6 payload databodies may be encapsulated in a single IPv6 datagram using a newnon-terminal header will contain both a payload and necessaryfields (like a ``next header'' field) allowing header chaining.This document specifies how two packets can be merged into a singleone and the reverse one-step operation. But the main purpose is toprovide a basis to discussions about the pros and cons of such amechanism. "MIPv6 BU Attacks and Defenses", Jari Arkko, Tuomas Aura, 04-MAR-02, This document overviews attacks against mobile and fixed IP nodes by exploiting features of the Mobile IPv6 Route Optimization. Many of the attacks can be prevented by authenticating the Mobile IPv6 Binding Updates (BU) but some cannot, some depend on the details of the BU protocol, and some denial-of-service attacks specifically take advantage of authentication mechanisms. "GMPLS LSP Bandwidth Modification (LBM) for SDH/SONET", E Mannie, Lyndon Ong, D. Papadimitriou, 10-MAY-02, This document defines how GMPLS can be used to dynamically modifythe bandwidth of a TDM circuit. It focuses first on SONET/SDH andintend to cover other technologies in a further release.This document also defines how to use multiple differently routedLSPs to build a single SONET/SDH virtually concatenated circuit.Each LSP can be recovered (i.e. protected or restored) individually. "The Features of IPv6 Signaling", J Choi, 01-JUL-02, In this draft, we describe the features and requirements of IPv6 signaling protocol and explain the needs of QoS signaling in IPv6 network. We also explain mapping of IPv6 signaling with IPv4 in some detail. "Host Requirements of IPv6 for Low Cost Network Appliances", NOBUO OKABE, 02-JUL-02, Resource limitations and cost constraints associated withsmall-embedded devices make it difficult to implement the entire IPv6 specification. We call such non-PC embedded devices(e.g. game-machines, AV devices, sensors, digital cameras, LCDprojectors, and home appliances) 'Low Cost Network Appliances', and define the IPv6 host requirements for them. In this document, wewill also point out several items to be discussed for the deploymentof IPv6 on LCNAs. "Wireless Internet X.509 Public Key Infrastructure Certificate Request Message Format and Protocol WCRMFP)", Jaeho Yoon, 05-JUN-02, This document describes the Wireless Certificate Request Message Format and Protocol (WCRMFP) in wireless internet environment. This format and protocol are 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. "Edge Based Admission Control with Class Based Resource Management", Diana Rawlins, 14-JUN-02, New value-added IP services such as VoIP requires per-flow admission control to be performed in order to ensure the admission of new traffic flows does not degrade the performance of the existing traffic flows in the network. Resource Reservation Protocol (RSVP) for Intserv [2205] is proposed to support per-flow admission control. However, RSVP requires per-flow state installation, per-flow state refreshment, per-flow traffic management and resource reservation on each node along a forwarding path, which cause significant scalability issues, especially on the boundary routers and core routers of service provides’ networks, which need to process thousands of traffic flows as network aggregation points. Intserv over Diffserv networks proposed in [2998] requires the RSVP/Intserv processing only on boundary routers and edge routers. Nevertheless, RSVP/Intserv has still rarely been supported by boundary router vendors because of the scalability issue. The use of edge-based admission control with per-class resource management and policy control offers a scalable approach to manage per-flow admission control for QoS sensitive applications. "Change Process for the Session Initiation Protocol (SIP)", S. Bradner, A. Mankin, R. Mahy, 27-AUG-02, The IETF's Session Initiation Protocol (SIP, RFC 3261), wasoriginally developed for initiation of multimedia sessions. Internetmultimedia, voice over IP, IP telephony, and SIP, have become quitepopular, both inside IETF and in consideration by other standardsgroups, and the applications of SIP have grown. The task for IETFmanagement of SIP has been to steer SIP to its core strengths,applications that it does best. One result of popularity has been acontinual flood of suggestions for SIP modifications and extensions.This memo describes how the Transport Area directors along with theSIP and SIPPING working group chairs have decided to deal with suchsuggestions. The effects of adding new features, often in a casewhere a point solution is sought, can be to damage security or togreatly increase complexity. Therefore this memo documents a processintended to apply architectural discipline to the future developmentof SIP. "Analysis of Existing QoS Solutions", Hermann De Meer, 01-JUL-02, This memo provides a brief analysis of existing IP quality of service(QoS) solutions and the implied signalling issues. This analysis isintended to point out open issues in QoS signalling. Moreover, thisanalysis is done in order to understand whether the strict QoSrequirements imposed by future fixed and mobile applications aresatisfied by the existing IP QoS solutions. The existing IP QoSsolutions can be categorized as follows:* End-to-end per-flow resource reservation protocols* Integrated Services over Differentiated Services* Statically assigned trunk reservations based onDifferentiated Services* Dynamic trunk reservations with Aggregated RSVP "Direct Internet Message Encapsulation (DIME)", C. Huitema, H. Sanders, R. Butek, H. Nielsen, 01-JUL-02, Direct Internet Message Encapsulation (DIME) is a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message construct. Each payload is described by a type, a length, and an optional identifier. Both URIs and MIME media type constructs are supported as type identifiers. The payload length is an integer indicating the number of octets of the payload. The optional payload identifier is a URI enabling cross-referencing between payloads. DIME payloads may include nested DIME messages or chains of linked chunks of unknown length at the time the data is generated. DIME is strictly a message format: it provides no concept of a connection or of a logical circuit, nor does it address head-of-line problems. "Content Network Advertisement Protocol (CNAP)", Brad Cain, 05-JUL-02, The Content Network Advertisement Protocol (CNAP) is a protocol Intended to facilitate the interconnection of Content Networks (CN). CNAP is a simple CN-to-CN information exchange protocol that advertises both content and area advertisements. These two types of advertisements are described in [3,6] and are intended to be used by content network request routing systems [9]. The exchange of these advertisements between CNs is intended to facilitate inter-CN request-routing decisions. "TCP/IP field behavior", S. McCanne, M. West, 06-MAR-02, This draft 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. "The CRAM-MD5 SASL Mechanism", John Klensin, Lyndon Nerenberg, Paul Krumviede, 17-JUN-02, This document defines a simple challenge-response [SASL] authenti-cation mechanism, using a [KEYED-MD5] digest. "Neighbor Discovery via PPP", Ben Mack-Crane, Janathan Sadler, 03-JUN-02, Work has been progressing in the Common Control and MeasurementProtocol (CCAMP) working group on the application of MPLS technologyto non-packet switching networks. Development of the GeneralizedMPLS (GMPLS) signaling draft [1] has allowed for Optical, SONET/SDH,and spatial switching systems to be controlled using IP protocols.In a GMPLS network, the path that a TDM connection will use isdeveloped using constraint based routing. The developed routeutilizes TDM link state information announced via OSPF or IS-IS byother nodes in the network. However, a node cannot advertise theexistence of a link without first identifying the remote nodeconnected to the link and the capabilities of the neighboring node.In a packet network, this function would typically be accomplishedusing OSPF or IS-IS Hello messages repeated every 10 or so seconds.However, the TDM link cannot transmit similar messages because theport terminating the link cannot be shared between a TDM serviceuser and the OSPF/IS-IS termination function. "Coordinating IETF and DMTF Joint Work", Lee Rafalow, A Westerinen, 06-MAR-02, The Distributed Management Task Force (DMTF) [1] is a membership-based standards organization with technology for, and expertise in, modeling systems and network-related management information. In the interests of promoting a common set of standards, from time to time the IETF and the DMTF have found and may continue to find opportunities to work together in developing overlapping standards. "Security Mechanism Agreement for SIP Connections", Jari Arkko, 05-MAR-02, SIP has a number of security mechanisms for hop-by-hop and end-to-endprotection. Some of the security mechanisms have been built in to theSIP protocol, such as HTTP authentication or secure attachments. Inthese mechanisms there are even alternative algorithms and parameters. "A Framework for Passive Packet Measurement", Nick Duffield, Matthias Grossglauser, Jennifer Rexford, Albert Greenberg, 07-MAR-02, A wide range of traffic engineering and troubleshooting tasks rely onreliable, timely, and detailed traffic measurements. We describe apassive packet measurement framework that is (a) general enough toserve as the basis for a wide range of operational tasks, and (b)relies on a small set of primitives that facilitate uniformdeployment in router interfaces or dedicated measurement devices,even at very high speeds. This document describes the motivation forsuch a framework through several operational examples, defines themeasurement primitives (filtering, sampling, and hashing), andillustrates their use. "Global Connectivity for IPv6 Mobile Ad Hoc Networks", Ryuji Wakikawa, 03-JUL-02, This document describes how to provide Internet connectivity withmobile ad-hoc networks. It describes how to obtain a globally routableaddress , Manet node operation, and Internet-gateway operation. Oncea Manet node obtains a global address from an Internet-gateway,it can start to send data to the Internet. Data goes through theInternet-gateway with a routing header specifying the gateway. Thisconnectivity method is not dependent on a particular Manet protocol.Further, use of global connectivity with Mobile IPv6 is specified. "Proposed MPLS/DiffServ TE Class Types", Jerry Ash, 07-JUN-02, Service Provider requirements for support of DiffServ aware MPLS TrafficEngineering (MPLS-DS-TE) are presented in [MPLS-DS-TE-REQ]. This initiative includes the definition of MPLS-DiffServ-TE class types (CTs), wherein CTs are defined as aggregations of individual service classes. Instead of having per-class parameters being configured and propagated on each LSR interface, classes are aggregated into CTs having common per-CT parameters (e.g., minimum bandwidth) to satisfy required performance levels, however, no bandwidth requirements are enforced for classes within a CT. The main motivation for grouping a set of classes into a CT is to improve the scalability of IGP LSAs by propagating information on a per-CT basis instead of on a per-class basis, and also to allow better bandwidth sharing between classes in the same CT. In order to further improve scalability through the introduction of CTs, we propose to a) limit the number of CTs to 6, and b) to generalize the notion of CTs and consider them to be a combination of i) DiffServ/queuing priority per-hop-behaviors (PHBs), ii) QoS classes (e.g., as specified in [Y.1541]), iii) admission-control priority classes, and iv) restoration priority classes at both the MPLS-LSP and transport link level. "Persistent Search: A Simple LDAP Change Notification Mechanism", Mark Smith, 27-FEB-02, This document defines two controls that extend the LDAPv3 [LDAP] searchoperation to provide a simple mechanism by which an LDAP client canreceive notification of changes that occur in an LDAP server. Themechanism is designed to be very flexible yet easy for clients andservers to implement. Since the IETF is likely to pursue a different,more comprehensive solution in this area, this document will eventuallybe published with Informational status in order to document an existingpractice. "Mobile Router Support with Mobile IP", Tim Kniveton, 05-JUL-02, This document describes how to support mobile networks with Mobile IP orMobile IPv6. It provides this support with no modifications to MobileIP or routing protocol signaling. It also describes two scenariosof mobile router support, consumer mode, and fully enabled mode. Inthe former, the mobile router is not allowed to use routing protocolsignaling with the home agent, but performs routing for subnet(s)assigned to it. In the latter mode, both the home agent and the mobilerouter use a routing protocol in the same manner as fixed routers. "Considerations for LDAP Extensions", Kurt Zeilenga, 04-JAN-02, The Lightweight Directory Access Protocol (LDAP) is extensible. Itprovides mechanisms for adding new operations, extending existingoperations, and defining operational and user applications schema.This document discusses considerations for designers of LDAPextensions. "Virtual Private LAN Services over MPLS", Marc Lasserre, 03-JUL-02, This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). VPLS simulates an Ethernet virtual 802.1d bridge [802.1D-ORIG] [802.1D-REV] 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 VLS services can be supported from a single PE node. "Additional Extensions to Generalized MPLS for Waveband Switching", Richard Douville, 24-JUN-02, Generalized-MPLS (GMPLS) extends the MPLS control plane to encompasstime-division, wavelength and spatial switching. A functionaldescription of the extensions to MPLS signaling needed to supportthe new types of switching is provided in [GMPLS-SIG]. Along withthe current development of IP over optical switching, there areconsiderable developments in optical transport systems based on themultiple optical switching granularities. [GMPLS-SIG] currentlydefines two layers of optical granularity (wavelength and fiber). Asdescribed in [IPO-MG], a revisited definition of waveband switchingmust be introduced. This document presents a functional descriptionof the extensions, to the GMPLS protocol suite, to integrate theadditional requirements of optical multi-granularity and to furtherbenefit from the features of those switching layers. "GeoPriv Object/Protocol Requirements", Randall Gellens, 12-JUN-02, This is a straw proposal for the requirements specification for theGeoPriv object and protocols which make use of it. "IKE Implementation Issues", D. Hugh Redelmeier, Henry Spencer, 04-MAR-02, The current IPsec specifications for key exchange and connectionmanagement, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects ofconnection management unspecified, most prominently rekeyingpractices. Pending clarifications in future revisions of thespecifications, this document sets down some successful experiences,to minimize the extent to which new implementors have to rely onunwritten folklore. "Using DHCPv6 for DNS Configuration in Hosts", Ralph Droms, Thomas Narten, B. Aboba, 07-MAR-02, An IPv6 device can configure its addresses and locate neighboringrouters through stateless address autoconfiguration (RFC2462) androuter discovery (RFC2461). Most IPv6 devices will requireinformation about DNS services to make use of the basic IPv6connectivity. "Potential Solutions to the Middle Box discovery problem", Louis Hamer, C. Aoun, 22-MAY-02, This document provides a high level outline of possible solutions for Middle Box discovery which is one of the problems which has not yet been addressed in the Midcom architecture. "The Session Inititation Protocol (SIP) 'Join' Header", R. Mahy, D. Petrie, 02-JUL-02, This document defines a new header for use with SIP multi-partyapplications and call control. The Join header is used to logicallyjoin an existing SIP dialog with a new SIP dialog. This primitivecan be used to enable a variety of features, for example: 'Barge-In',answering-machine-style 'Message Screening' and 'Call CenterMonitoring'. Note that definition of these example features is non-normative. "Payload-independent Delineation for Simple Data Link (SDL) Framing", Pankaj Jha, 07-MAR-02, Simple Data Link (SDL) framing specification (rfc2823) defines a [length, length CRC] based construct with a tail-end payload CRC for delineating frames over digital links. Many protocols, however, already have built-in CRC mechanisms, and a tail-end CRC is not always needed. This draft proposes a modification to allow SDL receivers to delineate all types of payload without having to analyze payload protocol header to determine presence of CRC. "DNS Stale Resource Records Removal Mechanism", L. Esibov, Kamal Janardhan, 14-AUG-02, The Dynamic DNS Update Protocol assumes that the devices/applicationsperforming dynamic registration of the DNS records will delete therecords from the DNS database when the records become invalid. Initialdeployment of the devices supporting the Dynamic DNS Update protocol indicated that there are multiple legitimate scenarios when records dynamically registered in DNS are not removed from the database by the devices that originally registered them. This can result in a substantial number of stale records. This document describes a mechanism to clean up these stale records. "Issues in IPSec Context Transfer", Ram Gopal, 28-FEB-02, The reasons and the motivation for transferring context have beendescribed in [1]. The requirements for a context transfer protocolcan be found in [2]. In this document, we describe issues that needto be considered for transferring security (specifically IPsec)related context between access routers. "Dynamic Disconnect", M Chiba, 20-NOV-01, This document describes the current practices for dynamically disconnecting a user session on the NAS.The protocol uses RADIUS messages to send the disconnect request,but unlike RADIUS, the NAS in this case acts as a server and listens on a UDP port for requests originating from a client. "RTP Payload Format for AC-3 Streams", Jason Flaks, 01-JUL-02, This document describes an RTP payload format for transporting AC-3 encoded audio data. AC-3 is a high quality multichannel audio coding system fully described in [2] by the Advanced Television Standards Committee (ATSC). 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 EAP extension over AAAv6 (SIM6)", Tim Kniveton, Jari Malinen, 05-JUL-02, Providing an existing scalable authorization infrastructure formobile nodes is needed for IPv6-based mobility. SIM Authenticationprovides a protocol for authenticating and authorizing services. Ituses an authorizing home domain defined by the Subscriber IdentityModule (SIM). The protocol is an Internet Control Message Protocolfor IPv6 (ICMPv6) [17] extension. It can leverage the existing SIMauthorization infrastructure for automatic bootstrapping of securityassociation between the mobile node and a service, where the service canbe e.g. authorized last-hop VPN setup for network access or Mobile IPv6mobile-home security association setup. "Geographically Adjacent Access Router Discovery Protocol", Daichi Funato, 02-JUL-02, This document describes a scheme that allows a node to determine an IP address corresponding to a given link-layer id. The node performing the query doesn't need to be on the same link or subnet of the node associated with the link-layer id. This scheme was designed for the handoff candidate access router discovery in wireless networks, but may also be applied to other networks with similar behavior. "Threat Analysis for IPv6 Public Multi-Access Links", Erik Nordmark, James Kempf, 28-JUN-02, The Mobile IP Working Group has been conducting a threat analysis for the purpose of securing specific Mobile IPv6 mechanisms. In the process of conducting the analysis, threats were identified that are not specific to Mobile IP but that are amplified by the nature of mobility. These threats are likely to be more or less of an issue within any Public Multi-Access network, regardless of whether mobility is involved. This document discusses threats associated with Public Multi-Access links in IPv6. The document covers non-Mobile IP specific threats uncovered by the Mobile IPv6 study, threats raised in the IPv6 Neighbor Discovery and Stateless Address Autoconfiguration RFCs that have yet to be adequately addressed, and new threats that have not previously been identified. "Diameter NASREQ Application MIB", Jay Koehler, 01-MAR-02, This document describes the Diameter application that is used for AAAin a PPP/SLIP Dial-Up and Terminal Server Access environment. Thisapplication, combined with the base protocol, satisfies therequirements defined in the NASREQ AAA criteria specification and theROAMOPS AAA Criteria specification. "The Managed Object Aggregation MIB", Glenn Keeni, 09-SEP-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 MOsand to service queries related to the aggregated MOs. "HASM: Hierarchical Application-Level Secure Multicast", Brian Coan, 07-DEC-01, The HASM system addresses some of the current limitations ofend-to-end secure multicast. Specifically, the techniques used inHASM can achieve: (1) multiple autonomous administrative units, eachwith its own locally-managed authentication and authorization server,(2) efficiency in rekeying portions of a multicast group by usingnetwork elements to translate between keys (all without trusting anysingle network element to securely manage message text in the clear),and (3) defense against denial-of-service attacks by using a secureextension of IGMP. The HASM system makes use of (1) network support,including extensions to the Internet Group Management Protocol (IGMP),extended firewall functionality, and router support for encryption anddecryption and (2) host operating system support, specificallyextensions to IGMP. "URI Scheme for the TFTP Protocol", Eliot Lear, 22-APR-02, TFTP [TFTP] is a very simple TRIVIAL file transfer protocol thathas been in use on the Internet for quite a long time. While thisdocument does not recommend its continued use, largely due tosecurity concerns, we do define a URI Scheme, as well as provide aprotocol applicability statement. "Benchmarking Methodology for Basic OSPF Convergence", Russ White, Vishwas Manral, Aman Shaikh, 13-DEC-01, This draft establishes standards for measuring OSPF convergenceperformance. Its initial emphasis is on the control plane of singleOSPF routers. We do not address forwarding plane performance. "OSPF Benchmarking Terminology and Concepts", Russ White, Russ White, Vishwas Manral, Aman Shaikh, 13-DEC-01, This draft explains the terminology and concepts used in [2] andfuture OSPF benchmarking drafts. "Requirements for QoS Signaling Protocols", Marcus Brunner, 14-DEC-01, This draft proposes a set of requirements for signaling QoS acrossdifferent network environments. To achieve wide applicability of therequirements, the starting point is a diverse set of user scenariosconcerning both access and core networks, application interactions,and use within cellular networks. We also provide an outlinestructure for the problem, including QoS related terminology. "SPKI-XML Certificate Structure", Joan-Maria Mas, Xavier Orri, 14-DEC-01, This draft suggests a standard form for transforming SPKI certificates encoded using S-expressions from and to XML documents. We present a XML Schema for the encoding and validation of SPKI certificates and other SPKI objects such as sequences and ACLs, and discuss different possibilities for the transformation of S-expressions into an XML document and vice-versa. The XML Schema is based on the 'SPKI Certificate Structure' [SPKI]. "Test Specification for MTP3 User Adaptation", Anshoo Sharma, 14-DEC-01, This document presents the test specification for M3UA (MTP3 UserAdaptation) protocol (ver 10), which can be used to test M3UAimplementations for conformance to the protocol definition. The listof test is exhaustive and covers almost all the categories of test.This draft can also be used in conjunction with M3UA specification byimplementers of protocol as implementers guide, as the pictorialrepresentation of various scenarios help easy understanding of theprotocol. "RSVP Mobility Proxy", Sarantis Paskalis, 17-DEC-01, Mobility management and QoS provision have been research topics inthe past years. Mobile IP is the dominant protocol for mobilitymanagement, whereas RSVP is a well established protocol for QoSprovision. These protocols when deployed separately can work quiteefficiently. However, their interworking has been widely recognizedto be problematic. We propose a new approach that limits mobilityand QoS related network modifications inside the domain in which auser moves. "Using Bloom Filters for Authenticated Yes/No Answers in the DNS", Steve Bellovin, 17-DEC-01, Some aspects of DNSSEC, such as NXDOMAIN error messages, require anauthenticated answer. Producing this answer requires complexmechanisms, online storage of the zone's secret key, expensive onlinecomputations, or massive zone files. As an alternative, we proposestorage of authenticated pointers to Bloom filters. This schemeprovides large reductions in the size of, and computational expenseto produce, partially-signed zone files. "Definition of IP Packet Reordering Metric", Stanislav Shalunov, 17-DEC-01, Various pieces of network testing equipment currently often report acharacteristic that is referred to as a 'degree (or percentage) ofpacket reordering'. The way this metric is computed is oftenundocumented and it differs between vendors. Having a useful numericmeasure of the degree of packet reordering is important forapplications such as TCP and VoIP on different ends of the spectrum.However, the metric that makes sense for one application may have noor little applicability to another. This document introduces adefinition of reordering metric that is hoped to be applicable to anumber of different applications by parametrizing the metric. "SS7 MTP2-User Peer-to-Peer Adaptation Layer Test Specifications M2PA-TEST", Brian Bidulock, 16-APR-02, This Internet Draft provides information for the Internet communityon test cases for testing the SS7 M2P2-User Peer-to-Peer AdaptationLayer [M2PA] based on the conformance test specifications for SS7 MTPLevel 2 [Q.781]. "Visualizing Change; Re-Defining the Role of the IPv6 Protocol Specification", Eugene Terrell, 03-APR-02, This paper attempts an exploration of the reasons that supportsor offers a viable justification for an IP Addressing Protocolwhich must be Manually Configured using HEX Notation. I mean, whyuse HEX Numbers, and why not use an Integer? "The Reason Header Field for the Session Initiation Protocol", David Oran, H. Schulzrinne, G. Camarillo, 04-MAR-02, For creating services, it is often useful to know why a SIP requestwas issued. This document defines an optional informational headerfield, Reason, that provides this information. "Protection of Hierarchical LSPs", Yoshihiko Suemura, Aleksandar Kolarov, Tatsuya Shiragaki, 03-JAN-02, In this document, we propose two different mechanisms for protection of hierarchical LSPs. We assume that an hierarchical LSP traverses a network that is partitioned into multiple smaller, non-overlapping subnetworks. Protection of the hierarchical LSP can be realized through two mechanisms: 1)Subnetwork Protection and 2)End-to-end Protection. "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management", Thomas Nadeau, B. Schliesser, 04-JAN-02, This document defines Textual Conventions used as part of theManagement Information Base (MIB) for use with network managementprotocols in the Internet Community. In particular, it describesTextual Conventions for managing Provider Provisioned VirtualPrivate Networks (PPVPNs). "What's In A Name:Thoughts from the NSRG", Eliot Lear, 02-AUG-02, Over the last few years, the character of Internet connectivity haschanged dramatically. A research group in the IRTF has beenchartered to review these changes, and make recommendations onwhether or not remediation within the protocol stack is necessary.This document discusses the outcome of some of those discussions.The key question we will consider is this: does the stack need anadditional level of naming above layer 3 but below the applicationlayer? While we do not conclude an answer at this point, we flushout the question a bit more, talk about existing work, and discussadditional questions, such as the structure and use of such names.Although this document has a single author, the ideasdescribed are those of many people both within and outside of theIRTF (see the References and Acknowledgements sections for moredetails). However, others within the NSRG hold views that differfrom those presented in this document. "Applicability Statement for Service Location Protocol, Version 2", E. Guttman, 04-JAN-02, The Service Location Protocol provides a scalable framework for thediscovery and selection of network services. Using this protocol,computers using the Internet need little or no static configurationof network services for network based applications. This documentdescribes the domain for which the protocol applies, in shortnetworks under a common administration, compatibility issues amongdifferent versions of the protocol and provides an overview to thevarious IETF documents which concern the use of SLP. "The serviceid: URI Scheme for Service Location", E. Guttman, 13-AUG-02, The Service Location Protocol (SLP) allows clients to discoverservices with little or no prior configuration. SLP can be used toadvertise services of any kind through the use of URLs. However, SLPuses URLs for two purposes: as a LOCATOR (indicating the location ofthe service) and as an IDENTIFIER (used for subsequent operations ona service, such as registration, deregistration and looking upattributes.) Confounding these two functions in one object leads tocertain problems. The serviceid: scheme separates identificationfrom location, eliminating these problems. "Secure Path MTU discovery: framework", Jerome Etienne, 04-JAN-02, This document presents a framework for a secure path MTU discoverywhich intend to improve the security compared to the current method.The rfc1191 [5] method relies on unauthenticated packets sent byrouters on the path. The lack of authentication allows an attackerto send fake packets and forces the host to instensively fragment allpackets (see Appendix A). "SIP Event Package for Keys", Jean-Francois Mule, Bert Culpepper, Robert Fairlie-Cuninghame, 06-MAR-02, This document defines a protocol independent message format for requesting and reporting state related to keys or buttons. The document also defines a SIP Event Package to make use of this extensible framework through the SIP SUBSCRIBE & NOTIFY messages. The draft currently defines key event sub-packages to represent the state of telephone dial pads, feature buttons found on many commercial telephones, standard keyboards as well as support for user or device specific buttons (for instance, a 'Double Latte' button). The event package and associated key packages can be used to enable new SIP services where an application or SIP entity requires notification of user interface activity either associated with a particular SIP session or simply in relation to the device itself. "AS-wide Unique BGP Identifier for BGP-4", J. Yuan, E Chen, 11-JAN-02, To deal with situations where the current requirements for the BGPIdentifier are not met, this document relaxes the definition of theBGP Identifier to be a 4-octet unsigned, non-zero integer, andrelaxes the 'uniqueness' requirement so that only AS-wide uniquenessof the BGP Identifiers is required. These revisions to the base BGPspecification does not introduce any backward compatibility issue. "IPv6 Neighbor Discovery Link-Layer Option Extension", Subrata Goswami, 07-JAN-02, This document describes changes to the Source/Target Link-layer Addressoption in IPv6 Neighbor Discovery Protocol [IPv6ND] to support addressesof any liength. "IM Simple Exchange (IMSX)", M. Rose, 15-JAN-02, The Common Presence and Instant Messaging profile (CPIM) is a set ofsyntax and semantics for instant messaging (IM) and online presenceservices, independent of the underlying transfer infrastructure. TheSession Initiation Protocol (SIP) negotiates session information formedia streams. This memo defines a BEEP profile, IMSX, forexchanging CPIM messages after SIP has performed signalling. "MGCP Extended Analog Line Package", Martin Wakley, Tania Sassenberg, 07-JAN-02, This document provides proposed definitions for a supplemental package for MGCP. This package addresses support of functionality for standard and enhanced telephony services delivered over analogue line terminations, specifically line/tip & ring polarity reversal. The package is defined with the intention of adding further line supervision signals at a later date. "Explicit Multicast Tunneling", J Lee, 09-AUG-02, Explicit multicast(Xcast)[1] is a new kind of Internet multicast,and encodes the list of destinations within its packet. Thisdocument specifies tunneling scheme of Xcast packets. Since asingle Xcast tunnel has multiple egress-nodes, the original Xcastpacket can be encapsulated either within a Xcast packet or within aunicast packet. When tunneled by Xcast-in-Xcast encapsulation, thebitmap of the original Xcast packet is overwritten by the bitmap ofthe tunnel Xcast packet at tunnel egress-nodes, in order to controlthe active destination set. "Multicast Avalanche Avoidance in Mobile IP (MAAMIP)", J Lee, 07-JAN-02, While it is a necessary feature that the home agent tunnelsmulticast packets to mobile nodes away from home, it can causesevere network congestion on the forward path between the homeagent and the care-of address nodes, because of the unicasttunneling of multicast packets. Multicast avalanche avoidance inMobile IP (MAAMIP) is designed to avoid the network congestion byusing of Explicit multicast tunneling. Explicit multicast tunnelingin Mobile IP enables avoidance of network congestion and realizesthe true bandwidth saving, which is the primitive goal ofmulticast. "Registration of GSTN SMS Service Qualifier", Erik Wilde, 16-APR-02, This memo describes the registration of the Short Message Service(SMS) as a registered IANA service selector for Global SwitchedTelephone Network (GSTN) numbers. SMS is not available for all GSTNsubscribers, but it has proven very popular with users of the GlobalSystem for Mobile Communications (GSM), and has also been adapted toother telephone network technologies such as the Integrated ServicesDigital Network (ISDN). "Reducing the Buffering Load of Paging Agent in IP Paging", H Jung, Seok Koh, 08-JAN-02, This draft defines two procedures to distribute buffering load in IPpaging using PA. A couple of documents using the PA, which includesall functions defined RFC 3154 in an entity, have beee submitted forcadidate protocol for IP paging. In this PA paging approach, thecentralized buffering in PA can be a bottleneck point if a PA has tomanage large paging area and a number of idle mobile hosts. Toaddress the problem, it can be good solution to distribute bufferingload among ARs in the paging area "HTTP Header Field-Name Registries", J Mogul, Mark Nottingham, 08-JAN-02, This note establishes an IANA registry for standardized HTTP headerfield-names, and an IANA registry indexing known non-standardizedHTTP header field-names. "FP", Fred Cohen, 08-JAN-02, This is a new protocol now being used to communicate within a local areanetwork. It is called 'FP' (rumored to stand for Frame Protocol) and isintended for use by communicating parties on the same LAN segment. "Using Media Resource Control Protocol over SIP", F Robinson, 08-JAN-02, This Draft presents a method for using Media Resource ControlProtocol (MRCP) in the body of SIP messages for the purpose ofcontrolling Prompt Players, Text to Speech, and Speech RecognitionEngines. Here we present MRCP->SIP as a function of the 'ServiceController,' identified in the decomposition of Application ServerCompenent Architecutures for SIP (draft-rosenberg-sip-app-components-01). The aurthor's believe that MRCP->SIP brings some powerfulsynergies to bare; rapid development of reliable media resourcecontrol, and the highly available, redundant, SIP infrastructure,capable of intelligent resource location. "DNS RR type for NAI", Junhyuk Song, 28-MAR-02, This document proposes the use of the new DNS RR type 'NAI' (Network Access Identifier) [RFC2486] to specify dynamically assignedIP address "Multiprotocol-DiffServ interworking using COPS", Sergio Giacomo, 10-JAN-02, This document introduces a new client type for the COPS protocol to support Multiprotocol-DiffServ inter-working in a network scenario where the access network is a non-DiffServ network. In such a scenario, traffic flows originating from heterogeneous applications ask to be admitted to the Diffserv core network. The Policy Decision Point (PDP) acts as a 'Bandwidth Broker' for Policy Enforcement Points(PEP) requesting resources. The new client type is located on each Border Router (PEP) of the Diffserv Network. "Dynamic Security Associations Setup in Mobile IP", John Floroiu, 10-JAN-02, This document proposes extensions to the Mobile IPv4 base protocol[RFC2002] enabling mobile nodes and mobility agents to dynamicallysetup security associations. Mobile IP is therefore employed as asupporting protocol for SA negotiation. The proposed mechanism isbased on RSA cryptography [RSA78], entities acting as keydistribution centers and Diffie-Hellman exchanges [DH76]. "CPIM to SMPP Mapping", Hisham Khartabil, 10-JAN-02, Messaging is the fastest growing means of communication in the world. Mobile telephony and SMS have also been growing at an enormous rate, eventually bound to edge out traditional telephony systems in volumes and importance. "CPIM to UCP/EMI Mapping", Hisham Khartabil, 10-JAN-02, Messaging is the fastest growing means of communication in the world. Mobile telephony and SMS have also been growing at an enormous rate, eventually bound to edge out traditional telephony systems in volumes and importance. "MTP Extensions for Message Threading and Message Identification", Petri Koskelainen, 10-JAN-02, The IMTP specification defines a session-based IM transportas well as the message format for it. However, it does not support message threads or discussion topics which are useful in applications such as multi-party chat. This document defines extensions to IMTP which allow applications to utilize threads and sub-threads within an IMTP message session. Also, the extensions enable message identification. "Overview of the ENUM Forum", Rob Freilich, 10-JAN-02, This document describes the current status and work plans for theENUM Forum and its Task Groups as an informational document to detail additional resources available and avoid overlap and duplication of efforts in the area of ENUM. The primary mission of the ENUM Forum is to develop the implementation framework for deploying RFC 2916 in a two-tiered DNS structure rooted under “e164.arpa” for E.164 numbers within the United States and a potential common implementation with other countries served by the North American Numbering Plan (NANP). "EAP over ICMP", George Tsirtsis, 10-JAN-02, This specification describes a way to carry the Extensible Authentication Protocol (EAP) over the Internet Control Message Protocol (ICMP). This provides a generic mechanism for user/device authentication to access routers or other designated nodes. "IP over InfiniBand(IPoIB): Advanced Capabilities", Vivek Kashyap, 11-JAN-02, InfiniBand Architecture(IBA) defines a high speed, channelbased interconnect between systems and devices. The InfiniBandarchitecture provides multiple modes of transport serviceswith differing characteristics. IPoIB may be implemented overany or multiple such modes to take advantage of the underlyingmode's features. IPoIB by default is implemented over the UDmode of IBA. This document describes IPoIB over IBA's non-UDtransport modes. "Configuring Security Parameters in Small Devices", Steve Hanna, 11-JAN-02, Before a device is installed into a secure network, certain securityparameters (such as keys) must be configured. This document describesseveral techniques for establishing these parameters and analyzestheir advantages and disadvantages, considering especially theirsuitability for inexpensive devices and inexperienced operators. "A Framework for Intra-ITAD Communications Protocol", Radhika Roy, 11-JAN-02, This document describes a framework for the intra-Internet TelephonyAdministrative Domain (Intra-ITAD) communications protocol. Theintra-ITAD communications scenarios are analyzed. The requirementshow the protocol will provide alias addresses resolution for routinga call to the appropriate gateway are described along with otherattributes like capacity and QoS. "LKH+2: An improvement on the LKH+ algorithm for removal operations", Sandro Rafaeli, 11-JAN-02, Several algorithms have been proposed to deal with the group key management problem. The most promising are those based on Logical Key Hierarchies (LKH). An LKH reduces the size of the rekey messages, reducing also the storage and processing requirements. An improved LKH algorithm called LKH+2 is described here. Using LKH+2, a group manager can use keys already in the tree to derive new keys. Using previously known keys saves information to be transmitted to members when a membership change occurs and new keys have to be created or updated. LKH+2 achieves K log_2 n message size (K is the size of a key) for leave operations. It is alsoshown that the LKH+2 algorithm does not increase the storage andprocessing requirements when compared to other LKH schemes. "IDsec: Virtual Identity on the Internet", Bob Hulsebosch, Hans Zandbelt, Henk Eertink, 15-MAY-02, IDsec is a mechanism that provides an identity for users on theInternet. Identity in IDsec means that a user is known by a certainprofile that contains precisely those attributes that the user wantsto reveal to the requester of his profile. Access to profileattributes is managed by the user himself. Certificates andpublic/private key mechanisms ensure that information is exchanged ina secure way only between parties that trust each other. "SIGTRAN Inter Signaling Process Communication", V. Gupta, 14-JAN-02, This Internet Draft explains the need of Inter Signaling processcommunication in the systems making use of SIGTRAN protocol. It alsoproposes procedures and various interface primitives for inter signalingprocess communication. This draft mainly focuses on Signaling GatewayProcesses and Application Server Processes as defined in SIGTRAN. "Application Server Process (ASP) Extension (ASPEXT) Framework for Signalling User Adaptation Layers", Brian Bidulock, 14-JAN-02, This Internet-Draft describes ASP Extensions (ASPEXT) for SignallingUser Adaptation Protocols [IUA, DUA, V5UA, M2UA, M3UA, SUA, TUA],which permits cooperating Signalling Peer Processes (SPPs) toindicate to each other the specific protocol extensions that eachsupports. "Signalling Gateway (SG) Information (SGINFO) Supportfor Signalling User Adaptation Layers", Brian Bidulock, 14-JAN-02, This Internet-Draft describes Signalling Gateway (SG) Information(SGINFO) for Signalling User Adaptation Protocols [M3UA, SUA, TUA],which permits supporting Signalling Gateways (SG) to conveyadditional Application Server (AS) support information to ApplicationServer Processes (ASPs) activating for AS on the SG. This additionalAS support information consists of information pertaining to theunderlying SS7 Signalling Provider that otherwise would have to bestatically configured at the Application Server Process (ASP) orexchanged between SG and ASP using a non-IETF defined protocol. "Load Selection for Signalling User Adaptation Layers", Brian Bidulock, 14-JAN-02, This Internet-Draft describes Load Selection for Signalling UserAdaptation Protocols [M3UA, SUA, TUA], which permits an ApplicationServer Processes (ASP) to indicate its placement within anApplication Server and permits an Signalling Gateway (SG) todistribute traffic over ASPs in Application Servers under ApplicationServer Process (ASP) control. "Load Grouping Extension for Signalling User Adaptation Layers", Brian Bidulock, 14-JAN-02, This Internet-Draft describes an extension parameter and procedure tothe Signalling User Adaptation Protocols [IUA...TUA], based on theStream Transmission Control Protocol (SCTP) [RFC 2960] which permitsan Application Server Processes (ASP) to indicate its placementwithin a Load Group and permits an Signalling Gateway (SG) todistribute traffic over Load Groups under Application Server Process(ASP) control. "Correlation Id and Hearbeat Procedures (CORID)Supporting Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Layers", Brian Bidulock, 14-JAN-02, This Internet-Draft describes Correlation Id and Heartbeatprocedures to support lossless fail-over between SCTP [RFC 2960]associations for Signalling User Adaptation Protocols [M3UA, SUA,TUA] above MTP3 [Q.704] supporting the concept of a Routing Context.These procedures permit lossless fail-over between Application ServerProcesses (ASPs) at a Signalling Gateway (SG) and fail-over betweenSignalling Gateway Processes (SGPs) and Signalling Gateways (SGs) atan Application Server Process (ASP). Lossless fail-over permitsthese fail-overs to occur without loss or duplication of UA-Usermessages. "SS7 TCAP-User Adaptation Layer TUA", Brian Bidulock, 14-JAN-02, This document defines a protocol for the transport of any SS7 TCAP-User signalling (e.g, INAP, MAP, etc.) over IP using the StreamControl Transport Protocol [RFC 2960]. The protocol should be modularand symmetric, to allow it to work in diverse architectures, such as aSignalling Gateway and IP Signalling End-point architecture. Protocolelements are added to allow seamless operation between peers in theSS7 and IP domains. "RPSL extensions for IPv6 and Multicast Routing Policies", Florent Parent, 14-JAN-02, This document describes the definitions and extensions required inRPSL [1] in order to be able to define IPv6 and multicast routingpolicies. Defining RPSL for IPv6 is an important step to build anIPv6 Internet Routing Registry. "Exploring the Loose Route Proposal", Robert Sparks, 14-JAN-02, This memo documents a proposal to allow SIP elements to use localpolicy when processing requests containing Route header fields. Itidentifies two restrictions on that local policy and provides analgorithm for satisfying one of those restrictions. It also presentsseveral example flows utilizing policies enabled by this proposal. "Registration of a Georgian Character Set", Gia Shervashidze, 14-JAN-02, This document provides information about character encoding GEOSTD8 (Georgian standard single byte encoding) which is a de-facto standard in Georgia for information interchange and presentation of WWW information resources in Georgian language. "Security issues in Internet Group Management Protocol version 3 (IGMPv3)", O. Paridaens, Annelies Van Moffaert, 05-MAR-02, This document discusses security aspects in IGMPv3 the protocol usedby hosts and routers to communicate their multicast group membership.A number of security issues are identified for which a possiblesolution is proposed. "Security issues in Protocol Independent Multicast - Sparse Mode (PIM-SM)", O. Paridaens, Annelies Van Moffaert, 05-MAR-02, This document points out a number of security issues in PIM-SM. "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 thatis managed by SWIFT s.c.r.l. (societe coopérative a responsabiliteslimitees) for usage within messages standardized by SWIFT. "IPv6 Network Ingress Filtering", F. Dupont, C. Castelluccia, 15-JAN-02, This document describes how network ingress filtering should bedone for the IPv6 protocol, including with mobile IPv6.Ingress filtering is a standard reply to Distributed Denial ofService (DDoS) using forged source addresses. A priori ingressfiltering can be done anywhere but is most efficient when it isdone by border routers of the source site. This can be consideredas a form of "The 'application/soap+xml' media type", Mark Baker, Mark Nottingham, 28-JUN-02, This document defines the 'application/soap+xml' media type which canbe used to describe SOAP 1.2 messages serialized as XML. "QoS-Conditionalized Binding Update in Mobile IPv6", Xiaoming Fu, 15-JAN-02, This draft presents a scheme for QoS support in Mobile IPv6. A QoShop-by-hop option piggybacked in the binding messages is used for QoSsignaling. A handoff takes place only upon the availability ofsufficient resources along the new transmission path. "Lightweight Directory Access Protocol (LDAP):Schema for Printer Services", I. McDonald, P. Fleming, 02-JUL-02, This document defines a schema, object classes and attributes, forprinters and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document isbased on the printer attributes listed in Appendix E of InternetPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printerattributes are based on definitions in the Printer MIB (RFC 1759). "Diameter Multimedia Application", T. Johansson, 11-FEB-02, This document specifies a Diameter application that allows a Diameterserver to authenticate, authorize, and collect accounting informationfor Session Initiation Protocol (SIP) services rendered to a clientnode. This application, combined with the base Diameter protocol andappropriate SIP extensions, allows SIP User Agents (UAs) to obtainservices from SIP servers that are connected to a Diameterinfrastructure. When combined with the Inter-Domain capability ofthe base protocol, service may even be obtained from SIP servers thatbelong to foreign domains, as would be encountered by roaming mobilenodes. "The EAP SecurID(r) Mechanism", S. Josefsson, 25-FEB-02, This document describe a EAP mechanism based on SecurID. SecurID isa hardware token card product (or software emulation thereof)produced by RSA Security, which is used for end-user authentication.The SecurID EAP mechanism can be used to provide authentication inprotocols utilizing EAP, such as PPP, IEEE 802.11 Wireless LAN andpossibly Bluetooth in the future. "RADIUS Master Session Key Attribute", Dan Simone, 17-JAN-02, This document specifies the RADIUS Master-Session-Key attribute, anattribute used to key ciphersuites used with PPP and IEEE 802.11. "The 'auth:' URI Scheme for Hierarchical Authority Identifiers", Patrick Stickler, 25-MAR-02, This document describes the 'auth:' Uniform Resource Identifier (URI)scheme for hierarchical authority identifiers.The 'auth:' URI scheme belongs to the class of Hierarchical URISchemes as defined in RFC 2396 'Uniform Resource Identifiers (URI):Generic Syntax'. "The 'tdl:' URI Scheme for Typed Data Literals", Patrick Stickler, 17-JAN-02, This document describes the 'tdl:' Uniform Resource Identifier (URI)scheme for Typed Data Literals "The 'uri:' URI Scheme for URI Reification", Patrick Stickler, 25-MAR-02, This document describes the 'uri:' Uniform Resource Identifier (URI)scheme for the reification of arbitrary Uniform Resource Identifiers. "The 'qname:' URI Scheme for XML Namespace Qualified Names", Patrick Stickler, 25-MAR-02, This document describes the 'qname:' Uniform Resource Identifier(URI) scheme for the representation of XML Namespace qualified names. "An Extended Class Taxonomy for Uniform Resource Identifier Schemes", Patrick Stickler, 17-JAN-02, This document defines a taxonomy of URI classes which extends the setof classes defined in RFC 2396 [15]. "The 'voc:' URI Scheme for Vocabulary Terms and Codes", Patrick Stickler, 25-MAR-02, This document describes the 'voc:' Uniform Resource Identifier (URI)scheme for vocabulary terms and codes.The 'voc:' URI scheme also belongs to the class of Hierarchical URISchemes as defined in RFC 2396 'Uniform Resource Identifiers (URI):Generic Syntax'. "The 'hrn:' URI Scheme for Hierarchical Resource Names", Patrick Stickler, 25-MAR-02, This document describes the 'hrn:' Uniform Resource Identifier (URI)scheme for hierarchical resource names.The 'hrn:' URI scheme belongs to the class of Hierarchical URISchemes as defined in RFC 2396 'Uniform Resource Identifiers (URI):Generic Syntax'.This URI scheme is also a type of URN, as defined by RFC 2396, but isnot a namespace of the 'urn:' URI scheme. "The 'xmlns:' URI Scheme for XML Namespace Reification and Namespace Prefix Declaration", Patrick Stickler, 25-MAR-02, This document describes the 'xmlns:' Uniform Resource Identifier(URI) scheme for the reification of XML namespaces and namespaceprefix declarations "Requirements for transmission of IP datagrams over DVB networks", H Clausen, P. Karn, 09-MAY-02, 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. One example is the Digital Video Broadcast (DVB), specified by standards published by the European Telecommunications Standards Institute (ETSI). The document 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. "Unifying Early Media, Manyfolks, And HERFP", J. Rosenberg, 18-JAN-02, The SIP working group has been grappling with a variety of verydifficult problems lately. These include early media, coupling ofresource reservation and call signaling, and the so-calledHeterogeneous Error Response Forking Problem (HERFP). Additionalproblems being considered include supporting capability negotiationfor indicating support any one of one-of-N codecs, upgrading thesecurity on RTP streams, and demultiplexing media from a forkedINVITE. In this document, we present a unified view of all of theseproblems, and present a unified solution that solves all of them inthe same way. "Generic Client Server Protocol (GCSP) for Application Layer", Anirban Majumder, 04-FEB-02, Generic Client Server Protocol is a simple generic Application levelprotocol to standardize communication between a pair of generic Clientand Server. It also tries to show some way to develop a tool that will build automatically the generic Client/Server pair at application layer.However, the main objective of this memo is to standardize an application layer protocol stack for Client/Server communication. "Registration of xmlns Media Feature Tag", Simon St.Laurent, Ian Graham, 26-FEB-02, This document specifies an xmlns Media Feature per RFC 2506 [5] foridentifying some or all of the URIs defining XML namespaces [14] in agiven XML resource, and the relative importance of these namespaces.This feature is designed primarily for use with the XML Media Typesdefined in RFC 3023 [12], to provide additional hints as to theprocessing requirements of a given XML resource "Use of GRE for routing support in IPSec VPNs", Archana Khetan, 21-JAN-02, When IPSec tunneling is used for VPN connections, transporting routingprotocols across the encrypted tunnels becomes challenging. Thisdocument outlines the use of GRE encapsulation in conjunction withIPSec transport mode to support transport of dynamic routing protocolsacross an IPSec encrypted tunnel. Some usage scenarios are alsoaddressed in this document. "Supporting Mobile SSM Sources for IPv6 (MSSMSv6)", Thomas Noel, Christophe Jelger, 22-JAN-02, Mobile IPv6 describes how a Mobile Node can change its point of attachment to the Internet. While MIPv6 focuses on unicast communications, it also proposes two basic mechanisms, known as bidirectionnal tunneling and remote subscription, to handle multicast communications with mobile members. In the mean time, the deployment of Source-Specific Multicast (SSM) is of great consideration, using the PIM-SM and MLDv2 protocols. "iSCSI EUI64-based Node Naming", Rob Grant, Todd Sperry, 22-JAN-02, This document proposes a new method of identifying iSCSI Nodesbeyond the iSCSI name. The new method uses a 64-bit field to becompatible with technologies using 64-bit identifiers such as EUI-64.These technologies include Fibre Channel and Infiniband, but may alsoextend to storage features such as failover, LUN-level masking or storage asset management. "URI scheme for GSM Short Message Service", Antti Vaha-Sipila, Erik Wilde, 16-APR-02, This memo specifies a URI (Universal Resource Identifier) scheme'sms' for specifying a recipient (and optionally a gateway) for anSMS message. SMS messages are two-way paging messages that can besent from and received by a mobile phone or a suitably equippedcomputer "Design and Implementation of the Quality-of-Service in IPv6 using the modified Hop-by-Hop Extension header-A Practicable Mechanism", Rahul Banerjee, 21-MAR-02, This paper proposes a temporary solution to the QoS implementationin IPv6, the design of which uses the Hop-by-Hop Extension headerand not the 20-bit flow label field in the IPv6 main header. Thispaper deals extensively with Integrated Services type of QoS model(like the one supported by RSVP) and gives the definition of the important TLV options that will be needed to specify the Type of QoSand the corresponding resource requirements in the Hop-by-HopExtension Header. "PPP EAP MS-CHAP-V2 Authentication Protocol", Jonathan Zamick, Doug Potter, 31-JAN-02, This document specifies an Extensible Authentication Protocol (EAP)mechanism for authentication using the Microsoft Challenge-Handshake Authentication Protocol (Version 2). "VeriSign Registry Registrar Protocol (RRP) Version 2.0.0", S. Hollenbeck, Srikanth Veeramachaneni, Suresh Yalamanchilli, 27-JUN-02, This document updates version 1.1.0 of the NSI Registry RegistrarProtocol specified in RFC 2832. The changes described in thisdocument combined with the base specification documented in RFC 2832specify version 2.0.0 of the VeriSign Registry Registrar Protocol. "Diversion with No Transport Overhead", Glenn Morrow, 28-JAN-02, Under certain circumstances the desired effects of diversion can be achieved with no per-packet transport overhead. This draft describes these circumstances as well as the per-packet bearer processing and general signaling requirements of some proposals that strive to remove the need for this overhead. The first proposal is referred to as Zero-Overhead Diversion (ZOD). The second is referred to as More Robust Zero-Overhead Diversion (MR. ZOD). Mobile IP and load distribution are examples of the useful application of diversion. "KOI8-C", Serge Winitzki, 29-JAN-02, This document provides information about character encodingKOI8-C (KOI8 Cyrillic) proposed for use with Russian (includingold orthography), Ukrainian, Belorussian, Serbian, Macedonianlanguages with special punctuation marks. KOI8-C is compatiblewith KOI8-R [1] and KOI8-U [2] in the area of Russian, Ukrainianand Belorussian letters, and extends these with letters for oldRussian orthography, Yugoslavian cyrillic letters andtypographical symbols in positions compatible with CP1251 for usein legacy applications. "A mechanism for Discovery of PANA Authentication Agents(PAA-discovery)", P Engelstad, 29-JAN-02, A PANA authentication protocol is under development in the PANAWorking Group. It will allow hosts to authenticate with PANAAuthentication Agents (PAAs). The protocol is expected to run oversome IP-based transport protocol, such as ICMP, UDP, TCP or SCTP.Before a host can authenticate with a PAA, it must obtain an IP-address of the PAA. This document specifies such a 'discovery'mechanism by defining extensions (or options) to RouterAdvertisements and DHCP messages for both IPv4 and IPv6. Hosts MAYalso obtain an identity of a PAA and other information during thediscovery process. The proposed discovery mechanism makes noassumptions about the location of a PAA, and more than one PAA maybe discovered. "DNS/LDP Based VPLS", Juha Heinanen, 29-JAN-02, This memo describes how provider provisioned Virtual Private LANService (VPLS) can be implemented using DNS and LDP for PE discoveryand label distribution. "Random generation of interface identifiers", Marcelo Bagnulo, Arturo Azcorra, Ignacio Soto, 29-JAN-02, This document evaluates the use of random numbers to generate theinterface identifier part of an IPv6 address on mobile environments,where Duplicate Address Detection (DAD) mechanisms are expensive. Wehave estimated the probability of having an address duplication usingthis mechanism and we conclude that the IPv6 addresses created inthis way could be used without previously doing DAD to test theuniqueness of the address in a link. "Requirements for CAR Discovery Protocols", Govind Krishnamurthi, 05-MAR-02, The pre-requisite for IP based seamless mobility protocols is theknowledge of the access router (AR) to which a mobile node can behanded over to. Further, a handoff can be optimized if the capabilitiesof the AR being considered for handoff are known. The protocol whichdiscovers ARs for potential handoff along with their capabilities iscalled the CAR discovery protocol. In this draft we list therequirements which are to be met by CAR discovery protocols. "OSPF Area 0 PE/CE Links in BGP/MPLS VPNs", Eric Rosen, 31-JUL-02, [VPN] describes a method of providing a VPN service. That methodallows a variety of different protocols to be used as the routingprotocol between the Customer Edge (CE) router and the Provider Edge(PE) router. [OSPF-VPN} specifies the procedures which must beimplemented within the Provider's network when the PE/CE routingprotocol is OSPF [OSPF], and the PE/CE link is not an area 0 link.This document specifies the additional, optional, procedures thatmust be implemented to support the case in which the PE/CE link is anarea 0 link. "CPIM to CIMD2 Mapping", Hisham Khartabil, 31-JAN-02, Messaging is the fastest growing means of communication in the world. Mobile telephony and SMS have also been growing at an enormous rate, eventually bound to edge out traditional telephony systems in volumes and importance. "Add a 'parallel resource allocation style object' to GMPLS signaling-RSVP-TE and CR-LDP", Hui Wang, 31-JAN-02, The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. GMPLS is assumed tobe the most possible control plane for the future all optical transport network. "Improved Low Latency Handoff in Mobile IPv4", Shiva Pandey, S. Jamadagni, 05-FEB-02, We are considering the IETF Mobile IP WG proposed Low Latency Handoffdraft[2] in the different network scenerios and suggesting one simplersolution with low loss, reduced number of timers, reduced network overhead, along with the low latency. One more achievement will be reduction in the dependency on exact L2 trigger timing and Pre-Registration timer expiration in Combined Handoff method[2]. "Fast Convergence Extension for ISATAP Router Discovery", F. Templin, 01-FEB-02, This document specifies an optional extension for [ISATAP] that sup-ports fast convergence (i.e, fast discovery of on-link routers). Theextension employs a subset of the multicast mechanisms specified by[6OVER4] to augment the NBMA mechanisms specified by [ISATAP]. "Optimized IP Mobility - Requirements for Underlying Systems", S. Jamadagni, 01-FEB-02, IP mobility protocols have traditionally been designed to be independent of any L2 considerations. A critical factor in achievinggood performance for IP mobility protocols is the design of L2 handover. Handover occurs when a Mobile Node moves from one radio Access Point to another. "A Survey of IPv4 Multicast Service Implementations", Bill Nickless, 01-FEB-02, This document surveys various ways of implementing the IPv4Multicast Service Model. Each mechanism is evaluated against acommon set of criteria. "The IP Multicast Service Model", Bill Nickless, 01-FEB-02, This document outlines a framework for IP Multicast applications. It intends to describe the services that an application host and associated networks should provide. "Authoritative Mail Sender DNS Resource Record", Andrew Church, 02-AUG-02, This document defines a new experimental DNS resource record type,Authoritative Mail Sender (MS), which can be used to verify theauthenticity of the domain name provided in the sender address of amail message and help to prevent forgery of sender addresses. "Phased Implementation for Internationalized Domain Names in Applications", L Tseng, 01-FEB-02, This document proposes a phased implementation for IDNA (Internationalized Domain Names in Applications). DNS infrastructure is critical for the Internet operation. The implementation of IDNA shall be carefully considered and examined. Deployment of IDN infrastructure shall be migrated step by step to ensure the reliability of the new infrastructure. To fulfill the incremental change requirements, this document proposes a phased implementation for IDNA. "Simple Middlebox Configuration (SIMCO) Protocol Version 1.0", Juergen Quittek, Martin Stiemerling, 01-JUL-02, This memo specifies the Simple Middlebox Configuration (SIMCO)protocol for configuring Network Address Translators (NATs) andfirewalls dynamically to create address bindings and open pinholes.NATs and firewalls are a problem for applications using voice andvideo streaming, such as IP telephony, because they need to establishvoice or video channels dynamically. The SIMCO protocol allowsclients to send requests for this purpose to serving NATs and/orfirewalls. The protocol is designed to provide a simple and basicsolution that can easily be implemented and used, while still meetingalmost all requirements defined by the MIDCOM working group (see[4]). "AES Ciphersuites for DIGEST-MD5 SASL mechanism", Alexey Melnikov, 01-FEB-02, This document describes the use of the AES Cipher Algorithm in CipherBlock Chaining Mode, as a confidentiality algorithm for DIGEST-MD5SASL mechanism. "WS-Attachments", H. Nielsen, 01-JUL-02, This document defines an abstract model for SOAP attachments and based on this model defines a mechanism for encapsulating a SOAP message and zero or more attachments in a DIME message. SOAP attachments are described using the notion of a compound document structure consisting of a primary SOAP message and zero or more related documents known as attachments. "NDT-Framing", Julian Satran, 04-FEB-02, During the last year several attempts have been made to provide a generalized framing mechanism for protocols using TCP. The main pur-pose of those mechanisms is to enable hardware network adapter builders to discover fast the next Upper Layer Protocol Data Unit boundary and thus minimize the amount of memory required on the network adapters in order to handle packet drop or reordering in the network. "A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using hybrid approach", Rahul Banerjee, 22-APR-02, This memo suggests a pragmatic specification for defining the 20-bitFlow Label field using a hybrid approach that includes options toprovide IntServ as well as DiffServ based support for IPv6 Quality ofService. It also compares various suggested approaches for definingthe 20-bit Flow Label field in IPv6 Base Header based on RFC 2460(December 1998) and few other drafts. Addressing the IPv6-Multicast-QoS issues also becomes possible as a consequence. This draft clearlyspecifies exactly when and how various options are to be used; and incase of the MFC, exactly how a specific action might be taken by thesuggested implementation. Thus the resultant mechanism is fullyimplementable and unambiguous as even the lower-level details have beenworked out as may be required for actual implementations. The draftalso has a pointer to an experimental QoS scheme called MultServ. "Use of /127 Prefix Length Between Routers Considered Harmful", P. Savola, 28-JUN-02, In some cases, the operational decision may be to use IPv6 /127prefix lengths, especially on point-to-point links between routers.Under certain situations, this may lead to one router claiming bothaddresses due to subnet-router anycast being implemented. This draftdiscusses the issue and offers a couple of solutions to the problem;nevertheless, /127 should be avoided between two routers. "Reply Posting Guidelines in One to Many Communications", John Bambenek, 25-MAR-02, This document describes the proper methods to use when replying to messages in a One to Many communication environment such asUSENET, mailing lists, or bulletin boards. It is recommended that top-posting in a summary reply be used primarily, or if desiredand appropriate that middle-posting or conversational-posting be used in a point-by-point reply. "Proposal for IPFIX Flow Export Architecture and Data Model", Ganesh Sadasivan, Benoit Claise, 05-FEB-02, This memo defines the architecture, the data model and theinformation model for the export of measured IP flow information outof an exporter to a collector, per the requirements defined in [1].While this document discusses the key concepts of flow export, someof the topics discussed are far from complete. The intention of thisrevision is to provide a starting framework for the flow exportarchitecture "The basic NICNAME/WHOIS protocol", Ben Campbell, 05-FEB-02, This memo defines the basic WHOIS protocol as used on the Internet today. "SIP Extension for Multiparty Conferencing", Johannes Stadler, Igor Miladinovic, 12-SEP-02, This document proposes an extension to the Session InitiationProtocol (SIP) that extends SIP for the CONF method and theParticipant header field. The extension provides that the identity ofeach participant in a multiparty conference is known by otherparticipants all the time, from the initialization to the end of theconference. Examples of using this extension with different SIPconferencing models are also given. "Internet Registry Directory Requirements", A Newton, 28-JUN-02, Internet registries expose administrative and operational data viavarying directory services. This document defines the commonrequirements for the directory services of these Internet registries. "Edge Policy Propagation Control", Joe Abley, 07-FEB-02, There is a requirement for some multi-homed sites to influence thepath selected by autonomous systems beyond those that are immediatelyadjacent.This draft describes a community-based convention which might be usedto limit propagation of particular prefixes to those ASes where theyare required. "Keywords Systems - Definition and Requirements", Tim Tan, XiaoDong Lee, Yves Arrouye, 28-FEB-02, The DNS (Domain Name System), which was designed as a networkresource naming layer, is not able to serve today's Internet usersnaming needs anymore. Attempts to change the DNS to adapt to thoseneeds, such as the IDN (Internationalized Domain Name) IETF effort,are not only proving themselves unsatisfactory in many ways, they arealso limited by the nature of DNS itself. "MGCP Fax Package", F. Andreasen, 08-FEB-02, 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. "A Context Transfer Framework for supporting fast handover", S. Jamadagni, 08-FEB-02, Mobile nodes enhance their connections across wireless media byestablishing specific parameters at the FA/AR/AP in order tofacilitate optimal usage of the resources as well as enhance the QoSas seen by a MN. During handover from one access router to another, abandwidth-constrained mobile node MAY need to have state informationpassed from the previous router to the new one. This documentproposes a context transfer framework that makes use of existing fasthandoff signaling for context transfer as well as provide a mechanismfor QoS negotiation and renegotiations. We also cover CT under CARdiscovery. The suggested mechanism provides for context transfer sothat the applications running on the mobile node could operate withminimal disruption. "Public Wireless LAN roaming issues", Jacques Caron, 11-FEB-02, Public wireless Internet access zones based on IEEE 802.11 [1] wireless LAN technology are becoming common. However, many issues are impeding further adoption of the technology by end-users, in particular the inability or difficulty to roam between the networks of different providers. This document aims to document these issues, show how they are different from roaming in other contexts such as dialup access to the Internet or GSM roaming, and how current solutions do not fully address these issues. Future documents will try to address these issues with practical solutions. "IMEI-based universal IPv6 interface IDs", F. Dupont, L. Nuaymi, 01-JUL-02, The IPv6 addressing architecture [1] defines a modified EUI-64format for interface identifiers. These interface identifiers mayhave global scope when a global token is available (e.g., IEEE 80248-bit MAC or IEEE EUI-64 identifiers). Such a global token, theIMEI (International Mobile station Equipment Identity), is definedfor GSM and UMTS terminals [2, 3, 4] and has the same propertiesthan identifiers based on IEEE standards.This document explains the construction of a global IPv6 interfaceidentifier from an IMEI. "3GPP Requirements for SIP Authentication", Jari Arkko, 11-FEB-02, The 3rd Generation Partnership Project (3GPP) has selected SessionInitiation Protocol (SIP) [1] as the session establishment protocolfor the 3GPP IP Multimedia Core Network Subsystem. This documentdiscusses requirements identified by 3GPP concerning SIPauthentication methods. "Global Unique Identifiers (GID)", H Ould-Brahim, 01-JUL-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. "RADIUS accounting for SIP servers", H. Schulzrinne, 11-FEB-02, This memo defines mappings of RADIUS accounting attributes for usewith SIP servers. It also defines several new attributes to supportthe provision of RADIUS accounting for SIP servers. "Enhanced Usage of HTTP Digest Authentication for SIP", James Undery, S. Sen, V Torvinen, 14-JUN-02, HTTP Digest has some shortcomings if applied for SIP. Firstly, SIP UA has serious difficulties to distinguish the source of Authentication-Info and Proxy-Authentication-Info headers in SIP forking situations. This is due to the absence of the ‘realm’ parameter in these headers. Secondly, HTTP authentication is particularly vulnerable against MITM bid-down attacks on the list of algorithms (e.g., MD-5, SHA-1) or the desired security level (auth, auth-int). Thirdly, HTTP authentication provides limited integrity protection of only the message body. In SIP, important information can be carried in many of the headers that may need integrity protection. This draft proposes to add the realm parameter in the *-Authentication-Info headers, recommends a format for computing the nonce for detection of bid-down attack and proposes a mechanism for integrity protection of SIP headers using MIME body. "The Direct Data Placement Protocol (DDPP) Core", Stephen Bailey, 12-FEB-02, This document defines the core of a Direct Data Placement Protocol(DDPP) to run on Internet Protocol-suite transport protocols. TheDDPP core is mapped to specific transport protocols in separatedocuments "Extensible Provisioning Protocol DNS Security Extensions Mapping", S. Hollenbeck, 12-JUN-02, This document describes an Extensible Provisioning Protocol (EPP)extension mapping for the provisioning and management of DNS securityextensions for domain names stored in a shared central repository.Specified in XML, this mapping extends the EPP domain name mapping toprovide additional features required for the provisioning of DNSsecurity extensions. "The Remote Direct Memory Access Protocol (iWarp)", Stephen Bailey, 12-FEB-02, This document defines a Remote Direct Memory Protocol (iWarp) torun on the Direct Data Placement Protocol (DDPP) [DDPP]. Thisinitial draft is an incomplete sketch of iWarp to be used only asthe basis of discussion of protocol and architectural issues withDDPP and RDMA. "The Architecture of Direct Data Placement (DDP)And Remote Direct Memory Access (RDMA) On Internet Protocols", Stephen Bailey, 12-FEB-02, This document defines an abstract architecture for Direct DataPlacement (DDP) and Remote Direct Memory Access (RDMA) protocols torun on Internet Protocol-suite transport protocols. Thisarchitecture does not necessarily reflect the proper way toimplement such protocols, but is, rather, a descriptive tool fordefining and understanding the protocols "LDAPv3: Requesting Attributes by Object Class", Kurt Zeilenga, 05-AUG-02, The Lightweight Directory Access Protocol (LDAP) search operationprovides mechanisms for clients to request all user applicationattributes, all operational attributes, or attributes selected bytheir description. This document extends LDAP to provide a mechanismfor LDAP clients to request the return of all attributes of an objectclass. "LDAP True/False Filters", Kurt Zeilenga, 05-AUG-02, This document extends the Lightweight Directory Access Protocol (LDAP)to support absolute True and False filters based upon similarcapabilities found in X.500 directory systems. The document alsoextends the String Representation of LDAP Search Filters to supportthese filters. "Note about Routing Header Processing on IPv6 Hosts", P. Savola, 13-FEB-02, [IPV6] specifies routing header processing for nodes. The text issufficiently ambiguous where the behaviour of hosts is concerned.This draft clarifies the issue by referring to IPv4 Host Requirementsdocument and requiring hosts must not, by default, forward routingheaders outside of the node. "The SPEKE Password-Based Key Agreement Methods", David Jablon, 16-APR-02, This document describes SPEKE, B-SPEKE, and SRP-4, three methods forpassword-based key agreement and authentication. In the same classof techniques as SRP-3 [RFC 2945], these methods provide a zero-knowledge proof of a password and authenticate session keys over anunprotected channel, with minimal dependency on infrastructure andproper user behavior. These methods are compatible with IEEE 1363and ANSI X9 standards, and are closely aligned with RFC 2945 from anapplication perspective. They use different techniques than earlierpatented alternatives, and provide an expanded set of choices forconvenient and secure personal authentication over the Internet. "Ethernet Pseudo Wire (PW) Management Information Base", Thomas Nadeau, S. Park, 27-AUG-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, it describes managed objectsfor modeling of Ethernet Pseudo Wire (PW) services. "NSIS QoS Signalling Requirements", David Partain, 15-FEB-02, This memo identifies a set of requirements that must be applied tothe development of the NSIS quality of service (QoS) signallingprotocol. These requirements are based upon the needs of variouskinds of applications that will utilize IP networks and need to beable to signal their QoS needs "Backtrace Messages for Label Switched Paths", HariKishan Desineni, Kameswara Avasarala, 04-SEP-02, Label switched path (LSP) backtrace is a method to backtrack the paths followed by packets in a particular forwarding equivalence class (FEC). This document describes the encoding and procedures for new label distribution protocol (LDP) messages, the backtrace message and backtrace reply message used for performing LSP backtrace. The backtrace message is sent upstream for an established LSP. The backtrace message can be used for LDP LSPs as well as for constraint based label switched paths (CR-LSPs). The data requested through a backtrace message is encoded into the backtrace reply message. Backtrace reply message is sent in downstream direction. It always travels towards the tail end of the LSP. Backtrace mechanism described in this document can also be used for obtaining additional attributes of the LSPs. "RTP Archiving, Delivery, and Playback (RADPLAY) Extensions for SDP", R. Lanphier, 15-FEB-02, This document defines RTP Archiving, Delivery, and Playback (RADPLAY) extensions for the Session Description Protocol (SDP, [RFC 2327]). These extensions provide a standard meansof archiving and delivering RTP streams via HTTP, using SDP and the commonly used 'rtpdump' file format. As a result of its design, it also provides a way of delivering generic RTP streams over HTTP, thus making it a suitable replacement for approaches which rely on network-unfriendly mechanisms such as 'HTTP tunneling'. "Responsible Vulnerability Disclosure Process", SteQven Christey, Chris Wysopal, 15-FEB-02, New vulnerabilities in software and hardware products are discoveredand publicized on a daily basis. The disclosure of vulnerabilityinformation has been a divisive topic for years. During the processof disclosure, many vendors, security researchers, and other partiesfollow a variety of unwritten or informal guidelines for how theyinteract and share information. Some parties may be unaware of theseguidelines, or they may intentionally ignore them. This state ofaffairs can make it difficult to achieve a satisfactory outcome foreveryone who uses or is affected by vulnerability information. "IPv6 Prefix Options for DHCPv6", Ralph Droms, Ole Troan, 02-MAY-02, The Prefix Delegation option and the Prefix Request option provide amechanism for delegation of IPv6 prefixes using DHCP. This prefixdelegation mechanism is intended for simple prefix delegation from adelegating router to a requesting router, across an administrativeboundary, where the delegating router does not require knowledgeabout the topology of the links in the network to which the prefixeswill be assigned. "Requirements for SIP Security Mechanism Agreement", Jari Arkko, 15-FEB-02, The Session Initiation Protocol (SIP) is an application-layercontrol (signaling) protocol for creating, modifying and terminatingsessions with one or more participants. These sessions includeInternet telephone calls, multimedia distribution and multimediaconferences. SIP has a number of security mechanisms used for hop-by-hop or end-to-end protection. In this document we discussrequirements concerning SIP security mechanism agreement. "MObile Networks (MONET) problem statement and scope", H. Soliman, 18-FEB-02, This draft illustrates some of the problems that need to be addressed in order to provide an optimal mobility management mechanism for mobile networks consisting of a mobile router and a number of IPv6 hosts. The reader shall refer to a separate document[TERMINOLOGY] for the terminology used in this draft, while a list of proposed requirements can be found in [REQUIREMENTS] "Discussing Application Public Keys in the DNS", Ed Lewis, 18-FEB-02, A debate over whether to include public keys for other applications inthe Domain Name System has been held ever since the introduction of theDNS Security Extensions. This document records the salient points ofthe debate. "CPL-Extensions for Network Operators", Stephan Koetter, 18-FEB-02, The Call Processing Language (CPL) can be used to describe and control Internet telephony services. The original CPL specification focuses on call handling on network servers. The extensions of CPL in this document are designed to add capabilities to describe network-operator-related services. These services are essential for providing services on a network. "EAP IANA Considerations", B. Aboba, 28-FEB-02, This document describes the IANA considerations for ExtensibleAuthentication Protocol (EAP). "The Vendor-Specific EAP Method", B. Aboba, 28-FEB-02, This document defines a Vendor-Specific Method for the ExtensibleAuthentication Protocol (EAP), defined in RFC 2284. "Requirements for Delegation of Message Protection for SIP", Jari Arkko, 18-FEB-02, The Session Initiation Protocol (SIP) is an application-layercontrol (signaling) protocol for creating, modifying and terminatingsessions with one or more participants. These sessions includeInternet telephone calls, multimedia distribution and multimediaconferences. "NSIS QoS Signaling Requirements from a Multi-access Wireless Perspective", Gabor Fodor, 18-FEB-02, We consider access technology agnostic applications that use IP levelQoS primitives to specify their QoS requirements. In future wirelesssystems (beyond what is often referred to as 3G), where mobile nodesmay access an IP backbone over diverse access networks, the IP levelQoS primitives are not only used to specify the requested IP levelservice, but also (through an access specific translation function)to help the mobile node's wireless link manager to configure thewireless bearer service. In such a scenario, the IP level QoSprimitives must meet special requirements in order to support thespectrum efficient management of the wireless resources. "New EPP Parameters for the usTLD", Hong Liu, 18-FEB-02, This document defines two new EPP parameters to enable the exchange of additional information between the registry and the registrars for the United States ccTLD (usTLD). These two new parameters only apply to contact objects served as registrants for usTLD domains. This is accomplished according to the EPP extension framework in the command-response field. "Some Heuristics about Piggybacked Binding Updates", C. Perkins, Cedric Westphal, 19-FEB-02, This document presents some simple analytical results with respect tothe performance improvement brought by piggybacking binding updates(BUs). We see that the improvement in term of bandwidth is notsignificant unless the mobile terminal sending BUs moves very fast.We also see on the other hand that the improvement in term of jitteris quite significant in most situations. "ENUM Root Domain", William Dutcher, Kevin McCandless, 21-FEB-02, RFC 2916 specifies that the domain e164.arpa is the rootdomain for the DNS storage for NAPTR records for ENUMs.This document proposes that the root domain referenced inRFC 2916 be changed from e164.arpa to a generic domain, suchas e164.foo. This would give developers of ENUM applica-tions a greater degree of flexibility in configuring DNSstructures for ENUM. "Securing BGPv4 using IPsec", David Ward, 19-FEB-02, This document discusses how BGPv4 may utilize IPsec to provideauthentication, integrity, confidentiality and replayprotection. "ARP Mediation for IP interworking of Layer 2 VPN", Himanshu Shah, 19-FEB-02, This draft addresses an issue in a particular kind of Layer 2 VPN, which provides point-to-point connectivity for IP traffic only. In this kind of VPN it is possible to form heterogeneous point-to-point links, where the two ends of the link use different technologies, e.g., one end is Ethernet and the other is Frame Relay or ATM. If two IP systems are connected via a heterogeneous point-to-point link, each may be using different address learning techniques, e.g., one is using ARP and the other Inverse ARP. It is up to the Provider Edge routers to make these different techniques interwork. This draft specifies the procedures, which the Provider Edge routers should perform in order to allow correct operation across heterogeneous point-to-point links. "The SLP URL Format", H. Schulzrinne, W. Zhao, 14-JUN-02, This document describes the SLP URL format for the Service LocationProtocol. The SLP URL is used to encode an SLP search query into aURL string, which facilitates the integration of SLP with systemsthat use URL as an interface, and provides a convenient way toexpress remote SLP discovery. "Internet Registry Information Service", A Newton, 19-FEB-02, This document describes an application layer client-server protocolfor a framework of representing the query and result operations ofthe information services of Internet registries. Specified in XML,the protocol defines generic query and result operations and amechanism for extending these operations for specific registryservice needs. "IRIS Domain Registry Schema", A Newton, 19-FEB-02, This document describes an IRIS (draft-newton-iris-00.txt ) registrynamespace and schema for registered DNS information. The schemaextends the necessary query and result operations of IRIS to providethe functional information service needs for syntaxes and resultsused by domain registries and registrars. "IRIS Address Registry Schema", A Newton, 19-FEB-02, This document describes an IRIS registry namespace and schema forregistered Internet address information. The schema extends thenecessary query and result operations of IRIS(draft-newton-iris-00.txt) to provide the functional informationservice needs for syntaxes and results used by Internet addressregistries. "IRIS HTTP Binding", A Newton, 19-FEB-02, This document specifies how to use HTTP as the application transportsubstrate for IRIS (draft-newton-iris-00.txt). "An API for Service Location", E. Guttman, James Kempf, 19-FEB-02, 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. "DSTM in a VPN Scenario", J. Richier, Octavio Medina, Laurent Toutain, 19-FEB-02, In an implicit manner, the specification of DSTM focuses on ascenario where DSTM nodes are inside an IPv6-only intranet. Thisdocument describes a new usage for DSTM in which DSTM nodes arelocated outside the intranet: the VPN scenario. "IPv6 Router Advertisement Prefix Delegation Option", Nathan Lutchansky, 20-FEB-02, This document defines the Prefix Delegation (PD) option used todelegate IPv6 address space to simple IPv6 sites. The PD option,which lists the global prefixes that a site may use to number itsnetwork, is attached to IPv6 Neighbor Discovery Router Advertisementmessages that are sent across a point-to-point link from a provider'srouter to a site's border router. This document defines themechanism by which a site router processes the PD option andconfigures each of its attached links allowing hosts within the siteto obtain global addresses using address autoconfiguration. "Issues with NAT-PT DNS ALG in RFC2766", Alain Durand, 20-FEB-02, Recent discussions on DNS over IPv6 transport have brought a betterunderstanding on the impact of tools like NAT-PT (RFC2766). Severalproblems have been identified around the DNS ALG functionality. "A generic fragment identifier syntax for URI references", Simon St.Laurent, Jonathan Borden, 20-FEB-02, URI references with fragment identifiers uniquely identify parts of adocument. Such identifiers have been specified as SGML/XML IDs e.g.in HTML [6]. The XPointer [2] specification is intended to serve asa fragment identifier syntax for XML documents. IDs conform to theXPointer 'raw name' form. Specifications constraining the behaviorof user agents such as SMIL [8], XHTML [15], and SVG [10] have allsupported this simple fragment naming convention though some extendit. "SIP Communications Resource Priority Header", H. Schulzrinne, James Polk, 06-MAR-02, This document defines a new SIP header field for communicationsresource priority, called 'Resource-Priority'. This header fieldinfluences the behavior of gateways and SIP proxies. It does notinfluence the forwarding behavior of IP routers. "RADIUS accounting for SIP servers", H. Schulzrinne, 20-FEB-02, This memo defines mappings of RADIUS accounting attributes for usewith SIP servers. It also defines several new attributes to supportthe provision of RADIUS accounting for SIP servers "Zero-Configuration Subnet Prefix Allocation Using UIAP", Andrew White, Aidan Williams, 20-FEB-02, The ability of a multiple segment network to zero configure hasadvantages. This is especially the case when the networkdesigner/builder has few IP networking skills, as can be expected inthe home environment. This document describes a method for the zero-configuration of unique subnet prefixes in a network. The methodproposed is based on the existence of the Unique IdentifierAllocation Protocol (UIAP) but can be modified to use anotherprotocol providing the same service. "Unique Identifier Allocation Protocol", Andrew White, Aidan Williams, 20-FEB-02, This memo specifies a distributed mechanism for testing theuniqueness of identifiers within a connected collection of devices.The mechanism supports multiple identifier domains, and uses onlylink-local communication and flooding. "A Locally Scoped DNS Namespace", Aidan Williams, 05-JUL-02, This memo defines a locally scoped private DNS namespace. "MEGACO/H.248 FXO packages", Sridhar Kalubandi, Vijayapal Patil, 22-APR-02, This document describes the events and signals helpful for signaling between Central Office (CO) and Foreign Exchange Office (FXO) at Customer Premises Equipment (CPE).It is intended to satisfy the requirements in section 12 of the Megaco RFC 3015/H.248 document. "IPv6 Stateless Address Autoconfiguration for Hierarchical Mobile Ad Hoc Networks", Martina Zitterbart, Kilian Weniger, 20-FEB-02, This document describes, how the IPv6 Stateless AddressAutoconfiguration [1] can be applied to hierarchical mobile ad hocnetworks. A hierarchical address space is build up to limit theprotocol overhead needed for the Duplicate Address Detection (DAD)and to enable route aggregation for hierarchical routing protocols.Unique addresses are guaranteed, even if the network splits up andmerges later on. "A New QoS Mechanism for Mass-Market Broadband", John Adams, A Smith, 20-FEB-02, This document describes a proposal which deals with congestion conditions that may arise when a home or SME customer requests too many simultaneous flows to be forwarded down a DSL link or other access technology. It provides a solution to guaranteeing certain flows while making others (typically the latest or another flow selected for policy reasons) the subject of focused packet discards. It has a number of significant benefits over other possible solutions, such as classical RSVP, and these are also listed in the document. "Network Mobility Support Terminology", T Ernst, H Lach, 05-JUL-02, This document proposes a terminology for defining the problem facedby network mobility. Network mobility is concerned with situationswhere an entire network changes its point of attachment to theInternet and thus its reachability in the topology. We shall refer tosuch a network as a mobile network. Network mobility support is tomaintain session continuity between nodes in the mobile network andnodes in the global Internet. "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources", John Brezak, 21-FEB-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. "Analyzing IPv4 and Ipv6 address space with the HD-ratio", Alain Durand, 21-FEB-02, This document analyses current IPv4 allocation and projected IPv6allocations using the HD-ratio defined in RFC3194. "PPP over Full Duplex Point-to-Point Ethernet Physical Layers", Earl McCoy, John Sauer, 21-FEB-02, This document provides a definition for encapsulating the PPPprotocol directly on the various full duplex point-to-point Ethernetphysical layers. The later includes transmission bit rates of10Mbps, 100Mbps, 1Gbps, and 10Gbps. Note this is a distinct protocolfrom PPPoE, as the Ethernet frame is not existent here. All PPPpacket semantics and syntax are retained. The proposed methods inthis document may be especially useful for low cost, high bandwidthphysical channel implementations. In particular it specifies andredefines all necessary Ethernet Medium Independent Interfacefunctional 'clauses.' "IPv4 Multicast Unusable Group And Source Addresses", Bill Nickless, 25-JUN-02, 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. "ENUM Service Resolution Pointer", Andrew Zmolek, 21-FEB-02, Current notions of service field tags in ENUM NAPTR records would frame the service exposure problem as a tradeoff between the privacy and heft involved in revealing detailed service information on the one hand or the arbitrary constraint of such information on the other. This draft suggests an alternative approach that keeps NAPTR record size small, places service exposure policy and presence capabilities in the hands of the ENUM registrant where it belongs, and minimizes impact to the ENUM registrar and their respective DNS architecture. "PPVPN Architecture using L2TP", Brijesh Kumar, B. Schliesser, Elwin Eliazer, 21-FEB-02, This document discusses the use of L2TP for establishing PPVPNs. Itproposes to use L2TP for VPN membership, topology discovery, and as atunneling mechanism. The basic idea is based on leveraging the inherentstrengths of L2TP for tunneling traffic, and extend the same advantagesto PPVPNS. The mechanism is applicable for both Layer2 and Layer3PPVPNs. "Security Requirements for Keys used with the TCP MD5 Signature Option", Marcus Leech, 21-FEB-02, The TCP MD5 Signature Option [RFC2385], used predominantly by BGP,has seen significant deployment in critical areas of Internetinfrastructure. The security of this option relies heavily on thequality of the keying material used to compute the MD5 signature.This document addresses the security requirements of that keyingmaterial. "Limited Private Address Support:An addendum to Reverse Tunneling for Mobile IP (RFC3024)", Samita Chakrabarti, 21-FEB-02, Reverse Tunneling for Mobile IP [1] defines limited private addresssupport for mobile nodes and mobile agents. This document providesinformation and guidance to the users on the requirements and desc-ribes implementation issues regarding Limited Private Address Supportfor Mobile IP [2]. This document's purpose is to clarify Mobile IPv4temporary deployment scenarios within an operator's environment whereprivate IPv4 addresses are required for the mobile devices.However, the scenarios and communication between private addressedmobile nodes have limited usage. Solutions involving Network AddressTranslation are out of scope of this document. "EAP over UDP (EAPoUDP)", P Engelstad, 21-FEB-02, This document specifies the Extensible Authentication Protocol overUDP (EAPoUDP) to be used for network access authentication. Anaccess domain is represented by one or many PANA AuthenticationAgents (PAAs). Before a PANA Client (PaC) is granted access to thedomain, a PAA and a PaC MAY use EAPoUDP to authenticate each other.EAPoUDP is a variation of the Extensible Authentication Protocol(PPP EAP) [2], but runs instead over IP - either IPv4 or IPv6.Unlike PPP EAP, EAPoUDP allows authentication over any link layertechnology. Furthermore, the PAA and the PaC need not be on the samelink. EAPoUDP uses UDP as its transport protocol. "Internet Unified Messaging Requirements", E. Burger, 21-FEB-02, Internet Unified Messaging brings together the body of work done in VPIM, FPIM, IMAPEXT, and other IETF work groups. The goal is to provide a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of their messages, no matter what the media or source. This document describes the requirements for providing such a service. "SDPng extensions for Quality of service negotiation", Lieve Bos, 21-FEB-02, This document describes a framework that allows end-users/applications to inform each other and negotiate about the QoS characteristics of the media components in a session, prior to its establishment. "An Authenticated Key Exchange Protocol in IPv6", John Floroiu, 21-FEB-02, This document proposes an authenticated key exchange scheme enabling twonodes to establish a security association in a way robust to man in themiddle attacks. The scheme is based on owner-bound IP addresses and DNSlookups.The proposed scheme relies on the fact that an attacker cannot timelyproduce a piece of information to match the output of a one wayfunction. "Network Mobility Support Requirements", T Ernst, H Lach, 21-FEB-02, The purpose of traditional mobility support is to provide continuousInternet connectivity to mobile hosts (host mobility support). Incontrast, network mobility support is concerned with situations wherean entire network changes its point of attachment to the Internet andthus its reachability in the topology. We shall refer to such anetwork as a mobile network (MONET). This document tries to identifywhat constraints limit the implementation and the deployment of apotentially and ideally good solution, and what requirementssolutions must comply to. Our main aim is to raise the discussion onthe mailing list. "RDMA over IP Problem Statement", Allyn Romanow, 21-FEB-02, This draft describes the problem that copying in network I/Otypically causes high system costs in end-hosts at high speeds.The problem is due to the high cost of memory bandwidth, and it canbe substantially improved using 'copy avoidance.' The high overheadhas prevented TCP/IP from being used as an interconnection network,and instead special purpose memory-to-memory fabrics have beendeveloped and widely used. An IP-based solution, developed withinthe IETF, is desirable for interoperability of various networkfabrics. It is also particularly important for the IETF to guidethe standardization because interconnection technology will soonstart to be used over the wide area in the Internet "Analysis of IDR requirements and History Group B contribution", Avri Doria, Elwyn Davies, 21-FEB-02, This draft is the product of Group B, which is one of, at least, twosubgroups in the IRTF-Routing Research Group working on requirementsfor routing solutions for the future. This document analyses thecurrent state of IDR routing with respect to RFC1026 and other IDRrequirements and design efforts. It is the companion document todraft-irtf-routing-reqs-groupb-00.txt, which is a discussion ofrequirements for the future routing architecture and future routingprotocols "Future Domain Routing Requirements Group B contribution", Avri Doria, 21-FEB-02, This draft is the product of Group B, which is one of, at least, twosubgroups in the IRTF-Routing Research Group working on requirementsfor routing solutions for the future. This document sets out a setof requirements that we believe are important for the future routingarchitecture and future routing protocols. It should be noted thatthe IRTF-Routing Research group does not endorse this set ofrequirements or any other set of requirements as the one and only setof requirements. "Messaging profile for telephone-based Messaging clients", G Vaudreuil, 21-FEB-02, This document discussed issues and requirements for a profile of the IMAP 4, message submission, and notification protocols for use by telephone user interfaces delivering the traditional voice mail user experience. Experience with IMAP 4 and voice mail systems has shown quite a few limitations that may be addressed by protocol extensions and standardized conventions between clients and servers. "S-SSM : A Secure SSM Architecture", I Chrisment, Ghassan Chaddoud, Andre Schaff, 21-FEB-02, The SSM model is appeared in order to overcome the problems of deployment of IP multicast. However, a real commercial deployment of SSM have to offer some security services. Our work proposes anarchitecture, called S-SSM, for securing the SSM model. S-SSMdefines two mechanisms for access control and content protection.The first one is carried out through subscriber authentication andaccess permission. As for the second, it is realized through themanagement of a unique key, called the channel key, k_ch, sharedamong the sender and subscribers. "PPVPN Terminology", Tove Madsen, Loa Andersson, 01-JUL-02, PPVPN deals with provider provisioned VPNs. This document provides the basis for a common terminology for the ppvpn working group. "Mobile Networks Scenarios, Scope and Requirements", H Lach, 21-FEB-02, This draft proposes scenarios, scope and requirements for mobilenetworks, i.e. IP networks that change their points of attachmentto the Internet. The text is in support of chartering an IETFWorking Group whose purpose is to develop IP-level solutions forthe mobility of an IP-subnet. "Reordering Metric for IPPM using Non-Reversing Sequence", Alfred Morton, 21-FEB-02, This memo proposes a simple metric to determine if a network hasmaintained packet sequence. It provides motivations for the newmetric, suggests a metric definition, and discusses the issuesassociated with measuring packet sequence. The memo includessecondary metrics to quantify the extent of reordering in severaluseful dimensions. Some examples of evaluation using the non-reversing sequence criterion are included. "SIP Telephony Device Requirements", Henry Sinnreich, 21-FEB-02, The SIP Telephony Device Requirements in this document are aimed toenable users to procure SIP phones from various vendors and installthem using a configuration process over the network, though stillallowing manual configuration data input if desired. SIP telephonydevices are also required to be updated up automatically, without theintervention of the end user. "Automatically BGP Integrity Check using IRR-DB", Kengo Nagahashi, 21-FEB-02, In interdomain routing environment, it is often observed Multiple Origin ASes and it causes instability in interdomain routing. To work aroundits problem, this draft describes the mechanism of automatically integrity check about origin AS. In this approach, BGP router compareswith the origin AS in BGP UPDATE and origin AS in IRR database. Also this draft defines messages between BGP router and IRR-DB to transmit query and reply packet. And by introducing the cache mechanism in BGP router, it can apply route flapping environment. "A method for an Optimized Online Placement of MPLS Bypass Tunnels", Jean-Louis Le Roux, 22-FEB-02, The present document focuses on the MPLS Fast Reroute many-to-one solution. It defines on the one hand, a specific PLR behavior for the dynamic setup of bypass LSPs, and on the other hand a distributed bypass LSP path computation mechanism, taking into account the possibility to share protection resources. It proposes ISIS-TE/OSPF-TE and RSVP-TE extensions required to support the described functionality. "RTP payload Format for JVT Video", Stephan Wenger, Thomas Stockhammer, Miska Hannuksela, 10-JUN-02, This memo describes an RTP Payload format for the JVT codec. This codec is designed as a joint project of the ITU-T SG 16 VCEG, and the ISO/IEC JTC1/SC29/WG11 MPEG groups. The most up-to-date draft of the video codec was specified in early May 2002, is due for revision in late July 2002, and is available for public review [2]. "RFC 3041 Considered Harmful", F. Dupont, P. Savola, 05-JUL-02, The purpose of the privacy extensions for stateless addressautoconfiguration [1] is to change the interface identifier (andthe global-scope addresses generated from it) over time in orderto make it more difficult for eavesdroppers and other informationcollectors to identify when different addresses used in differenttransactions actually correspond to the same node.Current Distributed Denial of Service (DDoS) [2] attacks employforged source addresses which can also be in the same prefixesthan the real addresses of the compromised nodes used for attacks.Indeed, network ingress filtering defeats DDoS using "An efficient method to dicover an agent in the network", Stefano Faccin, Franck Le, 22-FEB-02, In many protocols, such as IP Paging [1] and PANA [2], there is theneed for the user to discover an agent in the network: In IP Paging,the user first needs to discover the address of the Paging agent inorder to perform Paging registration, Paging Area Update and otherpaging procedures. In the same way, in PANA, the user first needs todiscover the PANA Authentication Agent to know where to send itscredential. This document describes an efficient method for a userto discover one, or many agents in the network. "The SPIRITS Protocol", Vijay Gurbani, 01-MAR-02, This document describes SPIRITS protocol. The purpose of the SPIRITSprotocol is to support services that originate in the Public SwitchedTelephone Network (PSTN) and necessitate the interactions between thePSTN and the Internet. "Diameter XML Dictionary", David Frascone, 22-FEB-02, This document describes a coding of Diameter dictionaries in XML.This coding is intended for use by Diameter implementations torepresent Applications, Commands, Vendors, and AVPs. "HTTP Digest Authentication Using AKA", Jari Arkko, Aki Niemi, V Torvinen, 22-FEB-02, The Hypertext Transfer Protocol (HTTP) Authentication Frameworkincludes two authentication schemes: Basic and Digest. Both schemesemploy a shared secret based mechanism for access authentication.The Authentication and Key Agreement (AKA) mechanism performs userauthentication and session key distribution in Universal MobileTelecommunications System (UMTS) networks. AKA is a challenge-response based mechanism that uses symmetric cryptography. This memospecifies an AKA based password generation mechanism for HTTP Digestaccess authentication. "SIP End Point Configuration Data Format", Christian Stredicke, Ian Butcher, 22-FEB-02, Mass deployment of SIP compliant devices requires a simple mechanism for configuring and maintaining them. For the economical success of SIP based devices on a large scale, a platform independent mechanism for finding and exchanging the required information is vital. The goal of this draft is to reduce the amount of effort required for administrators to provision devices. This draft focuses on defining a common data set to configure SIP end points. The mechanism for providing and maintaining the configuration data to the end point is defined elsewhere [7]. "Problem Statement and Requirements for Mobile IPv4 Traversal Across VPN or 'NAT and VPN' Gateways", Farid Adrangi, Prakash Iyer, 22-FEB-02, This draft describes the problem statement and specifies the solution requirements for MIPv4 traversal across VPN or 'NAT and VPN' gateways. The 'NAT and VPN' case refers to a network topology in which the MIPv4 traffic has to traverse one or more NAT gateway(s) followed by a VPN gateway in the path to its final destination. Requirements and problems associated with MIPv4 traversal through NAT gateways NOT involving VPNs is outside the scope of this draft. "Recommendations for the Design and Implementation of NAT-Tolerant Applications", Keith Moore, 22-FEB-02, This document describes a set of recommendations for the design andimplementation of networked applications. These recommendations areintended to provide such applications with increased ability to operatein the presence of Network Address Translators (NATs). "Problem Scope and Requirements for Mobile Networks Working Group", Tim Kniveton, Alper Yegin, 22-FEB-02, This document suggests problem scope definitions and possible domainrequirements for a proposed Mobile Networks working group. Therecommendations made in this draft result from the discussions of theMobile IP mailing list, the MONET mailing list, and an open meetingof interested parties which occured at IETF52 in Salt Lake City. "Mobile IP API", Aki Yokote, 01-JUL-02, The Mobile IP API is 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. API provides awareness of mobility 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. "Packet Reordering: The Minimal Longest Ascending Subsequence Metric", Sam Critchley, 22-FEB-02, This draft describes a metric, based on the minimal longest ascendingsubsequence (MLAS), which can be used to measure the level ofreorderedness of a given single sequence of packets transmitted by onehost and received by a second. This metric enables reordering betweensimilar packet flows to be compared across differing networktopologies. The draft goes on to provide a set of recommendedparameters which can be used when attempting to consistently comparereordering, and highlights potential issues which should be taken intoaccount during measurement. "Virtual Private LAN Service (VPLS) Solution Using GRE Based IP Tunnels", Tissa Senevirathne, 02-JUL-02, In this document we present VPLS solution that use GRE and IP tunnels. It is anticipated use of IP tunnels simplify the backend tunneling plane of VPLS solutions, specially compared to MPLS based solutions. "SigComp discovery for SIP", Miguel Garcia, G. Camarillo, 22-FEB-02, This document defines a mechanism for SIP clients to discover SIPservers that support signalling compression. DNS NAPTR records areused for this purpose. "Ports Option Support in DSTM", Myung-Ki Shin, 22-FEB-02, As an extension to the address allocation process for DSTM, thisdocument defines the ports option for DSTM. A DSTM server may alsoprovide a range of port numbers to be used by the client. Thiswould allow the use of the same IPv4 address by several DSTM nodesat the same time, reducing the size of the required IPv4 addresspool. "One-way Delay Measurement using IPv6 Source Routing", Jae-Hoon Jeong, 22-FEB-02, This document specifies a methodology for measurement of the IETFIPPM WG's one-way IP performance metrics such as one-way delay andjitter of subpaths consisting of a specific end-to-end path in IPv6network as well as end-to-end one-way IP performance metrics. Themethodology measures one-way IP performance metrics in use of IPv6source routing through IPv6 extension headers. Because themethodology can contribute to the finding of congested link orunderutilized link, it can provide important information toconfigure and manage IPv6 network. "Access Control Administration in LDAP", Steven Legg, 22-FEB-02, This document adapts the X.500 directory administrative model for useby the Lightweight Directory Access Protocol. The administrativemodel partitions the Directory Information Tree for various aspectsof directory data administration, e.g. subschema, access control andcollective attributes. The generic framework that applies to everyaspect of administration is described, along with the particulardefinitions that support Access Control administration. Thisdocument does not define a particular access control scheme. "Basic and Simplified Access Control in LDAP", Steven Legg, 22-FEB-02, An access control scheme describes the means by which access todirectory information and potentially to access rights themselves maybe controlled. This document adapts the X.500 directory Basic AccessControl and Simplied Access Control schemes for use by theLightweight Directory Access Protocol. "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, 22-FEB-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 LabelSwitching (MPLS) based fast rerouting. "Mobile IPv6 over Mobile IPv4", C Liu, 22-FEB-02, This document specifies a mechanism for Mobile IPv6 nodes of a 6to4 site [4] to continue utilizing Mobile IPv6 [5] services when they roam into IPv4 domains. The mechanism is based on Mobile IPv6 and Mobile IPv4 [7] glued together naturally by the 6to4 protocol [4] for delivering IPv6 packets between the Mobile IPv6 nodes and their Mobile IPv6 home agents. To support the mechanism specified in this draft, the Mobile IPv6 nodes MUST be Mobile IPv4 capable and MUST NOT utilize Mobile IPv6 route optimization. The 6to4 border router(s) at the 6to4 site MUST also be capable to act as Mobile IPv4 home agent(s). "HTTP Authentication Credential Caching Extension", Mark Nottingham, 22-FEB-02, This note proposes an HTTP cache-control extension mechanism thatallows caching of authentication credentials, thereby allowingauthenticated resources to be served from cache without incurring thecost of a round-trip to the origin server more than once during thefreshness lifetime of the credentials. "Web Active Resource Monitoring", Mark Nottingham, 22-FEB-02, WARM is a straw-man proposal for a solution to the RUP requirementsof the WEBI WG which reuses the Web Architecture (and HTTP). Inparticular, it provides a mechanism for distributing cacheinvalidations from HTTP servers to clients. "RSVP-TE Extension for IPv4/IPv6 Dual Stacking PE under IPv4 MPLS Core Environment", Hideo Ishii, 22-FEB-02, This document specifies a method to establish Label Switch Paths(LSPs) for IPv4 and IPv6 traffic interminglement over IPv4 MPLSnetwork using [RSVP-TE]. IP version(s) of traffic to be transmittedover the established LSP can be recognized by egress routers usingnew SESSION_ATTRIBUTE type. IPv4 Label Switch Routers (LSRs) are notrequired to have knowledge about the Provider Edge (RE) Routers whichsupport this extension "Instructions to Request for Comments (RFC) Authors", B Braden, Joyce Reynolds, 24-APR-02, This memo provides instructions for authors of Request for Comments(RFC) documents, including formatting requirements and editorialpolicies. This document addresses frequently asked questions, andserves as a guideline for constructing a properly formatted RFC. "Jabber", J. Miller, 22-FEB-02, This informational document describes the Jabber protocols, a set ofopen, XML-based protocols developed over a number of years mainly toprovide instant messaging and presence services. In addition, thisdocument describes the known deficiencies of the Jabber protocols. "IP Measurement Protocol (IPMP)", Anthony McGregor, 22-FEB-02, The practice and need for active network measurement is wellestablished, however current tools are not well suited to thistask, mostly because the protocols which they employ have notbeen designed for measurement of the modern Internet.The IP Measurement Protocol (IPMP) is based on packet-probes, andis designed to allow routers to participate in measurements by theinsertion of path information as the probe passes between a pair ofhosts. IPMP is tightly constrained and easy to implement. "Backup Record Route for Fast Reroute Techniques in RSVP-TE", Stefaan De Cnodder, 01-JUL-02, MPLS fast reroute [3] is considered as a possible solution to protecttraffic against link and node failures by re-directing the trafficlocally to a backup LSP. A backup LSP can be either a detour LSP or abypass tunnel. This document describes two methods to optimize therouting of detour LSPs such that they merge faster, a distributedmethod and a centralized method. The distributed method uses theBackup Record Route Object (BRRO) and the centralized method uses theBackup Explicit Route Object (BERO). The latter can also be used forbypass tunnels. "Multirouting", Lode Coene, 25-FEB-02, This document describes a way to loadshare the different paths of amultihomed SCTP association at the same moment while keepingcongestion control per path. The document also describes a possiblesolution to multihoming which would require no routing tables on thehost and which would try to guarantee non-overlapping multihomedpaths. It could possibly reduce the growth of the routing table in arouter. The selection of which link to take would be a localone. The solution is similar to the use of links and linksets withina routeset in SS7. "Mobile SCTP", M. Riegel, M. Tuexen, 09-AUG-02, Transport layer mobility management is presented in addition toMobile IP for providing seamless mobility in the Internet. By use ofSCTP (Stream Control Transmission Protocol) and some of its currentlyproposed extensions seamless handover can be fully accomplished inthe mobile client without any provisions in the network only assistedby functions embedded in Mobile SCTP enabled servers.Client mobility management based on Mobile SCTP seems not to requireany new protocol development. It is a particular application of SCTPeventually solving the requirements of transport layer mobility inthe Internet. "Identifying intra-realm calls and Avoiding media tromboning", C. Aoun, S. Sen, 25-FEB-02, This draft suggests several ways to identify calls initiated between users within the same addressing realm. By having this capability, media flows are kept within the same realm, thus avoiding usage of certain network intermediaries and reducing bandwidth requirements on certain access links. "HMAC-authenticated Diffie-Hellman for MIKEY", Martin Euchner, 25-FEB-02, This document describes a 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. It addresses the real-time aspects of multimedia key management in MIKEY. "Hierarchical LSP", Heinrich Hummel, Jochen Grimminger, 22-MAY-02, This draft pursues the standardization of the 'Hierarchical LSP'being a label-switched sequence of other LSPs, i.e. of hierarchicallynext-lower LSPs, which eventually, after some recursive cycles,consist of label-switched sequences of physical interfaces, i.e. ofLSPs as of today. Hierarchically stacked LSPs will eliminate thenotorious N-square problem when virtual networks (or even virtualnetworks on top of virtual networks) are to be built. "Requirements of optical link-state information for traffic engineering", Eiji Oki, 25-FEB-02, In a limited/non-wavelength-convertible (LNWC) optical network, awavelength is restricted to be converted into another wavelength onan optical path due to the limitation of wavelength converters at anoptical cross-connect. "Special-Use IPv4 Addresses", IANA, 14-AUG-02, This document describes the global and other specialized IPv4 addressblocks that have been assigned by the IANA. It does not address IPv4address space assigned to operators and users through the RegionalInternet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. "Supporting Call and Connection Control Separation using CR-LDP", Osama Aboul-Magd, 25-FEB-02, There has been a recent activity towards the use of GMPLS-based protocols (CR-LDP and RSVP-TE) for automatic switched optical networks (ASON) at the ITU-T. ASON control plane requirements mandates the separate treatment of call and connection control. This draft proposes additional CR-LDP messages necessary for satisfying this goal. "Tunnel LSPs Extended Across Autonomous System Boundaries", Mike Mroz, 25-FEB-02, This document describes the usage of the Border Gateway Protocol (BGP) to establish Transparent LAN Services (TLS) tunnels across Autonomous System (AS) boundaries. TLS is described in [MARTINI-SIG] and [LASSERRE-TLS]. The focus of this document is to explain how to achieve the tunnel LSP between Provider Edge (PE) routers in different ASes. The method described herein may also be used in [BGP-VPN] implementations. "The Mathematics of Quantification, and the New Paradigm,which Re-Defines Binary Mathematics", Eugene Terrell, 10-JUN-02, This paper provides the Mathematics for the New Paradigm Definingthe Binary System. Furthermore, while the Mathematical foundationand Logical justification, which established the New Structure forthe BINARY SYSTEM, were derived from The Mathematics ofQuantification. The Mathematics itself, which is used in the NewBinary System however, while providing the viable justification andthe logical reasons that supports the change for the New Binary Model,is not quite so new. In fact, it can be said that the Mathematics ofQuantification sustains a Cascading Effect, Producing a Profound Changein the Mathematics for the Entire Mathematical Field. But, the Mathematics for the New Binary System has a Historical Foundation, which dates to the beginnings of Mathematics itself. "Requirements for using RSVP-TE in GMPLS signaling", Nobuaki Matsuura, 28-JUN-02, In Generalized MPLS, a control channel can be separated physically from the data channel. Such a separation brings issues to use of RSVP-TE for signaling. This document defines requirements for using RSVP-TE in GMPLS signaling. "Recovery (Protection and Restoration) Terminology for GMPLS", E Mannie, D. Papadimitriou, 25-FEB-02, This document defines a common terminology for GMPLS based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. "Multilayer routing using multilayer switch capable LSRs", Wataru Imajuku, 01-JUL-02, The integration of multilayer switching capabilities within one box, such as the packet-switch capability (PSC) and the lambda-switch capability (LSC) under the MPLS/Generalized-MPLS control mechanism, paves the way for achieving network resource optimization considering multilayer routing. This document clarifies the model of the GMPLS-controlled integrated PSC/LSC label switch router (LSR) and discusses the requirements of the routing extensions needed to achieve optimized multilayer traffic engineering. "Multi-area multi-layer traffic engineering using hierarchical LSPs in GMPLS networks", Kohei Shiomoto, 25-JUN-02, This draft proposes a traffic engineering framework for multi-layer pathnetworks using dynamic virtual topology configuration capability ofGMPLS protocols. The electrical label switched path is routed over thevirtual topology built on a set of optical label switched path in multi-layer path networks. The virtual topology is dynamically altered bysetting up or tearing down optical label switched paths. Virtual topol-ogy is configured in response to traffic demand change so that conges-tion of the network is mitigated. Utilization of label switched path ismeasured at ingress node and disseminated with routing protocolextensions for the individual node to decide whether the virtual topol-ogy should be altered or not without centralized coordination. "Preventing SCTP Congestion Window Overgrowth During Changeover", Janardhan Iyengar, 03-JUL-02, SCTP [RFC2960] supports IP multihoming at the transport layer. SCTPallows an association to span multiple local and peer IP addresses,and allows the application to dynamically change the primarydestination during an active association. We present a problem in thecurrent SCTP specification that results in unnecessary retransmissionsand 'TCP-unfriendly' growth of the sender's congestion window duringcertain changeover conditions. We present the problem and propose analgorithm called the Split Fast Retransmit Changeover Aware CongestionControl (SFR-CACC) algorithm as a solution. We recommend the additionof the SFR-CACC algorithm to the SCTP specification [RFC2960]. "Further considerations for Forwarding Adjacency LSPs", D. Papadimitriou, S. Van den Bosch, 05-JUL-02, Forwarding adjacencies (FA) as described in [2] are a useful tool for improving the scalability of Generalized MPLS (GMPLS) Traffic Engineering (TE). Through the aggregation of TE LSPs this concept enables the creation of a TE-LSP Hierarchy. Forwarding adjacency LSPs (FA-LSP or simply FA) may be advertised as TE link into the same instance of ISIS/OSPF as the one that was used to create the LSP, allowing other LSRs to use FAs as TE-links for their path computation. As such, forwarding adjacency LSP have characteristics of both links and LSPs.This document list a number of topics for further study regarding forwarding adjacencies in an attempt to identify what future work may result in the MPLS WG (or other) from the link/LSP duality. "LDP Extensions for MPLS Multicasting Services", Jong-Moon Chung, 25-FEB-02, This paper proposes the extensions necessary for the Label Distribution Protocol (LDP) to support MPLS network multicasting functionalities. The IP multicasting requirements based on the protocol procedural format (e.g., PIM-DM, PIM-SM, DVMRP, MOSPF, CBT, etc.) will be fully embedded into the LDP signaling procedures to enable multicasting operations through pure MPLS networking procedures alone. "RSVP-TE Extensions for MPLS Multicasting Services", Jong-Moon Chung, 25-FEB-02, This document addresses the required extensions to the Resource Reservation Protocol (RSVP) to support MPLS network multicasting functionalities. The concepts presented in this paper support the delivery of multicasting traffic in accordance to the traffic engineering (TE) parameters provided in the MPLS specifications. "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", Ananth Nagarajan, 01-JUL-02, This document is an applicability statement for Layer 3 ProviderProvisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR)approaches. This document describes how VR-based approaches meetthe key requirements that are outlined in the PPVPN ApplicabilityStatements Guideline document. "RObust Header Compression (ROHC):Profiles for UDP Lite", Ghyslain Pelletier, 25-FEB-02, This document defines ROHC (Robust Header Compression) profiles forcompression of IP/UDP Lite/RTP packets (Internet Protocol, UserDatagram Protocol Lite, Real-Time Transport Protocol) and IP/UDPLite. These profiles are defined based on their differences with theprofiles specified in [RFC-3095] for the classic UDP [RFC-768]. "(FA-)LSP Initiation using Link Management Protocol (LMP)", D. Papadimitriou, Jim Jones, 05-JUL-02, This memo is a companion document to Link Management Protocol [LMP],for which it details the FA-LSP Initiation and Bundling process.[LMP] protocol is being developed as part of the GMPLS protocolsuite to control and manage Traffic Engineering (TE) Links. Thecurrent document extends the LMP capabilities to FA-LSPs enablingamong other to dynamically configure TE Links (in particular the LSPit can serve) between non-adjacent LSRs. "QoS signaling requirements, interfaces and architecture", Maarten Buchli, 25-FEB-02, This draft gives evidence for the existence of different QoS signaling interfaces based on a reference architecture that is derived from two use cases. The main purpose is to refine the requirements for the signaling interface that is being considered in scope of NSIS. "RTP Profile for EPIC", M. West, A. Surtees, 05-JUL-02, This draft describes a profile for compressing RTP/UDP/IP using theEfficient Protocol Independent Compression (EPIC) [2] scheme.The RObust Header Compression [1] scheme is designed to compresspacket headers over error prone channels. It is built around anextensible core framework that can be tailored to compress newprotocol stacks by adding additional ROHC profiles.This profile gives behaviours similar to (a subset of) thefunctionality of [1] and is useful to show how EPIC would work on aprotocol stack about which much is already known. "Overview of Multicast in VPNs", D. Ooms, 25-FEB-02, This document describes on a high level how the various types of VPNservices (L3VPN, L2VPN, VPLS) can support multicast and broadcastdelivery between sites of a VPN. Various approaches and theirapplicability are discussed. "The Equivalent Differentiated Services Model", Benjamin Gaidioz, Pascale Primet, 25-FEB-02, This document describes EDS (Equivalent Differentiated Services), anew building-block for a simple, robust, free and scalable end-to-endservice differentiation in IP networks. The EDS schema aims toprovide a spectrum of 'different but equal' network services thatoffer to the end-to-end flows a trade-off between delay and lossrate. The EDS schema can be deployed incrementally in the Internet. "SCTP Profile for EPIC", M. West, A. Surtees, 25-FEB-02, This draft describes a profile for compressing SCTP/IP using theEfficient Protocol Independent Compression (EPIC) [2] scheme.The RObust Header Compression [1] scheme is designed to compresspacket headers over error prone channels. It is built around anextensible core framework that can be tailored to compress newprotocol stacks by adding additional ROHC profiles.This profile describes a new profile for ROHC which will allow SCTP/IP headers to be compressed. "Applicability Statement for Provider Provisioned CE-based Virtual Private Networks", Jeremy De Clercq, 05-JUL-02, This document is an applicability statement for Provider ProvisionedCE-based IPsec VPNs, as discribed in [CEVPN]. This documentdescribes how provider provisioned CE-based approaches meet the keyrequirements that are outlined in the PPVPN Applicability StatementsGuideline document [ASGUIDE]. "Minimally Disruptive Router Upgrades", Daniel Kilsdonk, 09-AUG-02, This memo documents a process which can be used to avoid network outages during the upgrading of a router's software. In this way, disruptions to the network community are avoided. The upgrade process definition comprises requirements for inserting a replacement router or upgrading the software in a working router within an operational network. To do this, it maximizes the use of accepted internet standards with minimal alteration. "Transparent Third Party Call Control Model for SIP-H.323 Interworking", Radhika Roy, 26-FEB-02, This contribution describes a generalized interworking mechanismbetween SIP and H.323 for third party call control where thecontroller function can reside anywhere within the IP Telephonynetwork. The proposed generalized interworking mechanism offerstransparent IP Telephony services between the SIP and H.323endpoints considering the third party call control function residesin a separate application server. The implementation of the thirdparty call control function on a SIP proxy, SIP endpoint, H.323 GK,H.323 endpoint, MCU, or IWF is a special case of the generalizedmechanism proposed in this document "Making TCP Robust Against Delay Spikes", Reiner Ludwig, Andrei Gurtov, 26-FEB-02, We suggest a more conservative management of TCP's retransmit timer,and a more careful response of the TCP sender to duplicate ACKs thatarrive after a timeout. The former reduces the risk of triggeringspurious timeouts, while the latter eliminates potentiallyunnecessary retransmits. Although, we believe that these suggestionsare permitted (although not explicitly) by RFC2581 and RFC2988, theydo not seem to be widely known nor deployed in existing TCPimplementations. We therefore want to make implementers aware ofthese choices. "VPOXC Provider Provisioned Virtual Private Optical Cross-Connect Service", H Ould-Brahim, 01-JUL-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. "An echo request/reply mechanism for ISAKMP", Michael Richardson, 26-FEB-02, Bringing up IPsec gateways, clients and end systems is a hard task.One of the basic problems is determining if two peers can evencommunicate with each other. There are two typical blocks that canoccur. They are at the transport and at the keying levels. "Mobile IPv6 Authentication, Authorization, and Accounting Requirements", Stefano Faccin, 26-FEB-02, This document describes the motivation why Diameter support forMobile IPv6 is required and needs to be developped. It analyses therequirements expressed in RFC 2977 which was written both for MIPv4and MIPv6; and it finally updates the IPv6 requirements for the AAAsupport for Mobile IPv6 to reflect the latest modifications andevolution of the Mobile IP, AAA and other relevant working groups. "IMAP ANNOTATEMORE Extension", Cyrus Daboo, 26-FEB-02, The ANNOTATEMORE extension to the Internet Message Access Protocol[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4servers. This document describes two 'profiles' for mailbox andserver metadata. "Use SIP and SOAP for Conference Floor Control", Xiaotao Wu, 22-APR-02, During a conference, floor means the right to access some sharedresources such as audio or video channel. Floor control controls suchright so as to enable applications or users to gain safe and mutuallyexclusive or non-exclusive access to the shared resources. Thisdocument defines an approach of using SIP event notificationmechanism and SOAP to perform floor control. "Comparison of Multi-Area TE Methods", Jerry Ash, 26-FEB-02, This draft makes comparisons of various multi-area TE methods, which are evaluated against specific criteria. Four basic path selection approaches are compared: a) distributed methods, b) path-computation-server (PCS) methods (centralized & distributed),c) interarea-flooding methods, and d) multiple-path-compare methods. These approaches include needs to support PCS functionality, query functionality, crankback functionality, summary-te-LSA functionality, and TE feedback functionality. The target is to converge on a reduced subset of required multi-area TE methods and protocol extensions. "NSIS Scope Recommendations", Tricci So, 26-FEB-02, The intent of this draft is to recommend the scope of the work for the NSIS working group so that the team can focus on the key work signaling issues that need to be resolved and to develop the solutions promptly. "Mobile IPv4 Extension: Using DNS Servers Assigned by Home Agent", Jayshree Bharatia, Kuntal Chowdhury, 26-FEB-02, This draft provides an extension to Mobile IPv4 protocol where the Mobile Node (MN) obtains an information regarding DNS Servers from a home agent. This is achieved by defining a new extension of a Registration Reply message. "Geopriv Scenarios", Jorge Cuellar, 26-FEB-02, Location-based services, navigation applications, emergency services,management of equipment in the field, and other location-dependentservices need geographic location information about a target (user,resource or other entity). There is a need to securely transfer thelocation information to a location server and to authorize thelocation server to release securely the information to a client. "Mobile IPv6 Extension: Using DNS Servers Assigned by Home Agent", Jayshree Bharatia, Kuntal Chowdhury, 26-FEB-02, This draft provides an extension to Mobile IPv6 protocol where the Mobile Node (MN) obtains an information regarding DNS Servers from a home agent. This is achieved by defining a new extension of a Binding Acknowledgement message. "DHCP Option for Mobile IP Foreign Agents", Henrik Levkowetz, 27-JUN-02, This document defines a new Dynamic Host Configuration Protocol(DHCP) option with sub-options. One sub-option may be used by a DHCPclient to provide mobile IP related identity information to the DHCPserver. Another sub-option may be passed from the DHCP Server to theDHCP Client to announce the presence of one or more mobile IPMobility Agents. For each announced Mobility Agent, information isprovided which is the same as that of the classical Mobile IP AgentAdvertisement extension to ICMP Router Advertisements. "Access Control for Networked Appliances", T. Chan, B. Srinivas, 26-FEB-02, The use of the SIP protocol for controlling Networked Appliances (NA)has been proposed in several recent IETF drafts including [1] and[2]. The issue of controlling access to NAs from a remote deviceis paramount, especially in the context of NAs in the home. Thisdraft investigates the issue of where the access rules must be storedand executed to control access to an NA. The use of proxy gatewayswithin the home domain and their resultant impact on communicationpathways between the remote device and the NAs have been studied. "The Equivalent Differentiated Services", Benjamin Gaidioz, 26-FEB-02, This document describes EDS (Equivalent Differentiated Services), anew building-block for a simple, robust, free and scalable end-to-endservice differentiation in IP networks. The EDS scheme aims atproviding a spectrum of 'different but equivalent' network servicesthat offer a trade-off between delay and loss rate to the end-to-endflows. The EDS scheme can be deployed incrementally in the Internet. "PPP IPV6 Control Protocol Extensions for Name Server Addresses", G. Zorn, Tom Hiller, 26-FEB-02, 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. "'The ENUM 'tel' enumservice'", Lawrence Conroy, Rudolf Brandner, 26-FEB-02, This document describes the enumservice 'tel' and how it is used with anENUM application when indicated within a returned a NAPTR record. Itgives guidelines for the treatment of records having this sub-fieldvalue, and for the onward processing of information gleaned from theenclosing NAPTR record. "BGP-4 Finite State Machine Table", Susan Hares, 01-JUL-02, This document describes the BGP-4 Finite State Machine in detail. This Finite State machine (FSM) describes how the 27 events operate on the 6 states described in the BGP-4 standard. These 27 events include administrative events, timer events, TCP connectivity events and BGP message events. This document is standards track to accompany the BGP-4 [1] standard as a standard document. This description augments the BGP-4 FSM description (section 8 of BGP-4 draft). "MUTE and UNMUTE extension to RTSP", Aravind Narasimhan, Jonathan Sergent, 26-FEB-02, RFC 2326 [1] overloads the functionality of the PLAY and PAUSEmethods to provide rudimentary support for 'muting' individualstreams in an (Real Time Streaming Protocol) presentation. Thecurrent specification has several inconsistencies. In addition, webelieve that this functionality should be optional. This documentspecifies an extension to RTSP consisting of new MUTE and UNMUTEmethods, providing equivalent functionality in a consistent, optionalmanner. "Parameters and related metrics to compare PPVPN Layer 2 solutions", Loa Andersson, 01-JUL-02, The PPVPN working group deals with provider provisioned VPNs. Thisdocument describes metrics primarily for Layer 2 Virtual PrivateNetworks, to be used in comparing solutions proposal and later whencomparing new proposals to the existing. "Local Security Association (LSA): The Temporary Shared Key (TSK)", Stefano Faccin, Franck Le, 26-FEB-02, This document describes a mechanism to set up a Local SecurityAssociation (LSA) between a user and the local network where the useris attaching to the Internet. It defines all the required relatedfunctionalities such as the key generation, distribution and updateprocedures; it also describes the reasons and the benefits of theadoption of such LSA. "Uniform Resource Identifier (URI) scheme for Digital Object Identifiers (DOIs)", Norman Paskin, 26-FEB-02, This document defines the 'doi' Uniform Resource Identifier (URI) scheme for Digital Object Identifiers (DOIs). The DOI system was developed by the International DOI Foundation (http://www.doi.org), an open membership-based organization founded to develop a framework of infrastructure, policies and procedures to support the identification needs of providers of intellectual property. DOI identifiers are persistent across time and unique across network space. The 'doi' URI scheme allows a DOI to be referenced by a URI for Internet applications. "How to make IPsec more mobile IPv6 friendly", F. Dupont, 05-JUL-02, IPsec specifications [1-6] does not work well with Mobile IPv6 [7]and with any mobility device based on addresses [8] even if HIP [9]should change this regrettable situation.But many problems come directly from bad or dubious interpretationsof IPsec specifications, so this document presents many pointswhere many current implementations can be improved (i.e., canbecome more Mobile IPv6 friendly). "Problem Statement for DCCP", Sally Floyd, 27-AUG-02, This document gives the problem statement underlying thedevelopment of an unreliable transport protocol incorporatingend-to-end congestion control. This is also the problemstatement underlying the development of DCCP, the DatagramCongestion Control Protocol. DCCP implements a congestion-controlled, unreliable flow of datagrams suitable for use byapplications such as streaming media or on-line games "IP Paging Threat Analysis", C. Castelluccia, Pars Mutaf, 26-FEB-02, This document is an analysis of threats that arise from using link layer paging technologies or IP paging in the Internet where denial-of-service attacks are common and easy. These problems fall in the scope of IP paging, since link layer pagingtechnologies do not have provisions for repelling such threats and the source of an attack may be anywhere in the Internet. In addition, vulnerabilities that may be added by IP paging are also discussed. "LMP Security Mechanism", A. Zinin, Sankar Ramamoorthi, 26-FEB-02, This memo describes an IPsec-based security mechanism for the LMPprotocol [LMP]. "WCDP 2.0: Web Content Distribution Protocol", Renu Tewari, 26-FEB-02, Cache consistency at web intermediaries is required for scalable content delivery on the web. In this document we describe the Web Content Distribution protocol (WCDP), which is an invalidation and update protocol to maintain cache consistency for a large number of frequently changing web objects. "Post-handover Mobile Initiated Tunneling for Fast Mobile IPv4 Handover", James Kempf, 26-FEB-02, The Mobile IP working group has been considering enhancements that significantly reduce the amount of service disruption involved in Mobile IP handover. The proposals considered by the working group so far are based on having Layer 2 information available prior to the handover that allows the Mobile Node and/or the old Foreign Agent to prepare for handover in some fashion. "Advancement of Application Programming Interface specifications on the IETF Standards Track", Brian Pawlowski, 26-FEB-02, The Internet Standards Process [RFC2026] requires that all IETFStandards Track specifications must have 'multiple, independent, andinteroperable implementations' before they can be advanced beyondProposed Standard status. "ForCES Architectural Framework", T. Anderson, Ram Dantu, T. Anderson, Lily Yang, 14-MAY-02, This document defines the architectural framework for ForCES network elements (NE), associated entities and the interaction among them. The architecture defined herein is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES-REQ]. "Towards a Framework for QoS Signaling in the Internet", B. Hancock, 26-FEB-02, This Internet Draft presents a framework for further development of QoS signaling in the Internet. We give a basic model for the entities involved in QoS signaling, which is intended to be applicable to a very wide range of networking environments, while still retaining the flexibility to allow lightweight implementations in particular environments and incremental deployment in the Internet as a whole. "IP Services Management Information Base Using SMIv2", S Hancock, Elwin Eliazer, 26-FEB-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 networks using IPService Profiles. "A Packet 1+1 Path Protection Service for MPLS Networks", Ramesh Nagarajan, 26-FEB-02, To provide resiliency from failures in MPLS-based networks, variousprotection and restoration approaches have been proposed anddiscussed in the literature. One important application is thesupport of a highly reliable control plane of the transport network. "NAPSTR: A constrained use of NAPTR and SRV RRs for domain-based service location", Leslie Daigle, A Newton, 26-FEB-02, This memo defines a use of NAPTR records [3] to provide one morelayer of redirection for service lookup than is feasible with SRVrecords. Some will view this as a dangerous use of DNS. It isproposed because real-life use is demonstrating a need for somethingslightly more substantial than SRV, and alternatively SRV usage maybecome twisted out of its intended shape. "A Method to Provide Dynamic Routing in IPsec VPNs", B. Gleeson, P. Knight, 02-JUL-02, 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. "Context Relocation of AAA Parameters in IP Networks", C. Perkins, D Forsberg, R. Koodli, 27-FEB-02, Network access authentication and authorization is used forproviding unabused access to users and for billing and accountingpurposes. AAA has been proposed as an infrastructure that couldprovide such support. With AAA, an access router can be configuredwith packet filtering rules to allow controlled access. "Applicability statement on providing solutions for IP multicast services management", Frederick Le Garrec, 27-FEB-02, This document describes a return of experience in trying to determine a practical solution to a list of identified functional requirements for managing an IP multicast network and its services. This list includes information that is scattered among many IETF drafts. "Protocol Requirements for Internet Program Guides", H. Schulzrinne, Yuji Nomura, 27-FEB-02, This memo specifies requirements for protocol for accessing andupdating program guide information for media-on-demand and multicastapplications. "Signaling between PE and L2PE/MTU for Decoupled VPLS and Hierarchical VPLS", Himanshu Shah, 27-FEB-02, The [DTLS] draft identifies the need for an information exchange mechanism between a PE device and its adjunct L2PE devices in the decoupled transparent LAN architecture. For example, the PE needs to provide information to an L2PE about the existence of remote site(s), and the MPLS label(s) that the L2PE needs to use to reach those site(s). The [HVPLS] draft requires signaling between the PE-rs and the MTU-s device to setup the spoke VC connection for the VPLS service. "Decoupled/Hierarchical VPLS: Commonalities and Differences", Michael Chen, 27-FEB-02, This draft describes commonalities and differences between decoupled and hierarchical architectures to support scalable Virtual Private LAN Services (VPLS). The need to maintain a full mesh of control connections (e.g. LDP, BGP, etc…) and transport paths between all PEs that are service aware may impose a scalability limit on the non decoupled VPLS architecture. "Forwarding Element Model", Ram Gopal, 27-FEB-02, This document describes a model for the Forwarding Element (FE) Forces protocol endpoint. This model represents all the logical components, which are responsible for providing per-hop behavior inside a network element. This document also describes the MIB for the FE model, which can be used to communicate between Forwarding and Control Elements. "Hand-off Extensions for Reverse Tunneling", Alan O''Neill, 27-FEB-02, Reverse tunneling in RFC3024 [RevTun] introduces new packet loss scenarios at the HA and also incurs similar packet routing issues as RFC3220 [MIPv4] between Foreign Agents, during a handoff. Whether a Co-located Care-of-Address or a Foreign Agent Care-of-Address is used during Mobile IP registration, any packets from the new Foreign that are received at the Home Agent before the visitor list has been updated will be dropped. In addition, any in-flight packets from the old Foreign agent will be dropped once the visitor list has been updated. "DS-TE Requirements for Support of multiple-COS on an E-LSP", S Ganti, 27-FEB-02, The current DS-TE requirements document [DSTEREQ] focuses onsolutions that enable carrying a single Class of Service on an LSP.This document extends the work in [DSTEREQ] by motivating the need tosupport a DS-TE solution that enables multiple COS on an E-LSP. Thedocument further defines the requirements for such an approach.The requirements are developed such that this approach would be anoptional extension to the existing DS-TE. "BGP Security Vulnerabilities Analysis", S. Murphy, 27-FEB-02, BGP, along with a host of other infrastructure protocols designed beforethe Internet environment became perilous, is designed with littleconsideration for protection of the information it carries. There areno mechanisms in BGP to protect against attacks that modify, delete,forge, or replay data, any of which has the potential to disrupt overallnetwork routing behavior. "BGP Security Protections", S. Murphy, 27-FEB-02, BGP, along with a host of other infrastructure protocols designed beforethe Internet environment became perilous, is designed with littleconsideration for protection of the information it carries. There areno mechanisms in BGP to protect against attacks that modify, delete,forge, or replay data, any of which has the potential to disrupt overallnetwork routing behavior. "Network Overhead Problem Statement", Douglas Otis, 27-FEB-02, System performance is often limited by an integrated device interconnect. Process differences between logic and memory keep large-scale memory interconnects critical as Moore's Law surpasses the rate of packaging reductions. Two areas are related to memory interconnect performance when handling network messaging: - Logic and memory state context switching - Reassembly of partial messages with bifurcation of payload "Statistics of One-Way Internet Packet Delays", Andrew Corlett, 27-FEB-02, The statistical properties of packet delays for transmission across theInternet are investigated, based on analysis of three datasets obtainedusing CQOS cNodes, each measured over several days of continuous transmission.Two of these sets comprise high and low bandwidth measurement data for vectors (defined here as a cNode to cNode link) from CQOS headquarters to the Irvine Data Center, while the third is a low-bandwidth dataset obtained from a CQOS-Irvine to London vector. "GMPLS Extensions to OSPF and IS-IS for SONET/SDH Control", E Mannie, D. Papadimitriou, 02-JUL-02, This document introduces some of the extensions required in existingIGP routing protocols to support sub-sequent signalling fordynamically established SONET/SDH circuits using GMPLS-based controlplane architecture [GMPLS-ARCH]. In particular, it specifies theGMPLS routing extensions to OSPF and IS-IS routing protocols forSONET/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 linkbundling (aka TE Links) as defined in [MPLS-BDL]. This documentproposes several new sub-TLVs for SONET/SDH network control whichcomplement those proposed in [GMPLS-OSPF] and [GMPLS-ISIS]. Theproposed encoding does not preclude any further integration in thesedocuments that the current one intends to complement. "TESLA: Multicast Source Authentication Transform Introduction", Adrian Perrig, 27-FEB-02, Data authentication is an important component for many applications,for example audio and video Internet broadcasts, or data distributionby 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 onTESLA in different contexts. "A Component Model for SIMPLE", J. Rosenberg, 27-FEB-02, The SIMPLE working group has developed a core set of specificationsfor messaging and presence functionality. However, those protocolsalone are not sufficient to build a complete IM and presenceapplication. In this document, we advocate a componentized model,whereby the other pieces of the system are very loosely coupled, andeasily swapped out for others, in order to allow innovation anddifferentiation. We also propose some simple solutions for several ofthem to allow for interop. "Gateway Identification for TRIP_GW", F. Burg, 27-FEB-02, This contribution has proposed that an identification of the gatewayneeds to be provided. The identification of a gateway is required inmany circumstances especially in the VPN environment. "DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP)", Marc Blanchet, 05-JUL-02, Based on the actions they perform, The network model presented inDSTM [1] defines three types of equipments: a DSTM server, DSTM nodesand a Tunnel End Point (TEPs). Within this model, a protocol isrequired for configuration data exchange among these equipments.This document presents a method to perform these actions based on TSP[2]. "Extensions to RSVP-TE for Supporting Multiple Protection and Restoration Types", Yoshihiko Suemura, 27-FEB-02, This document proposes extensions to RSVP-TE for supporting multiple protection/restoration types (LSP Protection Types) in end-to-end protection/restoration. We propose the LSP Protection Type field to be defined in the Protection Object. Another aim of this document is prevention of an unintended connection for extra traffic when traffic from a failed working LSP is switched over to a backup LSP. We address this issue and propose a 3-way switchover signaling procedure. "ForwArding and Control ElemenT protocol (FACT)", Ram Gopal, Alex Audu, 02-JUL-02, 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 "VPLS Architectures", Ali Sajassi, 27-FEB-02, This document defines a reference architecture for a VPLS system. It describes possible VPLS architectures based on this reference architecture and the merits of each. Each VPLS architecture is described in terms of its logical components and their relationship to each other, as well as the mapping of these logical components to physical network elements. By understanding these logical components, which are fundamental building blocks for any VPLS system, one can easily compare different VPLS architectures and understand the pros and cons of each. A VPLS system may support one or more of these architectures simultaneously. "Ldap Schema for UDDI", Bruce Bergeson, Kent Boogert, 31-MAY-02, This document defines the schema for representing Universal Description Discovery & Integration (referred to here as UDDI) data types [UDDI] in an LDAP directory [LDAPV3]. It defines schema elements to represent a businessEntity, a businessService, a bindingTemplate, a tModel, and a publisherAssertion. "An outsider's view of MANET", F. Baker, 20-MAR-02, This note addresses routing in chaotic non-engineered radio networks "An Architecture for Gateway Registration based on Trunk Groups", J. Peterson, 27-FEB-02, This document presents a framework in which gateways (points ofinterconnection between the Public Switched Telephone Network andInternet-based telephone systems) register themselves with a locationservice in order to communicate their own availability and theavailability of the resources and services they provide. Unlikeprevious approaches to this problem, this document considers trunkgroups as a resource which gateways register. "A 'Reason' Field for ICMP 'Administratively Prohibited' Messages", Steve Bellovin, 27-FEB-02, The current ICMP 'Administratively Prohibited' message conveys onebit of information: we don't like your packet. This memo proposesadding additional information to help hosts retry other possiblepackets "RTP Payload Format for iLBC Speech", Steven Andersen, Alan Duric, 05-JUL-02, 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. "The SIP ALLOCATE Method", Triantafyllos Alexiou, 27-FEB-02, This document defines ALLOCATE, a new method extending the SIP protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media Gateway Controller to create a dynamic and short-lived binding between a PSTN telephone number and a set of SIP URIs. "Exclude Routes - Extension to RSVP-TE", C.Y. Lee, A. Farrel, 27-FEB-02, The current RSVP-TE specification [RSVP-TE] and GMPLS extensions[GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitlyincluded in a path setup, but not to be explicitly excluded. "The Calling Party's Category tel URL Parameter", J. Peterson, 27-FEB-02, This document specifies a new parameter for the tel URL [1] thatrepresents the Calling Party's Category, a parameter used in SS7 ISUP[2] signaling. "CE Auto-configuration", C.Y. Lee, 08-JUL-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). "Extensions of for QoS Support in Transparent VLAN Services over MPLS", Wing Lau, 27-FEB-02, The document draft-lasserre-vkompella-ppvpn-vpls-00.txt describes asolution to support point-to-multipoint Transparent Virtual LAN(TVLAN) service over MPLS. This document describes two extensions tofacilitate the provisioning and support of Quality of Service (QoS)in TVLAN over MPLS. First, we extend the use of the VCID field in theVC-FEC to identify a VPN endpoint. Second, we use one VC-label persource/destination VPN endpoint pair. In this document, we alsoidentify a number of other mechanisms that increase the flexibilityand ease of provisioning of QoS in the TVLAN service. "IMAP CHANNEL Use Cases", E. Burger, 27-FEB-02, This document describes different use cases for using the IMAP CHANNEL facility. Discussion of this and related drafts are on the IMAP Voice list. To subscribe, send the message 'subscribe' to ietf-imap-voice-request@imc.org . "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", James Kempf, 28-JUN-02, 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. "Internet Low Bit Rate Codec", Steven Andersen, 05-JUL-02, This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS) and is designed for narrow band speech and results in a payload bit rate of 13.867 kbit/s with an encoding frame length of 30 ms. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. "The Network Overlay Discovery Protocol (NODP)", B. Schliesser, 28-FEB-02, This document presents a mechanism for Auto-Discovery of membershiptopology and capability information for network overlays. Themechanism described herein is referred to as the Network OverlayDiscovery Protocol (NODP). "Real-Time Publish Subscribe (RTPS) Wire Protocol Specification", Stefaan Thiebaut, 28-FEB-02, The Real-Time Publish-Subscribe (RTPS) Wire Protocol provides twomain communication models: the publish-subscribe protocol, whichtransfers data from publishers to subscribers; and the CompositeState Transfer (CST) protocol, which transfers state. "Aggregated Multicast: A Scheme to Reduce Multicast States", Jun-Hong Cui, 09-SEP-02, In this document, we present a novel scheme, called aggregatedmulticast, to reduce multicast states ([FeiGI01] and [FeiNGC01]).The key idea is that multiple groups are forced to share onedistribution tree, which we call aggregated tree. In our scheme, core routers need to keep states only per aggregated tree instead of per group. This can significantly reduce the total number of trees in the network and thus reduce forwarding states.We investigate the implementation issues of aggregated multicastin different network scenarios. We also discuss the effects of aggregated multicast on some important issues, such as QoSmulticast provisioning, mobility support and fault tolerance.The scope of this paper is not to propose a detailed protocol, but present the idea of aggregated multicast at high level and show its merits. "IPPM Multicast metrics measurement", Emile Stephan, 28-FEB-02, This memo defines a set of spatial metrics for measuring the performance of multicast networks and a set of multicast metrics for measuring the performance of multicast services. It introduces a framework to perform operational multicast metrics measurements coupling SNMP and the IPPM-MIB. "Notes on Application Key Distribution", S. Josefsson, W. Griffin, 28-FEB-02, The debate over whether to store cryptographic keys used byapplications in the Domain Name System or not has been going on forsome time. There are arguments for and against [6]. This documenttries to take a step further and provides some initial terminology,problem statement and use cases for storing application keys in DNS,in order to enable more substantiated input to the discussion. Wemention some proposed solutions so far. We also give somerequirements on a solution (be it DNS based or not) that wouldsatisfy the use cases. "Issues for Redirects in Mobile Ad-hoc Networks (MANETs)", Mark Lewis, F. Templin, 01-MAR-02, This document discusses issues for the use of network layer redirectsin Mobile Ad-hoc Networks (MANETs). The document observes that theuse of redirects requires a transitive property for network layerconnectivity that does not hold for MANETs, thus the use of redirectsin MANETs can cause communication problems. Additionally, thedocument proposes several possible solutions for the problem. "Generic Use and RTP payload for State Signaling Events (SSEs)", Rajesh Kumar, 28-MAR-02, This document defines a mechanism to signal state changes using RTP packets called State Signaling Events (SSEs). The proposed MIME type is 'audio/sse'. SSE messages signal a media state which has no specified duration. In general, media state changes result in a two-way synchronization handshake via SSEs. "Security Through Obscurity Considered Dangerous", Randy Bush, Steve Bellovin, 01-MAR-02, Hiding security vulnerabilities in algorithms, software, and/orhardware decreases the likelihood they will be repaired and increasesthe likelihood that they can and will be exploited by evil-doers.Discouraging or outlawing discussion of weaknesses andvulnerabilities is extremely dangerous and deleterious to thesecurity of computer systems, the network, and its citizens. "OSPF Extensions to Support Multi-Area Traffic Engineering", Dean Cheng, 01-MAR-02, The [MULTI-AREA] introduces a set of mechanisms that could be usedto construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all theway to the ABR in the tail-end area. This document proposes somenew 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 LSRof LSPs in OSPF networks with multiple areas can be optimized. "Tariff Distribution Protocol (TDP)", Oliver Heckmann, 06-MAR-02, This draft describes a very flexible and efficient protocol for distributing price information (tariffs) inside an Internet Service Provider's management system and to its customers. It is designed to work with multiple QoS architectures, for example Intserv [2] and Diffserv [4]. It can also be used for dynamic pricing. It can use a number of different transport mechanisms, e.g. embedding tariff messages as policy objects in RSVP [9] messages. As tariffs can get very complex, it is possible but not necessary to send tariffs as code (e.g. Java). The draft also contains clear definitions of tariff and related terms. "FTCP Fluid Congestion Control", Duke Hong, 06-MAR-02, The goal of this document is to propose an improvement of TCPcongestion control algorithm based on a very simple idea.One specific goal of FTCP is to smooth TCP traffic in order toimprove the throughput, reduce losses and delay variation.FTCP algorithm is fully TCP-compatible [RFC 2914]. "PW ATM Pseudo Wire (PW) Emulation Network Management Information Base Using SMIv2", Thomas Nadeau, 06-MAR-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 an adaptation of ATM VCs over a Packet Switch Network (PSN) as defined in the PWE3 Framework [FRMWK]. "RTCP Extensions for Voice over IP Metric Reporting", Alan Clark, 01-JUL-02, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to support reporting of Voice over IP metrics from end-points. The proposed extension is useful for supporting both mid-call and end-of-call reporting of metrics for management and active control applications. "The Reality of the Schematic Design of the IPt1 and IPt2 Protocol Specifications: 'It is Just the Computer's Telephone Number'", Eugene Terrell, 21-MAY-02, This paper focuses upon the simplification of the presentation forDefining the New Schematic of what was called the IPv7 and IPv8 IPProtocol Specifications. Which is accomplished by first, Renamingthese Protocols to 'IPt1' and 'IPt2', where the 't' represents'Tele-Communications-Specification'. And second, by eliminatingeither all, or most of the extraneous information, which is notessential (at least not anymore) for understanding the overallSchematic Structure, nor the benefits, these Protocol Specificationsactually represent. Which is further emphasized with a comparison,that uses The New and the Modern Binary Systems. Where is it shownthat an increase in efficiency still exist, while the Number of IPAddresses remains Astronomically Large in both cases.In other words, the 'IPt1' and 'IPt2' IP Specifications represents aformat, which is nothing more than a 'Telephone Number Implementation'that can be used as the primary IP Addressing format in anyTelecommunications System, regardless of the choice for the Method inBinary Enumeration. Which means, in essence, this a TelecommunicationsProtocol that is essentially the 'Computer's Telephone Number'. "The 'application/srgs' Media Type", Brad Porter, Steph Tryphonas, 20-MAR-02, This document defines the 'application/srgs' media typefor the augmented BNF version of the Speech Recognition GrammarSpecification. "The 'application/srgs+xml' Media Type", Brad Porter, Steph Tryphonas, 20-MAR-02, This document defines the 'application/srgs+xml' media typefor the XML version of the Speech Recognition Grammar Specification. "The 'application/ssml+xml' Media Type", Brad Porter, Steph Tryphonas, 20-MAR-02, This document defines the 'application/ssml+xml' media typefor the Speech Synthesis based markup language. "The 'application/voicexml+xml' Media Type", Brad Porter, Steph Tryphonas, 20-MAR-02, This document defines the 'application/voicexml+xml' media typefor the VoiceXML based markup language. "OSPF Link-local Signaling", D. Yeung, A. Zinin, L. Nguyen, A. Roy, B. Friedman, 10-SEP-02, OSPF is a link-state intra-domain routing protocol used in IPnetworks. OSPF routers exchange information on a link using packetsthat follow a well-defined format. The format of OSPF packets is notflexible enough to enable applications exchange arbitrary data, whichmay be necessary in certain situations. This memo describes a vendorspecific, backward-compatible technique to perform link-localsignaling, i.e., exchange arbitrary data on a link. "OSPF Out-of-band LSDB resynchronization", A. Zinin, L. Nguyen, A. Roy, 10-SEP-02, OSPF is a link-state intra-domain routing protocol used in IPnetworks. LSDB synchronization in OSPF is achieved via two methods--initial LSDB synchronization when an OSPF router has just beenconnected to the network and asynchronous flooding that ensurescontinuous LSDB synchronization in the presence of topology changesafter the initial procedure was completed. It may sometime benecessary for OSPF routers to resynchronize their LSDBs. OSPFstandard, however, does not allow routers to do so without actuallychanging the topology view of the network. This memo describes avendor specific mechanism to perform such form of out-of-band LSDBsynchronization. "OSPF Restart Signaling", A. Zinin, L. Nguyen, A. Roy, 10-SEP-02, OSPF is a link-state intra-domain routing protocol used in IPnetworks. Routers find new and detect unreachable neighbors via Hellosubprotocol. Hello OSPF packets are also used to ensure two-wayconnectivity within time. When a router restarts its OSPF software,it may not know its neighbors. If such a router sends a hello packeton an interface, its neighbors are going to reset the adjacency,which may not be desirable in certain conditions. This memodescribes a vendor specific mechanism that allows OSPF routers toinform their neighbors about the restart process. Note that thismechanism requires support from neighboring routers. "A survey of the utilization of the BGP community attribute", Olivier Bonaventure, Bruno Quoitin, 21-MAR-02, In this document, we describe the two most common utilizations of theBGP community attribute, namely to tag routes and indicate how aroute should be redistributed by external peers. We then discuss howoften these two types of community attribute are used on the basis ofthe RIPE whois database and of BGP table dumps. "Signalling LSPID's in OSPF TE", Kumar Chetan, Kumar Sunil, 21-MAR-02, This draft introduces new a sub TLV to OSPF TE extensions to signalthe LSPID (Label Switch Path ID) of an LSP (Label Switch Path). This information can be used by any mechanism (normally constraintbased path calculation (CSPF) procedures) to calculate paths that may contain LSPID's as one its Explict Route Objects. "Applying Game Theory To The Domain Name Root System", S. Higgs, 21-MAR-02, This paper applies Game Theory and the Nash Equilibrium to the Domain Name Root System. "Language Property For Character References", Cyril Kostin, 26-AUG-02, (Backus-Naur Form (BNF) is used hereinafter.)This document introduces an optional language property which added to a character reference in HTML in the following manner: BNF: '&[,];'. This language property shows what language a referenced character belongs to. "Root Fix for the .US Top Level Domain", S. Higgs, Marc Schneiders, 25-MAR-02, This document describes the 'Root Fix for the .US Top Level Domain'. Root Fix is a series of actions taken by the Open Root Server Confederation (ORSC) to prevent the destabilization of the DNS due to ICANN's introduction of colliding top level domains. This document describes the actions taken bythe ORSC to remedy the collateral damage that has been directly caused to the .US top level domain in non-ICANN root systems. "Mobile IP and Virtual Private Networks Problem Statement", Hans Sjostrand, Henrik Levkowetz, 25-MAR-02, Both in enterprise and operator environments, Mobile IP and VirtualPrivate Network technologies are coexisting and providing mobilityand security. This draft describes some scenarios how this can beachieved and also describe the problem statement for Mobile IP andVirtual Private Network deployment. "SCTP DDP Adaptation", Douglas Otis, 12-APR-02, In many applications, direct placement of data avoids the overhead of multiple copies or excessive context switching and is a desirable feature. To accomplish this using an Internet Protocol, a direct placement adaptation layer is defined within this document. This adaptation exists as a small shim sitting above SCTP. This shim fragments messages for path compliance, prefixes the placement header, and may place data directly into a user buffer. The ultimate goal is to have placement occur by the network interface card, where this shim coordinates such placement while proper network layering is maintained. As SCTP was not designed to directly handle offset based fragmentation, the shim handles message fragmentation to introduce the offsets as well as determine message reception signaling as a result of unordered delivery needed for immediate placement. "Wireless Multiprotocol Label Switching (WMPLS)", Jong-Moon Chung, 25-MAR-02, The framework of wireless multiprotocol label switching (WMPLS) technology in applications of wireless mobile communications and ad hoc networking is presented in this document. WMPLS has been designed to be a homogeneous protocol to MPLS as well as Generalized MPLS (GMPLS) and MPLambdaS. "Terminal Independent Mobile IP (TIMIP)", Pedro Estrela, 25-MAR-02, IP mobility protocols usually assume that the mobile nodes have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including laptops and PDAs, still use legacy IP stacks, limiting their use to layer-2 mobility between Access Points (APs) connected to the same Access Router (AR) within a single IP subnet. This document presents Terminal Independent Mobile IP (TIMIP), which supports IP mobility of mobility-unaware mobile nodes with legacy IP stacks, while fully interoperating with Mobile IP to provide macromobility across IP subnets. "Resource and Representation Typing in HTTP", Sean Palmer, 25-MAR-02, This document defines the 'Repr-Type' and 'Resource-Type' HTTP entity-header field names, to provide URIs that identify the generic type (class membership) of representations and their original source resources respectively. "The 'val:' URI Scheme for Denoting and Describing Datatype Values", Patrick Stickler, 15-APR-02, This document describes the 'val:' Uniform Resource Identifier (URI)scheme for denoting and describing datatype values which arerepresented by a pairing of the datatype and a lexical form. "A combined Context Transfer and Candidate Access RouterDiscovery protocol", S. Jamadagni, 26-MAR-02, Protocols being designed for seamless IP-level handovers, such as fast handover, context transfer (CT) and Candidate Access Router (CAR)discovery protocols will have to go hand in hand for any meaningful seamless handover implementation. The CAR discovery and subsequent Target Access Router (TAR) discovery is achieved through L3 QoS parameters, user preferences and application level QoS parameter match between the geographically adjacent access routers (GAAR). It is asserted in this draft that the primary consideration for fast handover and CAR discovery will still be layer 3 QoS parameters as supported by the ARs. "Presence and Instant Messaging Protocol (PRIM) Overview", J Overbey, 26-MAR-02, This document presents an overview of the PRIM protocol architecture, which follows from the IMPP model and requirements set forth in RFC2778/2779. It is intended as prerequisite reading for implementers of the PRIM client-server and server-server protocols, which are described in separate documents. "Required behaviors for mail list managers", Mike Meyer, 26-MAR-02, The behavior of mail lists on the Internet has become much more sophisticated than the alias expanders discussed in the standards for Internet messages formats. The lack of standard behavior for this part of the Internet messaging system creates confusion among users, resulting in misdirected or inappropriately duplicated messages. This document lists required behaviors for mail list managers derived from [RFC2821] and [RFC2822] in hopes of reducing the confusion, misdirected and duplicated mail, while at the same time simplifying the configuration process for mail list managers. "MCI(Multicast Channel Identifier) DNS RR type for the support of SSM(Source Specific Multicast)", Junhyuk Song, 26-MAR-02, This document proposes the use of the new DNS RR type MCI (Multicast Channel Identifier), as it is specifying SSM (Source Specific Multicast) multicast channel [SSM] as a DNS ResourceRecord. It shall allow the advance multicast session advertisementby providing the dynamic mapping between SSM multicast channel and MCI. "Versatile File Delivery Protocol, a Nack-based reliable multicast file transfer Protocol Instantiation", Thomas Richon, 26-MAR-02, The aim of the Versatile File Delivery Protocol is to deliver files from few octets up to few hundred gigaoctets over multicast networks. It works over UDP and uses IP multicast addresses. VFDP transmissions have been designed to be as reliable as possible according to various and strong network constraints, either by retransmitting the whole file or by sending only the missing packets depending of a return channel existence. "Efficient End-to-End QoS Signaling - concepts and features", Teodora Guenkova-Luy, 26-MAR-02, This document analyzes issues for providing both sedentary and mobile users of multiparty, multimedia communication services with efficient mechanisms for coping with unstable network conditions and limited resource availability, conforming to the users' QoS requirements and expectations. "WebDAV SEARCH", Julian Reschke, 28-JUN-02, This document specifies a set of methods, headers, properties andcontent-types composing WebDAV SEARCH, an application of the HTTP/1.1protocol to efficiently search for DAV resources based upon a set ofDistribution of this document is unlimited. Please send comments tothe Distributed Authoring and Versioning (WebDAV) DASL mailing listat www-webdav-dasl@w3.org, which may be joined by sending a messagewith 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/. "Extensions to RSVP for RSVP over Signaled QoS Network", Weijing Chen, Kenneth Allen, 26-MAR-02, This document describes the use of RSVP, including all the necessary extensions, to establish guaranteed QoS IP sessions over a signaled QoS network. The examples of signaled QoS network are ATM SVC network and MPLS network with proper UNI signaling. The specified approach is very scalable with large number of service subscribers and incurs minimum administrative and operation overhead of service providers. "Using XML-RPC in BEEP", Ward Harold, 26-MAR-02, XML-RPC is a Remote Procedure Calling protocol that works over theInternet. It defines an XML format for messages that are transferedbetween clients and servers. The message specifies a procedure to beinvoked by the server and contains the parameters to use in theinvocation. Procedure parameters can be scalars, numbers, strings,dates, etc.; they can also be complex record and list structures. "The MUPDATE Distributed Mailbox Database Protocol", Robert Siemborski, 12-AUG-02, As the demand for high-performance mail delivery agents increases,it becomes apparent that single-machine solutions are inadequate tothe task, both because of capacity limits and that the failure ofthe single machine means a loss of mail delivery for all users. Itis preferable to allow many machines to share the responsibility ofmail delivery.The Mailbox Update (MUPDATE) protocol allows a group of IMAP (orPOP3) servers to function with a unified mailbox namespace. Thisdocument is intended to serve as a reference guide to that protocol.Please note that this specification is provided to give informationto the internet community; it is anticipated that it would need tobe revised before widespread adaption. "A URN Namespace for the Web3D Consortium (Web3D)", Aaron Walsh, 27-MAR-02, This document describes a Uniform Resource Name (URN) namespace forthe Web3D Consortium (Web3D) for naming persistent resourcessuch as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources,Extensible Markup Language (XML) Document Type Definitions (DTDs),XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. "Generic Format Parameter", Rajesh Kumar, 26-AUG-02, A method of associating, with a format, parameters that are not part of its standard (e.g. MIME) definition is described. This is done through a new SDP attribute, 'gfmtp', which is syntactically modeled after the existing 'fmtp' attribute. A new IANA registry for parameters used with the 'gfmtp' attribute is defined. "Network Application Interaction Requirements", Bert Culpepper, Robert Fairlie-Cuninghame, 01-MAY-02, This document defines the requirements for a mechanism that supports the interaction of SIP-based user agents with applications residing on remote network servers. 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 supported, especially those that are not restricted to the media plane. It is desired that an application can present the user with application-specific user interfaces and information. The user must also be able generate activity indications back to application to communicate actions on physical or virtual 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", A. Romanov, 03-JUN-02, SNMP is a ubiquitous protocol. Many software developers working inthe embedded space develop or interface with MIB handlers and SNMPagents one way or another. Often these developers are unfamiliarwith SNMP standards and overlook a number of subtle points. Thisdocument will provide a list of steps and rules to avoid commonproblems in order to develop a high quality SNMP agent. "Defining and Using Global Service Attributes in SLP", H. Schulzrinne, W. Zhao, 14-JUN-02, This document describes how to define and use global serviceattributes in the Service Location Protocol (SLP). A global serviceattribute is service type independent. Its name begins with the'service-' prefix. A global service attribute is defined using anattribute template, and can be imported into any service template. Weshow how to use global service attributes to query services acrossmultiple service types, and to support multi-protocol services,multi-function devices, URL changes, and replicated server groups. "Generic String Encoding Rules for ASN.1 Types", Steven Legg, 26-AUG-02, This document defines a set of Abstract Syntax Notation One (ASN.1)encoding rules, called the Generic String Encoding Rules, thatproduce a human readable text encoding for values of any given ASN.1data type "Toward a Quantitative Analysis of IETF Productivity", M. Rose, D. Crocker, 27-MAR-02, This memo presents an initial quantitative analysis of the IETF'sworking groups using RFC publication as the primary metric. "SCTP DDP Adaptation", Randall Stewart, 27-MAR-02, This document describes a method to adapt DDP to SCTP using ageneric DDP description found in [DDP-DRAFT]. This adaptionprovides a method for two peers to know that each side is performingdirect placement thus enabling hardware acceleration if available. "Session Initiation Protocol Extension Header Field for Service Route Discovery in Private Networks", Dean Willis, Bernie Hoeneisen, 30-MAY-02, This document proposes a private SIP extension header field used inconjunction with responses to REGISTER requests to provide amechanism by which a registrar may inform a registering UA of aservice route that the UA may use to request outbound services fromthe registrar's domain. "IO Vectoring to support DDP", Douglas Otis, 28-MAR-02, This draft describes local interchange routines to support Direct Data Placement shim layers. This includes memory authorization, memory boundary assignment, logical to physical address translation, cumulative TSN pooling per association, and Payload Protocol Identifiers with Stream binding. These functions may implement data vectoring as DMA bus master for a network interface card working above an SCTP transport layer. "SIP billing scenarios", Wolfgang Beck, 28-MAR-02, In contrast to other Internet services, most SIP sessions takeplace between individuals. Today's billing schemes (flat rate orvolume based) do not reflect that. A caller causes costs on thecallee's side. With SIP's authentication methods and few additionalheaders, a SIP billing service could be established that wouldenable callees to charge their callers. Call stateful proxies arenot required. "AAA NAI for Mobile IPv4 Extension", Fredrik Johansson, T. Johansson, 09-APR-02, When a mobile node moves between two foreign networks it has to bereauthenticated. If the home network has multiple AAA servers thereauthentication request may not be received by the same AAAH asprevious authentication requests.In order for the new AAAH to be able to forward the request to thecorrect HA it has to know the identity of the HA. This documentdefines an extension that enables the HA to pass its identity to themobile node which can in turn pass it to the AAA server when changingpoint of attachment. This document specifies a NAI extension thatcan carry these NAIs. "The Meta-Policy Information Base (M-PIB)", Raouf Boutaba, Andreas Polyrakis, 29-MAR-02, This document introduces the concept of COPS-PR meta-policies and defines the Meta-Policy Information Base. The meta-policy PIB does not introduce a new policing area. On the contrary, it defines some provisioning classes that can be used by all other PIBs, in order to add meta-policing functionality into them. The meta-policy PIB, like every PIB, stores policing information that controls some policing mechanisms of the device. However, unlike other PIBs, the policing mechanism controlled by the meta-policy PRCs is the PIB itself. The data maintained by these PRCs implement policies that control other policies, this is why they are called meta-policies. Meta-policies is an attempt to push intelligence towards the COPS-PR PEPs and overcome the rigidity of their PIBs. Through meta-policies, more policing information and functionality can be pushed towards the PEP, less interaction with the PDP is necessary and less network and PDP resources are consumed. The PEP is more independent and it can bear longer PDP absences. "A Radical Approach in providing Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field", Harshavardhan Jagadeesan, Tuhina Singh, 17-APR-02, This memo suggest a radical and a generic approach in using the 20-bit IPv6 Flow label field to provide Quality-of-Service on the Internet. The approach is generic in the sense that it does not enforce any specific implementation features on the developers; the only thing that will have specific semantics is the flow-label field. The methods of information storage and processing in the routers are router specific and can be implemented in a number of ways. Thus the resulting mechanism suggested here is fully and easily implementable and unambiguous as may be required for real implementations. "Content-Based Publish-Subscribe over APEX", Bob Wyman, Duncan Werner, 01-APR-02, This memo describes the Content-Based Publish-Subscribe service overAPEX. The Content-Based Publish-Subscribe service is designed as anextension to the APEX Publish-Subscribe service, allowingapplications to subscribe to specific content within a defined topic,rather than the entire topic. "Audio Jukebox Control via SNMP", Bryan Levin, Jim Wampler, 02-APR-02, This document describes a set of extensions (protocol operations andtextual conventions) to the existing SNMP framework architecture[RFC2571]. These extensions provide a mechanism for remote controlof an audio jukebox-style device via the SNMP protocol. "Analysis of Generalized MPLS-based Recovery Mechanisms (including Protection and Restoration)", E Mannie, D. Papadimitriou, 29-AUG-02, This document provides an analysis grid that can be used toevaluate, compare and contrast the large amount of GMPLS basedrecovery mechanisms currently proposed in the CCAMP WG. A detailedanalysis of each of the recovery phases as identified in [CCAMP-TERM] will be given using terminology as defined in [CCAMP-TERM].The focus will be on transport plane survivability and recoveryissues and ***not control plane resilience related aspects***. "An LDAPv3 Schema for X.509 Certificates", Peter Gietz, Norbert Klasen, 02-APR-02, This document describes an LDAP schema which can be used to implementa certificate store for X.509 certificates. Specifically, astructural object class for a X.509 certificate is defined. Keyfields of a certificate are stored as normal attributes so thatapplications can easily retrieve the certficates needed forencryption or chain building by using basic LDAP search filters.Multiple certificates for a single entity can be stored and retrieved "Securing REFER - Options discussed at IETF53", Robert Sparks, 03-APR-02, This memo documents and expands on the discussion on securing REFERat the IETF53 SIP meeting. It explores several possible solutionmechanisms with rough discussion of the pros and cons of each. Thismemo proposes futher development of an S/MIME based solution. "OSPF TE Only Option", Venkata Naidu, 04-APR-02, OSPF is a link state routing protocol used for IP-network topology discovery using different types of Link State Advertisements. The resulting Link State Database (LSDB) isused to compute IP address forwarding table based on shortest-path criteria. OSPF has been extended to support Traffic Engineering, QoS in packet and non-packet networks. These hasbeen a serious concern regarding scalability and convergence ofinformation in large networks. This memo documents an optional OSPF capability to support TE only functionality. This OSPF TE Only option is to support existing and future Traffic Engineering extensions for packet and/or non-packetnetworks with out exchanging any hop-by-hop routing information. This is accomplished by exchanging T-bit option in OSPF Hello packets. This gives flexibility of supporting larger TE areas,increased scalability and improved convergence. "RADIUS Support For Extensible Authentication Protocol (EAP)", B. Aboba, P. Calhoun, 12-AUG-02, This document defines RADIUS support for the Extensible AuthenticationProtocol (EAP), an authentication protocol which supports multipleauthentication mechanisms. While EAP was originally developed for usewith PPP, it is also now in use with IEEE 802.This document updates RFC 2869. "Securing Group Management in IPv6 with Cryptographically Generated Addresses", C. Castelluccia, G Montenegro, 05-JUL-02, Currently, group membership management in IP Multicast andAnycast can be abused in order to launch denial-of-service (DoS)attacks. The root of the problem is that routers cannotdetermine if a given host is authorized to join a group(sometimes referred to as the 'Proof-of-Membership Problem'[ECUMN00]). We propose a solution for IPv6 based on GroupCryptographically Generated Addresses (G-CGA).These addresses have characteristics of statistical uniquenessand cryptographic verifiability that lend themselves to severelylimiting certain classes of DoS attacks. Our scheme is fullydistributed and does not require any trusted third party orpre-established security association between the routers and thehosts. This is not only a huge gain in terms of scalability,reliability and overhead, but also in terms of privacy. "Protecting Against Bidding Down Attacks", Pekka Nikander, Gabriel Montenegro, 05-APR-02, Mobile IPv6 uses 'return routability' to secure route optimization.Even after using this procedure, there are residual threats for whichother stronger methods provide protection. Since these are optional,and return routability is the default, an attacker may engage in'bidding down' attacks. These attacks aim at coercing participantsin Mobile IPv6 route optimization to forgo the stronger methods forthe default return routability. This document discusses what theparticipants in route optimization can do to deter or alleviatebidding down attacks: the 'step down' procedure for the mobile nodeand the 'bit method' at the correspondent node. "Guidelines for The Use of XML within IETF Protocols", M. Rose, L. Masinter, S. Hollenbeck, 27-AUG-02, The Extensible Markup Language (XML) is a framework for structuringdata. While it evolved from SGML -- a markup language primarilyfocused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.There are a wide variety of Internet protocols being developed; manyhave need for a representation for structured data relevant to theirapplication. There has been much interest in the use of XML as arepresentation method. This document describes basic XML concepts,analyzes various alternatives in the use of XML, and providesguidelines for the use of XML within IETF standards-track protocols. "application/rdf+xml Media Type Registration", Aaaron Swartz, 09-SEP-02, This document describes a media type (application/rdf+xml) for usewith the XML serialization of the Resource Description Framework(RDF). RDF is a language designed to support the Semantic Web, byfacilitating resource description and data exchange on the Web. RDFprovides common structures that can be used for interoperable dataexchange and follows the World Wide Web Consortium (W3C) designprinciples of interoperability, evolution, and decentralization. "Session Initiation Protocol: Requirements on Reason Information beyond the Status Code", G. Camarillo, 08-APR-02, Some applications need to know why a particular SIP message wasissued. This document describes those applications and provides aset of requirements that a mechanism used to transport this type ofinformation has to fulfill. "Requirements For a Next Generation Routing and Addressing Architecture", Frank Kastenholz, 08-APR-02, This note sets requirements for a new routing and addressing architecture for the Internet. These requirements were developed by the IRTF's Routing Research Group. This draft is the product of Group ~B, which is one of the subgroups in the IRTF-Routing Research Group working on requirements for routing solutions for the future. This document sets out requirements that we believe are important for a future routing architecture and routing protocols. The IRTF Routing Research Group (RRG) does not endorse this set of requirements or any other set of requirements as the one and only set of requirements. "FACILITATING PRIVATE COMPETITIVE PROVISIONING OF ENUM AS A PREFERRED TECHNICAL, OPERATIONAL,AND REGULATORY CHOICE", A. Rutkowski, 10-APR-02, ENUM is an Internet information service for the benefitof private users of the Internet. It makes use ofauthoritative E.164 telephone number data maintainedamong public telecommunication service providers toenable some useful value added messaging services onthe Internet. Anyone can (and several companies do)provide these ENUM services competitively today withoutgovernment involvement or regulation. Other providerscan enter the marketplace.Although one ENUM provisioning option is to denominatea particular Internet offering worldwide as 'public'and 'authoritative,' there are significant technical,operational, and regulatory burdens and costs createdthat make the prospect rather daunting at best. It isalso unnecessary. A more effective alternative is tofacilitate ENUM service providers' access to authoritative E.164 number and customer information through fair and non-discriminatory contractual arrangements with public telecommunication service providers, and leave the rest to a competitive ENUM provider marketplace and the commercial relationships between Internet Service Providers and public telecommunication carriers. "Modifications to Regional Tunneling", Alan O''Neill, 10-APR-02, Regional Registration modifies the normal MIP Registration signalling back to the HA so that the signalling can traverse an intermediate Gateway Foreign Agent (GFA). The registered binding is between the Home Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the GFA. Two extensions are defined to support this new Registration processing these being the Hierarchical Foreign Agent extension (HFAext) and the GFA IP address extension (GFAIPext). The former is used to carry the FA CoA to the GFA and the latter is used by the FA to allocate a GFA to the MN, and by the FA, GFA, HA to securely return the GFA IP address to the MN.The present processing rules for the HA registration enable the FA to advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and for the MN to include that GFA address into the CoA field of the MIP me Registration. This however assumes a number of things about the GFA address in the FAA and the addressing realms between the FA-GFA and GFA-HA.. Specifically, the GFA CoA and the GFA IP address must potentially be from two different addressing plans and hence cannot be in the same FAA. This draft describes the issues and suggests a solution that requires slight modifications to the required extensions, that generalises the Home Registration signalling for arbitrary intermediate MIP nodes, and only slightly modifies the processing rules for the MIP Home Registration. This draft also describes a way to support dynamic HA allocation along-side Regional Registrations. "Fast Reroute Extensions to CRLDP", C Vijayanand, 05-SEP-02, This document describes the use of CR-LDP [CRLDP] to establish backup LSP tunnels for local repair of LSP tunnels established by CR-LDP. This document proposes extensions to existing CR-LDP for setting up backup tunnels for protecting LSPs on an exclusive bandwidth basis or shared bandwidth basis 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. Control over the location of the backup segments can be exercised by the tunnel initiator. Sharing of backup segments across multiple LSPs is also facilitated to achieve scalability "DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI", David Black, 18-APR-02, This draft describes an authentication mechanism based on enhancing CHAP [RFC 1994] with a Diffie-Hellman Exchange (see Section 22.1 of [Schneier] in order to prevent a passive eavesdropper from acquiring sufficient information to perform an off-line dictionary attack on the CHAP secret. The use of this authentication mechanism with iSCSI [iSCSI] is discussed, along with a brief comparison to the existing CHAP and SRP authentication mechanisms in iSCSI. Caution should be exercised in drawing inferences from the fact that the author of this draft is one of the chairs of the IP Storage Working Group. This draft is an individual submission that the IP Storage Working Group is free to adopt, modify, reject, fold, spindle, and/or mutilate as it sees fit. "STUN-aware NAT", R. Mahy, Adina Simu, Mahadev Somasundaram, 11-APR-02, STUN provides an easy way to traverse some types of NATs and it willwork satisfactorily in many NAT deployments. To overcome STUN'slimitations, one solution is to accept the idea that NATs can changetoo (and they've been proven to change, an example being theproliferation of IPsec pass-thru NAT devices) and to colocate STUNserver functionality on the NAT box itself. Upon receipt of a STUNrequest, the server colocated within the NAT device allocatesaddresses and ports, and installs bindings. This allows hostsrunning the STUN client software to transparently achieve symmetricNAT traversal and to make themselves addressable from the GlobalInternet. "Using Digest Authentication as a SASL Mechanism", Chris Newman, A. Hopkins, Alexey Melnikov, 18-JUN-02, This specification defines how HTTP Digest Authentication [Digest]can be used as a SASL [RFC 2222] mechanism for any protocol that hasa SASL profile. It is intended both as an improvement over CRAM-MD5[RFC 2195] and as a convenient way to support a single authenticationmechanism for web, mail, LDAP, and other protocols. "BGP/MPLS VPN Policy Information Base", Yacine Mghazli, 05-JUL-02, This document describes a Policy Information Base (PIB) for a deviceimplementing 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. "THE KERMIT URL SCHEME", Frank da Cruz, Jeffrey Altman, 11-APR-02, This document defines the Kermit URL according to the rules ofRFC 2717. "UTF-8, a transformation format of ISO 10646", F. Yergeau, 12-APR-02, ISO/IEC 10646-1 defines a multi-octet character set called theUniversal Character Set (UCS) which encompasses most of the world'swriting systems. Multi-octet characters, however, are not compatiblewith many current applications and protocols, and this has led to thedevelopment of UTF-8, the object of this memo. UTF-8 has thecharacteristic of preserving the full US-ASCII range, providingcompatibility with file systems, parsers and other software that relyon US-ASCII values but are transparent to other values. This memoupdates and replaces RFC 2279.Discussion of this draft should take place on the ietf-charsets@iana.org mailing list. "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks", L Martini, 19-JUN-02, A framework for providing various Layer 1 and Layer 2 services overa Packet Switched Network has been described in [3]. This draftprovides encapsulation formats and guidelines for transporting avariety of ATM services over a PSN.This draft includes refinements to draft-brayley-pwe3-atm-servicethat was previously submitted to the PWE3 working group. It reusesthe ATM cell and AAL5 encapsulation defined in the original martiniencapsulation draft [7], but includes an applicability statementfor each service along with ATM OAM handling and QoS guidelines. "Frame Relay Encapsulation over Pseudo-Wires", L Martini, 17-JUN-02, This document defines frame relay pseudo-wire emulation edge-to-edge.A frame relay pseudo-wire is a mechanism that exists between aprovider's edge network nodes and support as faithfully as possibleframe relay services over IP and MPLS packet switched network (PSN).Two mapping modes are defined: One-to-one mapping mode characterizedby a one to one relationship between a frame relay VC and a pairof MPLS LSPs is defined for MPLS PSN. The other mode is known as portmode or many-to-one mapping mode and is defined for MPLS PSN and IPPSN with L2TPv3. "Encapsulation Methods for Transport of Ethernet Frames Over IP and MPLS Networks", L Martini, 03-JUL-02, An Ethernet PW allows Ethernet/802.3 Protocol Data Units (PDUs) to becarried over Packet Switched Networks (PSNs) using IP, L2TP or MPLStransport. This enables Service Providers to leverage their existingPSN to offer Ethernet services.This document describes methods for encapsulating Ethernet/802.3 PDUsfor transport over an MPLS or IP network. "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and MPLS Networks", L Martini, 15-APR-02, This document describes methods for encapsulating the Protocol DataUnits (PDUs) of layer 2 protocols such as PPP, or HDLC for transportacross an MPLS or IP network. "Character Properties For Character References", Cyril Kostin, 26-AUG-02, (Backus-Naur Form (BNF) is used hereinafter.)This document describes an enhancing of symbolic name way of character references in HTML by adding to a character symbolic name an optional character property in the following manner: BNF: '&[];'. "The PERMIS X.509 Based Privilege Management Infrastructure", David Chadwick, 15-APR-02, This document describes the PERMIS X.509 Based Privilege Management Infrastructure, which is a trust management system as described in RFC 2704 [2]. The PERMIS Infrastructure is compared with the AAA Authorisation Framework described in RFC 2904 [4], and is shown to be compatible with it. "INTERNET PROTOCOL t1 and t2 ADDRESS SPACE", Eugene Terrell, 08-MAY-02, This paper Defines the 'IPtX Protocol Specification', and provides avisualization of the lack of IP Address Control, a Blunder, which maybe excused partly because of the impossibility of Predicting theCurrent, as well as the Future use and growth of the Internet.However, this requires an investigation, or Analysis for the Currentuse of the HD-Ratio in the IPv4 and IPv6 IP Specifications. Moreover,while the IPv4 IP Specification, is indeed the primary focus of thisinvestigation. To provide a fair comparison however, this Analysisrequires, if not mandates, the use of the IPt1 and IPt2 specificationsas well. The reasoning here nevertheless, is the difference in therespective Addressing Schematics. Where by, the Addressing Scheme of theformer focuses primarily on the HOST IP Address (Assignment), while thefocus of the latter emphasizes only the Network IP Address. Nevertheless,it shall be concluded, the Addressing Methods used in the Schematic also affects the Efficiency; 'the RATIO of Total Number of Nodes that can be attached to Service the Global Networking Community, and the Number of available IP Addresses used for the Connection'.In other words, this 'Analysis is Argument', whose focus upon the'HD-Ratio' and the 'CIDR Notation' establishes the foundation definingthe 'INTERNET PROTOCOL t1 and t2 ADDRESS SPACE' for the IPt1 and IPt2Protocol Specifications. Which moreover, exceeds the Mandate Defining aNew IP Addressing System specified as the Requirements outlined inRFC1550. "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 numberrouting (freephone), time-and-day routing, credit-card calling,virtual private network (mapping a private network number into apublic number) are realized by the Intelligent Network (IN). Thisdraft addresses means to support existing IN services from SessionInitiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services tothe call are provided by the data and procedures resident in thePSTN/IN. To provide IN services in a transparent manner to SIPendpoints, this draft describes the mechanism for interworking SIPand Intelligent Network Application Part (INAP). "Optical Path Protection Signalling Performance Extension to RSVP", George Young, 16-APR-02, With this extension to the RSVP-TE protocol, an optical path can be initiated with a requested maximum path restoration notification time, and signalling nodes which make up the path can determine compliance with this requirement and then establish the path. "AAA Key Distribution", R. Housley, J. Walker, Nancy Cam-Winget, 16-APR-02, This memo describes problems with the current AAA NASREQ key distribution mechanisms, and proposes enhancements to the NASREQ key distribution model to address these problems.Please send comments on this document to the aaa-wg@merit.edu mailing list. "Applicability Statement for ATM Cell Encapsulation over PSN (the basic mode)", G Koleyni, M Bocci, 02-MAY-02, This draft provides an applicability statement for the basic cell mode encapsulation in draft-fischer [18]. Draft-fischer describes methods to carry ATM services over IP, L2TP or MPLS. The PSN (e.g., MPLS) is used to transport ATM layer services such as those defined by ITU-T as ATM transfer capabilities [17] and ATM Forum as ATM service categories [15]. The basic requirement is to transparently transport the ATM VCC or VPC service related information (e.g., traffic parameters, QoS, OAM, etc.) over the Pseudo Wire (PW), over the packet network. "Simple Encapsulation for transmission of IP datagrams over MPEG-2/DVB networks", H Clausen, 17-APR-02, 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). "DNS-based roaming", Jacques Caron, 17-APR-02, To achieve global roaming, that is, allow any client of any service provider (the home network) to use the facilities of any other network provider (the foreign network), it is necessary to enable the foreign network to find AAA facilities able to handle requests for those users, based on the NAI provided. This document documents such a method, based on DNS. "Source Controlled Multicasting", Wolfgang Hansmann, Toni Paila, Lin Xu, 17-APR-02, Traditionally, multicast trees in the Internet are built bottom-up.The construction of multicast trees depends on the multicastreceivers's ability to inform their next hop multicast routers abouttheir multicast group memberships. There are cases, in which thetraditional host-driven way of building the multicast trees isinsufficient. To point out one, consider an access network withunidirectional links. In a mobile environment, this requires that thereceiving interface of a mobile node must also have the capabilitiesto send out MLD or IGMP responses. This is not possible for broadcastnetworks (e.g DVB-T and DAB), that provide high downstream datarates, but no uplink connectivity.This document presents Source Controlled Multicast as a proposalsolution to overcome the problems with unidirectional links. Itpresents a way to for source to control the multicast tree joiningprocess on behalf of mobile nodes behind unidirectional links. "PPP V.44/LZJH Compression Protocol", John Border, Jeff Heath, 24-JUL-02, The Point-to-Point Protocol [PPP] provides a standard means fortransporting multi-protocol datagrams over point-to-point links.The PPP Compression Control Protocol [CCP] provides a means tonegotiate and utilize compression protocols over PPP encapsulatedlinks.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 ofV.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). "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", J. Peterson, 05-JUL-02, The existing mechanisms for expressing identity in the SessionInitiation Protocol oftentimes do not permit an administrative domainto verify securely the identity of the originator of a request. Thisdocument recommends practices and conventions for authenticating endusers, and proposes a way to distribute secure authenticatedidentities within SIP messages. "JPIP Requirements and Profiles", R. Clark, R. Prandolini, S. Houchin, 18-APR-02, This document describes the requirements for an intelligent protocol for serving JPEG 2000 compressed image and metadata (JPIP). This document represents version 2 of the requirements and profiles of the JPIP standard (ISO/IEC 15444-9) found in document WG1N2522 of ISO/IEC JTC1/SC29/WG1 (the JPEG committee). "OSPF Extensions in Support of Transport Plane Sub-networks", Yoshihiko Suemura, Yoshiharu Maeno, 19-APR-02, This document specifies extensions to the OSPF routing protocol in support of carrying link state information for abstracted transport plane sub-networks and external addresses in an optical network. For this purpose, new TLV triplets for OSPF TE LSA are defined. "An IPv4 Flowlabel Option", Thomas Dreibholz, 19-APR-02, This draft defines an IPv4 option containing a flowlabel that iscompatible to IPv6. It is required for simplified usage of IntServand interoperability with IPv6. "Internationalized Resource Identifiers (IRI)", M. Duerst, M. Suignard, 05-JUL-02, This document defines a new protocol element, the InternationalizedResource Identifier (IRI), as a complement to the URI [RFC2396]. AnIRI is a sequence of characters from the Universal Character Set[ISO10646]. A mapping from IRIs to URIs is defined, which means thatIRIs can be used instead of URIs where appropriate to identifyresources.The approach of defining a new protocol element was chosen, insteadof extending or changing the definition of URIs, to allow a cleardistinction and to avoid incompatibilities with existing software. "MGCP Return Code Usage", B. Foster, C Sivachelvan, F Rednor, 22-APR-02, MGCP 1.0 provides a list of return codes with descriptions. This documents expands on the descriptions and provides some error categories as guidelines for use by Call Agents and gateways. "Transition Scenarios for 3GPP Networks", Jonne Soininen, 22-APR-02, 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 of this document. The purpose of the document is to list the scenarios for further discussion and study. "Evaluation Of DIAMETER Against MIDCOM Requirements", Tom Taylor, 30-APR-02, This document is submitted as part of the Midcom protocol selection process. It evaluates the suitability of the Diameter protocol as a transport for Midcom. The general conclusions are: . the Diameter architecture may be too heavy for the Midcom application, although this is a matter for discussion. It is clear in any event that much of the Diameter base is not needed; . a new application extension to Diameter would have to be defined to meet Midcom's requirements; . with these reservations, the protocol is a good fit to Midcom requirements. This version contains added details describing how to use Diameter to meet the requirements. "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol", H. Schulzrinne, 22-APR-02, This document summarizes requirements for prioritizing access to PSTNand proxy resources for emergency preparedness communications usingthe Session Initiation Protocol (SIP). "Evaluation of RSIP against MIDCOM requirements", Jim Renkel, 13-MAY-02, This document provides an evaluation of the RSIP (Realm SpecificIP) framework and protocol against the evaluation criteriaprovided by the MIDCOM working group for the evaluation of middlebox control protocols. RSIP is defined in experimental RFCs 3102(Realm Specific IP: Framework) [3] and 3103 (Realm Specific IP:Protocol Specification) [4]; see also RFCs 3104 (RSIP Support forEnd-to-end IPsec) [5] and 3105 (Finding an RSIP Server with SLP)[6] for more information on RSIP.The document has been updated based on comments made on the MIDCOMmailing list since the previous version of this document wasdistributed. "IMAP4 rev1 – STATUS-COUNTERS Extension", Alexey Melnikov, John Neystadt, 01-JUL-02, The STATUS-COUNTERS extends IMAP4rev1’s STATUS command. This extension adds the following functionality: Enable MUA to get mailbox counters per groups of messages, grouped according to the value of Message-Context header field. For example, the MUA can find out that the Inbox contains 5 unseen fax messages. "Architecture for Assured Service Capabilities in Voice over IP", Don Choi, Michael Pierce, 22-APR-02, Assured Service refers to the set of capabilities used to ensure thatmission critical communications are setup and remain connected. Thismemo describes the architecture required to meet the requirementsdetailed in [Pierce1]. "Examples for Provision of Preferential Treatment in Voice over IP", Don Choi, Michael Pierce, 22-APR-02, Assured Service refers to the set of capabilities used to ensure thatmission critical communications are setup and remain connected.[Pierce1] describes the requirements, one of which is to providepreferential treatment to higher priority calls. This memo describessome of the methods which may be applied to provide that preferentialtreatment. "Congestion Avoidance & Control for OSPF Networks", Jerry Ash, 23-APR-02, Based on overload and failure experience with link-state protocols, this draft identifies means to enable link-state protocols to:o avoid getting into congestion states wherever possibleo respond gracefully to network overloads and failureso gracefully recover from massive loss of topology database informationThe proposed mechanisms include the following:o throttle setups of link adjacencieso reduce the rate of flooding of link-state-advertisements(LSAs)o prioritized treatment of Hello & LSA ack packetso database backup & resynchronization for graceful recovery from loss of topology database information. "GVPN:Generalized Provider-provisioned Port-based VPNs using BGP and GMPLS", H Ould-Brahim, 01-JUL-02, Consider a service provider network that offers Provider-provisioned Port-based Generalized VPN service (GVPN). The service is a Port-based VPN, where the basic unit of the service is a Label Switched Path (LSP) between a pair of customer's ports. The service is 'generalized' as the interfaces on the customer's ports and provider ports could be any of the interfaces supported by Generalized MPLS (GMPLS). An important goal of such service is the ability to support what is known as 'single end provisioning', where addition of a new port to a given VPN would involve configuration changes only on the devices connected to that port. Another important goal of such service is the ability to establish/terminate an LSP between a pair of (existing) customer's ports within a VPN without involving configuration changes in any of the provider devices. In this document we describe a set of mechanisms built around BGP as a VPN auto-discovery, and GMPLS as a signaling that accomplishes these goals. "Using SNMP as Midcom Protocol", Juergen Quittek, 24-APR-02, This memo evaluates the Simple Network Management Protocol (SNMP) asa candidate for realizing a Midcom protocol. The properties andcapabilities of the SNMP management framework are compared to theMidcom requirements [MDC-REQ] and to the Midcom framework andarchitecture [MDC-FRM]. It is shown that SNMP matches almost allMidcom requirements and that with the already existing support forNATs [NAT-MIB] only little additional effort is required for creatinga Midcom protocol solution based on the SNMP management framework. "Protocol Extension for Support of ATM Service Class-aware MPLS Traffic Engineering", A. Malis, T. Hsiao, 12-SEP-02, This document specifies an RSVP-TE (Resource ReSerVation Protocol-Traffic Engineering) signaling extension for support of ATM(Asynchronous Transfer Mode) Service Class-aware MPLS(Multiprotocol Label Switching) Traffic Engineering. "IP Version 6 over MAPOS", Toshiaki Yoshida, M. Maruyama, Tsuyoshi Ogura, 24-APR-02, Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability overSONET/SDH.This document specifies the frame format for encapsulating an IPv6datagram in a MAPOS frame. It also specifies the method of formingIPv6 interface identifiers, the method of detecting duplicateaddresses, and the format of the Source/Target Link-layer Addressesoption field used in IPv6 neighbor discovery messages. "Responses to iFCP Rev. 10 Last Call Comments", Josh Tseng, Charles Monia, Franco Travostino, 24-APR-02, This document is a compilation of responses to review commentsreceived for revision 10 if the iFCP specification [IFCP] during thepreliminary last call period from 3/4/2002 to 3/18/2002 "Compressing the Session Initiation Protocol", G. Camarillo, 28-MAY-02, This document describes a mechanism to signal that compression isdesired for one or more SIP messages. It also states when it isappropriate to send compressed SIP messages to a SIP entity. "Interworking between SIP and QSIG", John Elwell, 07-AUG-02, This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate 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. "Mobility Events Management in SPIRITS", Daniel Moreno, 29-JUL-02, This document describes the management of the mobility eventsconsidered in SPIRITS protocol and the definition of their relatedparameters.The mobility events management will allow a SPIRITS server tosubscribe to and to be notified of location changes of a mobileuser. The events would only be applicable to mobile users reachablethrough a CS network. The sending of these events must be allowed bysetting the related marks in the HLR. Besides, the SPIRITS protocolmust be able to translate the CAMEL operations involving mobilityinformation into events that can be transferred to the SPIRITSclient. "A Framework for Stimulus Signaling in SIP Using Markup", J. Rosenberg, 24-APR-02, In order for SIP applications to work, they will frequently need tocollect user input and provide feedback to users. Traditionally, userinput has been done in the PSTN through DTMF. Much work has occurredon extending these DTMF models into the domain of SIP, typically bytransporting DTMF digits or user input through some SIP message to anapplication server. We propose a broader framework for stimulus usingmarkup. The approach can support traditional DTMF user input, butalso a rich variety of devices, user interfaces and stimulus thatgoes well beyond DTMF. "Peer to Peer Messaging Protocol (PPMP)", Steven Hessing, 24-APR-02, The Peer to Peer Messaging Protocol supports the creation of scalable, extensible and secure Peer to Peer networks leveraging current practices and introducing new concepts to P2P networking such as the support of multiple communities, security and multicasting. The protocol is highly extensible to allow for the development of additional features and applications for p2p networks. "SIP for SOAP Sessions", Neil Deason, 25-APR-02, This document describes how Session Initiation Protocol (SIP) can beused to create, modify and terminate sessions of Simple ObjectAccess Protocol (SOAP) messages transported over IM TransportProtocol (IMTP). "Private Session Initiation Protocol Extension for Access Network Information", Duncan Mills, 18-JUN-02, This mechanism is useful in SIP networks that provide layer 2/layer 3 connectivity through different access technologies. This document defines the private SIP extension header P-Access-Network-Info. SIP User Agents may use this header to relay information about the access technology to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service provider. "The Referred-By Header Field", Robert Sparks, 26-APR-02, This document defines the Referred-By header field. This SIPextension is used with REFER to carry information about the Referrorto the resource indicated by the Refer-To URI when that URI is a SIPURI. "Load Balancing using pseudo-Anycast and pseudo-Mobility (LBAM) in IPv6", Yanjun Feng, 26-APR-02, Load balancing is a method, by which IP packet can be distributed across a pool of servers, instead of directing to a single server. There are many applications needing load balancing such as Web service, FTP service and NAT gateway. However, current load balancing software and implementations have problems such as poor scalability, inability to balance session flow, long latency time and topological constraint on server pool. This document describes a method using pseudo-anycast and pseudo-mobility based on Mobile IPv6 to implement load balancing in session level in Ipv6 network, by which those problems above can be solved. Futhermore, this method only need little modification to Mobile IPv6 in the servers' and agent's side; as for the general users, it need not any modification. "IPv6 Fast Router Advertisement", James Kempf, M Khalil, Brett Pentland, 29-MAY-02, This document specifies an amendment to the router solicitationhandling procedures in RFC 2461 that allow for improved default router aquisition performance when an active IP host moves fromone subnet to another. "Implementing IPv6 Networks in the Enterprise", Paul Gilbert, 26-APR-02, This document is not meant to be a primer on IPv6 [IPv6] or supply any technical information about the protocol, it is meant to give network engineers a place to start and to get ideas as to what to prepare for when thinking about implementing IPv6, and also some changes that need to be made when thinking about the addressing schema.IPv6 brings some useful features that will help in making the transition as painless as possible, things like auto-configuration and renumbering. Particularly useful is the fact that both IPv4 and IPv6 can run concurrently on the network, on the same router interface and on the same PC. This affords an evolutionary approach rather that a revolutionary introduction of IPv6 technology. For the purpose of this document the terms router and layer3 switch are used interchangeably "DHCP Option for Host QoS", Richard Fangman, Ken Ryon, 29-APR-02, This document defines a new Dynamic Host Configuration Protocol (DHCP)option that is passed from the DHCP Server to the DHCP Client todefine which QoS mechanism and the specific classification settingsto be used by the host in its IP datagram forwarding field. This document describes the option support for IP datagram network layerQoS mechanisms. This option does have the ability to support datalink layer QoS mechanisms if so defined in future updates of thisdocument. "Protocol Independent Multicast-Sparse Mode (PIM-SM) Snooping", Tissa Senevirathne, Sridhar Vallepali, 29-APR-02, This document provides PIM-SM snooping solution. In the document wepresent the framework and reference model and required PIM-SMmessages for PIM-SM snooping solutions. Also we attempt to discussrelated issues to PIM-SM snooping. "Private Session Initiation Protocol (SIP) extension for Visited Network Identifier", Miguel Garcia, 05-JUN-02, This memo describes a private extension to SIP in the form of aP-Visited-Network-ID header. The contents of the header identify eachof the visited networks the message traversed en-route to the homenetwork. "Private Session Initiation Protocol ((SIP) extension for Called Party Identity", Miguel Garcia, 05-JUN-02, This memo describes a private extension to SIP in the form of aP-Called-Party-ID header. A proxy inserts this header typically in anINVITE, en-route to its destination. The header is populated with theRequest-URI received by the proxy in the request. The UAS identifieswhich ID out of several IDs the invitation was sent to (for example,the user may be using simultaneously a personal and a business SIP URIto receive invitation to sessions). The UAS may use the information torender different distinctive audiovisual alerting tones, depending onthe ID used to receive the invitation to the session. "Private Session Initiation Protocol (SIP)extension for Associated Uniform Resource Identifiers (URI)", Miguel Garcia, 05-JUN-02, This memo describes a private extension to SIP [1] that allows aregistrar to return a set of associated URIs to a registered address-of-record. We define the P-Associated-URI header field, used in the200 OK response to a REGISTER request. The P-Associated-URI headerfield transports the set of Associated URIs to the registered address-of-record. "Carrying ISUP in SIP Messages (SIP-ISUP-ANNEX)", Frank Miller, 29-APR-02, SIP-ISUP-ANNEX is a mechanism by which a simplified textualrepresentation of certain SS7 ISUP binary messages can be carriedin the body of SIP INFO messages. This mechanism can be used to allowSIP elements to perform certain ancillary functions associated withexisting PSTN equipment without having to implement a full SS7 stack. "Incident Object Description and Exchange Format Data Model and Extensible Markup Language (XML)Document Type Definition", Yuri Demchenko, Jan Meijer, Roman Danyliw, 29-APR-02, The purpose of the Incident Object Description and Exchange Format isto define a common data format for describing and exchanging incidentinformation between collaborating Computer Security Incident ResponseTeams (CSIRTs). The specific goals and requirements of the IODEF aredescribed in [2]. One of the design principles in the IODEF iscompatibility with the Intrusion Detection Message Exchange Format(IDMEF) [3] developed for intrusion detection systems. For thisreason, IODEF is heavily based on the IDMEF and provides upwardcompatibility with it. "Registration Event package", Georges Mayer, Michael Beckmann, 08-MAY-02, This draft defines an event package that allows a network entity torequest to be notified of changes in the registration state of aparticular user. Subscription and notification of registration stateis supported by defining an event package within the general SIPevent notification event framework. This event package is based onthe Presence event package as specified in [3] and therefore thisdraft only describes the deltas to the Presence event package. "Traffic restoration in link state protocols usingneighbor's shortest path", Sriganesh Kini, Yibin Yang, 30-APR-02, Traffic recovery time when a link (or node) fails is typically in theorder of tens of seconds for a link state IGP. The recovery time isgoverned by factors like the time it takes to detect an adjacencydown, the time taken to propagate link state database changesthroughout the network and the time it takes to run the SPF algorithmand install the new routes in the FIB. Till this entire process iscomplete, traffic in the network can be blackholed. This draftdescribes a technique to reduce the time for which traffic isblackholed by routing the traffic through a neighbor's shortest path. "Private SIP Extension for Mobile Charging Information", Eric Henrikson, 11-JUN-02, This memo describes a private extension to SIP in the form of P-Charging-Function-Addresses and P-Charging-Vector headers. The former header is used to pass the addresses of entities that provide a charging function. The latter header is used to pass charging correlation information. The affected UAs and proxies associated with a dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. They also need to pass correlation information so that the records generated and sent to the charging entities may be properly associated for a coordinated billing effort. "Private SIP Extension for Original Dialog Identifier", Eric Henrikson, 22-MAY-02, This memo describes a private extension to SIP in the form of a P-Original-Dialog-ID header. The header is used to correlate two different dialogs across a B2BUA that is non-transparent to dialogs. The contents of the header identify the original dialog (Call-id, From tag, To tag) associated with the SIP entity that inserted the header into a request. When the same instance of the header is received at that SIP entity in a different request, then it is used to correlate the two different dialogs. "Requirements for Tightly Coupled SIP Conferencing", Orit Levin, 03-JUL-02, This document examines a wide range of conferencing requirements being applied to a tightly coupled SIP Star conference. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols. Together, these documents would provide a guide for building interoperable SIP conferencing applications. "SMTP Submission Service Extension for Future Delivery", Greg White, Greg Vaudreuil, 30-APR-02, 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, 30-APR-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]. "Additional Requirements to Conferencing", H. Schulzrinne, Petri Koskelainen, Xiaotao Wu, 30-APR-02, This document focuses on advanced media-independent conferencing andconference control requirements, especially on user managementrelated requirements. Media control and floor control are out ofscope "SIP-AAA Requirements", G. Camarillo, J. Loughney, 05-JUL-02, As SIP services are deployed on the Internet, there is a need forauthentication, authorization and accounting of SIP sessions. Thisdocument sets out the basic requirements for this work. "IGMP for user Authentication Protocol (IGAP)", Daisuke Andou, 21-JUN-02, This memo describes IGAP, which allows user IP user clients and IProuters or network access servers to verify whether they canparticipate in a multicast group they hope and transport someinformation about it. IGAP is derived from IGMPv2, which can makeusers join a multicast group, who has the claim to participate amulticast group in a service. It's important for service providersto protect their revenue source. "Short term requirements for Network Asserted Identity", M. Watson, 01-MAY-02, There is no requirement for identities identities asserted by a UA in a SIP message to be anything other than the user’s desired alias. An authenticated identity of a user can be obtained using SIP authentication, however it is unlikely that the necessary Public Key Infrastructure to facilitate this for UAs will be available soon. A Network Asserted Identity is an identity obtained by a SIP network intermediary as a result of an authentication process. This draft describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks. General requirements for transport of Network Asserted Identities on the Internet are out of scope of this draft. "Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks", C. Jennings, 02-MAY-02, This document describes extensions to SIP that enable a network oftrusted SIP servers to assert the identity of end users or endsystems, and to convey indications of end-user requested privacy.The use of these extensions are only applicable inside anadministrative domain, or among federations of administrative domainswith previously agreed-upon policies for usage of such information.This document does NOT offer a general privacy or identity modelsuitable for inter-domain use or use in the Internet at large. "Process Control Protection Mechanisms", James Cupps, 02-MAY-02, This document provides mechanisms and details on ways to protect IPconnected Process Control Devices in a Manufacturing Facility. The proliferation of IP connected process controls systems has resultedin significant savings and efficiency gains in many manufacturingorganizations. The added safety risks and security vulnerabilitiesmust be addressed. Addressed in this document are definitions anduseful logical tools in protecting these systems. "PAK: Password-Authenticated Key Exchange for iSCSI", Philip MacKenzie, 02-MAY-02, This draft describes a password-authenticated key exchange protocolcalled PAK [PAK,PAK-Orig] that is secure against both a passiveeavesdropper and an active attacker, i.e., one who may insert, block,or modify messages sent over a network. In particular, it does notallow either type of attacker to obtain any information that wouldenable an off-line dictionary attack on the password. We discuss howthis password-authenticated key exchange protocol may be used withiSCSI [iSCSI]. "M3UA SG-SG communication", Brian Bidulock, Tolga Asveren, 04-SEP-02, This Internet-Draft describes a protocol to support communication of M3UA[2] based SGs over IP. The additional functionality needed by SGs to act as relay points between SS7 nodes is also addressed. "Supporting Intermediary Session Policies in SIP", J. Rosenberg, 03-MAY-02, The Session Initiation Protocol (SIP) was designed to supportestablishment and maintenance of end-to-end sessions. Proxy serversprovide call routing, authentication and authorization, mobility, andother signaling services that are independent of the session.Effectively, proxies provide signaling policy enforcement. However,numerous scenarios have arisen which require the involvement ofproxies in some aspect of the session policy. SIP has no support forsuch capabilities, as the community has generally consideringinvolvement of proxies in session details 'evil'. Practicalimplementations have therefore resorted to non-standard manipulationof SDP messages in order to enforce session policy. Theseimplementations are fragile and frought with problems. In thisdocument, we discuss a middle-ground approach which permits proxieslimited involvement in session policy, but retains the robustnessthat derives from the current prohibition on SDP manipulation. "Using MESSAGE for IM Sessions", J. Rosenberg, 03-MAY-02, The SIMPLE working group has been debating the issue of the IMsession model for quite some time. The primary issue is whattransport to use for the IMs once the session is established withSIP. Proposals have included the SIP MESSAGE request itself, IMSX,and a SIP spin-off, called IMTP. The usage of SIP MESSAGE, the veryfirst proposal, had been rejected by the group because of severaltechnical issues. This document revists that decision, based on therecent enhancements made to SIP itself. We believe that SIP MESSAGEnow represents the ideal transport choice for the IM session model. "Requirements for Binding Published Data to SIP Services", Ben Campbell, 03-MAY-02, A growing number of SIP based services depend on the idea thatclients may publish service-related information to network elements.This information may then affect further processing of the service.Examples of such services include presence and CPL.Multiple protocols may exists for the actual publication of suchdata. But regardless of the protocol, a client must know where tosend it. This document describes requirements for a mechanism toinform clients where and how to publish service related information. "Registration of mail header fields", Graham Klyne, 07-JUN-02, This document defines the initial IANA registration for some mailmessage header fields. "The IPtX Specification Expands the 'CIDR' Architecture,with a Definition of CIDR and the Network Descriptor", Eugene Terrell, 09-MAY-02, This paper Builds upon existing works and 'Works in Progress' thatprovides the foundation bases for the expansion of the 'CIDR'Architecture, and the Definition for CIDR and the Network Descriptor'.However, this work should only be considered an extension, hence,the Obsolescence of RFC's 1517, 1518, and 1519, because the Hardwareand Software specifications has been implemented, and this work onlyextends the foundation they jointly established. "TFTP Multicast Option", G Dion, 13-MAY-02, The Trivial File Transfer Protocol [1] is a simple, lock-step, filetransfer protocol which allows a client to get or put a file onto aremote host.This document describes a new TFTP option. This new option will allowthe multiple clients to receive the same file concurrently throughthe use of Multicast packets. The TFTP Option Extension mechanism isdescribed in [2].Often when similar computers are booting remotely they will eachdownload the same image file. By adding multicast into the TFTPoption set, two or more computers can download a fileconcurrently, thus increasing network efficiency.This document assumes that the reader is familiar with theterminology and notation of both [1] and [2]. "Internationalized Domain Name Administration Guideline", James Seng, 08-MAY-02, There are many complex issues revolving around the internationalizedaccess to domain names (IDN) such as the IDN protocol, IDN deployment,IDN transition and IDN administration.While the IDN working group focuses on the standard track specificationon access to IDN, the administration guideline is also necessary toensure a smooth deployment and transition.This document provides a guideline for all zone administrators,including but not limited to registry/registrars operators and alldomain names holders on the administration of these domain names.Comments on this document can send to the authors at idn-admin@jdna.jp. "SCTP Partial Reliability Extension", Michael Ramalho, Randall Stewart, 01-JUL-02, This memo describes an extension to the Stream Control TransmissionProtocol (SCTP) RFC2960 [4] that allows an SCTP endpoint to signal toits peer that it should move the cumulative ack point forward. Whenboth sides of an SCTP association support this extension, it can beused by an SCTP implementation to provide partially reliable datatransmission service to an upper layer protocol. This memo describes(1) the protocol extensions, which consist of a new parameter forINIT and INIT ACK, and a new FORWARD TSN chunk type (2) one examplepartially reliable service that can be provided to the upper layervia this mechanism. "MODBUS Application Protocol", Dennis Dube, Jacques Camerini, 08-MAY-02, MODBUS is an application layer messaging protocol, positioned at level 7 of the OSI model. MODBUS provides client/server communication between devices connected on different types of buses or networks. MODBUS is a confirmed service protocol and offers many services specified by function codes. MODBUS function codes are elements of MODBUS Request/Reply PDUs. The objective of this document is to describe thefunction codes used within the framework of MODBUS/TCP transactions. "Zyfer's StealthKey Management for frequent rekeying", Derek Au, Peter Balke, Hugo Fruehauf, Christina Helbig, Klaus Helbig, 02-JUL-02, This document describes a key management, designated as StealthKeyManagement. StealthKey Management establishes short-term keys whichare derived from a common long-term key in two entities, referredto as sender and receiver, for symmetric encryption algorithms andcryptographic authentication protocols based on a common secret.Stealthkey Management covers two main parts:- Independent generation of the short-term keys by the sender andreceiver from either the common long-term key and the time, orfrom the common long-term key and a sequence number.- Synchronization of the short-term keys between both entities.The important advantages of using StealthKey Management for messageencryption and authentication are the ability to change the short-term keys frequently, without exchanges between sender and receiverand the independence of other applications for the key changeprocess (in band). A commonly used term for key change is rekeying.The required long-term key can be established remotely through theuse of known symmetric or asymmetric key protocols, or locally viamanual setup. StealthKey Management improves the performance of anyof today's key management protocols, by extending the protocol withthe frequent changing of keys. "RFC Editor Guidelines on Author Lists", B Braden, Joyce Reynolds, 09-MAY-02, This memo presents a new set of guidelines to govern lists ofauthors on RFC documents. It is intended to counteract a recenttendency towards author list inflation. "Services Provided By Reliable Server Pooling", P. Conrad, P. Lei, 05-JUL-02, RSerPool [1] is a framework to provide highly available servicesbetween clients and servers. This is achieved by grouping serversinto pools, each with an identifier and pooling policy. Threeclasses of entities are defined: Pool Users (clients), Pool Elements(servers), and Name Servers.This memo defines the services provided by this framework to upperlayer protocols and applications for Pool Users and Pool Elements.It describes two modes in which RSerPool can provide these services:nameservice mode, and failover mode.It also describes the framework by which upper layer protocols usinga variety of transports (SCTP, TCP, UDP, or others) can be mappedonto the RSerPool framework. "Concatenated MIP for Mobility Management", Alan O''Neill, 09-MAY-02, Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically produces the hand-off of potentially multiple parallel remote access sessions. The consequences of this model are however reductions in bandwidth efficiency due to the additional layers of temporary and permanent encapsulation.This draft describes a complementary model for MIP forwarding, called Concatenated MIP that re-uses, and extends the localised and aggregated MIP signalling model from [NestMIP]. The enhanced forwarding model is intended to co-exist both with [NestMIP] and [RegTunMods] so that the appropriate trade-offs can be made on a per session basis between bandwidth efficiency and other features. Inter-RMA hand-offs between Nesting and Concatenating Regional Mobility Agents is also supported. "Proxy CCoA Tunneling for Mobile IP", Alan O''Neill, 09-MAY-02, In MIPv4, when a Mobile Node (MN) registers with the 'D' bit, in the MIP Registration to a Home Agent (HA), then the MN wishes to use a Co-located Care-of address (CCoA) with a specific Home Address (HoA). Packets sent to the MN Home Address (HoA) will then be encapsulated in the CCoA by the HA and forwarded directly to the MN. Alternatively, a MN can obtain from the local Foreign Agent(FA) a shared FA CoA for inclusion in its MIP Registration to the FA/HA. In this case, the HA encapsulates to the FA CoA, and the Foreign Agent then decapsulates and delivers the HoA addressed packet unencapsulated to the MN. This draft adds to MIPv4 the ability for the MN to acquire a MN specific FA CoA that provides the MN with a topologically correct local address and whose tunnel encaps/decaps is provided by the FA. This address is called a proxy CCoA (PCCoA) and the associated processing in the MN and FA is called Proxy CCoA tunneling. This capability is applicable to any access technology but is especially useful for wireless systems where the access bandwidth is expensive and when point-to-point link-layer connectivity exists between the MN and the FA. This draft also describes reverse tunneling and smooth hand-off extensions based on the PCCoA that enables inter-FA forwarding even for CCoAs. "Nested MIP for IP Mobility Management", Alan O''Neill, 09-MAY-02, Regional Registration provides a mechanism for MIPv4 to localise registrations. The Mobile Node (MN) initially registers to the HA via the Gateway Foreign Agent (GFA) so that the HA can learn the GFA Care of Address (CoA). The MN can then subsequently use a Regional Registration to maintain the binding in the GFA as the MN moves and changes its Foreign Agent (FA) CoA or Collocated CoA (CCoA). It can continue to do so whilst a MN remains under the GFA through which the MN sent the Home Registration. The GFA performs CoA switching between the GFA CoA and that used by the MN (CCoA or FA CoA).Whilst the regional registration provides localisation, it does not at the same time provide registration aggregation for MNs employing multiple HoAs. The ability to concurrently support multiple MN addresses from arbitrary addressing domains is a 3GPP commercial and technical requirement and therefore of interest to operators seeking to move to an all-IP solution based on MIP. In addition, the GFA is a very stateful element in the core of the Internet that cannot be bypassed on failure through routing updates.This draft describes a complementary, less stateful model for localisation that in addition supports aggregation both for regional-like registration and hand-offs. The model re-uses as much as possible from the home registration signalling model of [RegTun] but requires a new form of aggregated regional registration. "Parallel MIP for Aggregated Mobility Management", Alan O''Neill, 09-MAY-02, Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. Nested MIP and an associated proposal, Concatenated MIP [ConcatMIP] are necessary because existing MIP signalling is HA/HoA specific and therefore not easily amenable to aggregation for supporting multiple MIP sessions per MN. This document describes an alternative proposal for introducing aggregation that has significantly lower functionality but that is a smaller change from existing MIP standards and implementations. It is described here for completeness as part of the overall problem space. The solution uses a single HA/HoA specific MIP Registration as a master signal within which is carried an extension that defines an include/exclude list of the other HA/HoA pairs that should/should not be handed off. This extension can be carried in inter-FA hand-off signals and in regional registrations, and is also used within Nested/Concat MIP. "Regional Mobility Agent Signalling", Alan O''Neill, 09-MAY-02, Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to support both localization and aggregation of MIP signalling. They achieve this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically supports the hand-off of potentially multiple parallel remote access sessions. Nested MIP achieves this through encapsulation whilst Concatenated MIP achieves it though various forms of CoA switching.This draft describes the localised and aggregated MIP signalling model for managing both the Local Access and Remote Access MIP layers. This includes inter-FA and Inter-RMA hand-offs within and between Nesting and Concatenating Regional Mobility Agents. This is necessary to support incremental, heterogeneous deployment that is required given that Nested MIP is deployable now whilst Concatenated MIP requires additional and significant standards and development work. "A Triggered Interface", Scott Corson, 09-MAY-02, Layer 2 interfaces fundamentally operate as either broadcast or point-to-point. From these primitives, additional layer 3 interface constructs such as non-broadcast multiple access and point-to-multipoint are created as necessary. This approach has served the wired Internet well. However this memo argues that a third type of layer 2 interface is necessary to seamlessly extend IP over dynamic networks, principally wireless. This interface, here termed a 'triggered' interface, combines traditional broadcast interface addressing semantics (i.e. support for unicast, multicast and broadcast link layer addresses) with layer 2 trigger support for the dynamic creation of peer-to-peer interface associations within an otherwise broadcast interface. Its intended domain of applicability covers cellular, WLAN, MANET, etc; in short all currently envisioned forms of dynamic wireless networking. "Global Wide Emergency Broadcast System {GWEBS vs. IEPS}The Comparison with Internet Emergency Preference Scheme", Eugene Terrell, 09-MAY-02, This paper Discusses several points Lacking in the presentation of theIEPS Specification, and Condemns others as unwarranted mandates, whichdefines the Internet and its use as a Vehicle for WAR. The Alternative,'GWEBS', develops is a more realistic foundation that supports savinglives (Addressing the Concerns of all People in General, Regardless)during the Occurrence of some Catastrophic Event, which is the mandate it mintains regarding the Implementation of a Uniform Universal Protocolthat is the foundation for the 'Global Wide Emergency Broadcast System'that is used to Protect the lives and Livelihoods of all the Inhabitantsof Our Planet. Furthermore, this paper also addresses a more fundamentalconcern that requires the involvement of the UN (United Nations), whichwould mandate the Implementation of a World Wide Global Internet Backbone for every Country. The Development of such World Wide GlobalInfrastructure (A Global System to be sure) would guarantee uniform Access for All People, and would establish the necessary Foundation,infrastructure, as would be required for any Global Wide EmergencyBroadcast System (GWEBS) to work. In other words, this paper supports the belief that Information, and theexchange or the sharing related thereto, is just as important as theSustenance Consumed, which indeed, is the Vital Necessity used to sustain Life itself. "Extensible Authentication Protocol State Machine", Bryan Payne, Nick Petroni, 09-MAY-02, The specification for the Extensible Authentication Protocol (EAP) [2]omits a state machine description. This omission has led to ambiguityin the specification and potential security problems in EAPimplementations. This document outlines a state machine to beintegrated into the next revision of the EAP RFC. "Two-plane and Three-tier Framework Structure for NSIS", Jian Ma, Zhigang Kan, 24-JUL-02, This document proposes a 'two-plane three-tier' framework structure for NSIS signaling. In this framework the Access Networks are connected with wired backbone through default routers. It is assumed that one can do a competent job of network configuration & provisioning in the backbone network, and just keeps backbone networks stupid simple.Resource policies which are implemented in inter-NSIS Domains and intra-NSIS Domain, NSIS Signaling and NSIS negotiations are in the control plane. User data is transported in the transport plane. COPS/Diameter is used for exchanging resource policies. Three-Tier NSIS signalings mean that NSIS signaling should be done in three levels. The first level is Inter-NSIS Domain NSIS signaling across neighboring NSIS Domains, and the second level is Intra-NSIS Domain NSIS signaling inside each NSIS Domain while the third level is end-to-edge NSIS signaling and end-to-end NSIS signaling. The aggregate traffic crossing NSIS Domain borders is served according to relatively stable, long-lived bilateral agreements. End-to-end QoS support is achieved through the concatenation of such bilateral agreements. "Applicability Statement for AAL5 Transparent Frame Encapsulation over PSN", M Bocci, 10-MAY-02, This draft provides an applicability statement for the transparent AAL5 PDU frame mode encapsulation in draft-fischer [4]. Draft-fischer describes methods to carry ATM services over IP, L2TP or MPLS. The PSN (e.g. MPLS) is used to transport ATM layer services such as those defined by ITU-T as ATM transfer capabilities [2] and the ATM Forum as ATM service categories [3]. The basic requirement is to transparently transport ATM VCC service related information (e.g., traffic parameters, QoS, OAM, etc.) over the Pseudo Wire (PW), over the packet network. Transparent PDU frame mode enables bandwidth efficiency gains to be realized for ATM VCCs that use AAL5, yet still provide full ATM transparency, including the correct sequencing of OAM cells on an AAL5 flow. "Signed HTTP with static and dynamic content as a security enhancement against silent defacements", K Kretschmann, M Krech, 10-MAY-02, In case a webserver gets defaced a black hat might change vitalinformation with massive danger for the normal surfer. If for example abanking web portal site containing a link to the online banking loginscreen gets changed pointing to the black hats identical mirror of thelogin screen (as happend here some times already) he will get his handson real banking accounts. The encryption via SSL of already defaceddata will be no solution at all. SSL is only a counterpart in thisscenario to ensure the connected web server is the right one and to dis-able data sniffing on the wire.The solution to this case might be signing all HTTP-accessable con-tent including static and dynamic HTML pages. This solution even keepsan eye on dynamic portal content, as most starting pages now havedynamic content on it, starting from the current time to brokerage news.Best solution would never the less be to have the critical data withinstatic pages.We can sign any URL based content because the signature doesn't getinto the content sent, but into the HTTP reply headers. So we don'tmodify any data. The HTTP reply doesn't need any change within the web-server source code but can most times be configured by standard configu-ration ways.Signing not only HTML but possibly any critical data is needed forexample with a flash movie who display critical data like online broker-age data. This data might be forged by replacing a lying flash moviewith possibly bad consequences to stock rates. One shouldn't underesti-mate the criminal energy in these cases. "Biometric based Digital Signature scheme", Rohas Nagpal, Shuchi Nagpal, 13-MAY-02, Digital Signatures are fast emerging as a viable information securitysolution, satiating the objectives of data integrity, entity authentication, privacy, non-repudiation and certification. The technique, as it stands today, faces the problem of the maintenance of the secrecy of the private key. This document provides a conceptual framework for the establishment of a biometric-based key generation scheme. In this scheme, the private key is generated each time a document or record requires to be signed. Such generation is based upon a combination of biometric traits. "A URN Namespace for MACE", R. Morgan, K. Hazelton, 25-JUL-02, This document describes a proposed URN (Uniform Resource Name)namespace that would be managed by the Internet2 MiddlewareArchitecture Committee for Education (MACE) for naming persistentresources defined by MACE, its working groups and other designatedsubordinates. "Inter-domain QoS Signaling: the BGRP Plus Architecture", Stefano Salsano, 13-MAY-02, DiffServ architecture provides a set of 'user plane' tools for IP QoS.Deployment of DiffServ is starting with static, single-domain solutions.Dynamic QoS and multi-domain QoS are still open issues, as witnessed bythe activity of the IETF NSIS WG, related to the 'signaling plane'.In order to realize true end-to-end QoS services in the Internet,spanning multiple administrative domains, efficient and scalablesignaling and resource control mechanisms are needed.This document describes a scalable inter-domain resource controlarchitecture for DiffServ networks. The architecture is called BGRPPlus, as it extends the previously proposed BGRP framework. "Localized RSVP", Jukka Manner, 14-MAY-02, Guaranteed QoS for multimedia applications is based on reservedresources in each node on the end-to-end path. For stationary nodesthis may be achieved but not so easily for mobile nodes. Manymultimedia applications become less useful if the continuity of QoSis disturbed due to end-to-end signalling or slow re-reservations ofresources after each handover. Additionally, if the correspondentnode does not support QoS, it would be useful to be able to reserveat least local resources, especially wireless link resources. Thisdraft proposes small modifications to RSVP, so that initial resourcereservations and re-reservations due to host mobility can be donelocally in an access network. "A Guide to Implementing Stateless DHCPv6 Service", Ralph Droms, 14-MAY-02, Stateless DHCPv6 service is used by hosts to obtain configurationinformation such as the addresses of DNS servers that does notrequire the maintenance of any dynamic state for individual clients.A host that uses stateless DHCP must have obtained its IPv6 addressesthrough some other mechanism, typically stateless addressautoconfiguration. This document is a guide to the protocol messagesand options that must be implemented to provide stateless DHCPv6service. "DHCP Auto-configure Option (Option code 116) Deprecated", Ralph Droms, 14-MAY-02, RFC2563 defines the DHCP Auto-configure option, which controlswhether a DHCP client uses address auto-configuration. Because ofthe potential threat of a denial of service attack, the use ofRFC2563 is deprecated. "The 'MD5' and 'MMD5' FTP Command Extensions", James Twine, 14-MAY-02, This document specifies two additions to the File Transfer Protocol(FTP). These additions (new Server commands) would give FTP Servers the ability to generate (or otherwise obtain) and return MD5 checksums for the files it has available for transfer.It is the author's belief that this would provide a great benefitto the Internet community, because it would allow automatedtransfer agents, as well as Web Browsers and other'click-to-download' applications to be able to automatically verifythe data of a downloaded file, and hence be able to detect any datatampering and/or corruption that may occurred while 'on the wire',or possibly while the file was on the Server (a virus infection). "Network Requirements for Internet Emergency Preparedness Services", Cory Beard, 15-MAY-02, This document outlines requirements that need to be met in IP-basednetworks to enable and support communications for NationalSecurity/Emergency Preparedness (NS/EP) operations. It provides atemplate from which an emergency service can be negotiated andprovides a set of requirements that should be met for acceptableemergency communication services. The focus here is on networkrequirements, rather than requirements for particular applications.The requirements are general and are intended to provide widelatitude in implementation options for service providers. "Requirements for Emergency Telecommunication Capabilities in the Internet", Hal Folts, 15-MAY-02, Priority telecommunication capabilities are required to support critical emergency communications through the public telecommunications infrastructure to support disaster recovery operations for saving lives and restoring community infrastructure. Many important issues are identified that are essential to ensuring effective emergency telecommunications capabilities are established in Internet-based infrastructures. The term 'communication session' is used instead of 'call' so that all modes of communication can be considered collectively; emergency telecommunication capabilities are not just limited to telephony traffic. No solutions are suggested, but the basic requirements are clearly identified for consideration by the ieprep Working Group of the IETF. "SILC Message Flag Payloads", Pekka Riikonen, 15-MAY-02, This memo describes the data payloads associated with the SILC MessageFlags, as defined in the SILC Packet Protocol Internet Draft [SILC2]. The purpose of the Message Flags is to augment the function of the Private Message Payload and Channel Message Payload 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, 15-MAY-02, This document defines set of attributes that can represent the onlineuser's presence in a network, and to provide general information aboutthe user. The purpose is to provide a generic mechanism to shareonline presence and status, and general information about the userto be used in several kind of network protocols and applications.These attributes could be used by for example chat and conferencingprotocols (such as Instant Message protocols), network games, andother similar network protocols and applications that has onlineusers in a network. "Cell-Search List Indications for Seamless Anticipative, Resource-Mindful Handovers", Raymond Jayaraj, 15-MAY-02, In 802.11 or similar technologies, the network device enters a'cell-search mode' when the signal level/quality of the serving APdrops below a certain value. In the cell-search mode, the deviceactively measures the signal level and/or quality of neighbouringAPs in addition to that of the serving AP.This document describes how the use of MN originated cell-searchlist indications, which carry signal level and signal qualitymeasurements of access points in the immediate vicinity of themobile node, can assist in a handover scheme that factors inseamlessness, target router selection, context transfer andresource usage information. "Framework for Edge-to-Edge NSIS Signaling", Lars Westberg, 15-MAY-02, Real-time applications impose very strict requirements on theunderlying transmission network that requires a high level of qualityof service (QoS). This level of QoS can only be achieved by means ofQoS management on an end-to-end basis (i.e., end user to end user),from application to application, potentially across many domains, asthe current Internet is a concatenation of many domains, usuallymanaged by different QoS administrators (operators).The requirement for end-to-end QoS management does not necessarilymean that a single resource reservation protocol must be applied end-to-end. In fact it is most likely that the end-to-end QoS managementarchitecture will consist of many interoperable and concatenated QoSmanagement architectures rather than one global end-to-end QoSinfrastructure. Usually a network consists of three network parts,i.e., a host to first hop router, access network and the backbone ofthe network. Each of these three network parts imposes differentrequirements on the provided QoS solution.This draft describes a framework for NSIS QoS signaling in edge toedge networks. The main goal is to provide a skeleton for lightweightedge to edge NSIS signaling in a network. This skeleton would be usedas input to the NSIS 'Framework signaling architecture'.Even though designed for edge-to-edge signaling the applicability ofthis framework is not to be limited only to signaling between theedges of a network, but it can be extended in other signalingscenarios as well, such as end host - to - end host signaling.The QoS protocol that will be applied in an edge to edge network isdenoted as edge-to-edge NSIS protocol. "RDMA over IP (ROI) Requirements", Thomas Talpey, 15-MAY-02, This draft defines terminology and requirements to be used inconjunction with the RDMA over IP (ROI) effort. "Stream Control Transmission Protocol (SCTP) IPv4 Address Scoping", M. Tuexen, Randall Stewart, 16-MAY-02, Stream Control Transmission Protocol RFC2960 [5] provides transparentmulti-homing to its upper layer users. This multi-homing isaccomplished through the passing of address parameters in the initialsetup message used by SCTP. In an IPv4 network addresses SHOULD NOTbe passed without consideration of their routeablility. Thisdocument defines considerations and enumerates general rules that anSCTP endpoint MUST use in formulating both the INIT and INIT-ACKchunks when including IPv4 addresses. "Stream Control Transmission Protocol (SCTP) Bakeoff Scoring", M. Tuexen, Randall Stewart, 16-MAY-02, This memo describes some of the scoring to be used in the testing ofStream Control Transmission Protocol (SCTP) at upcoming bakeoffs. "An Outline Framework for QoS Signalling Protocols", Robert Hancock, Eleanor Hepworth, 20-MAY-02, The Next-Steps-in-Signalling (NSIS) working group of the IETF is considering the requirements for QoS signalling protocols [2]. One element of this, and follow up work, is to develop a framework within which existing and proposed protocols can be analysed, and which captures how QoS signalling protocols should interact, both with each other and with other components of the Internet, such as routing protocols or AAA mechanisms. Because of this aspect of interactions, the scope of an NSIS framework is necessarily broader than the scope of any new NSIS protocol. Previous work suggests that a complete QoS signalling framework is a major undertaking. This Internet Draft outlines the principal components of such a framework and their interrelationships. It could be used as a starting point for more detailed investigation of individual components. It could also be used to refine the scope of NSIS more precisely, both in terms of what functions are to be considered and how many variant approaches are relevant. "The IPtX Domain Name System (DNS), and the DNS Requirements for the 'IPtX' IP Addressing Protocol 'Family' Specification", Eugene Terrell, 29-MAY-02, This paper defines the changes as would be required for the Domain NameSystem (DNS) to support the Network(s) IP Addresses assigned and listedusing the Globalnet's Backbone, which are defined by the IPtX IPAddressing Protocol Family Specification. Furthermore, notwithstandingthe requirements necessitated by change, this presentation retains thecurrent Communications Protocol Specifications, which are currently usedfor the DNS Query in the IPv4 Specification. And while the DNS Service for the IPt1 Specification is identical to the IPv4 Specification. However, because the other IP Addressing Protocols define within the IPtX Protocol Specification requires the use of Prefixes, which change the Header Size Specification. The implementation of these IP Addressing Systems, while using the same Communications Protocol Specifications, nevertheless, redefines the Structure for the Naming Convention used in the DNS Hierarchy. Even still, asides from the clarity, referencing the RFC's governing the DNS Service Specifications will be somewhat limited. This is because the overall functions, and their respective Definitions for the IPv4 DNS Specification will not change in the IPtX DNS Specification. Hence, the objective this paper specifically maintains concerns only the presentation of the Subject-Matter relating to the change in the DNS Service(s), resulting from the implementation of the IPtX IP Addressing Protocol Specification. In other words, the paper does not represent a replacement for any of RFCs,which implemented the DNS Services. It should nonetheless, be considered an extension, which focuses upon the changes in the DNS Services resulting from the implementation of the IPtX IP Protocol Specification. "Fast Router Discovery with AP Notification", DongYun Shin, JinHyeock Choi, 19-JUN-02, This document presents Fast Router Discovery with AP Notification.For seamless handoff, a mobile node MUST quickly discover its newaccess router. In our proposal AP caches Router Advertisementmessage and sends it to a new mobile node as soon as L2 associationis made. We present a way for AP to cache necessary RA. By putting'RA Caching' and 'AP Notification' functionality on AP, we get theoptimized result without IPv6 standard change. "Voice & Video over mobile IP Networks", Vijay Madisetti, Antonios Argyriou, 20-MAY-02, Transmission of voice, video and other real-time multimediadata over IP networks is gaining much importance, and Quality ofService (QoS) issues are further compromised when wireless and mobility issues are also included into the picture. A unified approach, VoMo, to addressing QoS through consideration of appropriate signaling, control and data transmission is presented, that has the additional benefits of compliance with current IP network infrastructure through recently proposed IETF protocols, suchas Stream Control Tranmission Protocol (SCTP)[RFC2960] and Session Initiation Protocol (SIP)[RFC2543]. "Some Internet Architectural Guidelines and Philosophy", Randy Bush, Tim Griffin, David Meyer, 12-AUG-02, This document extends RFC 1958 [RFC1958] by outlining some of thephilosophical guidelines to which architects and designers ofInternet backbone networks should adhere. We describe the SimplicityPrinciple, which states that complexity is the primary mechanism thatimpedes efficient scaling, and discuss its implications on thearchitecture, design and engineering issues found in large scaleInternet backbones "The TIST (Topology-Insensitive Service Traversal) Protocol", Melinda Shore, 20-MAY-02, TIST is an application of the RSVP protocol to the problem of com-municating application requests, such as pinhole openings and NATtable entries, to NATs and firewalls. By using RSVP we avoid theproblem of having to locate these devices in the network and estab-lish trusted relationships with each one we would like to influ-ence. "Chinese Name String in Search-based access model for the DNS", XiaoDong Lee, Y. Wang, 21-MAY-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. "Eliminating IBGP Oscillations", Gordon Wilfong, 22-MAY-02, This document proposes an extension to the Border Gateway Protocol(BGP), that eliminates the route update oscillations and routingloops in Internal BGP (IBGP) even in the presence of route reflection. "Connecting Mobile IPv6 Nodes Across IPv4 Clouds Back To IPv6 Domains With Mobile IPv4", C Liu, 22-MAY-02, This document specifies a mechanism for Mobile IPv6 nodes of IPv6 Site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. The mechanism is based on Mobile IPv6 and Mobile IPv4 glued together by IPv4 encapsulation for delivering IPv6 packets between the Mobile IPv6 nodes and their Mobile IPv6 home agents. To support the mechanism specified in this draft, the Mobile IPv6 nodes MUST be Mobile IPv4 capable and MUST NOT utilize Mobile IPv6 route optimization when in IPv4 domain, and some of the border routers of the site MUST be capable to act as Mobile IPv4 home agent(s). The IPv6 site does not need to run 6to4 protocol, however. "The IPtX Dynamic Host Configuration Protocol (IPtX DHCP), and the Requirements for the 'IPtX' IP Addressing Protocol 'Family' Specification", Eugene Terrell, 23-MAY-02, This document defines the changes when the IP Bit Mapped Header SizeSpecification Equals 64 Bits, as would be required for the Implementation Dynamic Host Configuration Protocol (DHCP) to support hosts defined by the IPtX IP Addressing Protocol Family Specification. Furthermore, while the underlining implications regarding any Change in the Header Size Specification maintains the possibility of having a Profound Cascading Affect upon other Protocols. Noting specifically, the affects upon the 'TCP' and 'UDP' Headers, and the corresponding affects upon the Growth in the Number of Available 'PORTS'. Nevertheless, while there is a noticeable growth occurring in each of these areas, they remain manageable, because the difference between the IPv4 and the IPtX Specification is minimal. In which case, it should be clearly understood, the Operations presently defined for the IPv4 IP Addressing System would be the same under the IPt1 Specification. And this is valid because the differences between their IP Addressing Schematic Design does not mandate a requirement for any change, and they both use the same 32Bit Header Size Specification.In other words, the implementation of the IPtX Specification has little or No affect, nor does it constitute an appreciable change in the Dynamic Host Configuration Protocol Specification, which is Currently used in the IPv4 IP Addressing System. Hence, this work should only be considered as an extension of the RFC(s) governing and supporting the Dynamic Host Configuration Protocol (DHCP) for the IPv4 Specification, because the only objective this paper maintains, is the development and presentation of the IPtX DHCP Specification, which only compliments the requirements in the current RFC(s) defining the DHCP Protocol Specification. "Advertisement of Multiple Paths in BGP", John Scudder, Alvaro Retana, Daniel Walton, David Cook, 24-MAY-02, The BGP specification [1,2] defines an 'Update-Send Process' toadvertise the routes chosen by the Decision Process to other BGPspeakers. No provisions are made to facilitate the advertisement ofmultiple paths to the same destination. In fact, a route with thesame NLRI as a previously advertised route implicitly replaces theoriginal advertisement.This document proposes a mechanism that will allow the advertisementof multiple paths for the same prefix without the new pathsimplicitly replacing any previous ones. The essence of the mechanismis that each path is identified by an arbitrary identifier inaddition to its prefix. "BGP Persistent Route Oscillation Solution", John Scudder, Alvaro Retana, Daniel Walton, David Cook, 24-MAY-02, This document presents an application of the use of the advertisementof multiple paths [1] to solve the well known BGP persistent routeoscillation [2,3] problem. "NSIS Threats", Hannes Tschofenig, 05-JUL-02, As the work in the NSIS working has begun to describe requirements and the framework people started thinking about possible security implication. This document should provide a starting point for the discussion at the NSIS working group mailing list regarding the security issues that have to be addressed by a protocol or within the framework. This document does not describe vulnerabilities of a particular protocol or threats of published NSIS framework proposals. This memo is furthermore meant to create awareness for security issues within the NSIS group. Security requirements related to the threat scenarios are described in [1]. "IPSP Commmunication Description for M3UA", H Schwarzbauer, Javier Pastor, 24-MAY-02, This document is a compilation of all the IPSP literature presentedin the M3UA (MTP-3 User Adaptation Layer) RFC. It contains adescription of IPSP commmunication showing the main concepts andprocedures. "TCP Mapping for Reliable Server Pooling Failover Mode", P. Conrad, P. Lei, 28-MAY-02, This memo defines the shim protocol that maps the requirements of theASAP protocol [5] to the capabilities of the TCP protocol [7]. Inparticular, this shim protocol adds the following capabiltiies thatare required by ASAP, but not provided by TCP: (1) messageorientation, (2) heartbeat messages, (3) undelivered messageretrieval, and (4) multiple streams. "Resource Class considerations for CRLDP", Ravi Mantha, 28-MAY-02, This draft extends the CRLDP signaling to include the resourceclass affinity vectors of an LSP in the label request message.We define resource class attributes for hierarchical LSPs and procedures to admit LSPs into links/tunnels based on the resourceclass constraints. "Mapping of Media Streams to Resource Reservation Flows", G. Camarillo, A. Monrad, 28-MAY-02, This document defines an extension to the SDP grouping framework. Itallows to request that different media streams are mapped intodifferent resource reservation flows. "A Session Initiation Protocol (SIP) Event Package for Registrations", J. Rosenberg, 28-MAY-02, This document defines a Session Initiation Protocol (SIP) eventpackage for registrations. Through its REGISTER method, SIP allows auser agent to create, modify, and delete registrations. Registrationscan also be altered by administrators in order to enforce policy.These registrations therefore represent a piece of state in thenetwork that can change dynamically. There are many cases where auser agent would like to be notified of changes in this state. Thisevent package defines a mechanism by which those user agents canrequest and obtain such notifications "SPIRITS Location Services", Vijay Gurbani, 29-MAY-02, This document describes location- and mobility-related services asthey are enabled by SPIRITS. SPIRITS services originate from certainactions occurring in the PSTN (wireline and wireless) and involveinteractions with Internet hosts. The services described in thisdocument pertain to location- and mobility-related events detected bythe PSTN and reported to an Internet host which requested them forsubsequent service execution. "Exclude Routes - Extension to RSVP-TE", C.Y. Lee, A. Farrel, 30-MAY-02, The current RSVP-TE specification [RSVP-TE] and GMPLS extensions[GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitlyincluded in a path setup, but not to be explicitly excluded.In some systems where precise explicit paths are not computed at thehead end it may be useful to specify and signal abstract nodes andresources that are to be explicitly excluded from routes. Theseexclusions may apply to the whole of a path, or to parts of a pathbetween two abstract nodes specified in an explicit route.Shared Risk Link Groups (SRLGs) allow the definition of resources orgroups of resources that share the same risk of failure. Theknowledge of SRLGs may be used to compute diverse paths that can beused for protection. In systems where it is useful to signalexclusions, it may be useful to signal SRLGs to indicate groups ofresources that should be excluded on the whole of a path or betweentwo abstract nodes specified in an explicit path.This draft specifies ways to communicate route exclusions during pathsetup using RSVP-TE.These approaches are equally applicable to other MPLS TE signalingprotocols such as CR-LDP. "Conformance MIB", Andy Bierman, 31-MAY-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for identifying the conformancelevel of all management information available from an SNMP agent. "Applying WebDAV (Web Distributed Authoring and Versioning)to Network Configuration Management Problems", Randy Presuhn, 31-MAY-02, This memo examines the potential of using WWW Distributed Authoringand Versioning (WebDAV) technologies to address the problems ofnetwork configuration management. It reviews requirements and issuesthat have been identified in IETF network configuration managementand operator requirements discussions, matching these requirementsand issues with various WebDAV facilities. It concludes byidentifying areas for further exploration.Comments are welcomed, both from the Operations and Management Areain general, and from participants in the webdav and deltav workinggroups in particular. Please send comments to the author atrandy_presuhn@bmc.com. "Shared Risk Link Groups Encoding and Processing", D. Papadimitriou, 03-JUN-02, The Shared Risk Link Group (SRLG) concept introduced in [IPO-Frame]and extended in [CCAMP-SRG] is considered as one of the mostimportant criteria concerning the constraint-based path computationof optical channel routes. By applying the SRLG disjointnesscriteria to the constraint-based path computation, one can select aroute taking into account both resource and logical structuredisjointness. That implies a lower probability of simultaneousoptical channel failure.This document describes the various physical and logical resourcetypes considered in the SRLG concept. The proposed method focuses onthe inference of SRLG information between the network physical andlogical layers and the logical structures representing geographicallocations. The main applications of the proposed model are relatedto the Constraint-based Shortest Path First (CSPF) algorithm foroptical channel route computation and the aggregation of the SRLGinformation flooded throughout traffic engineering extensions of theIGP routing protocols (such as OSPF and IS-IS). "SIP server IPCP configuration option for PPP", D. Kim, Junhyuk Song, 03-JUN-02, The Point-to-Point Protocol (PPP) [1] provides a standard method fortransporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; anda family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.This document defines the PPP IPCP configuration option that containsa list of IPv4 addresses that can be mapped to one or more SIPproxy servers. It is just one of the many possible mechanism to locate the proxy server, such as DHCP option [6] and manual configuration. This approach is applicable to the system using PPP for the link layer protocol and IP address allocaiton (ex. 3GPP2 Packet Data network) "Extensions to OSPF-TE for supporting shared mesh restoration", Yoshihiko Suemura, Aleksandar Kolarov, Tomohiko Yagyu, 03-JUN-02, Shared mesh restoration technique efficiently uses network resourcessince restoration capacity is shared across multiple independentfailures. In this scheme, when a new working LSP is established, itscorresponding backup LSP is pre-calculated and resources along therestoration route are reserved. The resources reserved on each linkalong the restoration path may be shared across different workingLSPs that are not expected to fail simultaneously. To make the methodfor selection of backup LSPs more efficient in terms of utilizationof network resources, each link should provide the route calculatorwith information about its restoration capacity and SRLGs of workingLSPs whose backup LSPs share the link restoration capacity. In thisdocument we propose extensions to OSPF-TE in support of carrying link'Sharable Bandwidth' information. "Location Information and Privacy Concepts", Aleksandar Gogic, 03-JUN-02, This paper defines and explains some geographic location concepts ofinterest to GeoPriv. Many of these are of particular interest inmobile wireless systems and Internet applications involving thosesystems and devices. The interaction between location servicearchitecture elements is briefly described. Methods of protectingprivacy by controlling the precision with which location informationis disclosed are elaborated. "Scenarios for ENUM and ENUM-like Systems", Richard Stastny, 03-JUN-02, This document analyzes scenarios for ENUM and ENUM-like Systems, both for ENUM used by End Users and also for ENUM-like Systems used by operators for network-specific or infrastructure purposes. It also gives some examples of ENUM Usage and proposes a new URI scheme to be used with ENUM. This may allow a way forward for the definition of ENUM Services and also for the definition of the required URIs and their parameters. This document therefore deals with information stored in the ENUM and the look-up process and the usage of the information retived in this look up process. It does not deal with the administrative process related to the population of the relevant zones. "BGP Route Oscillation Reduction with Route Reflection", E. Chen, 12-JUN-02, This document proposes a simple revision to Route Reflection thatallows a Route Reflector to send a route advertisement (instead of aroute withdraw) in certain cases. The route advertisement helpsnarrow the gap between Route Reflection and IBGP full-mesh in termsof routing information. It has been shown that the proposed mechanismhelps achieve stable route selection and eliminate a number ofpersistent route oscillations involving Route Reflection. "BGP Route Oscillation Reduction with Confederation", E. Chen, 13-JUN-02, This document proposes a simple revision to Confederation that allowsa BGP speaker in a Confederation to send a route advertisement(instead of a route withdraw) in certain cases. The routeadvertisement helps narrow the gap between Confederation and IBGPfull-mesh in terms of routing information. It has been shown that theproposed mechanism helps achieve stable route selection and eliminatea number of persistent route oscillations involving Confederation. "Data Transfer Protocol for Distributed Information Acquisition (DTP/DIA)", Alexei Soloviev, 04-JUN-02, The described in this memo protocol was developed for the applicationin distributed information measurement systems (IMS) at any stage ofcommunication. It was designed for transmission of measured datafrom measuring devices to processing and storing equipment. Also itdoes support common device identification in distributed IMS. Due toits simplicity it can be easily implemented in firmware of anydigital measuring device. "SMTP Service Extension for message Media Size declaration", Vladimir Shveidel, Ari Erev, 04-JUN-02, 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. "An extension to IMAP BODYSTRUCTURE for returningContent-Location information", M. Crispin, Steve Hole, Alexey Melnikov, 05-JUN-02, The [IMAP4] BODYSTRUCTURE FETCH data item allows a client to learn aboutthe MIME structure of a message without the need to download the entiremessage.This document extends the syntax of the [IMAP4] BODYSTRUCTURE FETCHresponse data item to include information from the Content-Locationheader field described in [MHTML]. This extension helps MHTML-awareIMAP clients to save both the number of round trips and the amount ofinformation sent across the network.Fallback strategies are also discussed when an IMAP server doesn'tsupport this extension. "Network Application Session Framework", Robert Fairlie-Cuninghame, 05-JUN-02, This document defines a framework for using Session InitiationProtocol sessions to create user interface components for networkapplication interaction. These Network Applications Sessionsprovide a number of services to the application server and useragent including application identification, co-operation,association, and authentication. In addition to these services theframework allows for differing modes of interaction to be managed ina homogenous manner with similar expectations for security,establishment, update, closure and the handling of certain userinterface operations. "Leveraging Fast Handover Protocols to Support Localized Mobility Management in Mobile IP", James Kempf, 05-JUN-02, Longstanding work in the Mobile IP Working Group has been directed at 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 cases where the Home Agent and Mobile Node are separated by continental or transcontinental distances, this latency can be rather high and can interfere with the Mobile Node receiving its traffic upon Care of Address change when break-before-make handover is required. This draft discusses a solution that leverages the more recent fast handover work and mechanisms already described in the protocol specifications for Mobile IPv6 and the route optimization extension of Mobile IPv4. This alternative has certain simplicity, scalability, and robustness advantages over a design that incorporates additional mobility agents, and requires no additional mechanism in the network or change to the Mobile Node beyond that required to support these protocols. "Cisco Systems NetFlow Services Export Version 9", Benoit Claise, 05-JUN-02, Cisco Systems NetFlow Services provide network administrators with access to information concerning IP Flows within their data networks. Exported NetFlow Services data can be used for a variety of purposes, including network management and planning, accounting, and departmental chargebacks, Internet Service Provider billing, data warehousing, and data mining for marketing purposes. This paper discusses the most recent evolution of the NetFlow flow export format, which is known as Version 9. The distinguishing feature of the NetFlow Version 9 format compared to previous formats, is that it is template based. Templates (collection of fields along with the description and structure) provide a flexible and extensible design to the record format. These two features that allow future enhancements to NetFlow services without requiring concurrent changes to the basic flow-record format and minimize the consumed export bandwidthConventions used in this document. "Recommendations for Automatic Responses to Electronic Mail", Keith Moore, 06-JUN-02, This memo makes recommendations for software that automatically respondsto incoming electronic mail messages, including 'out of the office'response generators, mail filtering software, email-based informationservices, and other automatic responders. The purpose of theserecommendations is to discourage undesirable behavior which is caused oraggravated by such software, to encourage uniform behavior (whereappropriate) among automatic mail responders, and to clear up somesources of confusion among implementors of automatic email responders. "Multicast Control Protocol (MCOP)", Rami Lehtonen, 06-JUN-02, In IP multicast all hosts that join a multicast group (*, G) or (S,G) can receive the multicast traffic. This draft adds possibility toselectively enable multicast receiving and sending by introducingMulticast Control Protocol (MCOP). MCOP is used between multicastcontrol agent (MCA) and routers that have directly connectedmulticast sources or receivers. The receiver and source control isdone by MCOP enabled routers based on the information received fromthe MCA. MCOP enabled routers filter IGMP/MLD reports and multicastpackets before they reach the IGMP/MLD processing layer or multicastrouting stack of the router. MCOP is independent of multicastrouting protocols. "'The 'tel:' URI 'svc' Parameter'", Lawrence Conroy, Rudolf Brandner, Richard Stastny, 07-JUN-02, This document describes the 'svc' parameter for use within a 'tel:' URI.This is intended to indicate the uses to which a resource identifiedvia the 'tel:' URI can be put. It is an optional parameter, and if notunderstood can be ignored. It allows the user to 'hint' at the featuressupported at the resource. There are guidelines for how this parametermight be used, and for expected behaviour on detection of this parameter. "A Mail Header for Sequential Message Numbering", Phil Macias, 07-JUN-02, This memo describes a proposed mail header to allow tracking ofmessage numbers for mail generated by listservs. Inclusion of themessage number in the Subject: field confounds threading inarchiving software. "Server-to-Server Replication/Migration Protocol Design Principles", Robert Thurlow, 07-JUN-02, NFS Version 4 [RFC3010] provided support for client/serverinteractions to support replication and migration, but leftunspecified how replication and migration would be done. Thisdocument discusses the nature of a protocol to be used to transferfilesystem data and metadata for use with replication and migrationservices for NFS Version 4. "Analysis of the Usage of ENUM and ENUM Services", Lawrence Conroy, Rudolf Brandner, Richard Stastny, 07-JUN-02, This document analyzes the usage of the URI-schemes, services and 'enumservices' under discussion for the ENUM System. It tries to combine the existing proposals for 'enumservices' and proposes examples of a compatible approach as a way forward for the definition of the 'enumservices' to be used in the ENUM trials planned. "Mobile IP Forward Packets Using NAPT Method", R Zahng, 07-JUN-02, Mobile IP's datagram tunnelling is inconvenient and complicatedfor mobile node or foreign agent.In CDMA2000 system,the PDSN actsas a foreign agent and it must do decapsulation work after receivesdatagrams from home agent to a mobile node away from home.The costis big. "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", D Evans, W. Marshall, F. Andreasen, Matt Osman, 07-JUN-02, 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 SIP Proxy-to-Proxy Extensions for Supporting DCS", W. Marshall, B. Beser, F. Andreasen, 07-JUN-02, 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 draft-dcsgroup-sipping-arch). "application/xenc+xml Media Type Registration", J. Reagle, 07-JUN-02, This document describes a media type (application/xenc+xml) for usewith the XML Encryption specification. "Control Channel Bootstrap for Link Management Protocol", J. Drake, D. Papadimitriou, J. Lang, 09-SEP-02, The Link Management Protocol (LMP) requires that at least one bi-directional control channel is established between the nodes. 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 control channels and exchange interface mappings using a new LMP message that is transmitted in-band over the data links. "SDP attributes for Video media Media Control", Orit Levin, Petri Koskelainen, Roni Even, 10-JUN-02, This document defines the syntax and the semantics for the new SDP attributes required for handling of video. These attributes are not CODEC specific. "RObust Header Compression (ROHC):A Compression Profile for IP", Lars-Erik Jonsson, 11-JUN-02, The original RObust Header Compression (ROHC) RFC, RFC 3095, definesa framework for header compression, along with compression protocols(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressedpacket streams. However, no profile was defined for compression of IPonly, which has been identified as a flaw in RFC 3095. This documentaddresses that problem and defines a ROHC compression profile for IP,similar to the IP/UDP profile defined by RFC 3095, but simplified toexclude UDP. "Identification of IPv6 Routes that need Tunneling - Use of BGP Extended Community Attribute", Tissa Senevirathne, 11-JUN-02, In this document we provide methods to discover and connect nativeIPV6 clouds that are separated by IPV4 Internet. BGP-MP [2] is usedas protocol to discover IPV6 relay routers. BGP-MP(BGP4+) [3] isused to distribute IPV6 routes. Encapsulation of IPV6 presented in[4] is used to tunnel IPv6 traffic across IPV4 Internet. The methodpresented here is known as 6in4 as opposed to 6to4 [4] or 6over4[5]. "Japanese characters in Internationalized Domain Name labels", Yoshiro Yoneya, 11-JUN-02, Internationalized Domain Name (IDN) makes expression of domain namerich. The demand for such enrichment is to use native languagecharacters in a domain name. IDN itself has no locale dependency as aprotocol, but to utilize IDN in the real world, language and/orregional aspects should be taken into account.This document explains a guideline to any IDN zone administrator whoaccepts Japanese as an IDN label. "On the Future of Internet Network Management Standards", J. Schoenwaelder, 11-JUN-02, There have been ongoing debates during the past few years on thedirection for the evolution of various Internet managementtechnologies and standards such as SNMP, COPS, PCIM. This memo hasbeen written in preparation of the IAB network management workshop tobe help in June 2002. It documents some of the author's views andvisions and as such it does not even try to be objective. "Distance Vectored Monitoring Protocol", Matt Sibley, 12-JUN-02, Distance Vectored Monitoring Protocol (DVMP) is a inter-device communications protocol that merges the intelligence of routing protocol design with the ability to notify network management personnel of troubles experienced on managed devices. DVMP is intended to suppliment or replace conventional SNMP based monitoring systems in small to medium sized autonomous networks, require minimal planning, configuration overhead or supplimentalequipment, and be familiar in configuration and operation to network administrators. "DNS/L2TP Based VPLS", Juha Heinanen, 03-SEP-02, This memo describes a simple mechanism to implement providerprovisioned Virtual Private LAN Service (VPLS) using DNS and L2TP asdiscovery, control, and data plane protocols. "ROOT ZONE PROTOCOL", T. Glassey, 12-JUN-02, The changing structure and size of today's Internet has taxed the existing name services and their architecture to the breaking point. The DNS system of today was unfortunately architected to have a single root zone and limited set of Top Level Domains. This is defined usually in the set of root servers any resolving request uses to lookup an address. This proposal then is an attempt to lessen the impact on end-users and registrars and to allow IP owners a greater freedom in representing namespace to their customers. The elevator description is that this I-D proposes the restructuring of domain names more fully along the lines of a telephone number by creating a ROOT ZONE PROTOCOL as an addition to multiply the existing DNS services times the number of ROOT ZONES. "Secure Simple Mail Transport Protocol", Jefferson Nunn, 12-JUN-02, The Simple Mail Transport Protocol currently doesn't verify the authenticity of the message such that it allows spammers and scammersto exist without fear of retribution. This is due in part to the factthat almost all data contained within the DATA section of an SMTP mail transport can be spoofed. The SSMTP protocol would alleviate much of this concern. "The SIP Refer Method", Robert Sparks, 12-JUN-02, THIS IS AN INDIVIDUAL SUBMISSION PROPOSING A CHANGE TO draft-ietf-sip-refer. IT IS FOR DISCUSSION ONLY.This document defines the REFER method. This SIP extension requeststhat the recipient REFER to a resource provided in the request. Itprovides a mechanism allowing the party sending the REFER to benotified of the outcome of the referenced request. This can be usedto enable many applications, including call transfer.In addition to the REFER method, this document defines the refereventoption tag, the refer event package, and the Refer-To request header. "HighSpeed TCP for Large Congestion Windows", Sally Floyd, 29-AUG-02, This document proposes HighSpeed TCP, a modification to TCP'scongestion control mechanism for use with TCP connections with largecongestion windows. The congestion control mechanisms of the currentStandard TCP constrains the congestion windows that can be achievedby TCP in realistic environments. For example, for a Standard TCPconnection with 1500-byte packets and a 100 ms round-trip time,achieving a steady-state throughput of 10 Gbps would require anaverage congestion window of 83,333 segments, and a packet drop rateof at most one congestion event every 5,000,000,000 packet (orequivalently, at most one congestion event every 1 2/3 hours). Thisis widely acknowledged as an unrealistic constraint. To address thislimitation of TCP, this document proposes HighSpeed TCP, and solicitsexperimentation and feedback from the wider community "Limited Slow-Start for TCP with Large Congestion Windows", Sally Floyd, 09-AUG-02, This note proposes a modification for TCP's slow-start for use withTCP connections with large congestion windows. For TCP connectionsthat are able to use congestion windows of thousands (or tens ofthousands) of MSS-sized segments (for MSS the sender's MAXIMUMSEGMENT SIZE), the current slow-start procedure can result inincreasing the congestion window by thousands of segments in a singleround-trip time. Such an increase can easily result in thousands ofpackets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest ofthe traffic sharing the congested link. This note proposes LimitedSlow-Start, limiting the number of segments by which the congestionwindow is increased for one window of data during slow-start, inorder to improve performance for TCP connections with largecongestion windows. "Dynamic Hostname Exchange Mechanism for OSPF", Venkata Naidu, Sanjay Harwani, 13-JUN-02, Currently, there does not exist a simple and dynamic mechanism forrouters 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. "A DNS RR for Pointers to RRs outside class IN", Ted Hardie, 13-JUN-02, The Domain Name System is a global distributed lookup system withdelegation. In the original specification of the DNS [RFC 1035],CLASSes were described as parallel data structures within a singlenamespace but with potentially different delegations of authority.[BCP 42] defines a different vision, in which different CLASSesrepresent fundamentally different namespaces. Though [BCP 42]includes procedures for assignment of CLASSes, there has beenlittle use of this axis of extensibility; in practice, CLASS IN isthe only widely deployed CLASS in the DNS. The ubiquity of CLASSIN for name to IP address mapping has caused a vicious cycle inwhich extensions are placed within that CLASS to take advantage ofits global deployment, with each addition further increasing itsgravitational attraction. This document describes a ResourceRecord for use within CLASS IN that contains a pointer to a CLASSoutside of IN. This mechanism is intended to allow administratorsto indicate that a named resource identified within CLASS IN isalso present in a different namespace, potentially under a differentname. This cross-class pointer will allow the DNS to handlenew namespaces with mechanisms appropriate to those namespaceswhile providing a connection to the globally deployed CLASS INnamespace. "A Fault Notification and Service Recovery Protocol", Richard Rabbat, 13-JUN-02, This draft describes a fault notification and service recovery protocol that can be used in GMPLS-enabled networks to achieve bounded time activation of protection paths in the case of single failures. It presents a complete solution to the problem and justifies choices made for the notification method, extensions required to current algorithms and protocols and any security and deployment issues. "Registration of HTTP header fields", Mark Nottingham, 13-JUN-02, This document defines the initial IANA registration for some HTTPmessage header fields.Discussion of this documentPlease send comments to . To subscribe to thislist, send a message with the subject'subscribe' to . "Using OSPFv3 for IPv6 router autoconfiguration", Laurent Toutain, E Fleury, G. Chelius, 13-JUN-02, This document proposes the definition of three new OSPFv3 LSA types for auto-configuration of IPv6 networks with routers by allowing a consensus on the SLA part of the IPv6 address for each link of the network. "CAGE", Alexander Bogdanov, 14-JUN-02, This document focuses attention on some aspects of networktechnologies development. It does not contain any technicaldecisions. Nevertheless, it brings up questions, immediatelyconnected with IETF activity. "RObust Header Compression (ROHC): The ROHC Architecture", Lars-Erik Jonsson, 14-JUN-02, RFC 3095 defines a Proposed Standard framework with profiles forRObust Header Compression (ROHC). Various concepts are introducedwithin the standard, which might be difficult to understand, andespecially how these relate to the surrounding environments whereheader compression may be used. This document aims at clarifying thearchitectural aspects of ROHC, discussing terms such as ROHCinstances, ROHC channels, ROHC feedback, ROHC contexts, and how theseterms relate to other terms like network elements and IP interfaces,commonly used when for example addressing MIB issues. "MIDCOM Protocol Semantics", Juergen Quittek, Martin Stiemerling, 09-SEP-02, This memo specifies semantics for a Middlebox Communication (MIDCOM)protocol to be used by MIDCOM agents for interacting withmiddleboxes, such as firewalls and NATs. The semantics discussiondoes not include any specification of a concrete syntax or atransport protocol. However, a concrete protocol is expected toimplement the specified semantics or a superset of it. The MIDCOMprotocol semantics is derived from the MIDCOM requirements, from theMIDCOM framework, and from working group decisions. "The 'enum:' URI scheme", Lawrence Conroy, Rudolf Brandner, Richard Stastny, 14-JUN-02, This document specifies the 'enum:' URI scheme. This URI is intended foruse where a resource can be returned by evaluating the URI value using the ENUM DDDS application. It also includes a definition of an optional URI parameter to indicate a list of enumservices that should be considered in the returned response to the ENUM query. Syntactically, it uses a subset of the format defined for the 'tel:' URI scheme. "Semantics Which The MIDCOM Protocol Must Support", Tom Taylor, 17-JUN-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 is intended to be a working document of the IETF Middlebox Communications (MIDCOM) Working Group. "Multi-Class PPP with Channel Preemption and Dynamic Fragmentation", Mario Nunes, 17-JUN-02, This document defines the encapsulation and mechanisms that allows PPP packets to be transported over low-bitrate links such as modem lines, ISDN B-channels, and sub-T1 links with guarantee of quality of service for time sensitive services. A mechanism of channel preemption is defined, allowing the immediate occupation of the channel with the most priority packet, resuming the transmission of the lower priority frame without need to retransmit the octets already sent. This mechanism allows a dynamic packet fragmentation, guaranteeing simultaneously a low transmission delay for the services more sensitive to transmission delays and an efficient channel occupation. It is a recursive mechanism, which means that the packet that made the channel preemption can itself be preempted by another higher priority packet, and this process can be repeated whenever a higher priority packet requests transmission. The proposed mechanism is compatible with existing hardware and drivers for asynchronous and synchronous HDLC controllers. "Smooth Handover over IEEE 802.11 Wireless LAN", Masataka Ohta, 17-JUN-02, This memo describes, based on the experience of MIS (Mobile InternetServices, Inc.) for commercial mobile IP service over IEEE 802.11bbased wireless LAN environment, how smooth handover between accesspoints is implemented.The major obstacle for the smooth handover is time required to scanfrequency bands and latency of mobile registration is not so much aproblem, both of which is solved with terminals having twotransceivers. "Generalized MPLS (GMPLS) RSVP-TE Usage and Extensions For Automatically Switched Optical Network (ASON)", D. Pendarakis, Z. Lin, 11-SEP-02, The GMPLS suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SDH/SONET as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. "Applicability of LMP (and LMP-WDM) to Link Segments", D. Papadimitriou, 17-JUN-02, Integration of Generalized MPLS-capable SONET/SDH networks inexisting backbone environments has generated the need to determineinter-working capabilities between nodes interconnected by bothSONET/SDH and non-SONET/SDH overhead terminating networks. This isparticularly the case for critical functions and applications suchas the ones provided by the Link Management Protocol [LMP] and itsWDM extensions [LMP-WDM]. In this context, this document describesthe applicability of their respective functions and illustrates themthrough several inter-connection architectures. "NAT64 - NAT46", Alain Durand, 18-JUN-02, This document defines two scalable NAT mechanisms, NAT64 to enableIPv6-only devices to initiate communications with unmodified IPv4only devices and NAT46 to enable IPv4-only devices to initiatecommunications with IPv6-only devices. "BGP Route Oscillation Avoidance for Route Reflection and Confederation", E. Chen, 18-JUN-02, In this document we propose a mechanism and routing setup that wouldavoid persistent route oscillations and yield consistent routeselection in a network using one-level Route Reflection, or usingConfederation where routers that participate in inter-member-ASpeering are fully meshed. "A Structural Object Class for Arbitrary Auxiliary Object Classes", L. Howard, 18-JUN-02, The Lightweight Directory Access Protocol (LDAP) supports auxiliaryobject classes for adding additional attributes to a directory entry.This document defines a structural object class that may be used when noother structural object class is available. "Generic Header Compression Notation for ROHC", HongBin Liao, 18-JUN-02, This draft describes the framework of the generic header compression notation (ROHC-GN). The goal of Robust Header Compression (ROHC) is to develop generic header compression schemes that perform well over links with high error rates and long roundtrip times. ROHC will develop multiple compression schemes, for example, ROHC-RTP, ROHC-TCP [ROHC-TCP], ROHC-SCTP [ROHC-SCTP], etc. Our proposed generic header compression notation will describe the header fields that are to be compressed, and the information to be transmitted in the compressed header. Using this notation and the corresponding encoding methods, we can have a toolbox to standardize future ROHC profiles. "Optimized Packet Structure for HIP", Petri Jokela, 18-JUN-02, This memo describes alternative, optimized packet structures for theHost Identity Payload and Host Layer Protocol (HIP). The packetstructures presented in this memo are intended replace originalpackets 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 thepacket structures simpler and more distinct, which makes theimplementation work easier, hopefully leading to more secure protocolimplementation. The new structures reduce the average packet size andtake advantage of other existing IPv6 protocols formats, includingalignments concerns, like the newly suggested Mobility header formatfor Mobile IPv6. "Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)", M. Riegel, 18-JUN-02, This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed (TDM)digital signals over packet-switched networks. It is based on thecommon framework of PWE3 as defined in [PWE3-FW] and theconsiderations on protocol layering in PWE3 as discussed in [PWE3-LAYERS].It makes references to requirements in [PWE3-REQ] where applicableand complements [PWE3-REQ] by defining additional requirementsoriginating from specifics of TDM circuits. "Fast Handoff with Chain Tunneling for Mobile IPv6", H Jung, 19-JUN-02, Mobile IP allows a mobile node to send and receive packets regardless of the IP address of its current point of attachment in the Internet. Several handover protocol using Layer 2 information has proposed for fast handover. We propose a modification of the fast handover protocol with simple Layer 2 triggers. For successive handovers of a Mobile Node on real-time service, a chain tunneling handover is proposed. For effective operation of the chain, the chain length threshold is adopted to prevent packet delay due to the successive handovers. Tunnel negotiation is employed to adopt the local resource and security conditions and management policies. "IPv6 Reverse Routing Header and its application to Mobile Networks", Pascal Thubert, Marco Molteni, 19-JUN-02, Already existing proposals enable Mobile Networks by extending MobileIP to support Mobile Routers. In order to enable nested MobileNetworks, some involve the overhead of nested tunnels between theMobile Routers and their Home Agents.This proposal allows the building of a nested Mobile Network avoidingthe nested tunnel overhead. This is accomplished by using a newrouting header, called the reverse routing header, and by overlayinga layer 3 tree topology on the evolving Mobile Network. "Algorithm naming", Keith Burdis, Raif Naffah, 19-JUN-02, This document describes a process for registering cryptographicalgorithm names and parameters to ease referencing of suchinformation from IETF Drafts and RFCs. "ODETTE File Transfer Protocol Revision 1.4", D. Nash, I. Mokry, 30-JUL-02, This memo describes a file transfer protocol to facilitate electronicdata interchange between trading partners.The protocol, denoted the ODETTE File Transfer Protocol, supportsboth direct communication between installations and indirectcommunication via a third party clearing centre. It was developed bythe Organisation for Data Exchange by Tele Transmission in Europe tofacilitate communication within the European motor industry and ispresented here to allow for wider use within the Internet community. "O(n**2) Investigations", Heinrich Hummel, Bernd Hoffmann, 19-JUN-02, The O(n**2) problem is a well-known problem which occurs when overlaynetwork models are used, e.g. for building vpns. This draft comparesfour different methods as to accomplish an effective full meshconnectivity and shows precisely the amount of resource consumptionin each case - i.e. the consumption of states and labels. "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", R. Mahy, 19-JUN-02, When SIP entities use a connection oriented protocol to send arequest, they typically originate their connections from an ephemeralport. The SIP protocol includes mechanisms which insure thatresponses to a request, and new requests sent in original directionreuse an existing connection. However, new requests sent in theopposite direction are unlikely to reuse the existing connection.This frequently causes a pair of SIP entities to use one connectionfor requests sent in each direction, and can result in potentialscaling and performance problems. This document presentsrequirements for addressing this shortcoming, and separately proposesan example mechanism which addresses this deficiency. "NAT and Middlebox Tunnels", Jim Renkel, 20-JUN-02, This Internet Draft compares Network Address Translation (NAT) andRealm Specific IP (RSIP) tunnels, and the advantages anddisadvantages of each. It then shows how the advantages can becombined by implementing NAT as a tunnel in hosts, whileminimizing the disadvantages. Based on the advantages of middleboxtunnels in general and implementing NAT as a middlebox tunnel inparticular, it then recommends that the Middlebox Communicationsarchitecture protocol (MIDCOM) be amended to support tunnelsbetween hosts and middleboxes.This .txt version of this internet draft is identical to thePostScript version (draft-renkel-middlebox-tunnels-00.ps) exceptthat the figures from the PostScript version have been deleted.Please refer to the PostScript version for these figures. "Authentication/Confidentiality for OSPFv3", Mukesh Gupta, Nagavenkata Melam, 25-JUL-02, This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. "ISIS IIH Sequence Number Scheme", Naiming Shen, Steven Luong, 20-JUN-02, This draft describes an optional sequence number TLV inside theISIS IIH packets. This sequence number TLV can be used for ISISadjacency troubleshooting especially in the case where a largenumber of adjacencies are maintained and/or a low adjacencyholddown time is used for the purpose of fast convergence. "Requirements for Authorized Emergency CommunicationsUsing Elastic Service", K Carlberg, Ian Brown, 20-JUN-02, The objective of this draft is to present a set of requirements toaddress requests by users of authorized emergency communications forbetter than best effort service for elastic service. We stress theword 'request' versus guarantee, and we do NOT advocate broadsweeping changes to elastic applications. This document providesbackground information on emergency communications and presentssuggested do's and don'ts in addressing the issue of requirementsfor elastic services. Finally, examples of requirements for specificapplications are presented. "Guidelines for Mobile IP and IPSec VPN Usage", Serge Tessier, 20-JUN-02, This document highlights some of the issues that should be consider 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, which is a subjective task left to the user and implementation developers of both protocol, it rather proposes some usage guidelines and general considerations. "IPv6 Transition Solutions for 3GPP Networks", Juha Wiljakka, 11-SEP-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. "A Framework for Bi-Directional QoS Signaling", Sharif Shahrier, Kamel Shaheen, 28-JUN-02, This Internet Draft describes the end-to-end signaling architecture and framework model for transmitting packets through a series of heterogeneous networks. The Next-Steps-In-Signaling (NSIS) Working Group is already working on defining a set of requirements for the QoS signaling protocol [1]. This document is the follow on to the requirements draft, and the precursor to any solutions document. It outlines a framework for transporting end-to-end QoS parameters, initiated and maintained by the 'Originator' of the service. This draft elaborates on the requirements draft. It defines more precisely the scope of NSIS for end-to-end packet flows, in terms of QoS Signaling, where the resource reservations for the service are initiated by the “Originator” end point and whether this service is bi-directional or unidirectional (i.e., receive-only or send-only). The draft is fully backward compatible; it requires no changes to the existing QoS signaling protocols or procedures. It applysapplies generic messages to transport the information needed to establish the desired QoS for traffic flows in either one or both directions. This document can be used as the guideline for a prospective solution to the QoS signaling problem. "Protocol Actions for RFC2547bis", Eric Rosen, 14-AUG-02, The purpose of this document is to list all the protocol changes specified in [rfc2547bis] and related drafts which might be regadedto require approval or other action by IETF WGs other than the PPVPNWG. This document is for temporary administrative purposes only, anddoes not itself specify a protocol or an architecture. "Mobile IPv4 Compatibility Extensions", L. Salgarelli, Ahmad Muhanna, Pierre Boulos, 21-JUN-02, Mobile-IP, together with several other supporting standards suchas Reverse Tunneling and the Challenge-Response extensions, haveall been recently revised. Although such revisions are for themost part backward compatible with the original versions,sometimes static configuration of Mobile Nodes and Mobility Agentsis required to ensure smooth transition and avoid any possibleconflict between different standard versions implemented byalready-deployed equipment. In this draft we define compatibilityextensions for Mobile-IP Agent Advertisement, Registration Requestand Registration Reply messages that allow all Mobile-IPv4entities to dynamically synchronize their 'compatibilityversions', defined as the versions of the Mobile-IP standards thata particular node is able to support. This solution offers adynamic mechanism which informs all entities involved in aMobile-IP exchange of the version of the standard they support,therefore reducing the need to statically configure suchinformation at Mobile Nodes or Mobility Agents "Applicability statement for edge to edge emulation of Time Division Multiplexing (TDM) services over Packet Switched Networks (PSN)", Ron Cohen, 21-JUN-02, This document provides an applicability statement for the transport of TDM circuits over PSN. The document describes the various deployment scenarios and the recommended encapsulations and services to be used. In particular, it describes the scenarios applicable for SONET/SDH derived circuit emulation and scenarios applicable for native TDM emulation. "Network Management Observations", Andy Bierman, 21-JUN-02, This memo contains observations on the progress of standards basednetwork management efforts within the IETF. In particular, it describestechnical and process oriented deficiencies which have delayed thecreation and adoption of standards for network device configuration, andoffers recommendations for correcting these deficiencies. "Name resolution in zeroconf environment using ICMPv6 node information query", Jun-Ichiro itojun Hagino, 21-JUN-02, The document proposes a way to resolve DNS names in zeroconf environment[Williams, 2002] , by using ICMPv6 node information query/reply[Crawford, 2002] . The proposed protocol works only with IPv6 (not withIPv4). "Use of ICMPv6 node information query for reverse DNS lookup", Jun-Ichiro itojun Hagino, 21-JUN-02, The document proposes an alternative way to perform reverse DNS lookup,by using ICMPv6 node information query/reply [Crawford, 2002] . Theproposed protocol works only with IPv6 (not with IPv4). "An IP Traffic Engineering PIB for Accounting purposes", Mohammed Boucadair, 21-JUN-02, 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]. "Hierarchical MPLS Services using 2547bis and BGP/MPLS", P Menezes, 21-JUN-02, This document describes a network service model for service providers to deliver economical layer 2 VPN services using hierarchical MPLS. The service model builds on top of 2547 and BGP/MPLS and extends to building L2VPN services between customer sites with a scalable peering model. It reduces the cost of services for downstream providers by using a distance-insensitive IP Network Service Provider (NSP) as a WAN partner to connect distant regions. It simplifies downstream provider’s operation and improves the scalability of a traditional standard overlay model by allowing the downstream provider to peer with the upstream provider for both Internet transit and L2VPN services. "Synchronization operations for disconnected IMAP4 clients", Alexey Melnikov, 16-AUG-02, This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issuesof what might be called the 'driver' portion of the synchronizationtool: 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 disconnectedclient 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. "BGP Peer Restart Backoff Mechanisms", Susan Hares, 21-JUN-02, This document describes mechanisms for methods for damping the oscillations of BGP-4 [1] peers by increasing the time between automatic start functions of the BGP peers. The increase of time between automatic start functions will be denoted as a backoff of the automatic start functions by this draft. This draft is an informational RFC which provides a description of mechanisms for back-off of the automatic start function in bgp-4 peer reconnections. This Informational RFC includes descriptions about the back-off mechanisms and how this information is recorded in the BGP-4 MIB version 2 [2]. The expontential back-off mechanism contained in this draft was first recorded in a draft of the bgp-4 specification. The author requests that anyone with information regarding the original authors of that work contact the author. The lack of credit for thoseauthors is based on the author's lack of knowledge the originatorsof the expotential back-off. "Hop-by-Hop Local Mobility Agents Probing for Mobile IPv6", Vrizlynn Thing, 21-JUN-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 ofsignalling to the home agent and correspondent nodes when mobile node moves among the subnets of the visited domain. "IPFIX Applicability", Tanja Zseby, 21-JUN-02, 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. "Signaling Reverse-directional LSP in Generalized MPLS", Eiji Oki, Nobuaki Matsuura, 21-JUN-02, Generalized MPLS extends the MPLS control plane to encompass bidirectional LSPs. This document defines related extensions to Generalized MPLS signaling to support the establishment of reverse-directional LSPs. This document presents a functional description of the extensions for signaling reverse-directional LSPs. "RSVP Path computation request and reply messages", P. Psenak, J Vasseur, 21-JUN-02, This document describes extensions to RSVP-TE to support a new message type called a 'Path computation' message. This message is to be used between an LSR and a Path Computation Server, which may be an LSR or a centralized path computation tool. An RSVP Path Computation Request message is used by the head-end LSR to send its request to the Path Computation Server. The Path Computation Server in turn sends an RSVP Path Computation Reply message containing either: - a positive reply, containing one or more paths, if the request can be satisfied. - a negative reply if no path obeying the requested constraints can be found. The Path Computation Server may also optionally suggest new constraint values for which one or several paths could be found. There are many situations where a Path Computation Server may be used. A typical example is in the context of Inter-area MPLS TE. A head-end LSR could request that a Path Computation Server compute one or more paths obeying a specified set of constraints for a TE LSP spanning multiple areas. The path computation server could be a centralized path computation server or an ABR. Another example is the use of a Path Computation Server to compute diversely routed paths between two end points. This may be useful in the context of MPLS TE LSP Path protection or GMPLS LSP Path protection. The computation of Multi-constraints paths requires intensive CPU resources, and may be yet another usage example. Lastly, those protocol extensions could be used as a 'UNI' like protocol between a CE (Customer Edge equipment) and a PE (Provider Edge equipment) where the CE is not part of the PE's IGP domain. "IS-IS Path Computation Server discovery TLV", J Vasseur, 08-JUL-02, This draft proposes an IS-IS extension for a router to announce its Path Computation Server capability used in the context of MPLS Traffic Engineering. This draft defines a new TLV called PCSD sub-TLV (Path Computation Server Discovery) which is carried within the IS-IS LSP. "Mobile IPv6 handoff by Explicit Multicast", Yutaka Ezaki, Yuji Imai, 21-JUN-02, A handover process on Mobile IPv6 requires a time period referred as handoff latency. This latency is not acceptable to support real-time application. We propose a new smooth handoff method using the Explicit Multicast (xcast) technique. On the wired section, control/user packets are multicasted by Xcast scheme to the Base Stations where Mobile Node (MN) can receive, and then packets are passed to the air-link activated between a BS and the MN. This procedure provides mobility in heterogeneous media environment because this handoff mechanism is basically able to implemented without additional control or intelligence of neither intermediate routers. "Relialeble Serverpool applicability statement", Lode Coene, 21-JUN-02, This document describes the applicability of the Aggregate ServerAccess Protocol(ASAP) and Endpoint Name Resolution Protocol(ENRP)developed for relialeble serverpooling. Also some guidance is givenon the choice of underlying transport protocol(and correspondingtransport protocol mapping) for transporting application data andASAP/ENRP specific control data. "Registration of common IMAP keywords", Alexey Melnikov, John Neystadt, 21-JUN-02, The aim of this document is to document some common [IMAP4] keywordsfor the purpose of improving interoperability between different IMAPmail clients. The document both documents some keywords already inuse, as well as introduces several new ones. "Evaluating the ICAP protocol regarding the OPES callout protocol requirements", Martin Stecher, 21-JUN-02, This document uses the requirements for OPES callout protocols [1]and evaluates whether they are fulfilled by the ICAP protocol [2]. "IPPM metrics measurement packet", Emile Stephan, 21-JUN-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, a set of measurement packets has to be standardized. This document defines an IPPM measurement packet 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 packets in the future. "3GPP work related to SIP based messaging", A. Allen, 01-JUL-02, The 3rd Generation Partnership Project (3GPP) is using SIP RFC 3261[1] as the session establishment protocol for the 3GPP IP MultimediaCore Network Subsystem (IM CN Subsystem, IMS). 3GPP has recentlystarted working on messaging over the IM CN Subsystem. It isintended that this will utilize the IM CN Subsystem for delivery andmay be based on IETF protocols including the work being performed inthe SIMPLE working group. In this document is provided an outlineand areas of interest of the 3GPP work on IMS messaging for theinformation of the SIMPLE working group. "The ANANA Datastore", M. Rose, 28-JUN-02, This memo defines the ANANA datastore, a policy-neutral service formanaging registries, namespaces, and entries. "JXTA v1.0 Protocols Specification", Michael Duigou, 24-JUN-02, The JXTA protocols defines a suite of six XML-based protocols thatstandardize the manner in which peers self-organize into peergroups,publish and discover peer resources, communicate, and monitor eachother. The Endpoint Routing Protocol (ERP) is the protocol by whicha peer can discover a route (sequence of hops) to send a message toanother peer potentially traversing firewalls and NATs. TheRendezvous Protocol (RVP) is used for propagating a message within apeergroup. The Peer Resolver Protocol (PRP) is the protocol used tosend a generic query to one or more peers, and receive a response (ormultiple responses) to the query. The Peer Discovery Protocol (PDP)is used to publish and discover resource advertisements. The PeerInformation Protocol (PIP) is the protocol by a which a peer mayobtain status information about another peers. The Pipe BindingProtocol (PBP) is the protocol by which a peer can establish avirtual communication channel or pipe between one or more peers. TheJXTA protocols permit the establishment a virtual network overlay ontop of physical networks allowing peers to directly interact andorganize independently of their network location and connectivity.The JXTA protocols have been designed to be easily implemented onunidirectional links and asymmetric transports. "SIP endpoint service charging requirements", Wolfgang Beck, 24-JUN-02, Today, a SIP user wanting to charge for a service needs to establishan agreement with all prospective callers. This administrativeoverhead can be avoided if caller and callee can prove the durationand existence of a call in case of a dispute. The draft describesrequirements for protocols and SIP extension that can be used toimplement such functionality. "A Survey of Authentication Mechanisms", E. Rescorla, 24-JUN-02, Authentication is perhaps the most basic security problem for design-ers of network protocols. Even the early Internet protocols such asTELNET 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 beenintroduced in an attempt to close these holes.The most striking thing about these security mechanisms is how manyof them are essentially similar. There are only 7 basic classes ofauthentication protocol but there are a large number of slightly dif-ferent protocols with essentially the same security properties. Thismemo surveys the space of authentication mechanisms, describes thebasic classes and provides examples of protocols which fit into eachclass. "Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition", Shriharsha Hegde, Thomas Nadeau, 24-JUN-02, This memo defines how label switching controlled Frame-Relayand ATM interfaces can be realized given the interface stacking as defined in the MPLS-LSR and MPLS-TE MIBs. "Media Gateway AAL2 Bearer-Path Establishment", Dave Barr, 24-JUN-02, This document proposes specific procedures that Media Gateways (MGs) shall follow for AAL2 bearer-path establishment under the control of H.248 (Megaco) capable Media Gateway Controllers (MGCs). The procedures cover MGs which use provisioned VCCs and backward call setup mode dynamic SVCs, and which do not use AAL2 signalling (i.e. no Q.2630.x). Although this document refers to the use of the H.248 (Megaco) gateway control protocol, many of the concepts and procedures are not specific to this protocol. "Internet Emergency Preparedness Services in a Differentiated Services Domain", Cory Beard, Salil Talauliker, 24-JUN-02, The international community needs advice as to what standards to rely on for the operational implementation of services for Emergency Preparedness. This draft outlines the best current practices to provide deterministic behavior of Internet applications during emergencies using Differentiated Services. It should be noted that there can be more than one suitable approach and this draft only describes what can be done with the existing Differentiated Services architecture. "Address Allocation for PE-CE links within an RFC2547bis Network", Jim Guichard, 24-JUN-02, This document proposes to allocate a block of globally unique IPv4 addresses for exclusive use by 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). The main motivation for this proposal is to simplify the Service Providers' operations by eliminating the need for the Service Providers to acquire globally unique addresses for the links that connect Customer Edge (CE) routers with Provider Edge (PE) routers. An additional benefit of this proposal is that it conserves IPv4 address space by allowing multiple Service Providers to share the same block of IPv4 addresses for provisioning of customer links. This addressing scheme is not intended for use by VPNs that span more than a single Service Provider, unless co-operation of addressing structure is maintained to ensure uniqueness between providers. "Comparison of ATM encapsulation formats in pwe3", Thomas Walsh, 24-JUN-02, Different encapsulation formats have been proposed to carry ATM services over IP, L2TP and MPLS [2], [3], [4]. The cell mode proposals are discussed in [2] and [3]. The frame mode proposals are discussed in [2] and [4]. This paper analyzes certain key issues in these proposals and makes some conclusions. "XMPP CPIM Mapping", Jeremie Miller, Peter Saint-Andre, T Bamonti, 24-JUN-02, This document describes a mapping of the eXtensible Messaging andPresence Protocol (XMPP) to the Common Presence and Instant Messagingspecification. "XMPP Instant Messaging", Jeremie Miller, Peter Saint-Andre, 24-JUN-02, This document describes the specific extensions to and applicationsof the eXtensible Messaging and Presence Protocol (XMPP) that arenecessary to create a basic instant messaging and presenceapplication (specificlaly, an application that is compatible with theopen-source Jabber instant messaging system). "XMPP Core", Jeremie Miller, Peter Saint-Andre, 24-JUN-02, This document describes the core features of the eXtensible Messagingand Presence Protocol (XMPP), which is used by numerous applicationsthat are compatible with the open-source Jabber instant messagingsystem. "Label Set Priority and Flagging Operations", D. Papadimitriou, Timucin Ozugur, 24-JUN-02, This document presents the GMPLS Signaling mechanisms referred to asgeneralized label flagging method, and RSVP-TE/CR-LDP specificsignaling extensions formats needed to ease forward-link labelunavailability when the downstream label selection is restricted bythe upstream node using the Label Set. It also relaxes backward-linklabel collision when the downstream label collides with competinglabel selection. This method introduces the Flagged Label Setobject/TLV in order to prioritize the reservation of the labelsincluded in the Label Set enabling to decrease the forward- andbackward-link blocking probability. "ForCES Forwarding Element Functional Model", Lily Yang, 24-JUN-02, This document defines a functional model for ForCES forwarding elements (FEs). This model is used to describe the 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 function instances are present in the FEs and in what order these functions are performed. Theforwarding 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 components are not described and defined in this document. Definitions A set of terminology associated with the ForCES requirements is defined in [FORCES-REQ] and is not copied here. The following list of terminology is relevant to the FE model defined in this document. Datapath -- A conceptual path taken by packets within the forwarding plane, inside an FE. There might exist more than one datapath within an FE. Forwarding Element (FE) Block -- An abstraction of the basic packet processing functions in the datapath. It is the building block of FE functionality. This concept abstracts away implementation details from the parameters of interest for configuration, control and management by CE. The general rule of thumb on the granularity of FE blocks is that FE blocks should be coarse grained, stateful and focus on a particular domain. For example, RFC1812 compliant IPv4 forwarder, classifiers, meters, etc.. Forwarding Element (FE) Stage -- Representation of a FE block instance in a FE's datapath. As a packet flows through an FE along a datapath, it flows through one or multiple distinct stages, with each stage implementing an instance of a certain logical function. There may be one or more combination of such instances in a FE's datapath. Using NAT as "Extended Hitless OSPF Restart", Alfred Lindem, Anand Oswal, 24-JUN-02, This memo documents an enhancement to OSPF 'hitless restart' wherebyan OSPF router can request that its forwarding state be maintainedlonger that the router dead interval on one or more router interfaces. This is useful when the OSPF software is being updated and the router dead interval on one or more interfaces isconfigured to a small value. "PWE3: ATM Cell Encapsulation", John Rutemiller, 24-JUN-02, This draft defines the encapsulation formats and procedures for transporting ATM connections over a packet switched network (PSN) or packet based interface. This specification supports four levels of transport: 1) Transparent cell, 2) Virtual Path, 3) Virtual Channel, and 4) AAL5 Payload. Header compressions algorithms are provided for the Virtual Path and Virtual Channel transport levels. "Service Requirements for Optical Virtual Private Networks", H Ould-Brahim, 24-JUN-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. "BGPv4 INFORM message", John Scudder, David Ward, Gargi Nalawade, 14-AUG-02, This document defines a new message type, the BGP INFORMmessage that communicates Informational data and operationalwarnings without resetting the peering session. "Link-layer Triggers Protocol", Alper Yegin, 24-JUN-02, 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. "PWE3 Fragmentation and Reassembly", A. Malis, W. Mark Townsley, 24-JUN-02, This document defines a generalized method of performingfragmentation for use by PWE3 protocols and services. "Enhanced Forwarding From Previous Care-of Address For Fast Mobile IPv6 Handovers (eFWD)", Alper Yegin, Youngjune Gwon, 24-JUN-02, This document 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 document. The eFWD protocol removes extra burden on link layer by eliminating any requirement on pre-triggers. "Towards XML Based Management and Configuration", Ted Goddard, 24-JUN-02, This informational document surveys a variety of existingtechnologies relevant to the exploration of an XML-based technologyfor network management and configuration. The technologies surveyedinclude SOAP, WSDL, SyncML, WBEM, RDF, CC/PP, and JUNOScript. Thedata representation capability of XML with and without schemas andDTDs is compared with SMIv2. "Architecture and Framework for Wireless Virtual Private Networks (VPN)", Tissa Senevirathne, 24-JUN-02, In this document we present Architecture and Framework for WirelessVPN services. The wireless VPN services discussed here focus onmobility users of GSM and 3G services. This document does notdiscuss Wireless LAN services provided by 802.11 standard.In this document wireless VPN services are presented as a VPNservice with special requirements, underlying physical layercharacteristics are considered out of scope.The purpose of the document is to initiate the discussion on WVPNwith the possibility of expanding the PPVN charter to include WVPN. "Requirements for Layer 2 Virtual Private Network Services (L2VPN)", Waldemar Augustyn, 24-JUN-02, This draft describes service requirements for L2 Virtual Private Networks. It covers non-broadcast point to point and point to multipoint VPNs referred to as Virtual Private Wire Service (VPWS), as well as broadcast domain multipoint to multipoint VPNs referred to as Virtual Private LAN Service (VPLS). L2VPNs are a class of Provider Provisioned Virtual Private Network [2]. This draft is intended to supersede draft-ietf-ppvpn-vpls-requirements-00.txt [3]. "RTP Payload Format for Uncompressed Video", C. Perkins, L. Gharai, 24-JUN-02, This memo specifies a packetization scheme for encapsulatinguncompressed HDTV as defined by SMPTE 274M and SMPTE 296M intoa payload format for the Real-Time Transport Protocol (RTP).SMPTE 274M and SMPTE 296M define the analog and digitalrepresentation of HDTV with image formats of 1920x1080 and1280x720, respectively. The payload has been designed suchthat it may scale to future higher resolutions, suhc asDigital Cinema. "DDP and RDMA Concerns", J. Wroclawski, M. Speer, David Black, 24-JUN-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 eventual publication as an RFC. "GMPLS Architectural Considerations for (Hybrid) Photonic Networks", Martin Vigoureux, 25-JUN-02, Optical networks could have been reduced to point-to-point links buttechnology evolution led the way to an evolution trend. The conceptof optical transparency first took shape through the development ofphotonic switching fabrics and is now being reinforced by thecontinuous efforts produced to increase transmission distances.Optical networking obviously can not be left aside of suchevolutions and so it is for the (in particular, GMPLS-based)protocols that control these photonic networks. This documenthighlights the enhancements that seem to be necessary for GMPLS tocover these emerging trends (transparency, hybrid nodes) and fulfilits role of a generalized control plane. "CR-LDP Extensions for ASON", Osama Aboul-Magd, 25-JUN-02, This draft considers CR-LDP extensions for the support of the ITU ASON architecture (G.8080) [2] and its signaling requirements (G.7713) [3]. The CCAMP WG charter includes the statement: 'Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc.' This draft is within the CCAMP charter since it defines extensions to a CCAMP-defined signaling protocol, namely CR-LDP, for transport network tunnels. "Unidentified issues in IPv6 deployment/operation", T. Jinmei, Jun-Ichiro itojun Hagino, 25-JUN-02, This document tries to identify issues in IPv6 deployment/operation,that are yet to be addressed. The document covers broad range ofproblems, and therefore, may capture problems that should be discussedin multiple IETF working groups. "L2TP Call Information Messages", Thomas Mistretta, 25-JUN-02, This document defines additional L2TP AVPs to communicateinformational ASCII text messages between the tunnel endpoints duringcall establishment. The message contents are not interpreted by thereceiving endpoint in any way but can be used for logging ordebugging purposes. "TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3)", P Pate, 25-JUN-02, This document describes the service-specific implementation andrequirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) of TDMcircuits using SONET/SDH payload formats. This draft extendsSONET/SDH SPE emulation proposal [CEP-SPE], providing SONETVT1.5/2/3/6 and SDH VC-11/12/2 circuit emulation. This draft alsoprovides bandwidth saving modes for SONET STS-1 and SDH VC-3/4carrying tributaries or asynchronous T3/E3 signals. This proposalis optimized for VT level cross connect applications, for PDH toSONET/SDH emulation and for carrying PDH circuits across a PSN. Theapplicability statement for TDM circuit emulation (PDH andSONET/SDH) is described in [TDM-APP]. This draft discusses theemulation of these circuits over packet networks using IP or MPLS. "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", F. Dupont, 25-JUN-02, When a 'NAT traversal' capability is added to a class of signalingprotocols which can control some traffic aggregation points,a new attack based on a temporary access to the path followedby messages.Mobile IP [1] with NAT traversal [5] or IKE [2] with NATtraversal [6], including the IKEv2 [7] proposal, are potentialvictims of this kind of attacks.This document claims the vulnerability is an intrinsic propertyof the NAT traversal capability, so is a new point where theusage of NATs is very damaging. "Internationalized Domain Names (IDN)", D. Crocker, 25-JUN-02, Globalization of the Internet requires that domain namesbe able use characters outside the ASCII repertoire.This document specifies internationalized domain names(IDNs) and defines initial domain name constructs inwhich IDNs can be used. IDNs use characters drawn froma large repertoire (Unicode). "Object Oriented PDUs for SNMP", Wesley Hardaker, 25-JUN-02, This draft specifies some new PDU operations intended to optimizeSNMP requests for performance.This draft is very incomplete. The operations for SET semanticsdidn't make it into the draft in time for publication by the summary2002 draft deadline. There is not much documentation, and there areno error handling codes or elements of procedures defined yet. Theconcepts, however, have been thought out about a lot. I haven'tfinished transforming my thoughts into words and definitions,however, so you have been warned. Feedback, however, would still begreatly appreciated at this point. "Transition Scenarios for ISP Networks", Cleveland Mickles, 12-SEP-02, This document describes the different types of Internet ServiceProvider (ISP) networks in existence today. It will provide designand operational considerations in delivering network services tocustomers for five specific areas in an effort to better identifyspecific issues which may arise during a transition to IPv6. "Applicability of the Tunnel Setup Protocol(TSP) as an IPv6 Transition Technique", Marc Blanchet, Florent Parent, 25-JUN-02, There are multiple environments where IPv6 transition techniques canbe used. There are multiple IPv6 transition techniques. Thisdocument describes the applicability of transition techniques basedon the Tunnel Setup Protocol(TSP) used in different environments,such as: provider, enterprise, unmanaged networks, cable-dsloperators, wireless operators, mobile hosts and networks. TSPenables the automation of prefix assignment, DNS delegation androuting preferences. TSP supports IPv6 over IPv4 and IPv4 over IPv6encapsulations, as well as UDP-IPv4 encapsulation for IPv4 NATtraversals, through automatic NAT discovery. "IETF Rights in Submissions", S. Bradner, 25-JUN-02, The IETF policies about rights in submissions to the IETF is designedto ensure that IETF contributions can be made available to the IETFand Internet communities while permitting the authors to retain asmany rights in the document as possible. This memo details the IETFpolicies on rights in submissions to the IETF. It also describes theobjectives that the policies are designed to meet. "Testing Hierarchical Virtual Private LAN Services", Olen Stokes, 25-JUN-02, This document describes a methodology for testing theoperation, administration and maintenance (OA&M) of a generalVPN service, that is applied here to Hierarchical VirtualPrivate LAN Services (HVPLS) as described in [VPLS]. As partof this methodology, the MPLS ping concepts described in [LSP-PING] are extended to enable HVPLS spoke-to-spoke connectivitytesting. A method to provide the information necessary forthis 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 membershipThere are two specific requirements to which we call attentionbecause of their seemingly contradictory nature:- the checking of connectivity MUST involve theability to use packets that look like customerpackets- the OAM packets MUST not propagate beyond theboundary of the provider network "Requirements for IPv6 prefix delegation", Shin Miyakawa, 25-JUN-02, This document describes requirements about how an IPv6 address prefixshould be delegated to an IPv6 subscriber's network (or 'site'). "Network Management for GSMP Interface", Y. Cha, 25-JUN-02, General switch management protocol (GSMP) is an open interfaceprotocol between a label switch and a controller, and it providesconnection, configuration, event, performance management andsynchronization. In the GSMP interface, network management functionscan be located either in the controller or in the label switch. Wediscussed the implementation complexity of a label switch and theefficiency of resource usage according to the location of networkmanagement functions. "Extension of GSMP for optical burst switching", J Choi, 25-JUN-02, In this draft, we propose the extension of General Switch Management Protocol (GSMP) for optical data burst switching control. This document describes node architecture and reservation management using GSMP interface for data burst switching in optical domain. Particularly, we propose a reservation request message which is extended to the existing GSMP protocol. It contains the information about offset time and burst length to control data burst in optical switch. "Security Threats and Risks for Open Pluggable Edge Services", T. Chan, B. Srinivas, 25-JUN-02, This Internet Draft is an attempt to define the security threats against the OPES protocol. In addition to the threats, the effects of such security threats on the underlying architecture as well as the requirements of a security solution to mitigate such threats are discussed. The threats and requirements identified herein and the document should be considered as work in progress. "IPv6 DNS transition issues", Alain Durand, 25-JUN-02, This memo summarizes DNS related issues when transitioning a networkto IPv6. Those issues have been discussed in the NGtrans, IPv6,DNSext and DNSop working group. Wherever consensus has been reached,it is presented. When consensus has not yet been reached, a list ofopen issues is presented. "Concepts and Requirements for XML Network Configuration", Margaret Wasserman, 25-JUN-02, This document defines basic concepts and describes the requirementsfor a standard network configuration protocol, which could be usedto manage the configuration of networks and networking equipment.The document also discusses a phased approach to developing an XML-based configuration protocol that could provide tangible benefitsin the short term, while working towards an XML-based configurationprotocol that meets the full requirements. "Internationalized Domain Names in URIs", M. Duerst, 25-JUN-02, This document proposes to upgrade the definition of URIs (RFC 2396)[RFC2396] to work consistently with internationalized domain names. "Binding Generic URIs to SIP URIs", H. Schulzrinne, 25-JUN-02, For many services, it is useful to be able to associate data,represented by URLs, with SIP user identifiers, both address-of-records and host-based user names. This draft proposes a solutionthat addresses most of the requirements for such a mechanism. "Management Event MIB for PacketCable/IPCablecom MTAs", Wim De Ketelaere, Eugene Nechamkin, 25-JUN-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 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 "Private Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Duncan Mills, Miguel Garcia, Eric Henrikson, 07-AUG-02, This document describes a set of private SIP extensions used by the3rd-Generation Partnership Project (3GPP). "Requirements for SIP User Agent Profile Delivery Framework", D. Petrie, C. Jennings, 25-JUN-02, 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", D. Petrie, 25-JUN-02, 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. "Tunnel Interface Metric Determination for Virtual Routers", B. Schliesser, 25-JUN-02, In the Virtual Router (VR) model of Provider Provisioned VPNsmultiple VRs may be connected using tunnels over an existing IPnetwork, such as IPSec or MPLS based tunnels. In the VR modelthese tunnels often run routing protocols such as RIP or OSPF inorder to distribute route reachability information. This memopresents methods for assigning a meaningful metric to these tunnellinks that can be used by such routing protocols. "Internationalizing Domain Names in Applications (IDNA)", D. Crocker, 25-JUN-02, Internationalized Domain Names (IDN) use Unicode fordomain name, rather than using a subset of ASCII. Thisincreased name space, as well the requirement tomaintain compatibility with the existing domain nameservice means that IDNs must be encoded in a form thatcan be supported without changes to any portion of theDNS that does not participate in the upgrade to IDN.This specification defines a mechanism called IDNA forhandling them in a standard fashion and specifies anIDNA profile for domain names used as host references.IDNA allows non-ASCII characters to be represented usingthe same octets used in so-called host names today. Thisrepresentation allows IDNs to be introduced with minimalchanges to the existing DNS infrastructure. IDNA is onlymeant for processing domain names, not free text. "Augmented BNF for Syntax Specifications: ABNF", P. Overell, D. Crocker, 25-JUN-02, Internet technical specifications often need to define aformat syntax and are free to employ whatever notation theirauthors deem useful. Over the years, a modified version ofBackus-Naur Form (BNF), called Augmented BNF (ABNF), hasbeen popular among many Internet specifications. Itbalances compactness and simplicity, with reasonablerepresentational power. In the early days of the Arpanet,each specification contained its own definition of ABNF.This included the email specifications, [RFC733] and then[RFC822] which have come to be the common citations fordefining ABNF. The current document separates out thatdefinition, to permit selective reference. Predictably, italso provides some modifications and enhancements.The differences between standard BNF and ABNF involve namingrules, repetition, alternatives, order-independence, andvalue ranges. Appendix A (Core) supplies rule definitionsand encoding for a core lexical analyzer of the type commonto several Internet specifications. It is provided as aconvenience and is otherwise separate from the meta languagedefined in the body of this document, and separate from itsformal status. "Unified Messaging Support for Diverse Clients", J Wong, G Parsons, 25-JUN-02, This document describes an architecture for unified multimedia messaging -- capable of supporting clients of varying capabilities but based on extending existing IETF Internet Mail standards and infrastructure. "Anonymous SASL Mechanism", Kurt Zeilenga, 25-JUN-02, It is common practice on the Internet to permit anonymous access tovarious services. Traditionally, this has been done with a plain textpassword mechanism using 'anonymous' as the user name and optionaltrace information, such as an email address, as the password. Asplaintext login commands are not permitted in new IETF protocols, anew way to provide anonymous login is needed within the context of theSimple Authentication and Security Layer (SASL) framework. "Securing MIPv6 Binding Updates Using Address Based Keys (ABKs)", James Kempf, Satomi Okazaki, Yiqun Yin, 25-JUN-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. "Packetcable/IPCablecom MIB Framework", Wim De Ketelaere, Sumanth Channabasappa, 26-JUN-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 provides information on the management requirements of PacketCable(TM)/IPCablecom specific devices and defines a framework in which PacketCable MIBs are defined. This document does not precede any previously issued document. It is, however, intended to support and complement the actual Packetcable MIB documents, which are issued separately. "Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable 1.0 compliant devices", Matt Osman, Eugene Nechamkin, 26-JUN-02, This memo is a draft document of the initial version of the document. This document does not have any predecessors. 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 1.0 compliant Media Terminal Adapter (MTA) 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. "TSP-TEREDO: Stateful IPv6 over IPv4 Tunnels with NAT using TSP and TEREDO", Marc Blanchet, Florent Parent, 26-JUN-02, Teredo [3] is a stateless mechanism to encapsulate IPv6 traffic inIPv4 when there is an IPv4 NAT between the tunnel endpoints. Thisdocument enhances Teredo by providing a stateful IPv6 in IPv4connexion which enables additional features to be used, likepermanent IPv6 address or prefixes. It uses the Tunnel SetupProtocol (TSP) [2] to negociate the parameters of the tunnel andidentify the NAT translation map. TSP also enables negociation andestablishment of prefixes, routing, DNS delegation and otherparameters related to the tunnel. "Design Issues for Prepaid Data Service", P. Francis, B. Gleeson, J. Brandt, 26-JUN-02, Prepaid voice services have proven to be extremely successful. There is a desire to replicate this success for data services. Prepaid for data presents new technical challenges, primarily due to the wide range of billing that may be applied to data services---volume or time billing, differential billing by type of application (gaming, steaming, browsing, voice), billing by destination, and even billing of specific content. Furthermore, a single data prepaid service may need to accomodate simultaneous network access by multiple devices (phone, laptop, PDA). This paper discusses design issues for a protocol between a prepaid application and the data network element. It defines an architecture and terminology. It describes basic characteristics of data prepaid service, as well as some advanced features. It analyzes the main technical issues, especially performance issues. Finally, this paper describes the semantics of an illustrative prepaid data service protocol. This document does not, however, specify such a protocol. "Geopriv Service Scenarios", Y. Kohda, M. Mitsuoka, T. Kanai, 26-JUN-02, This document describes location-based service scenarios for Geopriv. It is intended to accelerate a discussion on usage model of privacy and security requirements. "Middle Box discovery integration solutions within the Midcom architecture", C. Aoun, 26-JUN-02, Middle Box discovery is one of the problems that the Midcom architecture has not yet solved. This document compares two Middle box discovery solutions: The decoupled model where the Middle Box discovery is handled by a separate protocol than the MIDCOM protocol vs the combo model were the MIDCOM protocol and the discovery protocol are the same. "Potential solution for authorization token authentication", C. Aoun, 26-JUN-02, This document describe a potential solution that could be used to authenticate authorization tokens used in the context of Middle Box discovery and control. "Extensions to IS-IS and OSPF for Advertising Optinal Router Capabilities", Alfred Lindem, Naiming Shen, R. Aggarwal, Scott Shaffer, 26-JUN-02, It is useful for routers in a IGP domain to know of the capabilities of their IGP neighbors and/or other routers in the domain. This draftproposes extensions to IS-IS and OSPF for advertising optional routercapabilities. We define an optional Router Capability TLV for IS-IS,while for OSPF we define an optional Router Capability Opaque LSA. "SIMPLE Presence Publication Mechanism", Ben Campbell, 26-JUN-02, This document describes an extension to the Session InitiationProtocol (SIP) [1]. The purpose of this extension is to create ameans for publishing event state (notably presence information) aspart of the SIMPLE [4] framework for presence and instant messaging.The method described in this document allows presence information tobe published to a presence agent on behalf of a user. This methodcan be extended to support publication of other event state, but itis not intended to be a general-purpose mechanism for transport ofarbitrary data as there are better suited mechanisms for this purpose(ftp, http, etc.) This method is intended to be a simple, light-weight mechanism that employs SIP in order to support SIMPLEservices. "Sieve -- 'body' extension", Jutta Degener, 26-JUN-02, This document defines a new primitive for the 'sieve' languagethat tests for the occurrence of one or more strings in the bodyof an e-mail message. "Plain SASL Mechanism", Kurt Zeilenga, 26-JUN-02, Clear-text passwords are simple, interoperate with almost all existingoperating system authentication databases, and are useful for a smoothtransition to a more secure password-based authentication mechanism.The drawback is that they are unacceptable for use over an unencryptednetwork connection. This document defines the the SASL PLAINauthentication mechanism, intended to be used with confidentialityprotection provided another layer (e.g. TLS). "Requirements for Manipulation of Data Elements in SIMPLE Systems", J. Rosenberg, M. Isomaki, 26-JUN-02, In an instant messaging and presence application, it is frequentlynecessary for the user to configure a number of pieces ofinformation. Users will need to manipulate their buddy list, addingand 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 set of requirements for such datamanipulations, and provide a framework for viewing them in a commonway. "Bridging and VPLS", Norman Finn, 26-JUN-02, Layer 2 techniques based on IEEE 802.1Q bridges are in widespreaduse by Ethernet MAN Service Providers. It is possible to implementthe data plane functionality of Service Provider Backbone asdescribed in the framework draft [ANDERSSON] using bridges as theProvider Edge (PE) equipment. There are three small butsignificant changes to the [LASSERRE-VKOMPELLA] VPLS draft whichwould make the Service Provider Backbone much more compatible witha bridge-based PE implementation, and which would improve theefficiency of all L2VPN implementations. "Requirements for Presence Service based on 3GPP specifications and wireless environment characteristics", Krisztian Kiss, Gabor Bajko, 26-JUN-02, This Internet-Draft defines requirements for Presence Service based on 3GPP specifications and wireless environment characteristics. The requirements presented in this document are proposed to be evaluated by the SIMPLE Working Group. The result of this evaluation process could help to determine the work expected to be done in IETF and identify the work which might be done in other standardization bodies, such as 3GPP. Thus, a more precise work-share between standardization bodies could be worked out. "Problem Statement for Link-layer Triggers work", Carl Williams, James Kempf, Alper Yegin, 26-JUN-02, Much discussion has resulted over the last few years regardingL2 triggers in wired and wireless scenarios. Recent wireless goals have been to collect requirements from various IETF related working groups for L2 triggers in wireless environments. For example, theMobile IP and SeaMoby working groups require such L2 informationto optimize handoff. It was the hope that the output of such an effort would be used to design an API or protocol if desired. A requirements draft [REQ] discusses requirements from the following FMIPv6, low latency MIPv4, and SeaMoby context transfer work. Discussion over the last several months in the PILC working group raises concerns about a generic L2 trigger framework independent if the it is for wired-line or wireless application. The goal of this document is to provide a clear problem statement of L2 triggers. Discussion has also been documented in this problem statement regarding special needs of the wireless application. For example, the method for communicatingL2 information to L3 may be better suited for the wire-lined case (e.g.,MIB) but not for the wireless scenario. Finally, recommendations on where to go with the L2 trigger area in IETF has been provided. Thisdraft is preliminary. "NSIS resilience analysis", S. Van den Bosch, Maarten Buchli, 26-JUN-02, The Next Steps in Signaling (NSIS) working group is chartered to develop requirements, architecture and protocols for the next IETF steps in signaling Quality-of-Service (QoS). Although the NSIS protocol may eventually be used for other applications in addition to QoS, it is expected that these, in much the same way as QoS, will depend on predictable and high-availability service delivery. This document attempts to identify, list and classify potential resilience issues for the NSIS protocol. "NAT-PT DNS ALG solutions", P. Hallin, S. Satapati, 25-JUL-02, There is an ongoing discussion about the impact of IPv4 to IPv6transition mechanisms such as NAT-PT (RFC2766). [NAT-PT-ISSUES]identifies several problems around the DNS ALG functionality in NAT-PT. This document proposes possible solutions to some of theproblems illustrated in [NAT-PT-ISSUES] and to additional issues withthe DNS ALG functionality in NAT-PT. "Upstream Label Set Support in RSVP-TE extensions", Eiji Oki, 26-JUN-02, This document describes extensions to GMPLS RSVP-TE signaling requiredto support a upstream label set when a bidirectional path is set up. Inthe existing drafts on GMPLS RSVP-TE signaling, a upstream label for theupstream path has to be reserved at an intermediate node before Pathmessage is transmitted to the next-hop node. On the other hand, a labelset that includes one or more labels for the downstream path is carriedby Path message and then Resv message reserves a label at each interme-diate node on the route or a source node. This document proposes theway to support the upstream label set as is the case of the Label Setfor downstream. "RSVP Security Properties", Hannes Tschofenig, 26-JUN-02, 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 further discussions. "Trust Models for Secure IPv6 Neighbor Discovery", Pekka Nikander, 26-JUN-02, This document outlines three different trust models forSecure IPv6 Neighbor Discovery (SEND). The trust models correspondto a trusted company intranet, a public network with a trustedservice provider, and a public network without any trustedparties. "'Categorical enumservices'", Lawrence Conroy, Rudolf Brandner, Richard Stastny, 26-JUN-02, This document defines the set of enumservices describing 'high level'communications categories. These are used as elements within the services field of NAPTR resource records within ENUM domain space. Each category identifies a kind of communications service in which an end user might want to engage using the associated resource. It includes the expected 'low level' service that comes under each category, together with a list of the URI schemes that are appropriate for use with each categorical enumservice. "A Mechanism for Content Indirection in SIP Messages", Sean Olson, 09-AUG-02, This Internet-Draft proposes an extension to the URL MIME External-Body Access-Type as defined in RFC2017 [7] to satisfy the contentindirection requirements defined in draft-ietf-sipping-content-indirect-00 [1]. These extensions are aimed at allowing any MIMEpart in a SIP message to be referred to indirectly via a URL [4]. "Framework for QoS in Provider-Provisioned VPNs", Fabio Chiussi, 26-JUN-02, 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", C. Aoun, Martin Wakley, Tania Sassenberg, 06-AUG-02, 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, Hannes Tschofenig, Cornelia Kappler, 26-JUN-02, RSVP version 1 has been designed for optimally support multicast.However, in reality multicast is being used much less frequently thananticipated. Still, even for unicast (one sender, one receiver)communication, full-fledged multicast-enabled RSVP signaling must beused. As pointed out in the NSIS requirement draft, multicast wouldnot be necessarily required for an NSIS signaling protocol. Thisdraft analyses ingredients of RSVP Version 1 which are affected bymulticast, and derives how these ingredients may look like ifmulticast is not supported. We find removing multicast capabilityfrom RSVP will make it and its extensions considerably more light-weight. "Extended RSVP-TE for Multicast LSP Tunnels", Seisho Yasukawa, 26-JUN-02, Multicast technology will become increasingly important with thedissemination of new applications such as contents delivery servicesand video conferences, which require much more bandwidth and stricterQoS than conventional applications. From the service providers'perspective, traffic engineering (TE) functions will be needed tohandle 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 protocolextensions defined in this document allows service providers to offerunicast and multicast multiprotocol label switching (MPLS) servicesin the same service network.This protocol assumes a variable LSP topology, e.g., point-to-multipoint, multipoint-to-multipoint, topologies. This documentdescribes how to establish point-to-multipoint and multipoint-to-multipoint LSPs as the most basic multicast topology. It defines twoways of constructing a point-to-multipoint LSP: sender-initiated LSPsetup and leaf-initiated LSP setup. Each method has an LSPmodification function in order to adapt to dynamic changes in the LSPtree topology.This MPLS architecture[10] is very flexible and can be expanded tocarry protocols other than IP multicasting, e.g., Ethernet, PPP, andSONET/SDH, but this document only defines IP multicasting (IPv4 andIPv6) as a forwarding equivalence class object (FEC). "Micromobility Problem Statement", Carl Williams, 26-JUN-02, Mobile IP [1] has been developed in the IETF for a number of years already.It's simplicity and scalability give it a growing success within the IETF as several Internet drafts are proposed to extend various improvements for Mobile IP and its counterpart designed for IPv6, Mobile IPv6 [2]. Mobile IP suffers from several well-known weaknesses that have led to the definition of the macro/micro-mobility architecture. Such an architecture implies the division of the mobility architecture into two different parts: mobility management at a large scale, between the different domains (macro-mobility), and, on the other hand, at a local scale, inside these domains (micro-mobility). Each type of mobility is then managed by specific mechanisms and protocols. The macro-micro approach results in many advantages that all micro-mobility protocols will have; thereby effectively addressing weaknesses that plague Mobile IP.This document discusses the micro-mobility problem, and is an attempt toenumerate some of the concepts and approaches defining the micromobilityproblem space. This draft will serve to document the problemspace and definition of micro-mobility for discussion in the IRTFmicro-mobility working group. "Recommended Internet Service Provider Procedures For Emergency Preparedness", F. Baker, SenthilKumar Ayyasamy, 26-JUN-02, The purpose of this document is to express what the engineering community expects of Service providers with respect to emergency preparedness. The document can be considered as a set of recommendations to support mission-critical traffic at various locations like access and core. The goal of the draft is to raise discussion among Internet service providers (ISPs) on the importance of accommodating emergency services across Internet. "Unidirectional link support for MLDv2", Janne Lundberg, 26-JUN-02, This memo specifies an experimental extension to MLDv2 that enables the protocol to operate over unidirectional links. Protection againstDenial of service attacks is provided by a simple cookie mechanism.This extension is intended for mobile hosts which use a unidirectional link technology to receive multicast data and need tofrequently change their unidirectional point of attachment to the network. "Selection of MIPv6 Security Level Using a Hashed Address", Pekka Nikander, Gabriel Montenegro, Jari Arkko, 26-JUN-02, MIPv6 is being defined with a security solution called ReturnRoutability (RR) that does not need any authentication infrastructure.Given that the solution is 'infrastructureless' in this manner, itisn't very easy to control the solution once it is widely deployed. Inparticular, it isn't clear how the solution could be changed to a newsolution, should that ever become necessary. Peers should be able toagree about the use the new solution in a secure manner, without Man-in-the-Middle attackers from being able to mount a Bidding Down attackand downgrade the security back to the original solution. This draftspecifies a simple but secure scheme which allows nodes to choose whatsecurity solution they use. One currently known drawback of thisscheme is that it is based on a technology that has IPR considera­tions. "Next Steps in Signaling: A Framework Proposal", Robert Hancock, 26-JUN-02, The NSIS working group is considering protocol developments in signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in a separate document [2]; This Internet Draft proposes a framework for such signaling. This initial version provides a model for describing the entities that take part in the signaling and the ways in which they can be used in different modes of operation. It also discusses the overall structure of such a signaling protocol. Finally, it considers the possible interactions of NSIS signaling with other protocols and functions, including security issues. "Pseudowires and L2TPv3", W. Mark Townsley, 26-JUN-02, This document provides an overview of the Layer 2 Tunneling Protocol(L2TPv3), presented in a manner which highlights its applicabilityfor Pseudo Wire Emulation Edge to Edge (PWE3). It is intended as aguide for architects, new implementers, and those addingfunctionality to L2TPv3 in support of new pseudowire types. "BGP Tunnel Attribute", Jeremy De Clercq, Geoffrey Cristallo, 26-JUN-02, This document proposes the Tunnel Attribute, which may be used by agiven BGP Speaker to indicate whether it expects to receive all,some, or none of its traffic through a tunnel and the types of tunnelthat may be used. "Requirements for the QoS negotiation at the Application Layer", Matt Holdrege, Suresh Leroy, Juan-Carlos Rojas, 26-JUN-02, This document identifies requirements for an end-to-end negotiationof the Quality of Service (QoS) aspects of each media component of amulti-media session at the application level, before requesting thetransport layer for bearer setup.It is believed that in the future, QoS will be one of the majordifferentiators in the context of a new generation of multi-mediaservices based on the IP technology. As such, QoS cannot beconsidered anymore as a matter of bearer handling only, but it hasalso to include the application layer. Moreover, QoS has to beconsidered as part of the media component description, andtherefore, to be negotiated or re-negotiated during the sessionlife. "TDM Applicability Statement", Y. Stein, Ronen Shashoua, Ron Insler, 26-JUN-02, This document is an applicability statement for emulation of time division multiplexed (TDM) digital voice and data signals over Pseudo Wires. "Securing IPv6 Neighbor Discovery Using Cryptographically Generated Addresses (CGAs)", Pekka Nikander, Jari Arkko, Vesa-Matti Mantyla, 26-JUN-02, IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, tofind routers and to maintain reachability information about the paths to active neighbors. The original ND specifications called for theuse of IPsec for protecting the ND messages. However, in thisparticular application the use of IPsec may not always be feasible,mainly due to difficulties in key management. If not secured, NDprotocol is vulnerable to various attacks. This document specifies a ightweight security solution for ND that does not rely on pre-configuration or trusted third parties. The presented solution uses Cryptographically Generated Addresses. "MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection", J Vasseur, 26-JUN-02, 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. "An Architecture for Layer 3 Virtual Networks", J. Touch, L Eggert, Y. Wang, 26-JUN-02, This document describes an architecture for layer 3 (IP) virtualnetworks. Virtual networks consist of virtual hosts and virtualrouters connected by virtual links (tunnels) just like a realnetwork. The focus of this draft is to extend the current Internetarchitecture to support virtual networks. "SPAN-A - Candidate A for the Pre-Midcom SPAN Protocol", Pete Cordell, 26-JUN-02, SPAN-A (pronounced 'spanner') is a candidate for the pre-midcom SPANprotocol. The scope of SPAN (Simple Protocol for Augmenting NATs) isto enable protocols involving multiple associated sessions to operateacross NATs. Such protocols typically use transport addresses toidentify associated sessions. This works well for environments whereend-to-end addressing is in force, but is broken by the introductionof NATs. SPAN is intended to operate with symmetric NATs by using arelay outside the NAT. It complements STUN [STUN] which operateswith various kinds of cone NAT. "A Framework for PPVPNs management", Thomas Nadeau, Yacine Mghazli, Arnaud Gonguet, 26-JUN-02, This document provides a framework for Provider Provisioned Virtual Private Networks (PPVPNs) management. This framework intends to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN management solution. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this framework document. "SPI Option for Mobile IPv6 Authentication Data Option", C. Perkins, V. Devarapalli, 27-JUN-02, This document specifies a new SPI (Security Parameters Index)option for use with the Binding Authorization Data option. Thenew SPI option allows for selection of a particular mobilitysecurity association to handle the case when several such securityassociations may exist between nodes exchanging messages containinga mobility header requiring authorization. The SPI value may be setduring manual configuration of the security association between twonodes, for example a mobile node and its home agent, or between amobile node and a favored correspondent node. "ISUP<>SIP Gap Analysis for IEPREP", Dennis Berg, 27-JUN-02, This document begins a gap analysis of SIP-ISUP mapping from the perspective of ieprep. Draft-ietf-sipping-isup-02 does not addressmapping/translation for two ISUP IAM parameters of specific interest to ieprep: the mandatory Calling Party's Category and the optionalPrecedence parameters. On the assumption that both of these parametersshould be mapped/translated in SIP-ISUP interworking, this ID beginswith the proposal for a new SIP Resource-Priority header in work inprogress in ieprep. Several variations on the proposed new headerare formulated and assessed for use in mapping/translating the two IAM parameters. The ID concludes that either a single header with namespace differentiation of instances or two distinct headers would meet the needs of ieprep. It is recommended that this choice be made and reflected into draft-ietf-sipping-isup-02. "CE-based Virtual Private LAN", C.Y. Lee, M. Higashiyama, 27-JUN-02, This draft describes how some existing technologies can be leveragedto realize provider provisioned Virtual Private LAN (VPL) service. "Context Aware Management Architecture", Catharina Candolin, Hannu Kari, 27-JUN-02, Most protocols and applications are designed for connections that arefairly static. When a node changes its point of attachment to theInternet frequently, it must be able to rapidly adapt to the newenvironment. Traditionally, each application and protocol tries to dothis independently of each other. In some cases, applications havebeen tailored to communicate with one other protocol layer to noticesuch changes. The main problem with this approach is that adding newprotocols and applications to the node cannot be made in a genericway. In order to obtain at least some level of context awareness,protocols and applications must be specifically tailored tointercommunicate. This also adds complexity to application and protocoldesign, since protocols and applications perform a wide range of tasksfor which they have not originally been designed. To overcome theseproblems, we add a new Context Aware Management (CAM) layer to theInternet Protocol stack. The purpose of CAM is to optimize thefunctionality of the node by monitoring the environment for changesand by adapting the behavior of the node accordingly. The protocolsand applications thus perform the tasks for which they have beendesigned in the first place, and CAM makes the decisions regardingwhich protocols to use and with what parameters. "The use of Multiple Locations in the Location Object", John Morris, 27-JUN-02, This document discusses three major questions that were posed anddiscussed at some length at the interim meeting in San Diego, June2002:(1) Should geopriv facilitate the misrepresentation of locationinformation?(2) Should the geopriv Location Object (LO) accommodate multiplelocations as part of a single positioning transaction?(3) If so, should the Location Object hold multiple locations in asingle object, or should the multiple locations be contained inmultiple objects?In this paper we propose an answer to those questions. "Link Management Protocol Update", Greg Bernstein, Michiel Van Everdingen, 27-JUN-02, Optical networks are being developed to include photonic switches, optical crossconnects, SONET/SDH crossconnects and routers. These networks consist of data links and a logically separated control network. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft proposes an update of the Link Management Protocol LMP. LMP runs between neighboring nodes (regarding data links) and is used to manage TE links. Specifically, LMP can be used to discover and verify the physical connectivity of the data links, correlate the data link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in GMPLS switched networks. "Considerations on Bandwidth Constraints Models for DS-TE", F Le Faucheur, 27-JUN-02, This document provides input for the selection of a default Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering (DS-TE). It discusses a number of considerations on Bandwidth Constraints Models and how the Maximum Allocation Model and the Russian Dolls Model address these considerations. While this document may not exhaustively cover all possible considerations for selection of a Bandwidth Constraints model, we feel it covers the most important considerations for practical DS-TE deployment. We conclude that the Russian Dolls Bandwidth Constraint Model is a good default Bandwidth Constraint Model for DS-TE. "AAA cost advertisement extensions", Jacques Caron, 27-JUN-02, In many roaming scenarios, it is necessary to be able to carry cost information between the different parties in order to facilitate credit checking, real-time accounting, cost presentation to the user. It is also necessary that this information be interpretable by automated systems, that these systems be able to modify it to take commissions into account, and that non-repudiation mechanisms be available. This document proposes such a system to be used with AAA architectures. "Mobile IPv6 VPN using Gateway Home Agent", Katsunori Suzuki, Hiroyiki Ohnishi, Yasushi Takagi, 27-JUN-02, Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. Itcan also be used for public mobility services. One of the mostimportant services is the VPN service enabling users to access theirIntranets from outside. Mobile IP does notwork well with VPN,however, and this issue is being discussed in the Mobile IP WG [VPNproblem]. This document proposes a simple mechanism that combinesVPN and Mobile IP functions. This mechanism uses a hierarchical HAarchitecture and includes an HA with GW functions, called a GatewayHome Agent (GHA). "Operational Environments and Transition Scenarios for 'Connecting IPv6 Islands across IPv4 Clouds with BGP'", F Le Faucheur, 27-JUN-02, This document describes the common operational environments of IPv4 Service Providers wanting to add IPv6 services to their service portfolio but not wanting (yet) to upgrade their IPv4 backbone to IPv6 routing. Two main transition scenarios are identified. We recommend that the 'MP-BGP over IPv6' and 'MP-BGP over IPv4' approaches defined in [BGP-TUNNEL] be respectively used for each of the two transition scenarios. "On path and off path signaling for NSIS", Olov Schelen, Alban Couturier, 27-JUN-02, The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches about thesignaling model have been discussed: on-path and off-path. This draft provides a conceptual comparison between on-path and off-path 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 Protocol for Anycast Address Resolving", Masayuki Murata, Hiroshi Kitamura, Shingo Ata, 27-JUN-02, This document describes a mechanism to realize anycast communicationwithout any modifications of applications and/or underlyingprotocols.The mechanism, using a DLL (Dynamic Linkable Library) based approach,is called AARP (Anycast Address Resolving Protocol), which resolvesthe anycast address into the corresponding unicast address prior toestablishing the communication.AARP smoothly supports anycasting without change of existingapplications. "A Formal Notation for Header Compression", R. Price, M. West, A. Surtees, 27-JUN-02, This draft defines a BNF-based notation for describing the behaviorof protocol stacks with respect to compressing the protocol headers.The RObust Header Compression ROHC [1] scheme is designed to compresspacket headers over error prone channels. It is built around anextensible core framework that can be tailored to compress newprotocol stacks by adding additional ROHC profiles.The aim of the notation is to simplify the creation of new ROHC [1]profiles. "A Lower Effort Per-Domain Behavior for Differentiated Services", Roland Bless, 27-JUN-02, This document proposes a differentiated services per-domain behavior(PDB) whose traffic may be 'starved' (although starvation is notstrictly required) in a properly functioning network. This is incontrast to the Internet's 'best-effort' or 'normal Internet traffic'model. In this sense this PDB's traffic is forwarded with a 'lower'priority than the normal 'best-effort' Internet traffic, thus the PDBis called 'Lower Effort' (LE). Use of this PDB allows to strictlylimit the effect of its traffic on 'best-effort'/'normal' or all otherInternet traffic. This document gives some example uses, but does notpropose constraining the PDB's use to any particular type of traffic. "A Requirement of the Network State Information Database for Traffic Engineering Over GMPLS", D. Kim, 27-JUN-02, This document presents a set of requirements of the Network State Information Database (NSID) for Traffic Engineering over Generalized Multiprotocol Label Switching (GMPLS). 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 resource. 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", M. Riegel, 25-JUL-02, Intellectual Property Rights (IPR), in particular patents areimportant for standards development organizations (SDOs). A patentgrants a monopoly to the owner to control the usage of the coveredtechnology. If such a technology is becoming part of a standard thepatent 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 patentrights in its standards. The proposal is based on the idea of openstandards and is fully aligned to the current IPR rules of the IETF.The intention is to retain the mind of the IETF while enabling theconsideration of IPR covered proposals in a defined way. "Bandwidth Constraint Models for Diffserv-aware MPLS Traffic Engineering", Wai Lai, 27-JUN-02, This document is intended to complement the Diffserv-aware MPLS TE Requirements document by describing the implications of some of the criteria for selecting a default bandwidth constraint model. Properties of candidate models are also presented to provide guidance to the corresponding Solution document for this selection. Contributions are welcome. Please send comments to the mailing list te-wg@ops.ietf.org "IMSX Protocol Evaluation for Session Based IM", M. Barnes, 27-JUN-02, This document is submitted to the SIMPLE WG as part of the ongoing discussion on the selection of the protocol for support of Session Based Instant Messaging. It evaluates the suitability of the IMSX protocol as a transport for Session Based IM. IMSX defines a BEEP profile for exchanging CPIM messages after SIP has performed its session setup signaling. This document evaluates IMSX against the IMPP requirements and its ability to interoperate with other IM systems based upon the CPIM profile. "SCTP Layer for Transporting Signaling Protocols", J. Loughney, Raquel Sanchez, 27-JUN-02, The Stream Control Transport Protocol (SCTP) has been standardized to provide a reliable transport services for signaling protocols. SCTP features a number of new features that are useful for transporting signaling protocols, but may require additional information on how to use them to transport existing signaling protocols. "HMAC SHA TSIG Algorithm Identifiers", Donald Eastlake 3rd, 27-JUN-02, Currently only the HMAC-MD5 and GSS TSIG Algorithm identifiers arespecified. This document specifies identifiers for additional HMACSHA TSIG algorithms. "Securing IPv6 Neighbor Discovery", Gabriel Montenegro, 27-JUN-02, The known security vulnerabilities in Neighbor Discovery have notbeen properly dealt with. This note suggests some techniques basedon cryptographically generated addresses and probes that may beapplied even in the absence of a pre-established securityrelationship between the parties involved. "SigComp User Guide", R. Price, M. West, A. Surtees, 27-JUN-02, 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. "Consideration of RSVP-TE Extension for Metro Network", J Choi, Younghun Yoo, 27-JUN-02, This draft mentions the bandwidth reservation in Metro Network. At first, this lists the issues that should be generally checked for bandwidth reservation, and is intended to point out RSVP-TE for Metro Network. Moreover, this focuses on consideration issues to understand whether the existing RSVP-TE supports the demands for bandwidth reservation in Metro Network. "MIME Type Registration for MPEG-4", D. Singer, Y. Lim, 27-JUN-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, 27-JUN-02, This document provides an overview of network measurements andmonitoring from the perspective of Sprint Advanced Technology Labs.It starts with a detailed discussion of the benefits of monitoringfor an ISP's backbone and the type of measurements required forvarious tasks. It describes the tools and techniques currently inuse, and then outlines what else is needed to meet the challenges ofmonitoring an operational network. "Discovering Nodes and Services in a VPLS Network", Olen Stokes, 27-JUN-02, This document describes a methodology for allowing the nodes in aVirtual Private LAN Service (VPLS) network as described in [VPLS]to discover each other via MPLS signaling. It also defines amethodology whereby the individual VPLS services are discovered viaMPLS signaling. The goal is to allow a VPLS network to be createdusing MPLS signaling and a minimal amount of configuration. "SIP Event Notification for Metadata Update Protocol", H. Schulzrinne, Yuji Nomura, 27-JUN-02, This document specifies an update notification protocol for metadatausing SIP event notification. This protocol improves metadatacoherency and efficiency between content providers and receivers byup-to-date notifications when metadata changes. This protocol canalso be applied to several systems such as a streaming videodistribution system and a web content ditsribution system. "Unicast Routing based Multicast Routing Protocol for Mobile Ad Hoc Networks (UMR)", Jung-Soo Park, Jae-Hoon Jeong, 27-JUN-02, This document describes a protocol for multicast in mobile ad-hocnetworks - named Unicast Routing based Multicast Routing Protocolfor Mobile Ad Hoc Networks (UMR). The protocol uses a new schemefor mobile ad-hoc network that has dynamic topology withoutmanaging multicast tree and depending on simple flooding. It is themulticast routing protocol that works in use of unicast routingprotocol. Any ad-hoc unicast routing protocol can be used. "Quick-Start for TCP and IP", Sally Floyd, Amit Jain, 28-AUG-02, This draft outlines an optional Quick-Start mechanism for transportprotocols to determine an optional allowed initial congestion windowor initial sending rate at the start of a data transfer. Thismechanism 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 itsdesired initial sending rate in packets per second in a Quick StartRequest option in the IP header of the initial TCP SYN or SYN/ACKpacket. Each router in turn could either approve the specifiedinitial rate, reduce the specified initial rate, or indicate thatnothing above the default initial rate for that protocol would beallowed. The Quick-Start mechanism also can determine if there arerouters along the path that do not understand the Quick Start Requestoption, or have not agreed to the initial rate described in theoption. If all of the routers along the path have agreed to theinitial rate in the Quick-Start Request, then TCP host B communicatesthis to TCP host A in a transport-level Quick-Start Response in theanswering SYN/ACK or ACK packet. Quick-Start is designed to allowTCP connections to use high initial windows in circumstances whenthere is significant unused bandwidth along the path, and all of therouters along the path support the Quick-Start Request. We note thatthis is currently not a mature proposal, but an outline of onepossible path of development in the IP protocol, and a request forfeedback from the community. "F-RTO: A TCP RTO Recovery Algorithm for Avoiding Unnecessary Retransmissions", Markku Kojo, Pasi Sarolahti, 27-JUN-02, Spurious retransmission timeouts (RTOs) cause suboptimal TCPperformance, because they often result in unnecessary retransmissionof the last window of data. This document describes the 'Forward RTORecovery' (F-RTO) algorithm for recovering from the TCP RTOsefficiently even when the RTO was spurious. F-RTO is a TCP senderonly algorithm that does not require any TCP options to operate.After retransmitting the first unacknowledged segment triggered by anRTO, the F-RTO algorithm at a TCP sender monitors the incomingacknowledgements to determine whether the timeout was spurious and todecide whether to send new segments or retransmit unacknowledgedsegments. The algorithm effectively avoids additional unnecessaryretransmissions and thereby improves TCP performance in case of aspurious timeout. "QoS Signaling Framework for Mobile IP", Hemant Chaskar, Cedric Westphal, 27-JUN-02, This draft provides a framework for QoS signaling that is optimizedfor Mobile IP handoffs. It covers the horizontal signaling betweenaccess routers (ARs) as well as the vertical signaling along thepacket data path, both of which are triggered by handoff of mobilenode (MN). The key design goals are wireless bandwidth economy,fast QoS establishment along the new data path after handoff andsecure protocol operation. "Internationalized Domain Name Transition (IDNX)", Edmon Chung, David Leung, 27-JUN-02, This document describes a strategy for domain name server operators to prepare and transition their services for multilingual domain names (IDN – Internationalized Domain Names). The IDNX approach accepts that users with non-IDN aware applications will be attempting to access multilingual domain names. Hence it is the registry or domain operator's responsibility to provide an IDN solution that resolves these issues to make it a seamless transition experience for technically unsophisticated users. In essence, the IDNX approach embraces a complementary server-side implementation to smooth the transition. IDNX compliant domain servers will successfully resolve IDN requests sent via non-IDN aware applications, whether they are formatted in local encoding, UTF-8 or an identifiable variant. The IDNX approach also utilizes a dynamic CNAME mechanism to provision for the sub-delegation of multilingual domain names to hosts running non-IDN aware DNS servers. "Middlebox Signaling in a NSIS framework", Marcus Brunner, Martin Stiemerling, 27-JUN-02, The Next Steps in Signaling (NSIS) working group has started looking into signaling for QoS in various cases. In this draft, we show the similarities and differences of signaling for QoS versus signaling for NAT and firewall traversal. It seams that there are quite a number of similarities, which might make sense to use a potential NSIS protocol for NAT and firewall traversal as well. "Usage Scenarios for Speech Service Control (SPEECHSC)", Stéphane Maes, Andrzej Sakrajda, 28-JUN-02, This document proposes usage scenarios for SPEECHSC. "Speech Engine Remote Control Protocols by treating Speech Engines and Audio Sub-systems as Web Services", Stéphane Maes, Andrzej Sakrajda, 28-JUN-02, This document proposes the use of the web service framework based on XML protocols to implement speech engine remote control protocols (SERCP).This document is informational. It illustrates how web services could be used. It is not a detailed specification. This is expectedto be the output of the SPEECHSC activity, if it is decided to go in this direction. It also enumerates the requirements that have led to selecting a web service framework.Speech engines (speech recognition, speaker, recognition, speech synthesis, recorders and playback, NL parsers, and any other speechprocessing engines (e.g. speech detection, barge-in detection etc) etc...) as well as audio sub-systems (audio input and output sub-systems) can be considered as web services that can be described and asynchronously programmed via WSDL (on top of SOAP), combined in a flow described via WSFL, discovered via UDDI and asynchronously controlled and via SOAP that also enables asynchronous exchanges between the engines.This solution presents the advantage to provide flexibility, scalability and extensibility while reusing an existing framework that fits the evolution of the web: web services and XML protocols [15].This document proposes using web services as a framework for SERCP.The proposed framework enables speech applications to control remote speech engines using the standardized mechanism of web services. The control messages may be tuned to the controlled speech engines. "General Summary of Interoperability Testing Results and Experiences", B. Jensen, 28-JUN-02, This document describes certain issues observed during a recent largeMPLS Interoperability Test Event conducted by the InteroperabilityWork Group of the MPLS Forum. The aim of this document is to make thevendor and service provider community aware of these issues. Certainrecommendations have also been provided in the document in theexpectation that a discussion will ensue to get these issuesresolved. "MIB Table Modifications Tracking MIB", Niraj Gopal, 28-JUN-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 themodifications in MIB tables on a system. "Route Optimization Support for Localized Mobility Management Based on IPv6", Youn-Hee Han, 02-JUL-02, Using localized mobility management based on IPv6, all packetsdestined to a mobile node are routed through the local mobilityagent in the mobile node's local mobility domain, which thentunnels the packets to the mobile node's current location. Suchpacket routing mechanism is similar to the triangle routing inMobile IPv4, which may leave the local mobility agent overloadedand take a longer route thus increasing the network traffic in thelocal mobility domain. This document specifies a route optimizationscheme for localized mobility management based on IPv6 with thehelp of L2 trigger. Using this, correspondent nodes can cache LCoAof a mobile node if it is actively communicating with the mobilenode, and then send their packets for the mobile node directly tothe LCoA, bypassing the local mobility agent. This routeoptimization scheme will result in more efficient localizedmobility management. It alleviates the local mobility agent's loadsand takes the nearly same handoff delay time as the one inlocalized mobility management based on IPv6. "An interconnection mechanism of Mobile IPv4 and Mobile IPv6 using 6to4", Hyun-Kook Kahng, 02-JUL-02, This document specifies a new mechanism using 6to4 to solve mobility problems in IPv4 and IPv6 interconnected networks. This draft is based on the Architecture of Hierarchical Dual Stack Mobility Agent(HDSMA) that supports the IP version-independent mobility of mobile node and improves the registration efficiency and the performance[3]. The aim is to support 6to4 mechanism for IPv6 transition while mobile node only uses mobile IPv6 capability for mobility services. "Domain Name Data-Types", Eric Hall, 02-JUL-02, This document defines syntax and structural rules for a namespace of internationalized domain names, and also clarifies the syntax and structural rules for the existing DNS namespace. Furthermore, this document defines syntax and structural rules for specific types of labels and domain names, and also defines usage rules for specific resource records within the domain name system. This document specifically does not describe any mechanisms for interacting with these namespaces, domain names or resource records, but instead focuses exclusively on the syntax and structural rules. "Intellectual Property Rights in IETF Technology", S. Bradner, 05-JUL-02, The IETF policies about intellectual property rights (IPR), such aspatent rights, claimed relative to technologies developed in the IETFare designed to ensure that IETF working groups and participants haveas complete information about any IPR constraints on a technicalproposal as possible. The policies are also intended to benefit theInternet community and the public at large, while respecting thelegitimate rights of IPR holders. This memo details the IETFpolicies concerning IPR related to technology worked on within theIETF. It also describes the objectives that the policies are designedto meet. "Configuring BGP to Block Denial-of-Service Attacks", Doughan Turk, 29-AUG-02, This document describes a technique that uses BGP communities toremotely trigger black holing of a particular destination network.Black holing can be applied on a selection of routers rather than allBGP speaking routers in the network. The document also describes asinkhole tunnel technique using BGP communities and Tunnels to pulltraffic into a sinkhole router for analysis. "Network Control Signaling (NCS) Signaling MIB for PacketCable/IPCablecom MTAs", Charles Schell, 08-JUL-02, 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. "URI Fragment Identifiers for the text/plain Media Type", Erik Wilde, 09-AUG-02, This memo defines URI fragment identifiers for text/plain resources.These fragment identifiers make it possible to refer to parts of atext resource, identified by character count or range, line count orrange, or a regular expression. These identification methods can becombined to identify more than one sub-resource of a text/plainresource. "Definitions of Managed Objects for PPP Multilink Bundles", S. Carthic, 22-JUL-02, PPP Multilink Protocol provides a means to aggregate multiplephysical links, providing a 'bundle', with greater bandwidth thanany of the constituent members. This memo defines SMIv2 ManagementInformation Base(MIB) for management of PPP Multilink Bundles. "Virtual Private LAN Service (VPLS) Management Information Base Using SMIv2", P Elangovan, 22-JUL-02, A Virtual Private LAN Service (VPLS) is defined as a service over aprovider managed IP or MPLS network which emulates a virtual privateLAN segment. All customer sites in the VPLS appear to be on the sameLAN regardless of their location.This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in TCP/IP based internets.In particular, it defines objects for managing networks using VirtualPrivate Lan Service (VPLS). "Mobile IP considerations for Inter-technology handovers", S. Jamadagni, D. Satish, 22-JUL-02, Multi mode terminals are becoming pervasive. In a multi mode environment, Mobile Terminals (MTs) move from the coverage of one radio access network to another. There is a need to maintain ongoing network sessions to support seamless services. For example, a MT may roam between a 3G cellular network and a wireless LAN seamlessly with session continuity. It is possible for a single service provider to support multiple modes but it is expected that different modes will be supported by different service providers. For example WLAN support can be enterprise supported where as 3G services are supported by a wide area service provider. In this draft we discuss handover support between multiple domains (modes) where a MT can use different IP addresses or can use a global IP address. Handover between different modes will then require greater federation capabilities between the different IP domains. In this draft we discuss Home Agent federation capabilities over Mobile IP so that inter-technology, inter-domain handovers are better supported. "Extending Mobile IPv4 for Multi-mode Terminals", Shiva Pandey, 23-JUL-02, Mobile IP[1] has emerged as a preferred solution for the macro mobilityproblem. In this draft, we discuss a possible extension to the existingMobile IPv4 for multi-mode wireless terminals. This extension is basedon [2] and has several advantages, including lesser packet delay,reduced traffic load on the home agent and lesser packet loss duringhandoff. In addition. This also allows the mobile node to take fulladvantage of Layer-2 specific features provided by the network. Theproposal in this draft is in its initial stage and needs to be furtherstudied. "Mobility Extensions to RSVP in an RSVP-Mobile IPv6 Framework", Charles Shen, 23-JUL-02, This memo first gives a brief review of a RSVP and Mobile IPv6interoperation framework proposed in [1] and compared its featureswith the Performance Requirements set forth by Requirements of a QoSSolution for Mobile IP [2]. The subsequent part of the memo presentsspecification details including message formats, processing rules andalgorithms that form the framework. The vast majority of thesespecifications has been verified by a prototype implementation. It isexpected that this work could serve as a useful input in dealing withNSIS protocol and mobility issue. "Several Framework Issues Regarding NSIS and Mobility", Charles Shen, 23-JUL-02, This memo discusses several framework issues related to Next Step InSignaling (NSIS) and mobility interaction. The first issue is relatedto handoff impact on NSIS operation. We present several generalrequirements for NSIS and mobility, followed by evaluation of howspecific approaches using Mobile IP or other mechanisms might fitinto the picture. Other issues covered include NSIS and mobilitysignaling layering and soft-state management. "SIEVE spamtest and virustest Extensions", Cyrus Daboo, 23-JUL-02, The SIEVE [SIEVE] 'spamtest' and 'virustest' extensions permit usersto use simple, portable commands for spam and virus tests on emailmessages. Each extension provides a new test with simple semantics.It is the responsibility of the underlying SIEVE implementation todo the actual checks that result in values returned by the tests. "Mobile IPv4 coexistence with IPsec remote access tunnelling", S. Vaarala, Antti Nuopponen, 23-JUL-02, This document describes a simple method that allows a mobile node touse a home agent situated inside a protected intranet, while alsoallowing the mobile to roam between the public internet and theintranet without losing active sessions. Whenever the mobile isoutside the intranet, it connects to the intranet using an IPsectunnel and registers the IPsec-assigned inner tunnel address as itsco-located care-of address to the internal home agent. If desired,handover performance while outside the intranet can be enhanced byemploying another Mobile IP layer underneath IPsec. The solutiondoes not require any new protocols, only a profile for using existingprotocols. Only the mobile node needs to be modified in order to usethis profile. "The 'MFxx' Command Extensions for FTP", David Somers, 23-JUL-02, This document defines extensions to the FTP specification STD9,RFC959, 'FILE TRANSFER PROTOCOL (FTP)'. These extensions provide theability for a FTP Client to modify the last modification time, thecreation time, or multiple facts (last modification time, creationtime, operating system permissions, etc.) of a file in the server-FTPprocess NVFS. These extensions are implemented by three new optionalcommands: 'MFMT' (Modify File Modification Time), 'MFCT' (Modify FileCreation Time), and 'MFF' (Modify File Facts). "Responding to Fast Timeouts in TCP", Reiner Ludwig, 24-JUL-02, A 'fast timeout' occurs if the retransmission timer expires, andafterwards the TCP sender receives the duplicate ACK that would havetriggered a fast retransmit of the oldest outstanding segment. Inthis case, staying in slow start is an unnecessarily drastic responseto the congestion indication. Instead, we believe it is safe to backout of the slow start phase but instead go into the fast recoveryphase. One benefit of this approach is that the potentially followingduplicate ACKs can be exploited for advanced loss recoveryalgorithms. "Bi-directional LSPs for classical MPLS", Rohit Dube, Michele Costa, 24-JUL-02, This memo proposes extensions to support bi-directional LSPs forclassical MPLS. Specifically RSVP-TE is extended with objects similar to those in GMPLS to allow establishment of bi-directional LSPs for MPLS networks. "IFAX service of ENUM", K. Toyoda, 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. "An Extension to the Session Initiation protocol to Assure Congestion Safety", Dean Willis, Ben Campbell, 24-JUL-02, The Session Initiation Protocol allows the use of UDP for transportof SIP messages. The use of UDP inherently risks network congestionproblems, as UDP itself does not define congestion prevention,avoidance, detection, or correction mechanisms. This problem isaggravated by large SIP messages which fragment at the UDP level.Transport protocols in SIP are also negotiated on a per-hop basis, atthe SIP level, so SIP proxies may convert from TCP to UDP and soforth. This document defines what it means for SIP nodes to becongestion safe and specifies an extension by which a SIP User Agentmay require that its requests are treated in a congestion safemanner. "MIPv6 for Multiple Interfaces", Mohammed Kassi-Lahlou, Thomas Noel, Nicolas Montavont, 24-JUL-02, MIPv6 [MIPv6] allows a MN to maintain its IPv6 communicationswhile moving between subnets. This document presents theproblematic for a MN of having multiple network interfaces. Itdiscusses how to perform vertical handovers (flow redirectionbetween interfaces) and propose MMI (MIPv6 for MultipleInterfaces) which describes the use of MIPv6 to support multipleinterfaces. These extensions focus on the MN ability to use abackup interface for communications and to redirect flows betweenits own interfaces. "On the Difference between Information Models and Data Models", A. Pras, J. Schoenwaelder, 10-SEP-02, There has been ongoing confusion about the differences betweenInformation Models and Data Models. This document explains thedifferences between these terms by analyzing how existing networkmanagement model specifications (from the IETF and other bodies suchas the ITU or the DMTF) fit into the universe of Information Modelsand Data Models.This memo documents the main results of the 8th workshop of theNetwork Management Research Group (NMRG) of the Internet ResearchTask Force (IRTF). "Mobility Management and IP Multicast", Alan O''Neill, 25-JUL-02, Mobile IP provides a mobile node, that visits a foreign subnet, the ability to continue to use an address from its home subnet (the home address) as a source address. This is achieved through the allocation of a Care of Address on the foreign subnet that is used as the end-point of a redirection tunnel from a home agent on the home subnet. Mobile IP in RFC 3220 states that when the mobile node originates multicast traffic intended for the foreign multicast system, it can only do so by first obtaining an IP address from the foreign subnet (a Collocated Care of Address) and then using this address as the multicast source address. This is to ensure that the source address will pass multicast routing reverse path forwarding checks.This foreign multicast model is however extremely restrictive, and still very problematic to multicast routing and applications when the mobile node regularly changes foreign subnets, as is common in wireless systems. This is because the source address continues to evolve which must be tracked by source specific multicast application and routing signalling. Using the home multicast system, again described above, is also non-optimal because the mobile node receiver is then serviced by packets that must be tunnelled from its home agent which, removes any multicast routing benefits (ie network based tree building). This draft therefore describes modifications to the foreign multicast interface between mobile IP and multicast routing that enable the mobile node to use its persistent home address as a multicast source address. "A Transport Layer Technology for Improving QoS of Networked Multimedia Applications", Vijay Madisetti, Antonios Argyriou, 25-JUL-02, Voice & Video over Internet have strict QoS requirements. Generally, lowjitter, low delay and high bandwidth are the critical requirements for this class of applications. However, achieving this goal is difficult, more so in a wireless/internet environment, where the both networking & communication channel conditions are dynamically changing over time. In this document, we propose a novel transport layer protocol that attempts to provide better QoS for multimedia applications. The purpose of the proposed technology is to act additively to existing QoS solutions at the lower protocol layers through enhancements to the SCTP protocol. "End-by-Hop Transmission Protocol", Alexander Bogdanov, 25-JUL-02, End-by-Hop Transmission Protocol (EHTP) is the connection-orientedtransport service for the reliable or unreliable delivery of datapackets with possible violation of a sequence. It has the ownaddress space compatible with Unified Memory Space Protocol (UMSP,RFC3018 [5]). EHTP includes the gateway protocol, which supportslabels and dynamic resources deallocating. Networks with non-overlapping or incompatible addresses space may be united at EHTPlayer with end-to-end interaction and with preservation of atransparency. "Congestion safety and Content Indirection", Hisham Khartabil, 25-JUL-02, The Session Initiation Protocol allows the use of UDP for transport of SIP messages. Baseline SIP does not allow congestion control for messages larger than MTU of a certain link nor does it allow end points to specify their maximum acceptable message size, regardless of the underlying transport protocol. This document combines two, namely 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. "BGP Extended Communities Attribute - Implementation Survey", Y. Rekhter, 29-JUL-02, This document provides a survey of BGP-4 Extended Communitiesimplementations. "GMPLS Signaling Applicability Statement", Daniel Awduche, A. Farrel, 26-JUL-02, This memo describes the applicability of GMPLS signaling to IP overOptical (IPO) networks. The underlying premise behind GMPLSsignaling for IPO networks is discussed and pertinent limitationsare highlighted. Throughout this discussion, GMPLS-RSVP (RSVP-TEwith GMPLS extensions) will be used to exemplify the class ofprotocols under consideration. This memo also describes the subsetsof GMPLS signaling message exchanges that are needed to supportconnection management between optical switches, and between IP/MPLSrouters and optical switches in IP over Optical networks. "BGRPP: Performance evaluation of the proposed Quiet Grafting mechanisms", Eugenia Nikolouzou, 26-JUL-02, End-to-end provisioning of quality of service guarantees is nowadays oneof the most basic and crucial issues. Towards this end, the inter-domain resource control architecture for DiffServ networks described in [1],tries to address this issue by applying a scalable and efficient signaling approach. Based on this architecture, this paper tries to provide an analysis and a performance study of the introduced quiet grafting mechanisms. "A Proposal for ICMP 'Authentication Required' Messages", S. Ostermann, A. Lakhiani, 29-JUL-02, The current ICMP 'Destination Unreachable - CommunicationAdministratively Prohibited' message conveys one bit of information:the gateway is administratively filtering your packets. This memoproposes the addition of an ICMP 'Authentication Required' responseto provide the more specific message that packets are beingadministratively prohibited until successful authentication. "Counter with CBC-MAC (CCM)", R. Housley, N. Ferguson, D. Whiting, 30-JUL-02, Counter with CBC-MAC (CCM) is a generic authenticated encryption blockcipher mode. CCM is defined for use with 128-bit block ciphers, suchas AES. "Architecture, Model and Requirements for Operations and Maintenance (Testability) of Virtual Private Networks AND Application Level VPN Testability Solution", Tissa Senevirathne, 12-AUG-02, In this document we present, Architecture, Model and Requirementsfor Operation and Maintenance of Virtual Private Networks (VPN).Operation and Maintenance of VPN is divided in to Application LevelVPN testability, Tunnel Level VPN testability and Tunnel specificVPN testability. Also, presented in this document is a solution forApplication level VPN Operation and Maintenance (Testability). "Uniform Treatment of Pending Action Notification in EPPA Strawman Proposal", Hong Liu, 30-JUL-02, Many domain registries, especially sponsored TLDs and ccTLDs, havespecific policy that calls for the server to perform additionalbackend processing before it completes a transform operation on anobject requested by a client. When the pending action is completed,the server must notify the client about the outcome. However, currentEPP core specifications do not address the notification messaging ina generic way. As a result, a registry has to resort to defining anew schema as extension to the object mapping concerned for thispurpose.Inspired by recent discussions on the 'ietf-provreg' mailing list onrelated topics, this draft presents a strawman proposal for uniformtreatment of server notification for pending action in the base EPPprotocol. A new OPTIONAL child element is added to response asbasic notification content, which consists of the transaction ID thattriggered the pending action and the outcome of the pending action.In addition, object specific data and extension information can bepiggybacked in existing child elements of . The requiredmodification to the EPP base protocol is kept to the minimum andincurs no change to the EPP base object mappings. Most importantly,the proposed solution is applicable to any object mapping, ensuringEPP's extensibility beyond domain registry applications.Strong interests by the registry community in deploying this featurewarrant that it be best handled as a generic but optional feature inthe EPP base protocol. This allows any registry to handle pendingaction without the need to define a new schema, eliminating theproliferation of ad hoc object extensions repetitively defined bydisparate registries for the very same purpose. "Guidelines for MPLS Load Balancing", David Allan, 31-JUL-02, RFC 3031 permits MPLS load balancing while making no specificrepresentations as to requirements of implementation. This hassubsequently become an issue with respect to the reliability of pathtest mechanisms. Load balancing algorthms may separate path testprobes from the path of interest. This I-D proposes guidelines forimplementation of load balancing such that path test mechanisms arenot impacted. "WVCM: The Workspace Versioning and Configuration Management API", Geoffrey Clemm, 01-AUG-02, This document specifies the classes and interfaces that define the Workspace Versioning and Configuration Management API. The WVCM API will minimize the complexity of clients that are capable of interoperating with a variety of versioning repositories. The WVCM API includes: workspace management, version history management, baseline management, activity management, and namespace versioning. "RTP payload format for a 64 kbit/s voice band data call", Ruediger Kreuter, 01-AUG-02, This document describes how to carry 64 kbit/s data streams transparently in RTP packets, using a pseudo-codec called 'CLEARMODE'. It also serves as registration for a related MIME type called 'audio/CLEARMODE'. "In-Line Network Management Prediction", S. Bush, N. Smith, A. Kulkarni, 01-AUG-02, In-line network management prediction exploits fine-grained models ofnetwork components, injected into the communication network, toenhance network performance. Accurate and fast prediction of localnetwork state enables more intelligent network control resulting ingreater performance and fault tolerance. Accurate and fastprediction requires algorithmic capability. Active and ProgrammableNetworking have enabled algorithmic information to be dynamicallyinjected into the network allowing enhanced capability andflexibility. One of the new capabilities is enhanced networkmanagement via in-line management code, that is, managementalgorithms embedded within intermediate network devices. In-linenetwork management prediction utilizes low-level algorithmictransport capability to implement low-overhead predictive management.A secondary purpose of this document is to provide generalinteroperability information for the injection of general purposealgorithmic information into network devices. This document may helpin some manner to serve as a temporary bridge between InternetProtocol and Active and Programmable Network applications. Thismay stimulate some thought as to the content and format of'standards' information potentially required for Active Networking.Management of the Internet Protocol and Active and ProgrammableNetworking is vital. In particular, coexistence and interoperabilityof active networking and Internet Protocol management is specifiedin order to implement the injection of algorithmic information into anetwork. "The Unified RFC Protocol", Thomas Hruska, 02-AUG-02, The goal of this Draft is to define a single protocol that envelopsall RFCs of the past, present, and future. This document describescommunication across the Unified RFC Protocol, preserving ancientprotocols, and a framework for new protocols. "OpenPGP data in the CERT RR", S. Josefsson, 05-AUG-02, This draft describes the decisions made in one pair of applications[4][5] that respectively serves and retrieve OpenPGP [3] Certificatesand Revocation Signatures using the CERT Resources Record [2]. Theintent is to provide a discussion on the kind of general updatesneeded to the CERT specification, and some suggested specific updatesfor the OpenPGP sub-type. It is offered in the hope that thisspecification, together with similar efforts for other applications,can be reviewed when designing a generic solution or guidelines forstoring application keying material in the Domain Name System (DNS),should it ever happen. "LDP and RSVP Extensions for Optical UNI Signaling", B. Rajagopalan, 12-AUG-02, The Optical Interworking Forum (OIF) has defined extensions to theLabel Distribution Protocol (LDP) and the Resource reServationProtocol (RSVP) for optical User Network Interface (UNI) signaling.These extensions consist of a set of new messages and data objects.This draft describes these extensions. "IANA Charset MIB", I. McDonald, 06-AUG-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 single textual convention 'CodedCharSet' that may be used to specify charset labels in MIB objects, forexample 'prtLocalizationCharacterSet' in Printer MIB v2 (RFC nnnn). 'CodedCharSet' was originally defined in Printer MIB v1 (RFC 1759). "Host Extensions to Protocol Independent Multicast", R. Perlman, K. Patel, 06-AUG-02, This document defines host extensions to Protocol Independent Multicast - PIM protocol. These host extensions allows endnodes to join/leave any multicast (S/*,G) groups. This helps in easingSSM-style multicast deployment that does not have to depend on IGMP (v1/v2/v3), in either endnodes or the routers. "Internationalized String Matching Rules for X.500", Kurt Zeilenga, 09-SEP-02, The existing X.500 Directory Service technical specifications do notprecisely define how string matching is to be performed. This haslead to a number of interoperability problems. This document providesstring preparation profiles for standard syntaxes and matching rulesdefined in X.520. "Generalized MPLS Recovery Functional Specification", B. Rajagopalan, J. Lang, 07-AUG-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. "Fault Tolerance and Load Balance Services using IPv6 Anycast", K Ettikan, 07-AUG-02, This document describes how fault tolerant anycast service can be achieved using IPv6 anycast service. Communication between an anycast client and an anycast server is required as indicated in [ANALYSIS]. While, proposed host based anycast MLD [HOSTANY] or other anycast group address management scheme is in place for this fault tolerant anycast service to take place. "Using International Standard Text Work Codes as Uniform Resource Names", Juna Hakala, 07-AUG-02, This document discusses how International Standard Text Work Codes (ISTCs; persistent and unique identifiers for textual works) can be supported within the URN framework and the syntax for URNs defined in RFC 2141 [Moats]. Analysis is in part based on the ideas expressed in RFC 2288 [Lynch], which analysed the use of ISSN, ISBN and SICI as URNs. Chapter 5 contains a URN namespace registration request modelled according to the template in RFC 2611 [Daigle et al.]. "An Addressing Architecture for virtual Private Network Identifier", Tissa Senevirathne, 07-AUG-02, In this document we present an addressing architecture for VPNIdentifier. Addressing Architecture presented in this documentallows to identify VPN in globally unique manner. It introduces anon overlapping address space for different classes of VPN (L3 VPN,VPLS etc..). The addressing architecture presented in this documentallow to identify attributes of the VPN as part of the VPNidentifier through an embedded attribute field. "Requirements for Floor Control", H. Schulzrinne, Petri Koskelainen, 09-AUG-02, This document defines the requirements for floor control. "SIP Conferencing Scenarios", Andrew Zmolek, Roni Even, Nermeen Ismail, 09-AUG-02, 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 work frame. "Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking Tool", Marcus Leech, 09-AUG-02, In 1991, Quisquater and Desmedt [DESMEDT91] proposed an estoeric, buttechnically sound, attack against DES or similar ciphers. Theytermed this attack the Chinese Lottery. It was based on a massively-parallel hardware approach, using consumer electronics as the 'hosts'of the cipher-breaking hardware.This document revisits the so-called Chinese Lottery, and exploresInternet-based analogues to the Chinese Lottery. "ISATAP Profile for Tunnel Setup Protocol (TSP)", F. Templin, 09-AUG-02, This document proposes a profile for the Intra-Site Automatic TunnelAddressing Protocol (ISATAP) using the Tunnel Setup Protocol (TSP). "The ADDR DNS Query-Type", Eric Hall, 12-AUG-02, This document defines a DNS query-type for 'all IP address resource records,' specifically including any A and AAAA resource records which may be bound to the queried domain name. This query-type would allow IPv6-aware applications to issue a single query and determine the capabilities of the remote host, rather than having to issue a second query for A resource records in those cases where no AAAA resource records are available. "EAP SIM GMM Authentication", Adrian Buckley, 12-AUG-02, This document specifies an Extensible Authentication Protocol (EAP) method for authentication using the GSM Subscriber Identity Module (SIM) and standard GPRS Security and Mobility Management(GMM) messages. This method uses standard GPRS authentication and is recommended to be used within a secure transport layer channel established using another EAP method like PEAP. "A method for storing IPsec keying material in DNS", M. Richardson, 12-AUG-02, This document describes a new resource record for DNS. This recordmay be used to store public keys for use in IPsec systems.This record replaces the functionality of the sub-type #1 of the KEYResource Record, which has been proposed to be obsoleted by [1]. "A Diameter accounting application for the Session Initiation Protocol", H. Schulzrinne, A. Kundaje, S. Narayanan, 12-AUG-02, This memo defines a SIP Diameter accounting application. It specifieshow Diameter servers can be used with SIP servers to provideaccounting. This accounting is expected to be compatible withexisting RADIUS servers. Specific Diameter accounting attribute valuepairs that are applicable to SIP are discussed, and where necessarynew attribute value pairs are defined. "Internet X.509 Public Key Infrastructure The use of Permanent Identifiers in LDAP Distinguished Names", David Chadwick, 12-AUG-02, This document defines a standard way of using Permanent Identifiers in LDAP distinguished names, in order to facilitate the allocation of globally unique distinguished names to PKI subjects, and to allow the certificates of these subjects to be easily retrieved from LDAP servers. "Encapsulating MPLS in IP or GRE", Y. Rekhter, Tom Worster, Eric Rosen, 13-AUG-02, In various applications of MPLS, label stacks with multiple entriesare used. In some cases, it is possible to replace the top label ofthe stack with an IP-based encapsulation, thereby enabling theapplication to run over networks which do not have MPLS enabled intheir core routers. This draft specifies two IP-basedencapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these isapplicable in some circumstances. "Explicit multicast reachability test", J Lee, 13-AUG-02, It can be important to know which node has Explicit multicastreceivability and routability before sending a large amount of datatraffic in Explicit multicast. This document provides how to testthe receivability and routability, in short, the reachability ofExplicit multicast packets to a particular node. "Requirements for Generalized MPLS (GMPLS) Usage and Extensions For Automatically Switched Optical Network (ASON)", D. Papadimitriou, 15-AUG-02, The GMPLS suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SDH/SONET as well as Optical Transport Networks (OTNs). "Extensions to DNS (EDNS2)", P Vixie, 16-AUG-02, This document specifies a number of extensions within the ExtendedDNS framework defined by [RFC2671] and [EDNS1], including several newextended label types. "IANA Registration of parameters and MIME types in proposed ITU Recommendation V.150", Rajesh Kumar, 16-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. "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, 27-AUG-02, The security problems in the internet are due to inherent problems inthe 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 cloning2) TCP Initial sequence number prediction "Guidelines for Extending the Extensible Provisioning Protocol", S. Hollenbeck, 27-AUG-02, The Extensible Provisioning Protocol (EPP) is an application layerclient-server protocol for the provisioning and management of objectsstored in a shared central repository. Specified in XML, theprotocol defines generic object management operations and anextensible framework that maps protocol operations to objects. Thisdocument presents guidelines for use of EPP's extension mechanisms todefine new features and object management capabilities. "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. "PKCS #1: RSA Cryptography Specifications Version 2.1", B. Kaliski, J Jonsson, 27-AUG-02, This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, andchange control is retained within the PKCS process. The body ofthis document is taken directly from the PKCS #1 v2.1 document.This document provides recommendations for the implementation ofpublic-key cryptography based on the RSA algorithm "SNMP Extended Capability Negotiation", D. Shield, 27-AUG-02, This draft discusses mechanisms for supporting future changes to thefunctionality and behaviour of SNMP, without needing to introduce newversions of the protocol, or completely new protocol operations. Itdefines a Management Information Base (MIB) for advertising supportfor various extensions to traditional SNMP protocol capabilities, andproposes a mechanism for negotiating the use of such extensions on aper-request basis. "Reliable Streaming Internet Protocol Detail Records", Jeff Meyer, 27-AUG-02, This memo defines a mechanism to deliver streams of network usageinformation which follow the Internet Protocol Detail Records (IPDR)format. This format provides an extensible means to exchange usageinformation between systems. The model of extension is based on theuse of a subset of the XML Schema specification language, inconjunction with a well defined mapping to a binary format based onthe eXtensible Data Record (XDR). "IMAP4rev1 QUOTA Extension", Alexey Melnikov, Dave Cridland, 27-AUG-02, The QUOTA extension of the Internet Message Access Protocol IMAP4 [2]permits administrative limits on resource usage (quotas) to bemanipulated through the IMAP protocol.This memo replaces RFC2087 [4], but attempts to remain backwardscompatible whenever possible. "Requirement for Analysis of SIP Paths", Arjun Roychowdhury, 27-AUG-02, There is no defined mechanism today by which SIP proxies can insertpath related information in a SIP message that is being routedacross a network.As an example, a network administrator may want to trace the path asa SIP message traverses across her network to detect failurepoints.As another example, a user may want to discover capabilities ofservers in the path of a call. Although there is an informal mentionof using the OPTIONS method to achieve the latter example [1], thereis 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 geographicposition of the DHCP server is passed to the DHCP client in orderto 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 forpacket selection. It suggests some terminology and shows differentsampling methods for selecting a subset of packets in a flow.Furthermore it describes which parameters can be varied for thedifferent sampling methods. "IPv4 mapped address considered harmful", Jun-Ichiro itojun Hagino, 28-AUG-02, IPv6 address architecture [Hinden, 1998] defines IPv4 mapped address.The representation is used in IPv6 basic API [Gilligan, 1999] to denoteIPv4 destinations on AF_INET6 socket within the API. At the same time,there are protocol proposals that use IPv4 mapped address on wire.Therefore, IPv4 mapped address has two meanings, and they are notdistinguishable from the userland applications. This draft discussessecurity threats due to the dual use of IPv4 mapped address. It alsodiscusses threats due to the additional complexities introduced by IPv4mapped address. "Services in the PSTN/IN Requesting InTernet Services (SPIRITS) protocol security", Vijay Gurbani, 13-SEP-02, This document analyses the trust model inherent in SPIRITS with theresult of documenting possible security implications for the entitiesparticipating in the SPIRITS network. It also proposes solutions forcountering the security threats that are possible in such a network. "Standardized caching of dynamic web content", Brent Baccala, 28-AUG-02, Summarizes the present state of web caching technology. Points outthe need for caching dynamic web sites, and the inadequacy ofpresent caching technology for anything but static sites. Proposesthe adoption of Java servlets, cryptographically signed WebApplication Archives (WARs), and LDAP as standards for dynamic webcaching, using an expanded interpretation of existing DNS standardsto locate and authenticate cached information. "Data-oriented networking", Brent Baccala, 28-AUG-02, Differentiates between connection-oriented and data-orientednetworking, identifies the advantages of data-oriented networks,argues that Internet web architecture is becoming moredata-oriented, and suggests ways of encouraging and acceleratingthis trend. "XML Method Call (XMC)", Adam Megacz, 03-SEP-02, This memo describes the XML Method Call (XMC) protocol.XMC a simple presentation layer protocol for network transactionswith method call semantics and payloads consisting of small objecttrees. XMC specifies the request and response protocol, an XMLrepresentation for the object trees, and a tree-encoding forgraphs.XMC is forward and backward compatible with XML-RPC [1]. XMCclients can make calls to XML-RPC servers, and XML-RPC clients canmake calls to XMC servers. "Transport of ATM AAL1/2 frames over PSN", Davari Shahram, 28-AUG-02, This document describes an efficient method for transporting AAL1/2 over IP/MPLS network, using effectively the ATM AAL5 PDU transport mode without introducing any new protocol. "JUNOScript: An XML-based Network Management API", Rob Enns, Philip Shafer, 28-AUG-02, JUNOScript is an XML-based API for managing devices. It allowsaccess to both operational and configuration data using a simple RPCmechanism. Sessions can be established using a variety ofconnection-oriented access methods. This document describes theframing protocol, message content, and capabilities of this API.Design decisions and motivations are also discussed. No attempt ismade to formally define a protocol, but rather to document thecapabilities of JUNOScript as part of the discussion of XML-basednetwork management. "Internationalisation of Email Addresses,Newsgroup Names and similar Identifiers", Claus Andre Faerber, 29-AUG-02, This document describes a possible architecture for theimplementation of internationalised email addresses, newsgroup names,and similar identifiers on top of the standards set by theInternationalised Domain Names [IDN] working group. "Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery", Richard Nelson, Greg Daley, 29-AUG-02, This draft describes a possible optimization to Duplicate AddressDetection (DAD) which can be used to successfully terminate DADearly, based on the presence of listeners on the link-scope solicitednodes multicast address. "A Proposal for RSVPv2", Lars Westberg, 29-AUG-02, The Resource ReSerVation Protocol (RSVP) has been on the standardstrack within the IETF for a number of years. During that time, thelevel of vendor support and deployment has been relatively slow,despite the desire of many to deploy technology to deliver serviceswith different levels of quality of service (QoS) to their customers.The reasons for this are arguably well-understood and documented andare not the focus of this memo. Rather, this memo attempts to lookforward toward a new version of RSVP that would address the problemsand remove some barriers to the realization of new QoS-basedservices. "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 for the PE/CE protocol in BGP/MPLS VPNs", Kunihiro Ishiguro, Ville Hallivuori, 30-AUG-02, This document describes a simple way to use OSPF for Provider Edge(PE) router and Customer Edge (CE) router communication in BGP/MPLSVPNs [RFC2547BIS]. [VPN-BGP-OSPF] propose a complicated way toachieve VPN routes propagation as Type-3 LSA. This documentdescribes the use of multiple instances of OSPF in conjunction withstandard BGP/OSPF route redistribution mechanisms to maintainreachability information throughout VPNs. VPN routes are propagatedas Type-5 LSA in this mechanism. "Microsoft EAP CHAP Extensions", A. Palekar, V. Kamath, 03-SEP-02, This document defines the Microsoft EAP CHAP Extensions Protocol,Version 2, which encapsulates the MS-CHAP-v2 protocol, defined in[RFC2759], within EAP. "Evaluation of the CRANE Protocol Against IPFIX Requirements", Kevin Zhang, 03-SEP-02, This document provides an evaluation of the applicability of theCRANE protocol developed by XACCT Technologies as an IPFIXprotocol. It compares the properties and capabilities of the CRANEprotocol with the IPFIX requirements [IPFIX-REQ]. "Multicast Announce and Control Protocol (MACP)", Jean-Noel Helal, 03-SEP-02, This memo describes the message and procedure related to the Multicast Announce and Control Protocol (MACP). This protocol is considered as one 'building blocks' of a reliable multicast transport framework. The Multicast Announce and Control Protocol (MACP) organizes the process by which a multicast sender node (Msender) manages transmissions to dynamic groups of receivers (Mreceivers) in the 'one-to-many' model. The prime objective of MACP is to work in conjunction with various data transport protocols in order to meet various network requirements. One other main objective is to provide a unified announce transport mechanism for both bulk data transfer and streamed data. "Architectural Framework for Localized Mobility Management", Behcet Sarikaya, 03-SEP-02, This document defines an architectural framework for localized mobility management (LMM) in Mobile IPv4 and Mobile IPv6. LMM requires new architectural entities to be added to the architectures of Mobile IPv4 and v6. Also the availability of localized mobility management must be advertised by the localized mobility agents. The document defines these entities and their interactions with the existing entities and changes required to router/agent advertisements. The document also identifies a number of open issues whose resolution is crucial to the standardization of LMM protocols. "Evaluation Of NetFlow Version 9 Against IPFIX Requirements", Benoit Claise, 03-SEP-02, 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]. This document is the first version of the draft and should not be considered as finished work. Updated version(s) will soon follow withchanges introduced by the publication of the new requirement draft version 6 [IPFIX-REQ6], and with the English syntax and grammar corrections. "Evaluation of Diameter Protocol against IPFIX Requirements", Sebastian Zander, 03-SEP-02, This document provides an evaluation of the applicability of theDiameter protocol [DIAMETER] as an IPFIX protocol. It compares theproperties and capabilities of the Diameter protocol to the IPFIXrequirements [IPFIX-REQ] "Evaluation Of Streaming IPDR Against IPFIX Requirements", Jeff Meyer, 03-SEP-02, This document provides an evaluation of the applicability of theStreaming IPDR protocol as an IPFIX protocol. It compares theproperties and capabilities of Streaming IPDR to the IPFIXrequirements.Streaming IPDR is a mechanism to deliver streams of network usageinformation which follow the Internet Protocol Detail Records (IPDR)format over a reliable transport connection. "Evaluation Of Protocol LFAP Against IPFIX Requirements", P. Calato, 03-SEP-02, This document provides an evaluation of the applicability of theLFAP protocol as an IPFIX protocol. It compares the properties andcapabilities of the LFAP protocol to the IPFIX requirements version05 [IPFIX- REQ]. "SPAN Discussion Issues", Pete Cordell, 04-SEP-02, This document collects points of discussion surrounding thepre-midcom SPAN deliverable (SPAN = Simple Protocol for AugmentingNATs). As far as possible it is intended to act as a collation pointfor facts surrounding the SPAN deliverable. Where a discussion itemis not black and white it attempts to collate opinion from all anglesas far as the author is able to without bias. It does not drawconclusions 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, "Identifying Intra-realm Calls using STUN", F. Audet, C. Aoun, S. Sen, F. Meijer, 05-SEP-02, This draft proposes the use of STUN to determine whether two communicating endpoints are in the same realm. This draft describes the use of STUN in a peer-to-peer fashion between endpoints during call set-up. The call set-up may proceed in parallel with the STUN messaging, allowing the peers to initially exchange media using their public IP addresses. If the peers are in the same realm, then the media is switched to the private IP addresses using a SIP UPDATE or a SIP reINVITE SDP offer-answer exchange. With this proposal, media flows are kept within the same addressing realm whenever possible, thus avoiding certain network intermediaries and reducing bandwidth requirements on external links into the realm. "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. "The Effect of Packet Loss on Voice Quality for TDM over Pseudowires", Y. Stein, I. Druker, 05-SEP-02, The effect of packet loss on voice quality has been the subject ofdetailed study in the VoIP community, but these results are notdirectly applicable to TDM transport as being studied in the PWE WG.The present document presents an analysis of packet loss for the TDMover PW case, and demonstrates that packet loss of a few percent canbe tolerated. We propose that robustness to packet loss of a fewpercent be a requirement for any proposed method for transport of TDMover pseudowires. "IPv6 Addressing Architecture Support for mobile ad hoc networks", E Fleury, G. Chelius, 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", D. Shield, 06-SEP-02, This draft discusses a mechanism for reporting on failuresto fulfil an SNMP request, in somewhat more detail than iscurrently possible. This includes both providing a textualdescription of the error, and reporting on more than oneproblem with an individual request. "The MPLS Working Group decision on MPLS signaling protocols", George Swallow, Loa Andersson, 09-SEP-02, This document is the documentation of the decision taken by the IETF tofocus the efforts on a signalling protocol for traffic engineeringapplications on 'RSVP-TE: Extensions to RSVP for LSP Tunnels' (RFC3209),and consequently discontinue the efforts on 'Constraint-Based LSP Setupusing LDP' (RFC3212). "An Architecture for IP Packet Tracing", G. 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", G. Keeni, 09-SEP-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 valuesof a (user) specified MO instance sampled at (user) specified intervalsfor a (user) specified number of times and to service queries relatedto the aggregated MOs. "Simultaneous Handoff in Mobile-IPv4 and 802.11", Subrata Goswami, 10-SEP-02, This document describes a way to perform simultaneous Mobile-IPv4 handoff and 802.11 Access Point Association/Reassociation. This is an attempt to seek comments and critique on this approach. "SIP Header Language Information Extension", S 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, 11-SEP-02, The NFS (Network File System) version 4[rfc3010bis] (NFSv4) specifiesa flavor of Access Control Lists (ACLs) that resembles that ofWindows NT's. ACLs are used to specify fine grained control ofaccess to file system objects. An ACL consists of a number of AccessControl Entries (ACEs), each specify some level of access for anentity; an entity can be a a user, group or a special entity. Theaccess level is described using an access mask, which is a bitmaskwhere each bit describes a level of access, for example read, writeand execute permissions on the file system object. "DHCP Option for SNMP Notifications", M Bakke, 11-SEP-02, The Dynamic Host Configuration Protocol [RFC1531] provides a methodfor 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 tothese configuration parameters from its local or network disk rightaway; it relies instead on DHCP to provide them. One such parameterthat is not yet provided is a list of IP hosts to which to send SNMPnotifications [RFC1448] during the boot process, particularly if theboot fails. As the host is already gleaning similar information fromDHCP, a new option to specify these SNMP 'trap' hosts appears to bethe simplest method to gain this information. Hosts not booting fromthe network benefit as well, since SNMP notification hosts can now beconfigured centrally through DHCP.This document describes a proposed DHCP option that specifies a listof SNMP notification hosts to which SNMP notifications should besent. "ISATAP interactions with TSP", F. Templin, 11-SEP-02, This document discusses possible interactions between the Intra-SiteAutomatic Tunnel Addressing Protocol (ISATAP) and the Tunnel SetupProtocol (TSP) "Light-weight Flow Accounting Protocol MIB", M. MacFaden, P. Calato, 11-SEP-02, This document provides a description of MIB module that accompaniesthe LFAP Specifications [1][2]. "An enhancement for limiting the length of tunnel in the fast handover method using bi-directional edge tunnel (BET)", J. Min, H Jung, 11-SEP-02, To support real-time services such as VoIP in Mobile IPv4/v6, severalfast handover methods have been proposed. The fast handover methodusing BET is one of them and was chosen as an alternate protocol toFMIPv6 version 4. BET has advantage in reducing the handover latencybecause it does not perform the layer 3 registration. However, thelong BET in certain situation could be not acceptable. In that case,a mechanism is needed to limit the tunnel length of BET. In thisdraft, we propose to group the ARs by predefined value to limit thetunnel length of BET. An anchor router is changed whenever a MNchanges its associated group. "Generalized Mobile IPv4 Extension", Jayshree Bharatia, Kuntal Chowdhury, 11-SEP-02, 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 generalized Mobile IP extension, 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, Network Access Identifier (NAI) and/or address of a session manager etc. "Robust Header Compression (ROHC) over Wireless Ethernet Media ROHCoWEM", K. Fleming, 12-SEP-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, 12-SEP-02, This memo presents a method for a client to prefix commands sent toan IRC (Internet Relay Chat) server with a label, in order to matchserver replies against commands previously sent, without having tokeeping excessive state on the server connection. It is a primarygoal to implement this in a way which is completely backwards-compatible with existing IRC servers. "Evaluation of Transition Mechanisms for Unmanaged Networks", C. Huitema, 12-SEP-02, In a companion paper we defined the 'unmanaged networks' scope,which typically correspond to home networks or small officenetworks, and the requirements for IPv6 transition mechanism in thatscope. We start from this analysis and evaluate here the suitabilityof mechanisms defined in the NGTRANS working group. "IPPM spatial metrics measurement", Emile Stephan, 12-SEP-02, The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end to end performance. Measurements system scope is often limited to administrative boundaries. 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 segment 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. "Transition Scenarios for 3GPP Networks", Jonne Soininen, 13-SEP-02, 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 of this document. The purpose of the document is to list the scenarios for further discussion and study. "Transcoding Services Invocation in the Session Initiation Protocol", G. Camarillo, 13-SEP-02, This document describes how to use SIP third party call control toinvoke transcoding services that involve media manipulations by amedia server. In particular, this document describes how to meet therequirements for the Session Initiation Protocol in support of deaf,hard of hearing and speech-impaired individuals using third partycall control. "The source and sink attributes for the Session Description Protocol", H. Schulzrinne, G. Camarillo, E. Burger, 13-SEP-02, This document defines two media level SDP attributes, namely sourceand sink. They are intended to be used to invoke services thatinvolve media manipulation, such as transcoding services. Next Steps in Signaling (nsis) ------------------------------ "Requirements for Signaling Protocols", Marcus Brunner, 15-AUG-02, This document defines requirements for signaling across different network environments, where different network environments across administrative and technology domains. Signaling is mainly though for QoS such as [1], however in recent year several other applications of signaling have been defined such as signaling for MPLS label distribution [2]. 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. We also provide an outline structure for the problem, including related terminology. Taken with the scenarios, this allows us to focus more precisely on which parts of the overall problem need to be solved. We present the assumptions and the aspects not considered within scope before listing the requirements grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Rodney Thayer, Jon Callas, Lutz Donnerhacke, Hal Finney, 09-AUG-02, This document is maintained in order to publish all necessaryinformation needed to develop interoperable applications based onthe OpenPGP format. It is not a step-by-step cookbook for writing anapplication. It describes only the format and methods needed toread, check, generate, and write conforming packets crossing anynetwork. It does not deal with storage and implementation questions.It does, however, discuss implementation issues necessary to avoidsecurity flaws.OpenPGP software uses a combination of strong public-key andsymmetric cryptography to provide security services for electroniccommunications and data storage. These services includeconfidentiality, key management, authentication, and digitalsignatures. This document specifies the message formats used inOpenPGP. Open Pluggable Edge Services (opes) ----------------------------------- "An Architecture for Open Pluggable Edge Services (OPES)", A Barbir, 05-AUG-02, This memo defines an architecture for a cooperative applicationservice in which a data provider, a data consumer, and zero or moreapplication entities cooperatively realize a data stream service. "Requirements for OPES Callout Protocols", Andre Beck, 05-AUG-02, This document specifies the requirements that the OPES (OpenPluggable Edge Services) callout protocol must satisfy in order tosupport the remote execution of OPES services [1]. The requirementsare intended to help evaluating possible protocol candidates and toguide 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 scenariosfor Open Pluggable Edge Services (OPES). The work examines servicesthat could be performed to requests and/or responses. "Diffie-Hellman USM Key MIB", M StJohns, 27-AUG-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 textual convention for doing Diffie-Hellman key agreement key exchanges and a set of objects which extendthe usmUserTable to permit the use of a DH key exchange in additionto the key change method described in [14]. In other words, this MIBadds the possibility of forward secrecy to the USM model. It alsodefines a set of objects that can be used to kick start security onan SNMPv3 agent when the out of band path is authenticated, but notnecessarily private or confidential.The author is submitting this draft at the request of the O&M areadirector. This memo revises and updates RFC 2786 [19] with the goalof moving the described protocol and MIB from Experimental toStandards Track. The one minor substantive change from theExperimental RFC is a restatement of the conditions on the selectionof the DH public number (see DHKeyChange and usmDHKickstartMyPublicin the body of the MIB as well as the MIBs revision history). Thespelling of 'Hellman' was corrected throughout. Author contactinformation was updated. Slight structural modifications were madeto more cleanly seperate boilerplate from substantive text. "Requirements for Policy, Authorization and Enforcement of OPES Services", A Barbir, 03-SEP-02, This document describes policy, authorization and enforcementrequirements for the selection of the services to be applied to agiven OPES flow. Operations & Management Open Area (opsarea) ------------------------------------------- "Textual Conventions for Transport Addresses", M. Daniele, J. Schoenwaelder, 10-SEP-02, This document introduces a MIB module which defines textualconventions to represent commonly used transport layer addressinginformation. The definitions are compatible with the concept ofTAddress/TDomain pairs introduced by the SMIv2 and support theInternet transport protocols over IPv4 and IPv6. "Operator Requirements of Infrastructure Management Methods", Bill Woodcock, 28-FEB-02, This document describes the network operator community'srequirements of the configuration, management, and debugginguser-interfaces of the devices of which the Internet is built, andestablishes a baseline of minimum functionality against whichproposed device-management interfaces can be evaluated. Open Shortest Path First IGP (ospf) ----------------------------------- "The OSPF NSSA Option", R. Coltun, V. Fuller, P. Murphy, 18-JAN-02, This memo documents an optional type of OSPF area which is somewhathumorously referred to as a 'not-so-stubby' area (or NSSA). NSSAsare similar to the existing OSPF stub area configuration option buthave the additional capability of importing AS external routes in alimited fashion.The OSPF NSSA Option was originally defined in RFC 1587. Thefunctional differences between this memo and RFC 1587 are explainedin Appendix E. All differences, while expanding capability, arebackward-compatible in nature. Implementations of this memo and ofRFC 1587 will interoperate.Please send comments to ospf@gated.cornell.edu. "OSPF Multiple Area Links", P. Murphy, 20-FEB-02, This memo describes an option to the OSPF Version 2 specificationwhich allows multiple areas to share the same OSPF link. One area isalways configured as the link's primary area. The link's remainingareas are termed secondary. Two border routers adjacent across thesame secondary area may forward the area's intra-area traffic acrossthe link. This option applies to standard areas, stub areas, andNSSAs. It works over any OSPF interface. Routers with this optionconfigured are backward compatible with routers running the standardOSPF Version 2 compliant implementation as defined in RFC 2328.Please send comments to ospf@discuss.microsoft.com. "Traffic Engineering Extensions to OSPF Version 2", D. Katz, K. Kompella, D. Yeung, 27-AUG-02, This document describes extensions to the OSPF protocol version 2 tosupport intra-area Traffic Engineering, using Opaque Link StateAdvertisements. "Alternative OSPF ABR Implementations", Alfred Lindem, D. Yeung, A. Zinin, 06-MAR-01, OSPF [Ref1] is a link-state intra-domain routing protocol used forrouting in IP networks. Though the definition of the ABR in thecurrent OSPF specification does not require a router with multipleattached areas to have a backbone connection, it is actuallynecessary to provide successful routing to the inter-area andexternal destinations. If this requirement is not met all traffic,destined for the areas not connected to such an ABR or out of theOSPF domain, is dropped. This document describes alternative ABRbehaviors implemented in Cisco and IBM routers. "Management Information Base for OSPFv3", Dan Joyal, Jacek Kwiatkowski, Sebastian Zwolinski, 09-APR-02, 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", P. Pillay-Esnault, 06-MAR-01, This document describes extension to the OSPF protocol [1] tooptimize flooding of Link State Advertisements (LSA) in stable topologies.The current behaviour of OSPF requires that all LSA be refreshedevery 30 minutes regardless of the stability of the network exceptfor Do Not Age (DNA) LSA [2]. This document proposes to generalize the use of DNA LSA so as to reduce protocol traffic in stablenetworks. "OSPF Version 2 Management Information Base", R. Coltun, F. Baker, Dan Joyal, Spencer Giacalone, 17-DEC-01, 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 PathFirst Routing Protocol.This memo is intended to update and possibly obsolete RFC 1850,however, it is designed to be backwards compatible. The functionaldifferences between this memo and RFC 1580 are explained in AppendixB.Please send comments to ospf@discuss.microsoft.com. "Hitless OSPF Restart", John Moy, 01-FEB-02, This memo documents an enhancement to the OSPF routing protocol,whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This is called 'hitless restart' or'non-stop forwarding'. A restarting router may not be capable ofadjusting its forwarding in a timely manner when the networktopology changes. In order to avoid the possible resulting routingloops the procedure in this memo automatically reverts to a normalOSPF restart when such a topology change is detected, or when one ormore of the restarting router's neighbors do not support theenhancements in this memo. Proper network operation during a hitlessrestart makes assumptions upon the operating environment of therestarting router; these assumptions are also documented. "Explicit Marking and Prioritized Treatment of Specific IGP Packets for Faster IGP Convergence and Improved Network Scalability and Stability", V Sapozhnikova, G Choudhury, 25-APR-02, In this draft we propose the following mechanisms in order to allowfast IGP convergence and at the same time maintain scalability and stability of a network:(1) Explicitly mark Hello packets, to differentiate them from otherIGP packets, so that efficient implementations can detect andprocess the Hello packets in a priority fashion.(2) In the absence of special marking, or in addition to it, use other mechanisms in order not to miss Hello packets. One exampleis to treat any packet received over a link as a surrogate fora Hello packet for the purpose of keeping the link alive.(3) The same type of explicit marking and prioritized treatment maybe beneficial to other IGP packets as well. Some examples include (a) LSA acknowledgment packet, (b) Database description (DBD) packet from a slave that is used as an acknowledgement, and (c) LSAs carrying intra-area topology change information.It is possible that some implementations are already using one ormore of the above mechanisms in order not to miss the processing ofcritical packets during periods of congestion. However, we suggestthe above mechanisms to be included as part of the standard so thatall implementations can benefit from them. "Type 5 to Type 7 Translation", P. Murphy, 06-MAR-02, This memo documents an extension to OSPF which allows area borderrouters to translate Type 5 LSAs into Type 7 LSAs with aggregation.Type 7 LSAs, which are translations of Type 5 LSAs, are flooded intoNot-So-Stubby areas (NSSAs). All differences, while expandingcapability, are backward compatible in nature. NSSA Border routerswhich run implementations of this memo will interoperate with otherNSSA routers which do not. This option is only applicable on aborder router with at least one directly attached NSSA. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Problem Space and Usage Scenarios for PANA", Y. Ohba, 17-JUN-02, Most of the commercial networks today require users (or devices onbehalf of users) to provide their authentication information, such asidentity, device identifier, etc., before being allowed access tonetwork resources. Resources here include basic access to thenetwork, specific value added services, different grade of servicesetc. While such networks are available in the market place, theauthentication process and access control mechanisms depend upon thetype of network that a user is attaching to and in most cases it isspecific to an access technology. Due to the rapid proliferation ofaccess technologies, wireless devices and next generation servicesofferings, a flexible authentication (which is independent ofunderlying access technologies) and access control mechanisms aredeemed necessary. This document therefore attempts to describeseveral such scenarios where existing mechanisms are not sufficientand finally argue the need for a new higher layer protocol calledPANA (Protocol for carrying Authentication for Network Access). Italso helps to understand the problem space clearly and facilitate thediscussion for PANA requirements and framework. "Protocol for Carrying Authentication for Network Access (PANA)Requirements and Terminology", Alper Yegin, Reinaldo Penno, 01-JUL-02, 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 the PANA is to provide a layer two agnostic and IPv4/IPv6 compatibleclient-server protocol that allows a host to be authenticated for network access. The protocol will run between a client's device and an agent device in the network where the agent might be a clientof the AAA infrastructure. This document defines the common terminology and identifies the requirements for PANA. Performance Implications of Link Characteristics (pilc) ------------------------------------------------------- "Advice for Internet Subnetwork Designers", P. Karn, 23-JUL-02, This document provides advice to the designers of digitalcommunication equipment, link-layer protocols and packet-switchedsubnetworks (collectively referred to as subnetworks) who wish tosupport the Internet protocols but who may be unfamiliar withInternet architecture and the implications of their design choices onthe performance and efficiency of the Internet.This document represents a consensus of the members of the IETFPerformance Implications of Link Characteristics (PILC) workinggroup. "TCP Performance Implications of Network Asymmetry", Hari Balakrishnan, Venkata Padmanabhan, 09-NOV-01, This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", Hiroshi Inamura, 05-JUL-02, This document describes a profile for optimizing TCP over second(2.5G) and third (3G) generation wireless networks. We describe therelevant characteristics of 2.5G and 3G networks, and specificfeatures of example deployments of such networks. We then recommendTCP optimization mechanisms and discuss open issues. Theconfiguration options in this document are commonly found in modernTCP stacks, and are widely available standards-track mechanisms thatthe community considers safe for use on the general Internet. Protocol Independent Multicast (pim) ------------------------------------ "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Mark Handley, I Kouvelas, T. Speakman, L Vicisano, 28-JUN-02, This document discusses Bi-directional PIM, a variant of PIMSparse-Mode [9] that builds bi-directional shared treesconnecting multicast sources and receivers. Bi-directionaltrees are built using a fail-safe Designated Forwarder (DF)election mechanism operating on each link of a multicasttopology. With the assistance of the DF, multicast data isnatively forwarded from sources to the Rendezvous-Point andhence along the shared tree to receivers without requiringsource-specific state. The DF election takes place at RPdiscovery time and provides a default route to the RP thuseliminating the requirement for data-driven protocol events. "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", Mark Handley, Bill Fenner, I Kouvelas, Hugh Holbrook, 07-MAR-02, This document specifies Protocol Independent Multicast -Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocolthat can use the underlying unicast routing information baseor a separate multicast-capable routing information base. "Protocol Independent Multicast - Dense Mode (PIM-DM)Protocol Specification (Revised)", A Adams, William Siadak, Jonathan Nicholas, 22-FEB-02, 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 datagramsto 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, 20-JUN-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects used for managing the ProtocolIndependent Multicast (PIM) protocol. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure:Roadmap", Sean Turner, Alfred Arsenault, 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. "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3", David Chadwick, 11-JAN-02, This document describes the features of the Lightweight Directory Access Protocol v3 that are needed in order to support a public key infrastructure based on X.509 certificates and CRLs. "Simple Certificate Validation Protocol (SCVP)", R. Housley, T. Freeman, A. Malpani, 29-JUL-02, The SCVP protocol allows a client to offload certificate handling to aserver. The server can give a variety of valuable information aboutthe certificate, such as whether or not the certificate is valid, acertification path to a trust anchor, and so on. SCVP has manypurposes, including simplifying client implementations and allowingcompanies to centralize their trust and policy management. "Internet X.509 Public Key Infrastructure Certificate Management Protocols", C. Adams, Stephen Farrell, 17-DEC-01, This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocols. Protocol messages are definedfor all relevant aspects of certificate creation and management.Note that 'certificate' in this document refers to an X.509v3Certificate as defined in [COR95, X509-AM]. "Internet X.509 Public Key Infrastructure Permanent Identifier", D. Pinkas, Thomas Gindin, 17-JUN-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 Certificate Request Message Format (CRMF)", D. Solo, C. Adams, D. Kemp, M. Myers, 17-DEC-01, This document describes the Certificate Request Message Format(CRMF). This syntax is used to convey a request for a certificate toa Certification Authority (CA) (possibly via a Registration Authority(RA)) for the purposes of X.509 certificate production. The requestwill typically include a public key and associated registrationinformation. "Certificate Management Messages over CMS", X Liu, M. Myers, Jeff Weinstein, Jim Schaad, 06-MAR-02, This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community:1. The need for an interface to public key certification productsand services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys. "Internet X.509 Public Key Infrastructure Proxy Certificate Profile", Steven Tuecke, 06-MAR-02, This document forms a certificate profile for Proxy Certificates, based on X.509 PKI certificates as defined in draft-ietf-pkix-new-part1-08.txt (the draft update to RFC 2459), 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 impersonation within a PKI based authentication system. This draft replaces draft-ietf-pkix-impersonation-00. "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", S. Chokhani, 08-JAN-02, 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. "CMC Transport", X Liu, M. Myers, Jeff Weinstein, Jim Schaad, 06-MAR-02, This document defines a number of transport mechanisms that are usedto move [CMC] messages. The transport mechanisms described in thisdocument are: HTTP, file, mail and TCP. "Internet X.509 Public Key Infrastructure Logotypes in X.509 certificates", R. Housley, T. Freeman, S. Santesson, 03-SEP-02, This document specifies a certificate extension for includinglogotypes in public key certificates and attribute certificates.Please send comments on this document to the ietf-pkix@imc.orgmailing list. "Supplemental Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", Ari Singer, William Whyte, 05-MAR-02, This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys, including NTRUSign digital signatures and NTRUEncrypt and NTRUSign subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", Peter Gutmann, 30-JAN-02, The protocol conventions described in this document satisfy some of theoperational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories (although RFC 2585 covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide a general-purpose interface to a certificate store). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", R. Housley, D. Pinkas, 15-MAY-02, This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. It also specifies the requirements for DPV and DPD policy management. "Out-of-Band Certificate and Key Identifier Protocol (OCKID)", Paul Hoffman, 28-FEB-02, In general, certificates need not be communicated with communication orstorage media that are integrity-secure or authentic. This is becausecertificates are digitally signed and users are expected to validate thesignatures using configured trust anchors. However, distribution oftrust anchor certificates, self-signed end-entity certificates, or bare(unsigned) public keys requires a mechanism for establishing theauthenticity of the certificate or public key. "Attribute Certificate Request Message Format", P. Yee, 06-MAR-02, The Certificate Request Message Format ([CRMF]) specifies a formatfor requesting an X.509 public key certificate from a CertificationAuthority (CA), possibly with assistance from an Local RegistrationAuthority (LRA). This specification, ACRMF, is modeled on CRMF,extending similar functionality to requests for X.509 attribute cer-tificates from Attribute Authorities (AA), possibly via an AttributeRegistration Authority (ARA). "Attribute Certificate Management Messages over CMS", Peter Yee, 06-MAR-02, This document specifies modifications to the Certificate ManagementMessages over CMS specification ([CMCbis]) to permit the managementof attribute certificates. This document does not stand alone, butmust be used in conjunction with [CMCbis]. It is expected that themodifications proposed here will also be used in conjunction with theAttribute Certificate Request Message Format specification ([ACRMF]). "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", M. Myers, 12-FEB-02, This document specifies a protocol useful in determining the currentstatus of a digital certificate without requiring CRLs. Additionalmechanisms addressing PKIX operational requirements are specified inseparate documents. "X.509 Extensions for IP Addresses and AS Identifiers", Charles Lynn, 27-FEB-02, This document defines two private X.509 v3 certificate extensions.The first binds a list of IP address blocks, or prefixes, to thesubject of a certificate. The second binds a list of AutonomousSystem Identifiers to the subject of a certificate. These extensionsmay be used to convey the authorization of the subject to use the IPaddresses and Autonomous System identifiers contained in theextensions. "Policy Requirements for Time-Stamping Authorities", D. Pinkas, J Ross, N Pope, 02-AUG-02, This document defines requirements for a baseline time-stamp policy for 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 toETSI TS 102 023 [TS 102023]. The ETSI TS is under theETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org "Update for Appendix A in draft-ietf-pkix-new-part1-12.txt", R. Housley, J Arkko, 23-APR-02, As all members of the PKIX Working Group know, draft-ietf-pkix-new-part1-12.txt is with the RFC Editor. However, an error in the ASN.1modules was discovered. The authors are working with the RFC Editorto ensure that the corrected ASN.1 modules are included in the finaltext, and we are publishing this Internet-Draft to distribute thecorrected ASN.1 modules as quickly as possible.This Internet-Draft contains only the updated Appendix. "Warranty Certificate Extension", Duane Linsenbardt, Sue Pontius, 17-MAY-02, This document describes a certificate extension to explicitly statethe warranty offered by a Certificate Authority (CA) for a thecertificate containing the extension. "Update for Section 3 in draft-ietf-pkix-ipki-pkalgs-05.txt", R. Housley, J Arkko, 25-APR-02, As all members of the PKIX Working Group know, draft-ietf-pkix-ipki-pkalgs-05.txt is with the RFC Editor. However, an error in the ASN.1modules was discovered. The authors are working with the RFC Editorto ensure that the corrected ASN.1 modules are included in the finaltext, and we are publishing this Internet-Draft to distribute thecorrected ASN.1 module as quickly as possible.This Internet-Draft contains only the updated ASN.1 module. "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", C. Adams, D. Pinkas, Patrick Cain, Robert Zuccherato, 26-APR-02, This document describes the format of a request sent to a TimeStamping Authority (TSA) and of the response that is returned. Italso establishes several security-relevant requirements for TSAoperation, with regards to processing requests to generate responses. "LDAPv3 DN strings for use with PKIs", David Chadwick, 17-MAY-02, RFC 2253 [2] standardises a set of strings that can be used to represent attribute types in LDAP distinguished names. This list is does not cover the full set of attribute types used in the distinguished names of issuers and subjects in public key certificates. This document standardises the strings needed for these additional attribute types. "Attribute Certificate Policies Extension", D. Pinkas, C. Francis, 12-JUN-02, This document describes a certificate extension to explicitly state the attribute certificate policies that apply to the attributes contained in the certificate containing that extension.It also defines two certificate extensions that may be used to indicate the location of the public or private repositories where the certificate is being stored. "Wireless LAN Certificate Extensions and Attributes", R. Housley, T. Moore, 13-SEP-02, This document defines two EAP extended key usage values and a publickey certificate extension to carry Wireless LAN (WLAN) System Serviceidentifiers (SSIDs). "Certificate Validation Protocol", D. Pinkas, 14-JUN-02, This document defines a protocol called Certificate Validation Protocol (CVP) that can be used to fully delegate the validation of a certificate to a CVP server, according to a set of rules called a validation policy. "Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PKIs", David Chadwick, Steven Legg, 28-JUN-02, This document describes LDAP schema features that are needed to support X.509 Public Key Infrastructures. Specifically, X.509 attribute types, object classes, matching rules, attribute value syntaxes and attribute value assertion syntaxes needed for PKIs are defined. "Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PMIs", David Chadwick, Steven Legg, 28-JUN-02, This document describes LDAP schema features that are needed to support X.509 Privilege Management Infrastructures. Specifically, X.509 attribute types, object classes, matching rules, attribute value syntaxes and attribute value assertion syntaxes needed for PMIs are defined. Policy Framework (policy) ------------------------- "Policy Core LDAP Schema", Ed Ellesson, Ryan Moats, John Strassner, Robert Moore, 30-AUG-02, This document defines a mapping of the Policy Core Information Model [1] to a form that can be implemented in a directory that uses 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 Framework QoS Information Model", Ron Cohen, John Strassner, Bob Moore, Yoram Snir, Yoram Ramberg, 13-NOV-01, 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 as specified by [PCIM] and [PCIMe]. This draft builds upon these two documents to define 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", David Durham, John Strassner, Walter Weiss, A Westerinen, Bob Moore, 31-MAY-02, The purpose of this draft is to define an information model todescribe the quality of service (QoS) mechanisms inherent indifferent network devices, including hosts. Broadly speaking,these mechanisms describe the attributes common to selecting andconditioning traffic through the forwarding path (datapath) of anetwork device. This selection and conditioning of traffic inthe datapath spans both major QoS architectures: DifferentiatedServices (see [R2475]) and Integrated Services (see [R1633]).This draft is intended to be used with the QoS Policy InformationModel [QPIM] to model how policies can be defined to manage andconfigure the QoS mechanisms (i.e., the classification, marking,metering, dropping, queuing, and scheduling functionality) ofdevices. Together, these two drafts describe how to write QoSpolicy rules to configure and manage the QoS mechanisms presentin the datapaths of devices.This draft, as well as [QPIM], are information models. That is,they represent information independent of a binding to a specifictype of repository. A separate draft could be written to providea mapping of the data contained in this document to a formsuitable for implementation in a directory that uses (L)DAP asits access protocol. Similarly, a draft could be written toprovide a mapping of the data in [QPIM] to a directory.Together, these four drafts (information models and directoryschema mappings) would then describe how to write QoS policyrules that can be used to store information in directories toconfigure device QoS mechanisms. "Policy Core Information Model Extensions", Bob Moore, 28-MAY-02, This document specifies a number of changes to the Policy CoreInformation Model (PCIM, RFC 3060). Two types of changes are included.First, several completely new elements are introduced, for example,classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- "Derivating Keys for use with Microsoft Point-to-Point Encryption (MPPE)", G. Zorn, 01-NOV-00, The Point-to-Point Protocol (PPP) [1] provides a standard method fortransporting multi-protocol datagrams over point-to-point links.The PPP Compression Control Protocol [2] provides a method to negotiateand utilize compression protocols over PPP encapsulated links. "PPP over ATM Adaptation Layer 2", B Thompson, Tmima Koren, Bruce Buffam, 04-MAR-02, The Point-to-Point Protocol (PPP) [1] provides a standard method fortransporting multi-protocol datagrams over point-to-point links. "Class Extensions for PPP over ATM Adaptation Layer 2", B Thompson, Tmima Koren, Bruce Buffam, 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, S. Blake-Wilson, 27-MAR-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. "Extensible Authentication Protocol (EAP)", J. Vollbrecht, L. Blunk, B. Aboba, 24-JUL-02, This document defines the Extensible Authentication Protocol (EAP), anauthentication protocol which supports multiple authenticationmechanisms. EAP typically runs directly over the link layer withoutrequiring IP and therefore includes its own support for in-orderdelivery and retransmission. Fragmentation is not supported within EAPitself; however, individual EAP methods may support this. While EAP wasoriginally developed for use with PPP, it is also now in use with IEEE802.This document obsoletes RFC 2284. "PPP Bridging Control Protocol (BCP)", F. Baker, M. Higashiyama, T. Liao, 25-JUL-02, The Point-to-Point Protocol (PPP) [6] provides a standard method fortransporting multi-protocol datagrams over point-to-point links. PPPdefines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring differentnetwork-layer protocols.This document defines the Network Control Protocol for establishingand configuring Remote Bridging for PPP links.This document obsoletes RFC 2878, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specificationby improving support for bridge control packets. "PPP IPV6 Control Protocol Extensions for DNS Server Addresses", G. Zorn, Tom Hiller, 24-JUN-02, The Point-to-Point Protocol (PPP) provides a standard method fortransporting multi-protocol datagrams over point-to-point links. PPPdefines an extensible Link Control Protocol and a family of NetworkControl Protocols (NCPs) for establishing and configuring differentnetwork-layer protocols.This document extends the NCP for establishing and configuringVersion 6 of the Internet Protocol (IPV6) over PPP, defining thenegotiation of primary and secondary Domain Name System (DNS) serverIPV6 addresses. Provider Provisioned Virtual Private Networks (ppvpn) ----------------------------------------------------- "Service requirements for Provider Provisioned Virtual Private Networks", Marco Carugi, 26-FEB-02, 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, 19-APR-02, This document provides a framework for Layer 3 Provider ProvisionedVirtual Private Networks (PPVPNs). This framework is intended to aidin the standardization of protocols and mechanisms for support oflayer 3 PPVPNs. It is the intent of this document to produce acoherent description of the significant technical issues which areimportant in the design of layer 3 PPVPN solutions. Selection ofspecific approaches, making choices regarding engineering tradeoffs,and detailed protocol specification, are outside of the scope of thisframework document. "Scalable Connectionless Tunneling Architecture and Protocols for VPNs", Takeshi Kuwahara, 19-JUN-01, This document defines a connectionless tunneling architecture that isapplicable to provider provisioned virtual private networks (PPVPNs)and specifies protocols for implementing it. This architecture isdesigned to facilitate scalable operation, load balancing, and highreliability. A prominent feature of it is to provide VPN tunnelsover a connectionless network. Since a connectionless network canprovide full mesh connectivity without a connection establishingprocedure, the architecture enables scalable operation of a VPN moreefficiently than connection-oriented tunneling technologies. "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy De Clercq, 05-JUL-02, This document describes the procedures for a Service Provider tooffer Virtual Private Network Services to its customers byprovisioning the CE devices on behalf of the customer. The IPsectechnology is used to protect the customer traffic. "BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure", Tri Nguyen, 05-JUL-02, This document describes a method by which a Service Provider may usean MPLS enabled IPv4 backbone to provide Virtual Private Networks forits IPv6 customers. This proposal makes use of the method to buildnetwork based VPNs described in the Internet draft 'BGP/MPLS VPN'[2547bis]. In BGP/MPLS VPN, MPLS is used to forward packets over thebackbone, and 'Multiprotocol BGP' is used for distributing VPN routesover the service provider backbone. This document defines an IPv6 VPNaddress family and describes the route distribution and the MPLStunnel selection. "MPLS/BGP Virtual Private Network Management Information Base Using SMIv2", Thomas Nadeau, 05-MAR-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, in response to customerdemands and strong input from vendors, it describes managed objectsfor modeling and managing Multi-Protocol Label Switching (MPLS)[MPLSArch]/Border Gateway Protocol (BGP) Virtual Private Networks(VPNs) [RFC2547bis]. "BGP/MPLS VPNs", Eric Rosen, 31-JUL-02, This document describes a method by which a Service Provider may usean IP backbone to provide VPNs for its customers. MPLS is used forforwarding packets over the backbone, and BGP is used fordistributing routes over the backbone. The primary goal of thismethod is to support the case in which a client obtains IP backboneservices from a Service Provider or Service Providers with which itmaintains contractual relationships. The client may be anenterprise, a group of enterprises which need an extranet, anInternet Service Provider, an application service provider, anotherVPN Service Provider which uses this same method to offer VPNs toclients of its own, etc. The method makes it very simple for theclient to use the backbone services. It is also very scalable andflexible for the Service Provider, and allows the Service Provider toadd value.This document obsoletes RFC 2547. "Use of PE-PE IPsec in RFC2547 VPNs", Eric Rosen, 13-AUG-02, [RFC2547bis] specifies a particular way of implementing Layer 3 VPNs.It presupposes the use of MPLS Label Switched Paths (LSPs) forcarrying VPN traffic between Provider Edge (PE) routers, andspecifies the use of two labels in the MPLS label stack. In somecircumstances, it is desirable to support the same type of VPNarchitecture, using an IPsec Security Association in place of an MPLSLSP, thus replacing the topmost of the two MPLS labels with anIP/IPsec header. This enables the VPN packets to be carried securelyover non-MPLS networks, using standard IPsec authentication and/orencryption functions to protect them. This draft specifies theprocedures which are specific to support of RFC2547bis VPNs using theIPsec encapsulation. "Use of PE-PE GRE or IP in RFC2547 VPNs", Y. Rekhter, Eric Rosen, 06-FEB-02, This draft describes a variation of RFC2547 [RFC2547] in which theoutermost MPLS label of a VPN packet is replaced with either IP or aGRE encapsulation. This enables the VPN packets to be carried overnon-MPLS networks. "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", H Ould-Brahim, 28-AUG-02, 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 (i.e., [L2VPN-KOMP], [L2VPN-ROSEN], [L2VPN-VKOMP-LASS], [L2VPN-DTLS], [L2VPN-LPE], [L2VPN-HVPLS]) 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", H Ould-Brahim, 01-JUL-02, 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", E. Stelzer, S Hancock, B. Schliesser, 25-JUN-02, 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 VirtualRouters (VR). "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management", Thomas Nadeau, B. Schliesser, 05-MAR-02, This document describes Textual Conventions used for managingPPVPNs. "Requirements for Virtual Private LAN Services (VPLS)", Waldemar Augustyn, 25-MAR-02, This draft describes service requirements related to emulating a virtual private LAN segment over an IP or MPLS network infrastructure. The service is called VPLS. It is a class of Provider Provisioned Virtual Private Network [2]. "Applicability Statement for VPNs Based on rfc2547bis", Eric Rosen, 21-JUN-02, This document provides an Applicability Statement for the VPNsolution described in [2547bis] and other documents listed in theReferences section. "Guidelines of Applicability Statements for PPVPNs", Junichi Sumimoto, 26-JUN-02, This document is expected to be guidelines to assist development ofapplicability statements for each PPVPN approach by providing acheck-list which consists of requirements/metrics. This check-list issystematically composed of (i)requirements and metrics common to allPPVPNs, (ii)requirements and metrics common to L3 PPVPN approaches,(iii)requirements and metrics specific to L3 PE-based PPVPNapproaches, (iv)requirements and metrics specific to L3 CE-basedPPVPN approaches and (v)requirements and metrics common to L2 PPVPNapproaches, according to the classification of PPVPN approaches. "PPVPN L2 Framework", Loa Andersson, 27-AUG-02, 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, 14-AUG-02, This document is an applicability statement for Layer 3 ProviderProvisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR)approaches. This document describes how VR-based approaches meetthe key requirements that are outlined in the PPVPN ApplicabilityStatements Guideline document. "CE-to-CE Authentication for Layer 3 VPNs", Y. Rekhter, Ron Bonica, 14-AUG-02, This document describes a CE-based authentication mechanism thatPPVPN customers can use to detect security breaches caused bymisconfiguration of the provider network. Provisioning Registry Protocol (provreg) ---------------------------------------- "Generic Registry-Registrar Protocol Requirements", S. Hollenbeck, 25-FEB-02, This document describes high-level functional and interfacerequirements for a client-server protocol for the registration andmanagement of Internet domain names in shared registries. Specifictechnical requirements detailed for protocol design are not presentedhere. Instead, this document focuses on the basic functions andinterfaces required of a protocol to support multiple registry andregistrar operational models. "Extensible Provisioning Protocol", S. Hollenbeck, 26-AUG-02, This document describes an application layer client-server protocolfor the provisioning and management of objects stored in a sharedcentral repository. Specified in XML, the protocol defines genericobject management operations and an extensible framework that mapsprotocol operations to objects. This document includes a protocolspecification, an object mapping template, and an XML media typeregistration. "Extensible Provisioning Protocol Contact Mapping", S. Hollenbeck, 26-AUG-02, This document describes an Extensible Provisioning Protocol (EPP)mapping for the provisioning and management of individual ororganizational social information identifiers (known as 'contacts')stored in a shared central repository. Specified in XML, the mappingdefines EPP command syntax and semantics as applied to contacts. "Extensible Provisioning Protocol Domain Name Mapping", S. Hollenbeck, 26-AUG-02, This document describes an Extensible Provisioning Protocol (EPP) map-ping for the provisioning and management of Internet domain namesstored in a shared central repository. Specified in XML, the mappingdefines EPP command syntax and semantics as applied to domain names "Extensible Provisioning Protocol Host Mapping", S. Hollenbeck, 26-AUG-02, This document describes an Extensible Provisioning Protocol (EPP)mapping for the provisioning and management of Internet host namesstored in a shared central repository. Specified in XML, the mappingdefines EPP command syntax and semantics as applied to host names. "Extensible Provisioning Protocol Transport Over TCP", S. Hollenbeck, 26-AUG-02, 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 clientand an EPP server. Packet Sampling (psamp) ----------------------- "A Framework for Passive Packet Measurement", Nick Duffield, 04-SEP-02, A wide range of traffic engineering and troubleshooting tasks relyon reliable, timely, and detailed traffic measurements. We describea passive packet measurement framework that is (a) general enoughto serve as the basis for a wide range of operational tasks, and(b) relies on a small set of primitives that facilitate uniformdeployment in router interfaces or dedicated measurement devices,even at very high speeds. This document describes the motivationfor such a framework through several operational examples, definesthe measurement primitives (filtering, sampling, and hashing), andillustrates their use.Comments on this document should be addressed to the PSAMP WGmailing list: psamp@ops.ietf.orgTo subscribe: psamp-request@ops.ietf.org, in body: subscribeArchive: https://ops.ietf.org/lists/psamp/ Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) ------------------------------------------------------------------------- "NOPEER community for BGP route scope control", Geoff Huston, 10-APR-02, This document proposes the use of a scope control BGP community.This proposed well-known advisory transitive community is intendedto allow an origin AS to specify the extent to which a specificroute should be externally propagated. In particular this community,termed here as NOPEER, allows an origin AS to specify that a routewith this attribute need not be advertised across bilateral peerconnections. "Controlling the redistribution of BGP routes", Olivier Bonaventure, 26-AUG-02, This document proposes the redistribution extended community. Thisnew extended community allows a router to influence how a specificroute should be redistributed towards a specified set of eBGPspeakers. Several types of redistribution communities are proposed.The first type may be used to indicate that a specific route shouldnot be announced to the specified set of eBGP speakers. The secondtype may be used to indicate that the attached route should only beannounced with the NO_EXPORT community to the specified set of eBGPspeakers and the third type may be used to indicate that the attachedroute should be prepended n times when announced to the specified setof eBGP speakers. Pseudo Wire Emulation Edge to Edge (pwe3) ----------------------------------------- "Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)", X Xiao, 28-JUN-02, This document describes generic requirements for Pseudo-WireEmulation Edge to Edge (PWE3). It provides guidelines for otherworking group documents that will define mechanisms for providingpseudo-wire emulation of specific services such as Ethernet, ATM,Frame Relay, TDM, and MPLS. It should be noted that the PWE3 WorkingGroup (PWE3 WG) standardizes mechanisms that can be used to providePWE3 services, but not the services themselves "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)", P Pate, 30-MAY-02, This document describes a framework for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services (suchFrame Relay, ATM, Ethernet T1, E1, T3, E3 and SONET/SDH) over packetswitched networks (PSNs) using IP or MPLS. It presents anarchitectural framework for pseudo wires (PWs), defines terminology,specifies the various protocol elements and their functions,overviews some of the services that will be supported and discusseshow PWs fit into the broader context of protocols. "Protocol Layering in PWE3", Stewart Bryant, 29-MAY-02, This draft proposes a unified protocol layering approach for pseudo-wire emulation edge-to-edge (PWE3). It adopts the principle that PWE3should be a single transport type operating over a common packet-switched network (PSN) service model using, wherever possible,existing IETF protocols. The draft defines the protocol layeringmodel for pseudo-wires, guidelines for the design of a specificencapsulation type, and the service requirements on the underlyingPSN tunneling mechanism. "Pseudo Wire (PW) Management Information Base", Dave Danenberg, Thomas Nadeau, S. Park, Sharon Mantin, 19-JUN-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 of Pseudo Wire (PW) services on a general Packet Switched Net (PSN). "Pseudo Wire (PW) over MPLS PSN Management Information Base", Dave Danenberg, Thomas Nadeau, S. Park, 19-JUN-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 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", A. Malis, Dave Danenberg, Thomas Nadeau, S. Park, 19-JUN-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 the textual conventions to be used in the various Pseudo Wire (PW) MIB modules. "SONET/SDH Circuit Emulation over Packet (CEP)", S. Park, 25-JUL-02, Generic requirements and framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3-FW]. This draft provides encapsulation formats and semantics for connecting SONET/SDH edge networks through a packet network using IP or MPLS. This basic application of SONET/SDH interworking will allow service providers to take advantage of new technologies in the core in order to provide traditional SONET/SDH services. "TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3)", P Pate, 07-AUG-02, This document describes the service-specific implementation andrequirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) of TDMcircuits using SONET/SDH payload formats over packet networks usingIP or MPLS. This draft extends SONET/SDH SPE emulation proposal[CEP-SPE], providing SONET VT1.5/2/3/6 and SDH VC-11/12/2 circuitemulation. This draft also provides bandwidth saving modes forSONET STS-1 and SDH VC-3/4 carrying tributaries or asynchronousT3/E3 signals. This proposal is optimized for VT level crossconnect applications, for PDH to SONET/SDH emulation and forcarrying PDH circuits across a PSN. The applicability statement forTDM circuit emulation (PDH and SONET/SDH) is described in [TDM-APP]. "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", L Martini, 12-AUG-02, An Ethernet PW allows Ethernet/802.3 Protocol Data Units (PDUs) to becarried over Packet Switched Networks (PSNs) using MPLS transport.This enables Service Providers to leverage their existing PSN tooffer Ethernet services.This document describes methods for encapsulating Ethernet/802.3 PDUsfor transport over an MPLS or IP network. "Transport of Layer 2 Frames Over MPLS", L Martini, 12-AUG-02, This document describes methods for transporting the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,Ethernet, and providing a SONET circuit emulation service across anMPLS network. "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2", A. Malis, S. Park, 29-AUG-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). Resource Allocation Protocol (rap) ---------------------------------- "Framework Policy Information Base", Keith McCloghrie, John Seligson, S Hahn, Andrew Smith, Francis Reichmeyer, K Chan, Mike Fine, R Sahita, 10-JUN-02, Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined PRovisioning Classes (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the Common Open Policy Service (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each. This document defines a set of PRCs and textual conventions that are common to all clients that provision policy using COPS for Provisioning. "COPS Over TLS", Jesse Walker, A. Kulkarni, 03-JUL-02, 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. "Session Authorization for RSVP", Bill Gage, Louis Hamer, Brett Kosinski, M Broda, Hugh Shieh, 02-JUL-02, This document describes the representation of session authorization information in the POLICY_DATA object (RFC 2750) for supporting policy-based per-session authorization and admission control in RSVP. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into the RSVP PATH message to facilitate proper and secure reservation of those resources within the network. We describe the encoding of media authorization information as RSVP policy elements and provide details relating to operations, processing rules and error scenarios. "Framework for session set-up with media authorization", Bill Gage, Louis Hamer, Hugh Shieh, 02-JUL-02, Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, we describe various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session. "Framework of COPS-PR Policy Usage Feedback", Diana Rawlins, A. Kulkarni, 06-MAR-02, Common Open Policy Services Protocol [COPS], RFC 2748, defined the capability of reporting information to the PDP. The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. "Framework of COPS-PR Policy Information Base for Policy Usage Feedback", Diana Rawlins, 03-JUL-02, Currently there are no policy classes defined for the PEP to convey provisioned policy usage feedback to the PDP. The purpose of this document is to define the policy usage feedback framework PIB that specifies the policy classes common for COPS feedback reports. The basic operation and objects for reporting usage information are defined in [COPS]. A specific clientSI feedback object named REPORT is defined in [COPS-PR]. A framework for approaching solicited and periodic usage feedback is described in [COPS-FEED-FRWK]. The COPS-PR Policy Usage Feedback Policy Information Base document defines the policy classes for a feedback framework Policy information base (PIB). "Framework for Binding Access Control to COPS Provisioning", Walter Weiss, 06-MAR-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. "An Architecture for COPS Based Policy Control Management Framework", Kwok Chan, Louis Hamer, 03-JUL-02, This document describes an architecture for a COPS based Policy Control Management System Framework. The architecture is designed to be modular, allowing future modification and addition to existing framework. The major units of the architecture are the Policy Decision Points (PDP), the Access Edge Policy Enforcement Points (AE_PEP), the Core Policy Enforcement Points (C_PEP). With Message Processing Subsystem, Security Subsystem, Framework Data Model Subsystem, and Application Specific Data Model Subsystem in each PDP and PEP. This document further provides a high level description of each unit and describes the relationship among each unit. This document also describes how the subsystems within each unit interact with each other to provide the functionality of a Policy Control Management System. "RSVP Policy Control Criteria PIB", Diana Rawlins, 07-MAR-02, This draft describes the use of COPS-PR for support of a PDP provisioning a PEP with RSVP policy control criteria and defines a RSVP policy control criteria PIB for this purpose. The RSVPCC-PIB described in the document is provided for definition of policies that are currently defined by the outsourcing model [2749]. It is designed to be scalable and flexible as well as extensible for accommodating future policy criteria Resource Capabilities Discovery (rescap) ---------------------------------------- "ResCap Requirements", John Beck, 24-JUN-02, A variety of resource identifiers have been widely deployed on theInternet as a means of identifying various resources, services, anddestinations. However, a means of attaching a set of attributes orcharacteristics to a given resource identifier and subsequentlyassessing those attributes or characteristics has not been specifiedand deployed.Two tasks are envisioned. The first task will be to define a generalresolution protocol that will translate resource identifiers to alist of attributes. The second task will be to define anadministrative model and update protocol that can be used to set upand maintain the information the resolution protocol accesses. "RESCAP Scenarios", G. Klyne, 11-JAN-02, This memo explores some scenarios for the resource capabailitydiscovery protocol (RESCAP). It is intended to provide somegrounding in specific use-cases for decisions about RESCAP goalsand design. "The Resource Catalog", Keith Moore, 05-MAR-02, This memo describes version 3 of the Resource Catalog. The ResourceCatalog (RC) is a service for storing and obtaining metadata thatdescribes network-accessible resources. This service is primarilyintended for use by clients prior to accessing, or attempting to access,a particular resource. The RC service may thus be used (for example) toinform a client as to which of a variety of features are supported bythe resource, or which methods may be used to access the resource, orwhich of a small set of locations may be used to access the resource. "The Binary Low-Overhead Block Presentation Protocol", Keith Moore, 05-MAR-02, This memo describes the Binary Low-Overhead Block (BLOB) protocol foron-the-wire presentation of data in the context of higher-levelprotocols. BLOB is designed to encode and decode data with low overheadon most CPUs, to be reasonably space-efficient, and for itsrepresentation to be sufficiently precise that it is suitable as acanonical format for digital signatures "RESCAP Profile for Mail User Agents", Paul Hoffman, 24-JUN-02, This document defines RESCAP Attributes for Mail User Agents (MUAs)and mail recipients. Values for these attributes will containinformation that a mail sender might want or need to know about aparticular mail recipient before sending a message. Remote Network Monitoring (rmonmib) ----------------------------------- "Application Performance Measurement MIB", Steven Waldbusser, 30-APR-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 formeasuring the application performance as experienced by end-users. "Transport Performance Metrics MIB", Russell Dietz, Robert Cole, 14-AUG-02, This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, it describes managed objectsused for monitoring selectable performance metrics and statisticsderived from the monitoring of network packets and sub-applicationlevel transactions. The metrics are defined through reference toexisting IETF, ITU and other standards organizations' documents. Themonitoring covers both passive and active traffic generation sources. "Remote Network Monitoring MIB Protocol Identifier Reference Extensions", C. Bucci, Russell Dietz, Andy Bierman, Albin Warth, 21-AUG-02, This memo defines extensions to the Protocol Identifier Referencedocument for the identification of application verb information. It doesnot obsolete any portion of the Protocol Identifier Reference document.In particular, it describes the algorithms required to identify protocoloperations (verbs) within the protocol encapsulations managed with theRemote Network Monitoring MIB Version 2, RFC 2021. "Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms.", D. Romascanu, Robert Cole, C. Kalbfleisch, 05-AUG-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 objects for configuring Synthetic Sourcesfor Performance Monitoring algorithms (SSPM).This memo specifies a MIB module in a manner that is both compliantto the SMIv2, and semantically identical to the peer SMIv1definitions.Distribution of this memo is unlimited. "Remote Monitoring MIB Extensions for High Capacity Alarms", Keith McCloghrie, Andy Bierman, 04-APR-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for extending the alarmthresholding capabilities found in the RMON MIB [RFC2819], to providesimilar threshold monitoring of objects based on the Counter64 datatype. "RMON Framework", Steven Waldbusser, 28-AUG-02, The RMON Framework consists of a number of interrelated standards. Thismemo describes these standards and how they relate to one another. Reliable Multicast Transport (rmt) ---------------------------------- "Forward Error Correction building block", M Luby, 15-SEP-02, This document describes the abstract packet formats and IANAregistration procedures for use of Forward Error Correction(FEC) codes within the context of reliable IP multicasttransport. "Asynchronous Layered Coding protocol instantiation", M Luby, 26-APR-02, This document describes the Asynchronous Layered Codingprotocol, a massively scalable reliable content deliveryprotocol, hereafter referred to as ALC. ALC combines the LCTbuilding block [13], a multiple rate congestion controlbuilding block that is in compliance with RFC2357 [14] and theFEC building block [12] to provide congestion controlledreliable asynchronous delivery of content to an unlimitednumber of concurrent receivers from a single sender. "NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks", Mark Handley, Carsten Bormann, B. Adamson, Joseph Macker, 01-JUL-02, This memo describes issues related to the creation of negative-acknowledgment (NACK) oriented reliable multicast (NORM) protocols.The general goals and assumptions for NORM are defined. The tech-nical challenges related to NACK-oriented (and in some cases gen-eral) reliable multicast protocol design are identified. Thesechallenges are resolved into a set of applicable 'building blocks'which are described in further detail. It is anticipated thatthese building blocks (as they are further refined and defined infuture revisions of this document) will be useful in generatingdifferent instantiations of reliable multicast protocols. "Layered Coding Transport transport building block", M Luby, 11-FEB-02, Layered Coding Transport (LCT) provides transport levelsupport for reliable content delivery and stream deliveryprotocols. LCT is specifically designed to support protocolsusing IP multicast, but also provides support to protocolsthat use unicast. LCT is compatible with congestion controlthat provides muliple rate delivery to receivers and is alsocompatible with coding techniques that provide reliabledelivery of content. "The use of Forward Error Correction in Reliable Multicast", M Luby, 15-SEP-02, This memo describes the use of Forward Error Correction (FEC)codes within the context of reliable IP multicast transportand provides an introduction to some commonly-used FEC codes. "NACK-Oriented Reliable Multicast Protocol (NORM)", Mark Handley, Carsten Bormann, B. Adamson, Joseph Macker, 05-MAR-02, This document describes the messages and procedures of the Nega-tive-acknowledgement (NACK) oriented reliable multicast (NORM) pro-tocol. This protocol is designed to provide end-to-end reliabletransport of bulk data objects or streams over generic IP multicastrouting and forwarding services. "PGMCC single rate multicast congestion control: Protocol Specification", Mark Handley, L Vicisano, Luigi Rizzo, Gianluca Iannaccone, 01-JUL-02, This document describes PGMCC, a single rate multicastcongestion control scheme which is TCP-friendly and achievesscalability, stability and fast response to variations innetwork conditions. PGMCC is suitable for both non-reliableand reliable data transfers. It is mainly designed for NAK-based multicast protocols, and uses a window-based, TCP-likecontrol loop using positive ACKs between one representative ofthe receiver group (the ACKER) and the sender. The ACKER isselected 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 fastresponse to changes in the receiver set and/or networkconditions. "Wave and Equation Based Rate Control building block", V. Goyal, M Luby, 02-JUL-02, Wave and Equation Based Rate Control (WEBRC) provides rate andcongestion control for data delivery. WEBRC is specificallydesigned to support protocols using IP multicast, but couldalso be used to provide support to protocols that use unicast.WEBRC provides multiple rate congestion controlled delivery toreceivers, i.e., different receivers joined to the samesession may be receiving packets at different rates dependingon their individual bandwidth connection to the sender and oncompeting traffic along that connection. WEBRC requires nofeedback from receivers to the sender, i.e., it is acompletely receiver-driven congestion control protocol. Thus,WEBRC is designed to scale to potentially massive numbers ofreceivers attached to a session from a single sender.Furthermore, because each individual receiver adjusts to theavailable bandwidth between the sender and that receiver,there is the potential to deliver data to each individualreceiver at the fastest possible rate for that receiver, evenin a highly heterogeneous network architecture, using a singlesender. "Reliable Multicast Transport Building Block Generic Router Assist - Signalling Protocol Specification", T. Speakman, L Vicisano, 24-JUL-02, This draft specifies the signalling protocol to be implementedin both end systems and network elements to activate built-inGRA functionality in network elements. It specifies thisprotocol specifically in the context of UDP as well asgenerally in the context of prospective (reliable multicast)transport protocols for IP. Robust Header Compression (rohc) -------------------------------- "Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression", Krister Svanbro, 04-JAN-02, This document describes lower layer guidelines for robust headercompression (ROHC) and the requirements ROHC put on lower layers. Thepurpose of this document is to support the incorporation of robustheader compression algorithms, as specified in the ROHC workinggroup, into different systems such as those specified by 3GPP, 3GPP2,ETSI, etc. The document covers only lower layer guidelines forcompression of RTP/UDP/IP and UDP/IP headers as specified in [ROHC].Both general guidelines and guidelines specific for cellular systemsare treated. "Requirements for ROHC IP/TCP Header Compression", Lars-Erik Jonsson, 28-MAY-02, This document contains requirements on the TCP/IP header compressionscheme (profile) to be developed by the ROHC WG. The documentdiscusses 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 documentdefining RTP/UDP/IP requirements for ROHC. "Signaling Compression Requirements & Assumptions", H Hannu, 03-JUN-02, In wireless environments and especially in cellular systems, e.g. GSM(Global System for Mobile communications) and UMTS (Universal MobileTelecommunications System), there is a need to maximize the transportefficiency for data over the radio interface. With the introductionof SIP/SDP (Session Initiation Protocol/Session Description Protocol)to cellular devices, compression of the signaling messages should beconsidered in order to improve both service availability and quality,mainly by reducing the user idle time, e.g. at call setup. Thepurpose of this document is to outline requirements and motivationsfor development of a scheme for compression and decompression ofmessages from signaling protocols. "Signaling Compression", R. Price, 03-JUN-02, This document defines SigComp, a solution for compressing messagesgenerated by application protocols such as SIP [RFC-2543] and RTSP[RFC-2326]. The architecture and pre-requisites of SigComp areoutlined, along with the format of the SigComp message.Decompression functionality for SigComp is provided by a 'UniversalDecompressor Virtual Machine' optimized for the task of runningdecompression algorithms. The UDVM can be configured to understandthe output of many well-known compressors such as DEFLATE [RFC-1951]. "Framework for EPIC-LITE", R. Price, 06-MAR-02, This draft describes the framework of the Efficient ProtocolIndependent Compression (EPIC-LITE) scheme. "Definitions of Managed Objects for Robus Header Compression", Juergen Quittek, 03-JUL-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 a set of managed objects that allowmonitoring of running instances of robust header compression. "0-byte Support for R-mode in Link-Layer Assisted ROHC Profile", Zhigang Liu, Khiem Le, 06-MAY-02, This document defines an additional mode of the link-layer assistedRObust Header Compression (ROHC) profile, also known as the zero-byteprofile, beyond the two defined in RFC 3242. Zero-byte headercompression exists in order to prevent the single-octet ROHC headerfrom pushing a packet voice stream into the next higher fixed packetsize for the radio. It is usable in certain widely deployed olderair interfaces. This document adds the zero-byte operation for ROHCReliable Bidirectional mode (R-mode) to the ones specified forUnidirectional (U-mode) and Optimistic (O-mode) modes of headercompression in RFC 3242. "SigComp - Extended Operations", H Hannu, 03-JUN-02, This document describes how to implement certain mechanisms inSigComp (Signaling Compression), RFC XXX, which can significantlyimprove the compression efficiency compared to using simple per-message compression.SigComp uses a UDVM (Universal Decompressor Virtual Machine) fordecompression, and the mechanisms described in this document arepossible to implement using the UDVM instructions defined in RFC XXX. "Universal Decompressor Virtual Machine (UDVM)", R. Price, 28-JAN-02, This draft defines a 'Universal Decompressor Virtual Machine'optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as [DEFLATE]. "TCP/IP Header Compression for ROHC (ROHC-TCP)", Qian Zhang, 05-JUL-02, Existing TCP/IP header compression schemes do not work well on noisy links, especially the one with high bit error rate and long roundtrip time. For many bandwidth limited links where header compression is essential, such characteristics are common. In addition, existing schemes [VJHC, IPHC] have not addressed how to compress TCP options such as SACK [RFC2018, RFC2883] and Timestamps [RFC1323]. A robust and efficient header compression scheme for TCP/IP, called ROHC-TCP, is proposed within the basic RObust Header Compression [ROHC] framework. "ROHC Implementer's Guide", Lars-Erik Jonsson, Peter Kremer, 01-JUL-02, This document describes common misinterpretations and some ambiguouspoints of ROHC [RFC 3095], which defines the framework and fourprofiles of a robust and efficient header compression scheme. Thesepoints have been identified by the members of the ROHC working groupduring different interoperability test events. "Requirements for RoHC IP/SCTP Robust Header Compression", C. Schmidt, M. Tuexen, 27-AUG-02, This document contains requirements for the IP/SCTP headercompression scheme (profile) to be developed by the ROHC WG. Thestructure of this document is inherited from the document definingIP/TCP requirements for ROHC. "TCP/IP Field Behavior", S. McCanne, M. West, 25-MAR-02, This draft describes TCP/IP field behavior in the context of headercompression.Header compression is possible thanks to the fact that most headerfields do not vary randomly from packet to packet. Many of thefields exhibit static behavior or change in a more or lesspredictable way. When designing a header compression scheme, it isof fundamental importance to understand the behavior of the fields indetail. Reliable Server Pooling (rserpool) ---------------------------------- "Architecture for Reliable Server Pooling", Lyndon Ong, Melinda Shore, Maureen Stillman, Qiaobing Xie, J. Loughney, M. Tuexen, Mark Stewart, 05-JUL-02, This document describes an architecture and protocols for themanagement and operation of server pools supporting highly reliableapplications, and for client access mechanisms to a server pool. "Comparison of Protocols for Reliable Server Pooling", J. Loughney, 05-JUL-02, This document compares protocols that may be applicable for Reliable Server Pooling problem space. This document discusses the usage and applicability of these protocols for Reliable Server Pooling. "Aggregate Server Access Protocol (ASAP)", Maureen Stillman, Qiaobing Xie, M. Tuexen, Randall Stewart, 03-JUL-02, Aggregate Server Access Protocol (ASAP) in conjunction with theEndpoint Name Resolution Protocol (ENRP) [6] provides a highavailability data transfer mechanism over IP networks. ASAP uses aname-based addressing model which isolates a logical communicationendpoint from its IP address(es), thus effectively eliminating thebinding between the communication endpoint and its physical IPaddress(es) which normally constitutes a single point of failure.In addition, ASAP defines each logical communication destination as apool, providing full transparent support for server-pooling and loadsharing. It also allows dynamic system scalability - members of aserver pool can be added or removed at any time without interruptingthe service.ASAP is designed to take full advantage of the network levelredundancy provided by the Stream Transmission Control Protocol(SCTP) RFC2960 [4]. Each transport protocol to be used by PoolElements (PE) and Pool Users (PU) MUST have an accompanyingtransports mapping document. Note that ASAP messages passed betweenPE's and ENRP servers MUST use SCTP.The high availability server pooling is gained by combining twoprotocols, namely ASAP and ENRP, in which ASAP provides the userinterface for name to address translation, load sharing management,and fault management while ENRP defines the high availability nametranslation service. "Enpoint Name Resolution Protocol (ENRP)", Maureen Stillman, Qiaobing Xie, Randall Stewart, 11-SEP-02, Endpoint Name Resolution Protocol (ENRP) is designed to work inconjunction with the Aggregate Server Access Protocol (ASAP) toaccomplish the functionality of the Reliable Server Pooling(Rserpool) requirements and architecture. Within the operationalscope of Rserpool, ENRP defines the procedures and message formats ofa distributed, fault-tolerant registry service for storing,bookkeeping, retrieving, and distributing pool operation andmembership information. "Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution (ENRP) common parameters document", Qiaobing Xie, Randall Stewart, 03-JUL-02, Aggregate Server Access Protocol (ASAP) [4] in conjunction with theEndpoint Name Resolution Protocol (ENRP) [5] provides a highavailability data transfer mechanism over IP networks.Both protocols work together and so share many common parameters usedin message formats. This document details the common messageparameters shared between the two protocols. This document providesparameter formats only, for procedures and message composition pleaserefer to the respective ASAP [4] and ENRP [5] documents. "Reliable Server Pooling : Management Information Base using SMIv2", P. Conrad, Jaiwant Mulik, Kevin Pinzhoffer, 09-MAY-02, RserPool [20] is a framework to provide reliable server pooling.This document defines a SMIv2 compliant Management Information Base(MIB) providing access to managed object in an RSerPoolimplementation. Open Security Area Directorate (saag) ------------------------------------- "Encryption and Security Requirements for IETF Standard Protocols", J. Schiller, 11-JUL-01, It is the consensus of the IETF that IETF standard protocols MUSTmake use of appropriate strong security mechanisms. This documentdescribes the history and rationale for this doctrine and establishesthis doctrine as a best current practice. Securely Available Credentials (sacred) --------------------------------------- "Securely Available Credentials - Credential Server Framework", Magnus Nystrom, Mike Just, Dale Gustafson, 13-JUN-02, 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 draft responds to the credential server framework requirements listed in [RFC3157]. It presents a strawman framework and outlines protocols for securely available credentials. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC-2119 [1]. Please send comments on this document to the ietf-sacred@imc.org mailing list. "Securely Available Credentials Protocol", Stephen Farrell, 26-FEB-02, This document describes an SRP-based protocol for securely availablecredentials. Discussion of this draft is taking place on the SACREDmailing list of the IETF SACRED working group (seehttp://www.imc.org/ietf-sacred for subscription information). Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting (seamoby) --------------------------------------------------------------------------------------- "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", J Kempf, 28-NOV-01, In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. In some cases, the host may establish certain routing-related services on subnets that are left behind when the host moves. Examples of such services are AAA, header compression, and QoS. In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called 'context transfer'. This document discusses the desirability of context transfer for facilitating seamless IP mobility. "General Requirements for a Context Transfer", Gary Kenward, 06-SEP-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 transferof context information may be advantageous in minimizing the impactof host mobility on IP services. This document captures the set of requirements for a context transfer framework and the requirementsfor a generic context transfer protocol to carry the context betweenthe context transfer peers. "Issues in candidate access router discovery for seamless IP-level handoffs", James Kempf, Govind Krishnamurthi, Hemant Chaskar, Dirk Trossen, 11-JUN-02, Handoff in IP mobility protocols involves moving a mobile node'sLayer 3 routing reachability point from one access router toanother, before or after the mobile node has established a Layer 2connection with the radio access point that is covered by the newaccess router. In addition, other context information about themobile node's IP service may be transferred from the old accessrouter to the new one, in order to minimize the service disruptionduring the handoff process. While the exact details of how this isaccomplished vary depending on the IP mobility and seamless handoffprotocols, one common thread required for IP-level handoffs isdiscovering the candidate access routers for the mobile node'shandoff. Discovering the candidate access router involvesidentifying its IP address as well as its capabilities that themobile node might be interested in. At the time of IP-level handoff,if a collection of candidates is identified, an algorithm is run todetermine the target access router for the mobile node's handoff.This document describes the problem of candidate access routerdiscovery. The document does not discuss the algorithm by which theactual target access router is selected, nor how the handoff to thetarget is achieved. "Dormant Mode Host Alerting (DMHA) Protocol Assessment", James Kempf, 31-JAN-02, The Seamoby Working Group has been working toward specification of an IP-level protocol for Dormant Mode Host Alerting (DMHA), sometimes known as IP-paging or simply paging (the terms IP-DMHA, DMHA, IP Paging, and Paging will be used interchangeably in this document). A problem statement and requirements have been developed, and in response to a request for protocol submissions, five protocols were submitted. "Requirements for CAR Discovery Protocols", Govind Krishnamurthi, 02-AUG-02, The pre-requisite for IP based seamless mobility protocols is theknowledge of the access router (AR) to which a mobile node can behanded over to. Further, a handoff can be optimized if the capabilitiesof the AR being considered for handoff are known. The protocol whichdiscovers ARs for potential handoff along with their capabilities iscalled the CAR discovery protocol. In this draft we list therequirements which are to be met by any solution for CAR Discovery. "Mobility Related Terminology", Markku Kojo, Jukka Manner, 03-SEP-02, There is a need for common definitions of terminology in the work tobe done around IP mobility. This memo defines terms for mobilityrelated terminology. It is intended as a living document for use bythe Seamoby working group in Seamoby drafts and in WG discussions.Other working groups dealing with mobility may also take advantage ofthis terminology. Secure Shell (secsh) -------------------- "SSH Transport Layer Protocol", T. Rinne, T. Ylonen, Tero Kivinen, Markku Juhani Saarinen, Sami Lehtinen, 25-MAR-02, SSH is a protocol for secure remote login and other secure networkservices over an insecure network. "SSH Authentication Protocol", T. Rinne, T. Ylonen, Tero Kivinen, M Saarinen, Sami Lehtinen, 04-MAR-02, SSH is a protocol for secure remote login and other secure networkservices over an insecure network. This document describes the SSHauthentication protocol framework and public key, password, and host-based client authentication methods. Additional authenticationmethods are described in separate documents. "SSH Connection Protocol", T. Rinne, T. Ylonen, Tero Kivinen, M Saarinen, Sami Lehtinen, 01-FEB-02, SSH is a protocol for secure remote login and other secure networkservices over an insecure network. "SSH Protocol Architecture", T. Rinne, T. Ylonen, Tero Kivinen, M Saarinen, Sami Lehtinen, 01-FEB-02, SSH is a protocol for secure remote login and other secure networkservices over an insecure network. This document describes thearchitecture of the SSH protocol, as well as the notation andterminology used in SSH protocol documents. "Generic Message Exchange Authentication For SSH", Frank Cusack, Martin Forssen, 05-APR-02, SSH is a protocol for secure remote login and other secure networkservices over an insecure network. This document describes a generalpurpose authentication method for the SSH protocol, suitable forinteractive authentications where the authentication data should beentered via a keyboard. The major goal of this method is to allowthe SSH client to have little or no knowledge of the underlyingauthentication mechanism(s) used by the SSH server. "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", Von Welch, Joseph Salowey, Joseph Galbraith, Jeffrey Hutzelman, 23-JUL-02, The Secure Shell protocol (SSH) is a protocol for secure remotelogin 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-independentfashion. "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol", W. Simpson, Niels Provos, Markus Friedl, 15-JAN-02, This memo describes a new key exchange method for the SSH protocol.It allows the SSH server to propose to the client new groups onwhich to perform the Diffie-Hellman key exchange. The proposedgroups need not be fixed and can change with time. "SSH Agent Forwarding", Darren Moffat, 27-FEB-02, SSH is a protocol for secure remote login and other secure networkservices over an insecure network. One of the common authenticationmechanisms used with SSH is public key. This document describes theauthentication agent forwarding protocol, which runs as a channelover [SSH-TRANS] it is designed to ensure that the sensitive privatekeys never leave the users control even when using SSH to login overmultiple hops. "SSH Fingerprint Format", Markus Friedl, 28-MAR-02, This document formally documents the fingerprint format in use forverifying public keys from SSH clients and servers. "SSH Protocol Assigned Numbers", Sami Lehtinen, Darren Moffat, 20-JUN-02, This document defines the initial state of the IANA assigned numbersfor the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], [SSH-USERAUTH]. This document does not define any newprotocols or any number ranges not already defined in the abovereferenced documents. It is intended only for initalization of theIANA databases referenced in those documents. "Using DNS to securely publish SSH key fingerprints", W. Griffin, J. Schlyter, 13-AUG-02, This document describes a method to verify SSH host keys usingDNSSEC. The document defines a new DNS resource record that containsa standard SSH key fingerprint. Signaling Transport (sigtran) ----------------------------- "Signaling System 7 (SS7) Message Transfer Part (MTP)2 - User Adaption Layer", J Mitchell, Ram Dantu, Greg Sidebottom, K Morneault, Jacob Heitz, Tom George, 21-FEB-02, This Internet Draft defines a protocol for backhauling of SS7 MTP2User signaling messages over IP using the Stream ControlTransmission Protocol (SCTP). This protocol would be used between aSignaling Gateway (SG) and Media Gateway Controller (MGC). It isassumed that the SG receives SS7 signaling over a standard SS7interface using the SS7 Message Transfer Part (MTP) to providetransport. The Signaling Gateway would act as a Signaling LinkTerminal. "SS7 MTP3-User Adaptation Layer (M3UA)", Greg Sidebottom, 08-FEB-02, This Internet Draft defines a protocol for supporting the transport of any SS7 MTP3-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 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. "Stream Control Transmission Protocol Management Information Base using SMIv2", Javier Pastor, Maria-Carmen Belinchon, 21-FEB-02, The Stream Control Transmission Protocol (SCTP) is a reliabletransport protocol operating on top of a connectionless packetnetwork such as IP, designed to transport PSTN signaling messagesover the connectionless packet network, but is capable of broaderapplications.This memo defines the Management Information Base (MIB) module whichdescribes the minimum amount of objects needed to manage theimplementation of the SCTP. "Signalling Connection Control Part User Adaptation Layer (SUA)", Greg Sidebottom, J. Loughney, 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, 28-MAR-02, This document describes the applicability of the new protocolsdeveloped under the signaling transport framework[RFC2719]. Adescription of the main issues regarding the use of the StreamControl Transmission Protocol (SCTP)[RFC2960] and each adaptationlayer for transport of telephony signalling information over IPinfrastructure is explained. "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Tom George, 29-AUG-02, This Internet Draft defines a protocol supporting the transport ofSignaling System Number 7 (SS7) Message Transfer Part (MTP) Layer 3signaling messages over Internet Protocol (IP) using the services ofthe Stream Control Transmission Protocol (SCTP). This protocol wouldbe used between SS7 Signaling Points employing the MTP Level 3protocol. The SS7 Signaling Points may also employ standard SS7 linksusing the SS7 MTP Layer 2 to provide transport of MTP Layer 3signaling messages. "SS7 MTP3-User Adaptation Layer (M3UA)Management Information Base using SMIv2", Antonio Roque, 09-AUG-02, The MTP3-User Adaptation Layer is a protocol for the transport of any SS7 MTP3-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 signalling over a standard SS7 interface usingthe SS7 Message Transfer Part (MTP) to provide transport.This memo defines the Management Information Base (MIB) module whichdescribes the minimum amount of objects needed to manage theimplementation of the M3UA. "V5.2-User Adaption Layer (V5UA)", Neeraj Khanchandani, Sanjay Rao, Eva Weilandt, 03-JUN-02, This document defines a mechanism for backhauling of V5.2 messagesover IP using the Stream control Transmission Protocol (SCTP). Thisprotocol would be used between a Signaling Gateway (SG) and a MediaGateway controller (MGC). It is assumed that the SG receives V5.2 sig-naling over a standard V5.2 interface.This document aims to build on top of the ISDN User Adaptation LayerProtocol (RFC 3057). It defines all differences to the IUAP needed forthe V5.2 implementation. "DPNSS/DASS 2 extensions to the IUA protocol", Anil Vydyam, 24-MAY-02, This document defines a mechanism for backhauling of DPNSS [2] andDASS2 [3] messages over IP by extending the ISDN User Adaptation Layer Protocol [1]. This document aims to become an Appendix to IUA [1] and to be the base for a DPNSS/DASS User Adaptation (DUA) implementation. "M3UA Implementor’s Guide", K Morneault, Javier Pastor, 01-JUL-02, This document contains a compilation of all defects found up untilMarch 2002 for the M3UA [RFCxxx]. These defects may be of aneditorial or technical nature. This document may be thought of as acompanion document to be used in the implementation of M3UA toclarify errors in the original M3UA document. This document updatesRFCxxxx and text within this document supersedes the text found inRFCxxxx "IUA (RFC 3057) Outstanding Issues", K Morneault, 22-JUL-02, This document captures problems and issues discovered on the SIGTRANmailing 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, issuesthat 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. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "Session Initiation Protocol (SIP) Extensions for Presence", J. Rosenberg, 21-MAY-02, This document describes the usage of the Session Initiation Protocol(SIP) for subscriptions and notifications of user presence. Userpresence is defined as the willingness and ability of a user tocommunicate with other users on the network. Historically, presencehas been limited to 'on-line' and 'off-line' indicators; the notionof presence here is broader. Subscriptions and notifications of userpresence are supported by defining an event package within thegeneral SIP event notification framework. This protocol is alsocompliant with the Common Presence and Instant Messaging (CPIM)framework. "An Extensible Markup Language (XML) Based Format for Watcher Information", J. Rosenberg, 21-MAY-02, Watchers are defined as entities that request (i.e., subscribe to)information about a resource. There is fairly complex stateassociated with these subscriptions. The union of the state for allsubscriptions to a particular resource is called the watcherinformation for that resource. This state is dynamic, changing assubscribers come and go. As a result, it is possible, and indeeduseful, to subscribe to the watcher information for a particularresource. In order to enable this, a format is needed to describe thestate of watchers on a resource. This specification describes an XMLdocument format for such state. "A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information", J. Rosenberg, 21-MAY-02, This document defines the watcher information template-package forthe SIP event framework. Watcher information refers to the set ofusers subscribed to a particular resource within a particular eventpackage. Watcher information changes dynamically as users subscribe,unsubscribe, are approved, or are rejected. A user can subscribe tothis information, and therefore learn about changes to it. This eventpackage is a template-package because it can be applied to any eventpackage, including itself. "CPIM Mapping of SIMPLE Presence and Instant Messaging", J. Rosenberg, Ben Campbell, 28-JUN-02, The SIMPLE work group has defined a SIP events package fordistribution of presence information. It has also proposed a MESSAGEextension for the transport of instant messages. This documentdescribes how those mechanisms map to the abstract CPIM service, inorder to interoperate with other CPIM compliant presence and instantmessaging services. "A SIP Event Package for List Presence", J. Rosenberg, Ben Campbell, 28-JUN-02, This document presents a SIP event package for subscribing to a listof presentities. Instead of the subscriber sending a SUBSCRIBE toeach presentity individually, the subscriber can subscribe to theirpresence list as a whole, and then receive notifications when thestate of any of the presentities on the list changes. Session Initiation Protocol (sip) --------------------------------- "Session Initiation Protocol Extension for Session Timer", J. Rosenberg, S. Donovan, 05-JUL-02, This document defines an extension to the Session Initiation Protocol(SIP). This extension allows for a periodic refresh of SIP sessionsthrough a re-INVITE or UPDATE request. The refresh allows both useragents and proxies to determine if the SIP session is still active.The extension defines two new header fields, Session-Expires, whichconveys the lifetime of the session, and Min-SE, which conveys theminimum allowed value for the session timer. "Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities", J. Rosenberg, H. Schulzrinne, 05-JUL-02, This document describes a set of extensions to the Session InitiationProtocol (SIP) which allow a caller to express preferences aboutrequest handling in servers. These preferences include the ability toselect which URIs a request gets routed to, and to specify certainrequest handling directives in proxies and redirect servers. It doesso by defining three new request headers, Accept-Contact, Reject-Contact and Request-Disposition, which specify the caller'spreferences. The extension also defines new parameters for theContact header that describe the characterstics of a UA. "Management Information Base for Session Initiation Protocol", Dave Walker, Joon Maeng, Jean-Francois Mule, Kevin Lingle, 14-FEB-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 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. "SIP Call Control - Transfer", Robert Sparks, 05-MAY-02, This document describes providing Call Transfer capabilites in SIP.Transfer capabilities. This work is part of the Call ControlFramework "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", J. Rosenberg, H Schulzrinne, 07-JUN-02, The Session Initiation Protocol (SIP) is a flexible, yet simple toolfor establishing interactive connections across the Internet. Part ofthis flexibility is the ease with which it can be extended. In orderto facilitate effective and interoperable extensions to SIP, someguidelines need to be followed when developing SIP extensions. Thisdocument outlines a set of such guidelines for authors of SIPextensions. "SIP Extensions for Media Authorization", D Evans, W. Marshall, F Andreasen, 23-MAY-02, This document describes the need for QoS and media authorization and defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. "Integration of Resource Management and SIP", J. Rosenberg, G. Camarillo, F Andreasen, 08-APR-02, This document defines a generic framework for preconditions which isextensible through IANA registration. This document also discusseshow network quality of service can be made a precondition toestablishment of sessions initiated by the Session InitiationProtocol (SIP). These preconditions require that the participantreserve network resources before continuing with the session. We donot define new quality of service reservation mechanisms; thesepreconditions simply require a participant to use existing resourcereservation mechanisms before beginning the session "The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol", J. Rosenberg, H. Schulzrinne, G. Camarillo, 01-JUL-02, This document specifies a mechanism for usage of SCTP (the StreamControl Transmission Protocol) as the transport between SIP entities.SCTP is a new protocol which provides several features that may provebeneficial for transport between SIP entities which exchange a largeamount of messages, including gateways and proxies. As SIP istransport independent, support of SCTP is a relativelystraightforward process, nearly identical to support for TCP. "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", J. Rosenberg, H. Schulzrinne, J. Weinberger, 05-JUL-02, The Session Initiation Protocol (SIP) operates over UDP and TCP. Whenused with UDP, responses to requests are returned to the sourceaddress the request came from, but from the port written into thetopmost Via header of the request. This behavior is not desirable inmany cases, most notably, when the client is behind a NAT. Thisextension defines a new parameter for the Via header, called rport,that allows a client to request that the server send the responseback to the source IP address and port where the request came from. "The SIP Refer Method", Robert Sparks, 23-JUL-02, This document defines the REFER method. This SIP extension requeststhat the recipient REFER to a resource provided in the request. Itprovides a mechanism allowing the party sending the REFER to benotified of the outcome of the referenced request. This can be usedto enable many applications, including call transfer.In addition to the REFER method, this document defines the the referevent package and the Refer-To request header. "Internet Media Types message/sipfrag", Robert Sparks, 29-APR-02, This document registers the message/sipfrag MIME media type. Thistype is similar to message/sip , but allows fragments of well formedSIP messages to be used for the same tunelling purposes as message/sip. In addition to end-to-end security uses , message/sipfrag isused with the REFER method to tunnel information about the status ofa referrenced request. "Session Initiation Protocol Extension for Instant Messaging", J. Rosenberg, Ben Campbell, 25-JUL-02, Instant Messageing (IM) refers to the transfer of messages betweenusers in near real-time. These messages are usually, but notrequired to be, short. IMs are often used in a conversational mode,that is, the transfer of messages back and forth is fast enough forparticipants to maintain an interactive conversation.The MESSAGE method is an extension to the Session Initation Protocol(SIP) that allows the transfer of Instant Messages. MESSAGE requestscarry the content in the form of MIME body parts. MESSAGE requestsdo not themselves initiate a SIP dialog; under normal usage eachInstant Message stands alone, much like pager messages. MESSAGErequests may be sent in the context of a dialog initiated by someother SIP request.Since the MESSAGE request is an extension to SIP it inherits all therequest routing and security features of that protocol. "The Session Inititation Protocol (SIP) 'Replaces' Header", Rick Dean, Billy Biggs, R. Mahy, 16-MAY-02, This document defines a new header for use with SIP multi-partyapplications and call control. The Replaces header is used tologically replace an existing SIP dialog with a new SIP dialog. Thisprimitive can be used to enable a variety of features, for example:'Attended Transfer' and 'Retrieve from Call Park'. Note thatdefinition of these example features is non-normative. "Session Initiation Protocol Extension for Registering Non-Adjacent Contacts", Dean Willis, Bernie Hoeneisen, 30-MAY-02, The REGISTER function is used in a SIP system primarily to associatea temporary contact address with an address-of-record. This contactis generally in the form of a URI, such as Contact: and is generally dynamic and associatedwith the IP address or hostname of the SIP UA. The problem is thatnetwork topology may have one or more SIP proxies between the UA andthe registrar, such that any request travelling from the user's homenetwork to the registered UA must traverse these proxies. TheREGISTER method does not give us a mechanism to discover and recordthis sequence of proxies in the registrar for future use. Thisdocument defines an extension header field, 'Path' which providessuch a mechanism "The Session Initiation Protocol UPDATE Method", J. Rosenberg, 01-MAY-02, This specification defines the new UPDATE method for the SessionInitiation Protocol (SIP). UPDATE allows a client to updateparameters of a session (such as the set of media streams and theircodecs) but has no impact on the state of a dialog. In that sense, itis like a re-INVITE, but can be sent before the initial INVITE hascompleted. This makes it very useful for updating session parameterswithin early dialogs. "DHCPv6 Options for SIP Servers", B. Volz, H. Schulzrinne, 10-APR-02, This document defines a DHCPv6 option that contains a list of domainnames or IPv6 addresses that can be mapped to one or more SIPoutbound proxy servers. This is one of the many methods that a SIPclient can use to obtain the addresses of such a local SIP server. "HTTP Digest Authentication Using AKA", R. Housley, J Arkko, V Torvinen, 20-MAY-02, The Hypertext Transfer Protocol (HTTP) Authentication Frameworkincludes two authentication schemes: Basic and Digest. Both schemesemploy a shared secret based mechanism for access authentication.The Authentication and Key Agreement (AKA) mechanism performs userauthentication and session key distribution in Universal MobileTelecommunications System (UMTS) networks. AKA is a challenge-response based mechanism that uses symmetric cryptography. This memospecifies an AKA based one-time password generation mechanism forHTTP Digest access authentication. "Security Mechanism Agreement for SIP Sessions", Jari Arkko, 05-JUL-02, SIP has a number of security mechanisms. Some of them have been builtin to the SIP protocol, such as HTTP authentication or secureattachments. These mechanisms have even alternative algorithms andparameters. SIP does not currently provide any mechanism forselecting which security mechanisms to use between two entities. Inparticular, even if some mechanisms such as OPTIONS were used to makethis selection, the selection would be vulnerable against theBidding-Down attack. This document defines three header fields fornegotiating the security mechanisms within SIP between a SIP entityand its next SIP hop. A SIP entity applying this mechanism mustalways require some minimum security (i.e. integrity protection) fromall communicating parties in order to secure the negotiation, but thenegotiation can agree on which specific minimum security is used. "The Reason Header Field for the Session Initiation Protocol", David Oran, H. Schulzrinne, G. Camarillo, 14-MAY-02, For creating services, it is often useful to know why a SIP requestwas issued. This document defines a header field, Reason, thatprovides this information. The Reason header field is also intendedto be used to encapsulate a final status code in a provisionalresponse. This functionality is needed to resolve the 'HeterogeneousError Response Forking Problem', or HERFP. "The Referred-By Mechanism", Robert Sparks, 23-MAY-02, The SIP REFER method [2] provides a mechanism where one party (thereferror) provides a second party (the referree) with an arbitraryURI to reference. If that URI is a SIP URI, the referree will send aSIP request, often an INVITE, to that URI (the refer target). Thisdocument extends the REFER method allowing the referror to provideinformation about the reference to the refer target using thereferree as an intermediary. This information includes the identityof the referror and the URI to which the referror referred. Themechanism utilizes S/MIME to help protect this information from amalicious intermediary. This protection is optional, but a recipientmay refuse to accept a request unless it is present "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", M. Watson, J Peterson, C. Jennings, 27-AUG-02, This document describes private extensions to SIP that enable anetwork of trusted SIP servers to assert the identity ofauthenticated users, and the application of existing privacymechanisms to the identity problem. The use of these extensions isonly applicable inside an administrative domain with previouslyagreed-upon policies for generation, transport and usage of suchinformation. This document does NOT offer a general privacy oridentity model suitable for use between different trust domains, oruse in the Internet at large. "A Privacy Mechanism for the Session Initiation Protocol (SIP)", J. Peterson, 07-JUN-02, This document defines new mechanisms for the Session InitiationProtocol (SIP) in support of privacy. Specifically, guidelines areprovided for the creation of messages that do not divulge personalidentity information. A new 'privacy service' logical role forintermediaries is defined to answer some privacy requirements thatuser agents cannot satisfy themselves. Finally, means are presentedby which a user can request particular functions from a privacyservice. "Compressing the Session Initiation Protocol", G. Camarillo, 06-AUG-02, This document describes a mechanism to signal that compression isdesired for one or more SIP messages. It also states when it isappropriate 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, 27-AUG-02, This document defines a SIP extension header field used inconjunction with responses to REGISTER requests to provide amechanism by which a registrar may inform a registering UA of aservice route that the UA may use to request outbound services fromthe registrar's domain. "Session Initiation Protocol Extension to Assure Congestion Safety", Dean Willis, Ben Campbell, 06-AUG-02, The Session Initiation Protocol allows the use of UDP for transportof SIP messages. The use of UDP inherently risks network congestionproblems, as UDP itself does not define congestion prevention,avoidance, detection, or correction mechanisms. This problem isaggravated by large SIP messages which fragment at the UDP level.Transport protocols in SIP are also negotiated on a per-hop basis, atthe SIP level, so SIP proxies may convert from TCP to UDP and soforth. This document defines what it means for SIP nodes to becongestion safe and specifies an extension by which a SIP User Agentmay require that its requests are treated in a congestion safemanner. "A Mechanism for Content Indirection in SIP Messages", Sean Olson, 14-AUG-02, This Internet-Draft proposes an extension to the URL MIME External-Body Access-Type as defined in RFC2017 [7] to satisfy the contentindirection requirements defined in draft-ietf-sipping-content-indirect-01 [1]. These extensions are aimed at allowing any MIMEpart in a SIP message to be referred to indirectly via a URL [4]. "Internet Media Type message/sipfrag", Robert Sparks, 13-SEP-02, This document registers the message/sipfrag MIME media type. Thistype is similar to message/sip , but allows certain subsets of wellformed SIP messages to be represented instead of requiring a completeSIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about thestatus of a referenced request Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Models for Multi Party Conferencing in SIP", J. Rosenberg, H. Schulzrinne, 05-JUL-02, The Session Initiation Protocol (SIP) can support multi-partyconferencing in many different ways. In this draft, we define thevarious multi-party conferencing models, and for each, discuss howthey are used and then analyze their relative benefits and drawbacks. "ISUP to SIP Mapping", G. Camarillo, 26-AUG-02, This document describes a way to perform the mapping between twosignaling protocols: the Session Initiation Protocol (SIP) and theISDN User Part (ISUP) of SS7. This mechanism might be implementedwhen using SIP in an environment where part of the call involvesinterworking with the Public Switched Telephone Network (PSTN). "SIP for Telephones (SIP-T): Context and Architectures", A. Vemuri, J. Peterson, 05-JUL-02, The popularity of gateways that interwork between the PSTN (PublicSwitched Telephone Network) and SIP networks has motivated thepublication of a set ofcommon practices that can assure consistentbehavior across implementations. This document taxonomizes the usesof PSTN-SIP gateways, provides uses cases, and identifies mechanismsnecessary for interworking. The mechanisms detail how SIP providesfor both 'encapsulation' (carriage of PSTN signaling across a SIPnetwork) and 'translation' (protocol mapping). "Using ENUM SIP Applications", Hong Liu, Ben Campbell, J Peterson, James Yu, 08-FEB-02, Although SIP was clearly one of the primary applications for whichENUM was created, there is nevertheless widespread uncertainty aboutthe demarcation of SIP location services from ENUM. This documentattempts to sharpen the distinction between location servicesprovided by the two protocols, illustrating how the two protocolsmight work in concert and clarifying the authoring and processing ofENUM records for SIP applications "Mapping of ISUP Overlap Signalling to the Session Initiation Protocol", G. Camarillo, 12-AUG-02, This document describes a way to map ISUP overlap signalling to SIP.This mechanism might be implemented when using SIP in an environmentwhere part of the call involves interworking with the Public SwitchedTelephone Network (PSTN). "Session Initiation Protocol Call Flow Examples", Alan Johnston, 01-AUG-02, 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, and Gateways to the PSTN (Public Switch Telephone Network). Scenarios include SIP Registration, SIP to SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway via SIP. Call flow diagrams and message details are shown. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ANSI 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). Example SIP messages used for testing during SIP interoperability test events include SIP 'torture test' messages, and messages with invalid parameters, methods, and tags. "SIP Service Examples", Alan Johnston, 08-JUL-02, This informational document gives examples of SIP (Session Initiation Protocol) 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 method and Replaces header. 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", J. Li, Jean-Francois Mule, 28-FEB-02, 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. "A Multi-party Application Framework for SIP", R. Mahy, 05-JUL-02, This document defines a framework and requirements for multi-partyapplications in SIP. To enable discussion of multi-partyapplications we define an abstract call model for describing themedia relationships required by many of these applications. Themodel and actions described here are specifically chosen to beindependent of the SIP signaling and/or mixing approach chosen toactually setup the media relationships. In addition to its dialogmanipulation aspect, this framework includes requirements forcommunicating related information and events such as conference andsession state, and session history. This framework also describesother goals which embody the spirit of SIP applications as used onthe Internet. "Best Current Practices for Third Party Call Control in the Session Initiation Protocol", J. Rosenberg, H. Schulzrinne, G. Camarillo, J Peterson, 05-JUN-02, Third party call control refers to the ability of one entity tocreate a call in which communications is actually between otherparties. Third party call control is possible using the mechanismsspecified within the Session Initiation Protocol (SIP). However,there are several possible approaches, each with different benefitsand drawbacks. This document discusses best current practices for theusage of the SIP for third party call control. "Short Term Requirements for Network Asserted Identity", M. Watson, 10-JUN-02, There is no requirement for identities asserted by a UA in a SIPmessage to be anything other than the user's desired alias.A Network Asserted Identity is an identity initially derived by a SIPnetwork intermediary as a result of an authentication process. Thisdraft describes short term requirements for the exchange of NetworkAsserted Identities within networks of securely interconnectedtrusted nodes and to User Agents securely connected to such networks. "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) static dictionary for Signaling Compression (SigComp)", Miguel Garcia, 30-AUG-02, The Session Initiation Protocol (SIP) [2] is a text-based protocolfor initiating and managing communication sessions. The protocol canbe compressed by using Signaling Compression (SigComp) [1].Similarly, the Session Description Protocol (SDP) [24] is a text-based protocol intended for describing multimedia sessions for thepurposes of session announcement, session invitation, and other formsof multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achievehigher efficiency. The dictionary is compression algorithmindependent. "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", R. Mahy, 20-JUN-02, This draft proposes a SIP event package to carry message waitingstatus and message summaries from a messaging system to an interestedUser Agent. "Requirements for Content Indirection in SIP Messages", Sean Olson, 24-JUL-02, Various applications of the Session Initiation Protocol (SIP) requirethe exchange of information between endpoints that is potentially toolarge to reasonably send directly in a SIP message. This Internet-Draft defines requirements for a mechanism to indirectly specify suchinformation so that a more appropriate non-SIP channel may be usedfor the transfer. "NAT and Firewall Scenarios and Solutions for SIP", J. Rosenberg, R. Mahy, S. Sen, 27-JUN-02, The problem of firewall and nat traversal for SIP is a complex one,due, in part, to the large number of different scenarios and themultitude of solutions developed to solve them. In this draft, weenumerate the various scenarios which can arise, and for each, pointto some of the existing solutions for that scenario, and present callflows and explanations for how it works. "A Session Initiation Protocol (SIP) Event Package for Dialog State", J. Rosenberg, H. Schulzrinne, 27-JUN-02, This document defines a dialog event package for the SIP Eventsarchitecture, along with a data format used in notifications for thispackage. The dialog package allows users to subscribe to anotheruser, an receive notifications about the changes in state of INVITEinitiated dialogs that the user is involved in. "A Session Initiation Protocol (SIP) Event Package for Conference State", J. Rosenberg, H. Schulzrinne, 27-JUN-02, This document defines a conference event package for the SIP Eventsarchitecture, along with a data format used in notifications for thispackage. The conference package allows users to subscribe to a SIPURI that is associated with a conference. Notifications are sentabout changes in the membership of this conference, changes in activespeaker, and media mixing information. "Session Initiation Protocol PSTN Call Flows", Alan Johnston, 27-AUG-02, This informational document gives 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 and Clients, 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), ANSI 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, 27-AUG-02, 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", M. Barnes, 29-AUG-02, 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", G. Camarillo, J. Loughney, 11-SEP-02, As SIP services are deployed on the Internet, there is a need forauthentication, authorization and accounting of SIP sessions. Thisdocument sets out the basic requirements for this work. S/MIME Mail Security (smime) ---------------------------- "Implementing Company Classification Policy with the S/MIME Security Label", Weston Nicolls, 08-MAY-01, This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from 3 companies are used to provide worked examples. "CMS Symmetric Key Management and Distribution", Sean Turner, 10-JAN-02, This document describes a mechanism to manage (i.e., setup,distribute, and rekey) keys used with symmetric cryptographicalgorithms. Also defined herein is a mechanism to organize usersinto groups to support distribution of encrypted content usingsymmetric cryptographic algorithms. The mechanisms use theCryptographic Message Syntax (CMS) protocol [2] and CertificateManagement Message over CMS (CMC) protocol [3] to manage thesymmetric keys. Any member of the group can then later use thisdistributed shared key to decrypt other CMS encrypted objects withthe symmetric key. This mechanism has been developed to supportS/MIME Mail List Agents (MLAs). "Use of the RSAES-OAEP Transport Algorithm in CMS", R. Housley, 14-AUG-02, This document describes the use of the RSAES-OAEP key transportmethod of key management within the Cryptographic Message Syntax(CMS). "Transporting S/MIME Objects in X.400", Paul Hoffman, Chistopher Bonatti, 19-OCT-01, This document describes protocol options for conveying CMS-protectedobjects associated with S/MIME version 3 over an X.400 message transfersystem. "Securing X.400 Content with S/MIME", Paul Hoffman, Chistopher Bonatti, Anders Eggen, 27-AUG-01, This document describes a protocol for adding cryptographic signatureand encryption services to X.400 content. "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", R. Housley, Jim Schaad, 06-FEB-02, This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption and the RSAES-OAEP key transport method [PKCS#1v2.0] for key management with the Cryptographic Message Syntax (CMS) [CMS]. "Wrapping an HMAC key with a Triple-DES Key or an AES Key", R. Housley, Jim Schaad, 06-FEB-02, The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover the of wrapping a Triple-DES key with another Triple-DES key and wrapping an AES key with another AES key, respectively. This document specifies two similar mechanisms. One specifies the mechanism for wrapping an HMAC key with a Triple-DES key, and the other specifies the mechanism for wrapping an HMAC key with an AES key. "AES Key Wrap Algorithm", R. Housley, Jim Schaad, 06-FEB-02, The purpose of this document is to make the AES Key Wrap algorithm conveniently available to the Internet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES Key Wrap posted by NIST. "S/MIME Version 3.1 Certificate Handling", B. Ramsdell, 03-JUL-02, S/MIME (Secure/Multipurpose Internet Mail Extensions), described in[SMIME-MSG], provides a method to send and receive secure MIMEmessages. Before using a public key to provide security services, theS/MIME agent MUST certify that the public key is valid. S/MIME agentsMUST use PKIX certificates to validate public keys as described in theInternet X.509 Public Key Infrastructure (PKIX) Certificate and CRLProfile [KEYM]. S/MIME agents MUST meet the certificate processingrequirements documented in this document in addition to those statedin [KEYM].This specification is compatible with the Cryptographic Message Syntax[CMS] in that it uses the data types defined by CMS. It also inheritsall the varieties of architectures for certificate-based keymanagement supported by CMS. "S/MIME Version 3.1 Message Specification", B. Ramsdell, 03-JUL-02, S/MIME (Secure/Multipurpose Internet Mail Extensions) provides aconsistent way to send and receive secure MIME data. Based on thepopular Internet MIME standard, S/MIME provides the followingcryptographic security services for electronic messaging applications:authentication, message integrity and non-repudiation of origin (usingdigital signatures) and data confidentiality (using encryption).S/MIME can be used by traditional mail user agents (MUAs) to addcryptographic security services to mail that is sent, and to interpretcryptographic security services in mail that is received. However,S/MIME is not restricted to mail; it can be used with any transportmechanism that transports MIME data, such as HTTP. As such, S/MIMEtakes advantage of the object-based features of MIME and allows securemessages to be exchanged in mixed-transport systems.Further, S/MIME can be used in automated message transfer agents thatuse cryptographic security services that do not require any humanintervention, such as the signing of software-generated documents andthe encryption of FAX messages sent over the Internet. Next Generation Structure of Management Information (sming) ----------------------------------------------------------- "SMIng - Next Generation Structure of Management Information", J. Schoenwaelder, Frank Strauss, 05-JUN-02, This memo presents an object-oriented data definition language forthe specification of various kinds of management information. It isindependent of management protocols and applications. Protocolmappings are defined as extensions to this language in separatememos. The language builds on experiences gained with the SMIv2 andits derivate SPPI. It is expected that the language presented inthis memo along with its protocol mappings will replace the SMIv2and the SPPI in the long term. "SMIng Internet Protocol Core Modules", J. Schoenwaelder, Frank Strauss, 05-JUN-02, This memo presents SMIng modules that introduce commonly usedInternet Protocol specific data definitions. They are provided sothat other SMIng modules that would otherwise define their ownrepresentations can import them from a common place. The IETF-INET module defines types and classes for representingInternet Protocol specific information. It builds on RFC 2851 andextends it in several ways. The IETF-INET-FILTER module extends the IETF-INET module byproviding generic definitions for typical IP packet filters. "SMIng Core Modules", J. Schoenwaelder, Frank Strauss, 05-JUN-02, This memo presents an SMIng module that introduces core data typessuch as counters, date and time related types, and various stringtypes. These definitions build on RFC 2578 and RFC 2579. "SMIng Mappings to SNMP", J. Schoenwaelder, Frank Strauss, 05-JUN-02, This memo presents an SMIng language extension that supports themapping of SMIng definitions of identities, classes, and theirattributes and events to dedicated definitions of nodes, scalarobjects, tables and columnar objects, and notifications forapplication in the SNMP management framework. "SMIng Mappings to COPS-PR", R Sahita, Harsha Hegde, 05-JUN-02, This memo presents an SMIng language extension that supports the mapping of SMIng definitions of identities, classes, and their attributes to dedicated definitions of nodes and tables for application in the policy based management framework [RAP-FRWK] using COPS-PR [COPS-PR]. "SMIng Compliance", Frank Strauss, 05-JUN-02, The memo [9], which has been approved by the IESG to be published asan Informational RFC, enumerates a number of objectives that theSMIng language is expected to fulfill. This memo describes thecompliance of a proposal based on former IRTF NMRG [8] work andpublished in [10] and companion I-Ds for each of the strivedobjectives. This is done by including the whole list of objectiveswithout any changes, but adding a compliance section for each of theobjectives, so that reading is as easy as possible. "Structure of Management Information:Data Structures", Andy Bierman, 16-MAY-02, This memo defines a portion of the Structure of Management Information(SMI) for use with network management protocols in the Internetcommunity. In particular, it describes a new structure and namingscheme for network management information, allowing the specification ofarbitrarily complex hierarchical data structures. "Capabilities MIB", Andy Bierman, 21-JUN-02, This memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for identifying the conformancecapabilities of all management information available from an SNMP agent. Configuration Management with SNMP (snmpconf) --------------------------------------------- "The Differentiated Services Configuration MIB", David Partain, H. Hazewinkel, 19-JUN-02, This memo describes a MIB module that provides a conceptual layerbetween high-level 'network-wide' policy definitions that affectconfiguration of the Differentiated Services (diffserv) subsystem andthe instance-specific information that would include such details asthe parameters for all the queues associated with each interface in asystem. This essentially provides an interface for configuringdifferentiated services at a conceptually higher layer than that ofthe Differentiated Services MIB. "Policy Based Management MIB", Steven Waldbusser, Jon Saperia, Thippanna Hongal, 08-JUL-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 thatenable policy-based configuration management of SNMPinfrastructures. "Configuring Networks and Devices with SNMP", Jon Saperia, W. Tackabury, David Partain, M. MacFaden, 14-JUN-02, This document is written for readers interested in the InternetStandard Management Framework and its protocol, the Simple NetworkManagement Protocol (SNMP). In particular, it offers guidance in theeffective use of SNMP for configuration management. This informationis relevant to vendors that build network elements, managementapplication developers, and those that acquire and deploy thistechnology in their networks. SNMP Version 3 (snmpv3) ----------------------- "Version 2 of the Protocol Operations for the Simple Network Management Protocol", M. Rose, Jeffrey Case, Steven Waldbusser, Keith McCloghrie, Randy Presuhn, 16-OCT-01, This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). This document obsoletesRFC 1905. It defines the syntax and elements of procedure forsending, receiving, and processing SNMP PDUs. "Transport Mappings for the Simple Network Management Protocol", M. Rose, Jeffrey Case, Steven Waldbusser, Keith McCloghrie, Randy Presuhn, 16-OCT-01, This document defines the transport of SNMP messages over variousprotocols. This document obsoletes RFC 1906. "Management Information Base for the Simple Network Management Protocol", M. Rose, Jeffrey Case, Steven Waldbusser, Keith McCloghrie, Randy Presuhn, 04-OCT-01, This document defines managed objects which describe the behavior ofan SNMP entity. This document obsoletes RFC 1907, ManagementInformation Base for Version 2 of the Simple Network ManagementProtocol (SNMPv2). "SNMP Applications", D. Levi, 27-NOV-01, This memo describes five types of SNMP applications which make use ofan SNMP engine as described in [SNMP-ARCH]. The types of applicationdescribed are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.This memo also defines MIB modules for specifying targets ofmanagement operations, for notification filtering, and for proxyforwarding.This memo will obsolete RFC2273. "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", Bert Wijnen, Uri Blumenthal, 30-NOV-01, This document describes the User-based Security Model (USM) for SNMPversion 3 for use in the SNMP architecture [SNMP-ARCH]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managingthe configuration parameters for this Security Model. "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", Keith McCloghrie, Bert Wijnen, Randy Presuhn, 30-NOV-01, This document describes the View-based Access Control Model for usein the SNMP architecture [SNMP-ARCH]. It defines the Elements ofProcedure for controlling access to management information. Thisdocument also includes a MIB for remotely managing the configurationparameters for the View-based Access Control Model. "An Architecture for Describing SNMP Management Frameworks", Bert Wijnen, Randy Presuhn, D. Harrington, 16-OCT-01, This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular toallow the evolution of the SNMP protocol standards over time. Themajor portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications whichprovide specific functional processing of management data. "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", Jeffrey Case, Bert Wijnen, Randy Presuhn, David Harrington, 16-OCT-01, This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC-ARCH]. It definesthe procedures for dispatching potentially multiple versions of SNMPmessages to the proper SNMP Message Processing Models, and fordispatching PDUs to SNMP applications. This document also describesone Message Processing Model - the SNMPv3 Message Processing Model. "Introduction and Applicability Statements for Internet-standard Network Management Framework", Jeffrey Case, 07-AUG-02, The purpose of this document is to provide an overview of thethird version of the Internet-Standard Management Framework,termed the SNMP version 3 Framework (SNMPv3). This Frameworkis derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the secondInternet-Standard Management Framework (SNMPv2).The architecture is designed to be modular to allow theevolution of the Framework over time.The document explains why using SNMPv3 instead of SNMPv1 orSNMPv2 is strongly recommended. The document also recommendsthat RFCs 1157, 1441, 1901, 1909 and 1910 be retired by movingthem to Historic status.This document obsoletes RFC 2570.This document is a work product of the SNMPv3 Working Group ofthe Internet Engineering Task Force (IETF). "Applicability Statement for SNMPv3 Cryptographic Algorithms", Randy Bush, Steve Bellovin, 28-FEB-02, This document attempts to put in perspective the use of cryptographicalgorithms in the Simple Network Monitoring Protocol Version 3standard. In particular, it notes that today's standard isinfinitely more secure than previous versions, as the previousversions had zero security. It further notes that, as cryptographicalgorthim developments change over time, we expect that therecommended algorithms will change when the security community hasreached new consensus. Speech Services Control (speechsc) ---------------------------------- "Requirements for Distributed Control of ASR, SR and TTS Resources", David Oran, E. Burger, 28-AUG-02, 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, speaker recognition (which includes both speaker identification and speaker verification) and text-to-speech. 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. Service in the PSTN/IN Requesting InTernet Service (spirits) ------------------------------------------------------------ "The SPIRITS Protocol", V Gurbani, 03-JUL-02, This document describes SPIRITS protocol. The purpose of the SPIRITSprotocol is to support services that originate in the Public SwitchedTelephone Network (PSTN) and necessitate the interactions between thePSTN and the Internet. Similarly, such services are called SPIRITSservices. Internet Call Waiting, Internet Caller-ID Delivery, andInternet Call Forwarding are examples of SPIRIT services, but theprotocol is to define the building blocks from which many otherservices can be built. On the PSTN side, the SPIRITS services areinitiated from the Intelligent Network (IN) entities. The earlierIETF work on the PSTN/Internet Interworking (PINT) resulted in theprotocol (RFC 2848) in support of the services initiated in thereverse direction - from the Internet to PSTN.This Internet-Draft has been written in response to the SPIRITS WGchairs call for SPIRITS Protocol proposals. Among othercontributions, this I-D is based on:o Informational RFC2995, 'Pre-SPIRITS implementations'o Informational RFC3136, 'The SPIRITS Architecture'o SPIRITS Protocol Requirements, presented in draft-ietf-spirits-reqs-04, current candidate for Informational RFC. "On selection of IN parameters for the SPIRITS Protocol", Alec Brusilovsky, 01-JUL-02, This document describes INAP parameters (IN information and its encoding) which the SPIRITS protocol can transport from the PSTN 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. These services include, but are not limited to: Incoming Call Notification (Internet Call Waiting), Internet Caller-Id Delivery, and Internet Call Forwarding ('Follow Me'). This draft outlines, what INAP parameters are of immediate interest to SPIRITS, how they may be extracted and encoded for use within the SPIRITS domain. INAP 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. Among other contributions, this I-D is based on: o Informational RFC2995, 'Pre-SPIRITS implementations' o SPIRITS Architecture, presented in draft-ietf-spirits-architecture-02, RFC 3136 o SPIRITS Protocol Requirements, presented in draft-ietf-spirits-reqs-04, current candidate for Informational RFC. "Toward the Definition of the SIP Events Package for SPIRITS Protocol", Vijay Gurbani, V Gurbani, Hui-Lan Lu, Jorge Gato, 19-FEB-02, This document describes the definition of the SIP EventPackage for SPIRITS, based on on the structure defined in [1], theSPIRITS protocol requirements documented in [2], the overall SPIRITSArchitecture presented in RFC 3136 [3], the discussion at theSalt Lake City meeting, and the subsequent decisions. To this end,the document defines the package and event names, and addressesthe SUBSCRIBE paramaters. "Mobility Events Management in SPIRITS", Daniel Moreno, 01-MAY-02, This document describes the management of the mobility eventsconsidered in SPIRITS protocol and the definition of their relatedparameters.The mobility events management will allow a SPIRITS server tosubscribe to and to be notified of location changes of a mobileuser. The events would only be applicable to mobile users reachablethrough a CS network. The sending of these events must be allowed bysetting the related marks in the HLR. Besides, the SPIRITS protocolmust be able to translate the CAMEL operations involving mobilityinformation into events that can be transferred to the SPIRITSclient. Source-Specific Multicast (ssm) ------------------------------- "An Overview of Source-Specific Multicast(SSM) Deployment", Supratik Bhattacharyya, 25-MAR-02, This document provides an overview of the Source-Specific Multicast(SSM) service and its deployment using the PIM-SM and IGMP/MLDprotocols. The network layer service provided by SSM is a 'channel',identified by an SSM destination IP address (G) and a source IPaddress S. "Source-Specific Multicast for IP", Brad Cain, Hugh Holbrook, 04-FEB-02, IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range aredesignated as source-specific multicast (SSM) destination addresses andare reserved for use by source-specific applications and protocols[IANA-ALLOCATION]. For IP version 6 (IPv6), a proposed range exists,although there is currently no IANA allocation [SSMIPv6]. This documentdefines the semantics of source-specific multicast addresses andspecifies the policies governing their use. Secure Network Time Protocol (stime) ------------------------------------ "Public-Key Cryptography for the Network Time Protocol Version 2", Duncan Mills, 07-FEB-02, This memorandum describes a scheme for authenticating servers to clients using the Network Time Protocol. It extends prior schemes based on symmetric key cryptography to a new scheme based on public key cryptography. The new scheme, called Autokey, is based on the premiss that the IPSEC schemes proposed by the IETF cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, the IPSEC model presumes authenticated timestamps are always available; however, cryptographically verified timestamps require interaction between the timekeeping function and authentication function in ways not yet considered in the IPSEC model. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "Syslog-Sign Protocol", John Kelsey, 25-JUL-02, This document describes syslog-sign, a mechanism adding originauthentication, message integrity, replay-resistance, messagesequencing, and detection of missing messages to syslog. Syslog-signprovides these security features in a way that has minimalrequirements and minimal impact on existing syslog implementations.It is possible to support syslog-sign and gain some of its securityattributes by only changing the behavior of the devices generatingsyslog messages. Some additional processing of the received syslogmessages and the syslog-sign messages on the relays and collectorsmay realize additional security benefits. "Syslog Device Configuration MIB", Bruno Pape, 07-JUN-02, This memo provides a MIB module that can be used to configure whichsyslog collectors or relays a syslog device will attempt to sendsyslog messages to. In addition it defines objects that allow thecollection of statistics related to the generation of syslog messages.And finally it provides a means for controlling the messages thatindividual applications on a device will generate. Internet Traffic Engineering (tewg) ----------------------------------- "Network Survivability Considerations for Traffic Engineered IP Networks", Fiffi Hellstrand, Ken Owens, Vishal Sharma, Mathew Oommen, 14-MAY-02, Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network [1]. This can be accomplished by recovering quickly from network failures quickly and maintaining the required QoS for existing services. With the increasing sophistication of network technologies, survivability capabilities are becoming available at multiple layers, allowing for protection and restoration to occur at any layer of the network. This makes it important to: scrutinize the recovery features of different network layers, understand the pros and cons of performing recovery at each layer, and assess how the interactions between layers impact network survivability. With these objectives in mind, this draft examines the considerations for network survivability at different layers of the network. "A Traffic Engineering MIB", K. Kompella, 03-SEP-02, This memo defines a standards-track portion of the ManagementInformation Base (MIB) for use with network management protocols inthe Internet community. In particular, it describes managed objectsfor Traffic Engineered Tunnels, for example, Multi-Protocol LabelSwitched Paths. "Traffic Engineering & QoS Methods for IP-, ATM-, & Based Multiservice Networks", Gerald Ash, 15-OCT-01, This is an informational document submitted in response to a request from the IETF Traffic Engineering Working Group (TEWG) for service provider uses, requirements, and desires for traffic engineering best current practices.As such, the work sets a direction for routing and traffic performancemanagement in networks based on traffic engineering (TE) and QoS bestcurrent practices and operational experience, such as used in the AT&Tdynamic routing/class-of-service network. "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering", W Lai, F Le Faucheur, 04-SEP-02, 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. "New TE LSAs to extend OSPF for Traffic Engineering", Pyda Srisuresh, Paul Joseph, 10-JAN-02, OSPF is a link state routing protocol used for IP-network topology discovery and collection and dissemination of linkaccess metrics. The resulting Link State Database (LSDB) isused to compute IP address forwarding table based on shortest-path criteria. "A Framework for Internet Traffic Engineering Measurement", Blaine Christian, Steven Van den Berghe, Wai Lai, Richard Tibbs, 12-SEP-02, 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. "Network Hierarchy and Multilayer Survivability", W Lai, 23-JUL-02, This document is the deliverable out of the Network Hierarchy and Survivability Techniques Design Team established within the Traffic Engineering Working Group. This team collected and documented current and near term requirements for survivability and hierarchy in service provider environments. For clarity, an expanded set of definitions is included. The team determined that there appears to be a need to define a small set of interoperable survivability approaches in packet and non-packet networks. Suggested approaches include path-based as well as one that repairs connections in proximity to the network fault. They operate primarily at a single network layer. For hierarchy, there did not appear to be a driving near-term need for work on 'vertical hierarchy,' defined as communication between network layers such as TDM/optical and MPLS. In particular, instead of direct exchange of signaling and routing between vertical layers, some looser form of coordination and communication, such as the specification of hold-off timers, is a nearer term need. For 'horizontal hierarchy' in data networks, there are several pressing needs. The requirement is to be able to set up many LSPs in a service provider network with hierarchical IGP. This is necessary to support layer 2 and layer 3 VPN services that require edge-to-edge signaling across a core network. Please send comments to te-wg@ops.ietf.org "Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering", F Le Faucheur, 02-JUL-02, This document specifies the IGP and signaling extensions and procedures (beyond those already specified for existing MPLS Traffic Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering "Use of Interior Gateway Protocol Metric as a second MPLS Traffic Engineering Metric", F 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). Transport Layer Security (tls) ------------------------------ "ECC Cipher Suites For TLS", C Hawk, V. Gupta, B Moeller, S. Blake-Wilson, 03-SEP-02, This document describes new key exchange algorithms based on EllipticCurve Cryptography (ECC) for the TLS (Transport Layer Security)protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use ofElliptic Curve Digital Signature Algorithm (ECDSA) as a newauthentication mechanism. "Extensions to TLS for OpenPGP keys", Wayne Price, M. Elkins, 19-FEB-02, This document builds upon the TLS Protocol Specification [TLS]. Theextensions described herein are intended to apply to Version 1.0 ofthe TLS specification.The purpose of this document is to update the TLS protocol withextensions to support the certificates, public key algorithms,symmetric ciphers, hash algorithms, and trust model used by OpenPGP[OpenPGP]. This document uses the same notation used in the TLS Protocol draft. "Addition of Camellia Ciphersuites to Transport Layer Security (TLS)", Shino Moriai, 06-AUG-02, This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the Camelliaencryption algorithm as a bulk cipher algorithm. "Using SRP for TLS Authentication", Dave Taylor, 04-SEP-02, This memo presents a technique for using the SRP [2] (Secure RemotePassword) protocol as an authentication method for the TLS[1](Transport Layer Security) protocol. "Transport Layer Security (TLS) Extensions", S. Blake-Wilson, 31-JUL-02, This document describes extensions that may be used to addfunctionality to TLS. It provides both generic extension mechanismsfor the TLS handshake client and server hellos, and specificextensions using these generic mechanisms.The extensions may be used by TLS clients and servers. The extensionsare backwards compatible - communication is possible between TLS 1.0clients that support the extensions and TLS 1.0 servers that do notsupport the extensions, and vice versa.This document is based on discussions within the TLS working groupand within the WAP security group. "Using OpenPGP keys for TLS authentication", Nikos Mavroyanopoulos, 16-AUG-02, This document proposes extensions to the TLS protocol to supportthe OpenPGP trust model and keys. The extensions discussed hereinclude a certificate type negotiation mechanism, and the requiredmodifications to the TLS Handshake Protocol. "The TLS Protocol Version 1.0", E. Rescorla, C Hawk, 05-MAR-02, This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications privacy overthe Internet. The protocol allows client/server applications tocommunicate in a way that is designed to prevent eavesdropping,tampering, or message forgery. "Transport Layer Security Protocol Compression Methods", S. Hollenbeck, 05-SEP-02, The Transport Layer Security (TLS) protocol (RFC 2246) includesfeatures to negotiate selection of a lossless data compression methodas part of the TLS Handshake Protocol and to then apply the algorithmassociated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method,CompressionMethod.null, which specifies that data exchanged via therecord protocol will not be compressed. This document describesadditional compression methods associated with lossless datacompression algorithms for use with TLS. Telnet TN3270 Enhancements (tn3270e) ------------------------------------ "TLS-based Telnet Security", Michael Boe, Jeffrey Altman, 11-APR-02, Telnet service has long been a standard Internet protocol. However, astandard way of ensuring privacy and integrity of Telnet sessions hasbeen lacking. This document proposes a standard method for Telnetservers and clients to use the Transport Layer Security (TLS) protocol.It describes how two Telnet participants can decide whether or not toattempt TLS negotiation, and how the two participants should processauthentication credentials exchanged as a part of TLS startup. "TN3270E Functional Extensions", Gene Pullen, Marty Williams, 18-APR-02, This draft addresses issues and implementation problems defined anddiscussed at the TN3270E/TN5250E Interoperability Events. It doesnot replace the current TN3270 Enhancements protocol. It describesfunctional extensions to the TN3270E protocol. The TN3270E functionnegotiation mechanism is used to allow the server and client todetermine which, if any, of these functions will be supported duringa session. This preserves backward compatibility between clientsand servers that do not support these features.Among the issues to be address by this draft are SNA/TN3270EContention state resolution and SNA Sense Code support. Internet Open Trading Protocol (trade) -------------------------------------- "Requirements and Design for Voucher Trading System (VTS)", Donald Eastlake, Ko Fujimura, 25-JUL-02, Crediting loyalty points and collecting digital coupons or giftcertificates are common functions in purchasing and tradingtransactions. These activities can be generalized using the conceptof a 'voucher', which is a digital representation of the right toclaim goods or services. This document presents a Voucher TradingSystem (VTS) that circulates vouchers securely and its terminology;it lists design principles and requirements for VTS and the GenericVoucher Language (GVL), with which diverse types of vouchers can bedescribed. "Payment API for v1.0 Internet Open Trading Protocol (IOTP)", Yoshiaki Kawatsura, Hans Beykirch, Werner Hans, Masaaki Hiroya, 05-APR-01, The Internet Open Trading Protocol provides a data exchange formatfor trading purposes while integrating existing pure paymentprotocols seamlessly. This motivates the multiple layered systemarchitecture which consists of at least some generic IOTP applicationcore 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 IOTPPayment API and a procedure in the Payment Bridge for use SET as thepayment protocol within Version 1.0 of the Internet Open TradingProtocol (IOTP). "Electronic Commerce Modeling Language (ECML):Version 2 Requirements", Donald Eastlake, Jon Parsons, 08-MAY-02, This document lists the design principles, scope, and requirementsfor the Electronic Commerce Modeling Language (ECML) version 2specification. It includes requirements as they relate to XML syntax,data model, format, payment processing, and external requirements. "XML Voucher: Generic Voucher Language", Ko Fujimura, Masayuki Terada, 17-JUN-02, This document specifies rules for defining voucher properties in XMLsyntax. A voucher is a logical entity that represents a right toclaim goods or services. A voucher can be used to transfer awide-range of electronic-values, including coupons, tickets, loyaltypoints, and gift certificates, which are often necessary to processin the course of payment and/or delivery transactions. "Electronic Commerce Modeling Language (ECML):Version 2 Specification", Donald Eastlake, Jon Parsons, 24-JUL-02, Electronic commerce frequently requires a substantial exchange ofinformation in order to complete a purchase or other transaction,especially the first time the parties communicate. A standard set ofhierarchicly organized payment related information fields in an XMLsyntax are defined as the second version of an Electronic CommerceModeling Language (ECML) so that this task can be more easilyautomated, for example by wallet software "Internet Open Trading Protocol (IOTP) Version 1, Errata", Donald Eastlake, 08-MAY-02, Since the publication of the RFCs specifying Version 1.0 of theInternet Trading Protocol, some errors have been noted. Thisinformational document lists these errors and provides correctionsfor them. "Voucher Trading System Application Programming Interface (VTS-API)", Ko Fujimura, Masayuki Terada, 04-SEP-02, This document specifies the Voucher Trading System ApplicationProgramming Interface (VTS-API). The VTS-API allows a wallet or otherapplication to issue, transfer, and redeem vouchers in a uniformmanner independent of the VTS implementation. The VTS is a system tosecurely transfer vouchers, e.g., coupons, tickets, loyalty points,and gift certificates; this process is often necessary in the courseof payment and/or delivery transactions. Transport Area Working Group (tsvwg) ------------------------------------ "TCP Processing of the IPv4 Precedence Field", Vern Paxson, Alan Hannan, X Xiao, 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 ofan IPv4 header [RFC791]. In a network that contains DiffServ-capablenodes, such a conflict can cause failures in establishing TCPconnections or can cause some established TCP connections to be resetundesirably. This draft proposes a modification to TCP for resolvingthe conflict. "A Conservative SACK-based Loss Recovery Algorithm for TCP", Kevin Fall, Mark Allman, Ethan Blanton, 24-JUL-02, This document presents a conservative loss recovery algorithmfor TCP that is based on the use of the selective acknowledgmentTCP option. The algorithm presented in this document conformsto the spirit of the current congestion control specification[RFC2581], but allows TCP senders to recover more effectivelywhen multiple segments are lost from a single flight of data. "TCP Friendly Rate Control (TFRC):Protocol Specification", Mark Handley, Sally Floyd, Jitendra Padhye, Joerg Widmer, 29-APR-02, This document specifies TCP-Friendly Rate Control (TFRC).TFRC is a congestion control mechanism for unicast flowsoperating in a best-effort Internet environment. It isreasonably fair when competing for bandwidth with TCP flows,but has a much lower variation of throughput over timecompared with TCP, making it more suitable for applicationssuch as telephony or streaming media where a relatively smoothsending rate is of importance. "Robust ECN Signaling with Nonces", David Wetherall, Neil Spring, David Ely, 29-APR-02, This note describes the ECN-nonce, an optional addition to ECN thatprotects against accidental or malicious concealment of markedpackets from the TCP sender. It improves the robustness ofcongestion control by preventing receivers from exploiting ECN togain an unfair share of network bandwidth. The ECN-nonce uses thetwo ECT codepoints in the ECN field of the IP header, and requires aflag in the TCP header. It is computationally efficient for bothrouters and hosts. "The Eifel Detection Algorithm for TCP", Michael Meyer, Reiner Ludwig, 24-JUL-02, The Eifel detection algorithm allows the TCP sender to detect aposteriori whether it has entered loss recovery unnecessarily. Italready determines this in the beginning of loss recovery when thefirst acceptable ACK arrives after the timeout-based retransmit orfast retransmit has been sent. The algorithm requires that the TCPTimestamps option defined in RFC1323 is enabled for a connection. Theidea is to use the timestamps echoed in returning ACKs to eliminatethe retransmission ambiguity in TCP. The Eifel detection algorithmprovides a basis for future TCP enhancements. This includes responsealgorithms to back out of loss recovery by restoring a TCP sender'scongestion control state. "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Randall Stewart, 15-MAY-02, This document describes extensions to the Stream ControlTransmission Protocol (SCTP) [RFC2960] that provides a method toreconfigure IP address information on an existing association. "Increasing TCP's Initial Window", C. Partridge, Sally Floyd, Mark Allman, 13-JUN-02, This document specifies an optional standard for TCP to increase thepermitted initial window from one segment to roughly 4K bytes,replacing RFC 2414. This document discusses the advantages anddisadvantages of the higher initial window. The document includesdiscussion of experiments and simulations showing that the higherinitial window does not lead to congestion collapse. Finally, thedocument provides guidance on implementation issues. "Sockets API Extensions for Stream Control Transmission Protocol", Randall Stewart, 15-MAY-02, This document describes a mapping of the Stream Control TransmissionProtocol [SCTP] into a sockets API. The benefits of this mappinginclude compatibility for TCP applications, access to new SCTPfeatures and a consolidated error and event notification scheme. "Stream Control Transmission Protocol (SCTP) Implementors Guide", Lyndon Ong, Randall Stewart, 01-JUL-02, This document contains a compilation of all defects found up untilthe publishing of this document for the Stream Control TransmissionProtocol (SCTP) RFC2960 [3]. These defects may be of an editorial ortechnical nature. This document may be thought of as a companiondocument to be used in the implementation of SCTP to clarify errorsin the original SCTP document.This document updates RFC2960 [3] and text within this documentsupersedes the text found in RFC2960 [3]. "Stream Control Transmission Protocol (SCTP) Checksum Change", Jonathan Stone, Douglas Otis, Randall Stewart, 07-MAY-02, Stream Control Transmission Protocol [RFC2960] (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum. "TLS over SCTP", E. Rescorla, M. Tuexen, Andreas Jungmaier, 19-NOV-01, This document describes the usage of the Transport Layer Security (TLS)protocol, as defined in [RFC2246], over the Stream Control TransmissionProtocol (SCTP), as defined in [RFC2960]. "The UDP Lite Protocol", M. Degermark, Lars-Åke Larzon, 25-JAN-02, This document describes the UDP Lite protocol, which is similar toclassic UDP [RFC-768], but can also serve applications which in lossynetwork environments prefer to have partially damaged payloadsdelivered rather than discarded. If this feature is not used, UDPLite is semantically identical to classic UDP. "TCP Extended Statistics MIB", R. Reddy, M. Mathis, Jon Saperia, J. Heffner, 05-JUL-02, This draft describes extended performance statistics for TCP. Theyare designed to use TCP's ideal vantage point to diagnose performanceproblems in both the network and the application. If a network basedapplication is performing poorly, TCP can determine if the bottleneckis in the sender, the receiver or the network itself. If the bottle-neck is in the network, TCP can provide specific information aboutits nature "The Eifel Response Algorithm for TCP", Reiner Ludwig, Andrei Gurtov, 15-AUG-02, The Eifel response algorithm uses the Eifel detection algorithm todetect a posteriori whether the TCP sender has entered loss recoveryunnecessarily. In response to a spurious timeout it avoids thego-back-N retransmits that would otherwise be sent, and reinitializesthe RTT estimators to avoid further spurious timeouts. Likewise, itadapts the duplicate acknowledgement threshold in response to aspurious fast retransmit. In both cases, the Eifel response algorithmrestores the congestion control state in way that avoids packetbursts. UniDirectional Link Routing (udlr) ---------------------------------- "Configuration of DVMRP over a UniDirectional Link", Yann Guinamand, Philippe Charron, Celine Benassy-Foch, 28-JUN-02, Routers connected to a UniDirectional Link (UDL) such as asatellite network, implement a link layer tunneling mechanism, asdefined in the RFC 3077 [UDLR]. These routers could exchangemulticast routing information. This document describes how DVMRPv3works on this network architecture and suggests a differentconfiguration of DVMRPv3 on routers connected to the UDL moreadapted and optimized to this network architecture. "Identifying Multicast Implications in a Link-Layer Tunneling Mechanism for Unidirectional Links", Jun Takei, Hidetaka Izumiyama, 28-MAR-02, This document describes operational information for deployingmulticast network with link layer tunneling mechanism whichdefined in [RFC3077]. RFC3077 defines the mechanism which allows aoperator to integrate unidirectional link(e.g. satellite linketc..) into the network transparently. In some multicast networkconfiguration, a certain configuration for unidirectional linkare necessary. This document clarifies the problem that exist whena operator use a multicast routing protocol with link layertunneling mechanism. It also describes how to solve those problemwith short term solutions and also long term solutions.This document does not define any new protocol. Uniform Resource Names (urn) ---------------------------- "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", M. Mealling, 07-MAY-02, RFCYYYY defines a how DNS is used as a DDDS database that containsURI delegation rules (sometimes called resolution hints). Thatdocument specifies that the first step in that algorithm is to append'URI.ARPA' to the URI scheme and retrieve the NAPTR record for thatdomain-name. I.e., the first step in resolving 'http://foo.com/'would be to look up a NAPTR record for the domain 'http.URI.ARPA'.URN resolution also follows a similar procedure but uses the'URN.ARPA' zone as its root. This document describes the proceduresfor inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. "Dynamic Delegation Discovery System (DDDS)Part Two: The Algorithm", M. Mealling, 07-MAY-02, This document describes the Dynamic Delegation Discovery System(DDDS) algorithm for applying dynamically retrieved stringtransformation rules to an application-unique string. Well-formedtransformation rules will reflect the delegation of management ofinformation associated with the string. This document is also partof a series that is completely specified in 'Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive DDDS Standard'(RFC WWWW). It is very important to note that it is impossible toread and understand any document in this series without reading theothers. " Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", M. Mealling, 07-MAY-02, This document describes a Dynamic Delegation Discovery SystemDatabase using the Domain Name System as a distributed database ofRules. The Keys are domain-names and the Rules are encoded using theNAPTR Resource Record.Since this document obsoletes RFC 2915, it is the officialspecification for the NAPTR DNS Resource Record. It is also part ofa series that is completely specified in 'Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive DDDS Standard'(RFC WWWW). It is very important to note that it is impossible toread and understand any document in this series without reading theothers. "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", M. Mealling, 07-MAY-02, A specification for taking a URI and locating an authoritative serverfor information about that URI. The method used to locate thatauthoritative server is the Dynamic Delegation Discovery System.This document is part of a series that is specified in 'DynamicDelegation Discovery System (DDDS) Part One: The Comprehensive DDDSStandard' (RFC WWWW). It is very important to note that it isimpossible to read and understand any document in this series withoutreading the others. "URN Namespace Definition Mechanisms", Patrik Faltstrom, R. Iannella, Leslie Daigle, D. van Gulik, 15-JAN-02, The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolutionand use in Internet applications ([RFCXXXX], [RFCYYYY]). The wholerests on the concept of individual 'namespaces' within the URNstructure. Apart from proof-of-concept namespaces, the use ofexisting identifiers in URNs has been discussed ([RFC2288]), and thisdocument lays out general definitions of and mechanisms forestablishing URN 'namespaces'.This document obsoletes RFC2611.Discussion of this document should be directed to urn-ietf@ietf.org "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", M. Mealling, 07-MAY-02, This document specifies the exact documents that make up the completeDynamic Delegation Discovery System (DDDS) standard. The DDDS is anabstract algorithm for applying dynamically retrieved stringtransformation rules to an application-unique string.This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. Usenet Article Standard Update (usefor) --------------------------------------- "News Article Format", C Lindsey, 27-AUG-02, This Draft is intended as a standards track document, obsoletingRFC 1036, which itself dates from 1987.This Standard defines the format of Netnews articles and specifiesthe requirements to be met by software which originates, distributes,stores and displays them.Since the 1980s, Usenet has grown explosively, and many Internet andnon-Internet sites now participate. In addition, the Netnewstechnology is now in widespread use for other purposes.Backward compatibility has been a major goal of this endeavour, butwhere this standard and earlier documents or practices conflict, thisstandard should be followed. In most such cases, current practice isalready compatible with these changes.[The use of the words 'this standard' within this document whenreferring to itself does not imply that this draft yet has pretensionsto be a standard, but rather indicates what will become the case if andwhen it is accepted as an RFC with the status of a proposed or draftstandard.] Voice Profile for Internet Mail (vpim) -------------------------------------- "Voice Profile for Internet Mail - version 2", G Parsons, Greg Vaudreuil, 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", G Parsons, Stuart McRae, 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", G Vaudreuil, 03-JUL-02, Voice messaging is traditionally addressed using telephone numberaddressing. This document describes two techniques for routing voicemessages based on a telephone number. The VPIM Directory serviceprovides a directory mechanism to lookup a VPIM email address with atelephone number and confirm that the address is both valid and theassociated with the intended recipient. However this service willtake time become widely deployed in the nearest term. This documentalso describes a more limited send-and-pray service useful simply toroute and deliver messages using only the ENUM telephone numberresolution service and the existing DNS mail routing facilies.Please send comments on this document to the VPIM working groupmailing list "Voice Messaging Directory Service", G Vaudreuil, 03-JUL-02, This document provides details of the VPIM directory service. Theservice provides the email address of the recipient given a telephonenumber. It optionally provides the spoken name of the recipient andthe media capabilities of the recipient.Please send comments on this document to the VPIM working groupmailing list "Critical Content MIME Parameter", E. Burger, 03-JUN-02, This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. "Message Context for Internet Mail", G. Klyne, E. Burger, Emily Candell, Charles Eliot, 05-JUN-02, This memo describes a new RFC822 message header, 'Message-Context'. This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. "VPIM (Voice Profile for Internet Mail) Addressing", G 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", G Vaudreuil, G 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", G Vaudreuil, G 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", Peter Higginson, B. Hinden, S. Knight, Alfred Lindem, Danny Mitzel, M. Shand, D. Whipple, D. Weaver, Peter Hunt, 04-MAR-02, This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assignsresponsibility for a virtual router to one of the VRRP routers on aLAN. "Virtual Router Redundancy Protocol for IPv6", B. Hinden, 04-MAR-02, This memo defines the Virtual Router Redundancy Protocol (VRRP) forIPv6. It is version three (3) of the protocol. It is based on theoriginal version of VRRP (version 2) for IPv4 that is defined inRFC2238. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "WebDAV Access Control Protocol", A. Hopkins, J. Whitehead, G. Clemm, E. Sedlar, 29-JUL-02, 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.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. "WebDAV Ordered Collections Protocol", J. Davis, John Crawford, J. Slein, Charles Fay, Geoffrey Clemm, E Whitehead, Julian Reschke, 28-MAR-02, This specification extends the WebDAV Distributed Authoring Protocolto support server-side ordering of collection members. Of particularinterest are orderings that are not based on property values, and socannot be achieved using a search protocol's ordering option andcannot be maintained automatically by the server. Protocol elementsare defined to let clients specify the position in the ordering ofeach collection member, as well as the semantics governing theordering.Distribution of this document is unlimited. Please send comments tothe Distributed Authoring and Versioning (WebDAV) working group atw3c-dist-auth@w3.org, which may be joined by sending a message withsubject '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", G. Clemm, 01-JUL-02, 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 only minor revisions mostly due to interoperability experience. XML Digital Signatures (xmldsig) -------------------------------- "Exclusive XML Canonicalization, Version 1.0", Donald Eastlake, J. Reagle, John Boyer, 13-AUG-02, Canonical XML [XML-C14N] specifies a standard serialization of XMLthat, when applied to a subdocument, includes the subdocument'sancestor context including all of the namespace declarations andattributes in the 'xml:' namespace. However, some applicationsrequire a method which, to the extent practical, excludes ancestorcontext from a canonicalized subdocument. For example, one mightrequire a digital signature over an XML payload (subdocument) in anXML message that will not break when that subdocument is removed fromits original message and/or inserted into a different context. Thisrequirement is satisfied by Exclusive XML Canonicalization. Zero Configuration Networking (zeroconf) ---------------------------------------- "Zeroconf IP Host Requirements", A Williams, 29-AUG-02, Many common TCP/IP protocols such as DHCP [RFC2131], DNS[RFC1034][RFC1035], MADCAP [RFC2730], and LDAP [RFC2251] must beconfigured and maintained by an administrative staff. This isunacceptable for emerging networks such as home networks, automobilenetworks, airplane networks, or ad hoc networks at conferences,emergency relief stations, and many others. Such networks may benothing more than two isolated laptop PCs connected via a wirelessLAN. For all these networks, an administrative staff will not existand the users of these networks neither have the time nor inclinationto learn network administration skills. Instead, these networks needprotocols 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, protocolrequirements are needed. This document states the zeroconf protocolrequirements for four protocol areas; they are: IP interfaceconfiguration, translation between host name and IP address, IPmulticast address allocation, and service discovery. This documentdoes not define specific protocols, just requirements. Therequirements for these four areas result from examining everyday useor scenarios of these protocols. "Dynamic Configuration of IPv4 Link-Local addresses", B. Aboba, E. Guttman, S. Cheshire, 28-AUG-02, In general, to participate in wide-area IP networking, a host needsconfiguration information, either entered manually by the user, orreceived automatically from an information source on the network suchas a DHCP server. However, such external configuration informationmay not always be available. It would be beneficial for a host tohave some useful subset of IP networking that it can depend upon tobe always functional, even when no configuration information isavailable to the host, or the configuration information the host hasis incorrect. This document describes a method by which a host mayautomatically configure an interface with an IPv4 address in the169.254/16 prefix that is valid for link-local communication on thatinterface.