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) -------------------------------------------------- "Mobile IPv4 Regional Registration", Pat Calhoun, Gabriel Montenegro, Charles Perkins, 19-Jul-04, Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. This document describes a new kind of `regional' registrations, i.e. registrations local to the visited domain. The regional signaling is performed via a new network entity called a Gateway Foreign Agent and introduces a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. "Diameter Mobile IPv4 Application", Pat Calhoun, Tony Johansson, Charles Perkins, Tom Hiller, 14-Jul-04, This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. "Diameter Network Access Server Application", Pat Calhoun, Glen Zorn, David Spence, David Mitton, 16-Jun-04, This document describes the Diameter protocol application used for Authentication, Authorization and Accounting (AAA) services in the Network Access Server (NAS) environment. This application specification, when combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, satisfies typical network access services requirements. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application was carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space, and eliminating the need to perform many attribute translations. "Diameter Extensible Authentication Protocol (EAP) Application", Pasi Eronen, Tom Hiller, Glen Zorn, 24-Jun-04, The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server "Diameter Credit-control Application", Leena Mattila, Juha-Pekka Koskinen, Marco Stura, John Loughney, Harri Hakala, 14-May-04, This document specifies a DIAMETER application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, download services etc. "Diameter Session Initiation Protocol (SIP) Application", Miguel Garcia-Martin, Maria-Carmen Belinchon, Miguel Pallares-Lopez, Carolina Canales-Valenzuela, Kalle Tammi, 12-Jul-04, This document specifies the Diameter Session Initiation Protocol (SIP) Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with the Session Initiation Protocol (SIP), and provides a Diameter client in a SIP server with the ability to request a Diameter server the authentication of users and authorization of SIP resources usage. This application does not require or is not related to other authentication services provided by the Mobile IP Diameter [7] or the Network Access Server Diameter [8] applications. "Uniform Resource Identifier (URI) schemes for Authentication, Authorization and Accounting (AAA) protocols", Miguel Garcia-Martin, 3-May-04, This memo provides an update for the 'aaa' and 'aaas' scheme definition originally specified in RFC 3588. The updated scheme is now compatible with the generic URI syntax specified in RFC 2396. This memo also updates the syntax and semantics of the 'aaa and 'aaas' URI schemes and provides instructions to IANA to register them in the namespace of registered URI schemes. ADSL MIB (adslmib) ------------------ "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding", Menachem Dodge, Bob Ray, 14-Jun-04, This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728 [RFC3728], which handles line code independent objects. "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding", Menachem Dodge, Bob Ray, 2-Jun-04, This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728 [RFC3728], which handles line code independent objects. "Definitions of Managed Objects for G.SHDSL.BIS Lines", Clay Sikes, Bob Ray, 28-Jun-04, This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This MIB described in this document will obsolete the MIB described in RFC 3276. AToM MIB (atommib) ------------------ "Definitions of Managed Objects for the DS3/E3 Interface Type", Orly Nicklass, 14-Apr-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", Orly Nicklass, 13-Jan-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document entirely replaces RFC 2495. "Definitions of Managed Objects for the IMA Interface Type", Faye Ly, 3-Jun-04, 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 IMA (Inverse Multiplexing for ATM) interface type in accordance with [ATM Forum IMA 1.1]. Atom Publishing Format and Protocol (atompub) --------------------------------------------- "The Atom Syndication Format", Mark Nottingham, 19-Jul-04, This specification describes Atom, an XML-based Web content and metadata syndication format. "The Atom Publishing Protocol", Joe Gregorio, 22-Jul-04, This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (draft-ietf-atompub-format-00.txt). Audio/Video Transport (avt) --------------------------- "Tunneling multiplexed Compressed RTP ('TCRTP')", B Thompson, Tmima Koren, Dan Wing, 7-Nov-02, This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path to reduce the bandwidth used when multiple RTP streams are carried over that path. This method was selected by the IETF Audio/Video Transport working group as best satisfying the need for standardized RTP multiplexing because it preserves full RTP semantics. Other methods may be more highly optimized for particular applications by constraining their applicability, for example to a small set of encodings and a subset of the RTP semantics. Those other methods may be more appropriate as proprietary protocols rather than standards. "An RTP Payload Format for Generic FEC", Adam Li, 21-Jul-04, This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation, and it is a generalized algorithms that includes Uneven Level Protection (ULP). The payload format described in this draft allows end systems to apply protection using arbitrary protection lengths and levels, in addition to using arbitrary protection group sizes. It enables complete recovery or partial recovery of the critical payload and RTP header fields depending on the packet loss situation. This scheme is completely backward compatible with non-FEC capable hosts. Those receivers that do not know about FEC can simply ignore the protection data. This draft will obsolete RFC 2733 and RFC 3009. "Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)", Joerg Ott, Stephan Wenger, 21-Jul-04, Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of RTCP to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term as sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allow for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. "RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback", Julian Chesterfield, 21-Jul-04, This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism. "RTP Retransmission Payload Format", Jose Rey, 28-Jan-04, RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF), is available in this memo. "RTP Payload Format for JPEG 2000 Video Streams", Satoshi Futemma, 21-Jul-04, This document describes an RTP payload format for transporting JPEG 2000 video streams, formed as a continuous series of JPEG 2000 still images. The payload format presented in this document has three features: (1) Improvement of robustness to packet loss by intelligently fragmenting JPEG 2000 packet units, (2) Persistency of main header to minimize loss effect and maximize recovery and (3) Priority information field for scalable delivery from the same codestream. These will allow for the scalability and robustness of JPEG 2000 images to be maximized in video streaming applications. "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", Henning Schulzrinne, Scott Petrack, 12-Feb-04, This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. This document updates RFC 2833. "Internet Low Bit Rate Codec", Steven Andersen, 2-Jun-04, This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. "RTP Payload Format for Uncompressed Video", Ladan Gharai, Charles Perkins, 17-Feb-04, This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. "A More Loss-Tolerant RTP Payload Format for MP3 Audio", Ross Finlayson, 10-Feb-04, This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as 'MP3'). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. "RTP payload Format for H.264 Video", Stephan Wenger, 19-Jul-04, This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability supporting from simple low-bit rate conversational usage to Internet video streaming with interleaved transmission, all the way to high bit-rate video-on- demand applications. "RTP Payload Format for iLBC Speech", Alan Duric, S Andersen, 30-Jun-04, This document describes the RTP payload format for the internet Low Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and SDP. "RTP payload format for a 64 kbit/s transparent call", Ruediger Kreuter, 22-Apr-04, 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'. 'Clearmode' is a basic feature of VoIP media gateways. "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Joerg Ott, Elisabetta Carrara, 21-Jul-04, An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 24-Jun-04, This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. "An Implementation Guide for RTP MIDI", John Lazzaro, John Wawrzynek, 24-Jun-04, This memo offers non-normative implementation guidance for the RTP MIDI payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. "Framing RTP and RTCP Packets over Connection-Oriented Transport", John Lazzaro, 2-Jul-04, This memo defines a method for framing Real Time Protocol (RTP) and Real Time Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP and TLS). The memo also defines how to specify the framing method in a session description. "Registration of the text/red MIME Sub-Type", Paul Jones, 20-May-04, This document defines the text/red MIME sub-type. The actual RTP packetization for this MIME type is specified in RFC 2198. [Note to RFC Editor: All references to RFC XXXX are to be replaced by references to the RFC number of this memo when published.] "RTP Payload Format for H.261 Video Streams", Roni Even, 15-Jun-04, This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list and/or the authors. "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", Joerg Ott, George Sullivan, Stephan Wenger, Roni Even, 31-Mar-04, This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. The document also describe the syntax and semantics of the SDP parameters needed to support the H.263 video codec. "RTP Payload Formats for European Telecommunications Standardsv Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding", Qiaobing Xie, David Pearce, 18-Jun-04, This document specifies RTP payload formats for encapsulating ETSI Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. "RTP Payload Format for 3GPP Timed Text", Jose Rey, Y Matsui, 21-Jul-04, This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined decorated text media format with defined storage in a 3GP file. Timed Text can be synchronised with audio/video contents. As of today, 3GP files containing timed text contents can only be downloaded via HTTP. There is no available mechanism for streaming 3GPP timed text contents neither out of 3GP files nor directly from live content. In the following sections the problems of streaming timed text are addressed and a payload format for streaming 3GPP timed text over RTP is specified. "Requirements for Header Compression over MPLS", Jerry Ash, Bur Goode, Jim Hand, Raymond Zhang, 10-Jun-04, VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels, where, for example, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS LSP without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In the draft we give a problem statement, goals and requirements, and an example scenario. "Real-Time Transport Protocol (RTP) Payload and File Storage Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec", Sassan Ahmadi, 8-Jul-04, This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of VMR-WB speech data in storage mode applications such as email. A MIME type registration is included, for VMR-WB, specifying use of both the RTP payload and the storage formats VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. "Real-Time Transport Protocol (RTP) Payload Format for Extended AMR Wideband (AMR-WB+) Audio Codec", Johan Sjoberg, 13-Jul-04, This document specifies a real-time transport protocol (RTP) payload format to be used for Extended AMR Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB codec providing additional modes designed to give higher quality of music and speech than the original modes. A MIME type registration is included for AMR-WB+. "RTP Profile for TCP Friendly Rate Control", Ladan Gharai, 14-Jul-04, This memo specifies a profile called 'RTP/AVPCC' for the use of the real-time transport protocol (RTP) and its associated control protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is a equation based congestion control scheme for unicast flows operating in a best effort Internet environment. "RTP Payload Format for BroadVoice Speech Codecs", Juin-Hwey Chen, 13-Jul-04, This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs developed by Broadcom Corporation. The document also provides specifications for the use of BroadVoice with MIME and SDP. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Bidirectional Forwarding Detection Management Information Base", , 29-Jun-04, This draft 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 Bidirectional Forwarding Detection (BFD) protocol [BFD]. "BFD For MPLS LSPs", Rahul Aggarwal, 12-Jul-04, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 13-Jul-04, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. "BFD for Multihop Paths", Dave Katz, David Ward, 13-Jul-04, This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 13-Jul-04, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. It further describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on this draft should be directed to rtg-bfd@ietf.org. Border Gateway Multicast Protocol (bgmp) ---------------------------------------- "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Dave Thaler, 20-Jan-04, This document describes BGMP, a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter- domain, distribution branches where needed. BGMP natively supports 'source-specific multicast' (SSM). To also support 'any-source multicast' (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the class D space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. Benchmarking Methodology (bmwg) ------------------------------- "Methodology for IP Multicast Benchmarking", Debra Stopp, B Hickman, 27-Jan-04, The purpose of this draft is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", Jerry Perser, David Newman, 3-Feb-04, This document describes terminology for the benchmarking of devices that implement traffic control based on IP precedence or diff-serv code point criteria. "Benchmarking Terminology for Routers Supporting Resource Reservation", Krisztian Nemeth, Istvan Cselenyi, Andras Korn, 2-Feb-04, The purpose of this document is to define terminology specific to the benchmarking of the resource reservation signaling of IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. "Terminology for Benchmarking BGP Device Convergence in the Control Plane", Howard Berkowitz, 21-Jul-04, This draft establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. "OSPF Benchmarking Terminology and Concepts", Vishwas Manral, Richard White, Aman Shaikh, 6-Jul-04, This draft explains the terminology and concepts used in OSPF benchmarking. While some of these terms may be defined elsewhere, and we will refer the reader to those definitions in some cases, we also include discussions concerning these terms as they relate specifically to the tasks involved in benchmarking the OSPF protocol. "Benchmarking Basic OPSF Single Router Control Plane Convergence", Vishwas Manral, Richard White, Aman Shaikh, 6-Jul-04, This draft establishes standards for measuring OSPF single router control plane convergence [TERM]. Its initial emphasis is on the control plane of single OSPF routers. We do not address forwarding plane performance. NOTE: Within this document, the word convergence relates to single router control plane convergence only. "Considerations When Using Basic OSPF Convergence Benchmarks", Vishwas Manral, Russ White, Aman Shaikh, 6-Jul-04, This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regards to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discussing specific advantages and limitations of specific OSPF convergence tests, and the second discussing more general pitfalls to be considered when testing routing protocols convergence testing. "Terminology for Benchmarking IPsec Devices", Michele Bustos, 20-Jul-04, This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Benchmarking Methodology for IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, 21-Jul-04, This draft describes the methodology for benchmarking IGP Route Convergence as described in Applicability document [1] and Terminology document [2]. The methodology and terminology are to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The terms used in the procedures provided within this document are defined in [2]. "Terminology for Benchmarking IGP Data Plane Route Convergence", Scott Poretsky, 19-Jul-04, This draft describes the terminology for benchmarking IGP Route Convergence as described in Applicability document [1] and Methodology document [2]. The methodology and terminology is to be used for benchmarking Route Convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [2]. "Benchmarking Applicability for IGP Data Plane Route Convergence", Scott Poretsky, 21-Jul-04, This draft describes the applicability of IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence bechmarking terminology [2]. The methodology and terminology is to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [1]. "Terminology for Accelerated Stress Benchmarking", Scott Poretsky, 14-Jul-04, This document provides the Terminology for performing Stress Benchmarking of networking devices. The three phases of the Stress Test: Startup, Instability and Recovery are defined along with the benchmarks and configuration terms associated with the each phase. Also defined are the Benchmark Planes fundamental to stress testing configuration, setup and measurement. The terminology is to be used with the companion framework and methodology documents. "Methodology for Accelerated Stress Benchmarking", Scott Poretsky, 16-Jul-04, Routers in an operational network are simultaneously configured with multiple protocols and security policies while forwarding traffic and being managed. To accurately benchmark a router for deployment it is necessary that the router be tested in these simultaneous operational conditions, which is known as Stress Testing. This document provides the Methodology for performing Stress Benchmarking of networking devices. Descriptions of Test Topology, Benchmarks and Reporting Format are provided in addition to procedures for conducting various test cases. The methodology is to be used with the companion terminology document [6]. "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", , 16-Jul-04, Test engineers take pains to declare all factors that affect a given measurement, including offered load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. Bridge MIB (bridge) ------------------- "Definitions of Managed Objects for Bridges", K Norseth, Ernest Bell, 5-Apr-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. The MIB presented in this memo is a direct translation of the BRIDGE MIB defined in [RFC1493], to the SMIv2 syntax required for current IETF MIB standards. This memo obsoletes RFC 1493. "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", Ernest Bell, Vivian Ngai, 25-Mar-04, 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 Rapid Spanning Tree capability defined by the IEEE P802.1t [802.1t] and P802.1w [802.1w] amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes a MIB module in a manner that is compliant to SMIv2 [RFC2578]. "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", Vivian Ngai, Ernest Bell, 25-Mar-04, 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 new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001. The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-1998, P802.1u and P802.1v. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB]. Calendaring and Scheduling (calsch) ----------------------------------- "Calendar Access Protocol (CAP)", Doug Royer, 24-May-04, The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). The CAP definition is based on requirements identified by the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) Working Group. More information about the IETF CALSCH Working Group activities can be found on the IMC web site at http:// www.imc.org/ietf-calendar and at the IETF web site at http:// www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the references within this memo for further information on how to access these various documents. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "CAPWAP Problem Statement", Pat Calhoun, 1-Jun-04, This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", Lily Yang, Petros Zerfos, Emek Sadot, 30-Jun-04, This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing WLAN (Wireless LAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This taxonomy may be utilized by the IEEE 802.11 Working Group as input to their task of defining the Access Point (AP) functional architecture. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control", Eric Mannie, Dimitri Papadimitriou, 28-Feb-03, This document is a companion to the Generalized Multiprotocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. "Generalized Multi-Protocol Label Switching Architecture", Eric Mannie, 19-May-03, Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. "Link Management Protocol (LMP)", Jonathan Lang, 10-Oct-03, For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", Kireeti Kompella, Yakov Rekhter, 17-Oct-03, This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", Kireeti Kompella, Yakov Rekhter, 17-Oct-03, This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching. "Link Management Protocol Management Information Base", Martin Dubuc, Sudheer Dharanikota, Thomas Nadeau, Jonathan Lang, Evan McGinnis, 25-May-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", Andre Fredette, Jonathan Lang, 16-Dec-03, The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes; i.e., nodes that peer in signaling and/or routing. In this document we propose extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the 'Optical Link Interface Requirements' described in a companion document. "Framework for GMPLS-based Control of SDH/SONET Networks", Greg Bernstein, Eric Mannie, Vishal Sharma, 15-Jul-04, 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 Signalling Extensions for G.709 Optical Transport Networks Control", Dimitri Papadimitriou, 31-Mar-04, This document is a companion to the Generalized MPLS (GMPLS) signalling documents. It describes the technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. "Definitions of Textual Conventions for Generalized Multi-Protocol Label Switching (GMPLS) Management", Thomas Nadeau, 3-Jun-04, This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multi-Protocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", Thomas Nadeau, 3-Jun-04, 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 Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. "Generalized Multiprotocol Label Switching (GMPLS) Label Switch Router Management Information Base", Thomas Nadeau, 3-Jun-04, 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 to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSRs). "Recovery (Protection and Restoration) Terminology for GMPLS", Eric Mannie, Dimitri Papadimitriou, 12-Apr-04, This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. "SONET/SDH Encoding for Link Management Protocol (LMP) Test messages", Jonathan Lang, Dimitri Papadimitriou, 16-Dec-03, This document details the Synchronous Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH) technology specific information needed when sending Link Management Protocol (LMP) test messages. "GMPLS RSVP Support for the Overlay Model", George Swallow, 26-Apr-04, Generalized MPLS defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", Dimitri Papadimitriou, Eric Mannie, 12-Apr-04, This document provides an analysis grid to evaluate, compare and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with respect to the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in a companion document. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", Dimitri Papadimitriou, John Drake, Jerry Ash, Adrian Farrel, Lyndon Ong, 19-Apr-04, The Generalized MPLS (GMPLS) suite of protocol has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signalling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements on the GMPLS signaling protocol to support the ASON functionality. "Exclude Routes - Extension to RSVP-TE", Adrian Farrel, 9-Jul-04, The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. "Generalized MPLS Recovery Functional Specification", Jonathan Lang, Bala Rajagopalan, 19-Apr-04, This document presents a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. "Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)", Wesam Alanqar, Deborah Brungard, David Meyer, Lyndon Ong, Dimitri Papadimitriou, Janathan Sadler, 5-May-04, The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)", John Drake, 22-Jul-04, This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in this document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. "Crankback Signaling Extensions for MPLS Signaling", Adrian Farrel, 19-Jul-04, In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) label switched path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP restoration to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. "GMPLS Signaling Procedure For Egress Control", Lou Berger, 11-May-04, This note clarifies the procedures for the control of the label used on a output/downstream interface of the egress node of a Label Switched Path (LSP). Such control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This note does not modify GMPLS signaling mechanisms and procedures and should be viewed as an informative clarification of GMPLS Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. "GMPLS - Communication of Alarm Information", Lou Berger, 1-Apr-04, This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", Jonathan Lang, 12-May-04, This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP recovery (protection and restoration). A generic functional description of GMPLS recovery can be found in a companion document. "Generic Tunnel Tracing Protocol (GTTP) Specification", Ronald Bonica, 6-Apr-04, This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace the path between any two points in an IP network. Enhanced route-tracing applications can trace through a network's forwarding plane, its control plane or both. Furthermore, enhanced route-tracing applications can reveal details concerning tunnels that support the traced path. Tunnel details can be revealed regardless of tunneling technology. For example, enhanced route-tracing applications can trace through an MPLS LSP as well as they can trace through an IP-in-IP tunnel. "Node ID based RSVP Hello: A Clarification Statement", Zafar Ali, 26-Apr-04, Use of node-id based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than RSVP Hellos, use of node-id based Hellos is optimal for detecting signaling adjacency failure for RSVP- TE. Nonetheless, this implied behavior is unclear and this document formalizes use of node-id based RSVP Hello sessions as a best current practice (BCP) in some scenarios. "GMPLS Based Segment Recovery", Lou Berger, 28-Apr-04, This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support LSP segment protection and restoration. These extensions are intended to be compliment and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service", A Newton, Marcos Sanz, 14-Jul-04, This document describes an IRIS registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. "IRIS - The Internet Registry Information Service (IRIS) Core Protocol", A Newton, Marcos Sanz, 14-Jul-04, This document describes an application layer client-server protocol for a framework of representing the query and result operations of the information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. "IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", A Newton, Marcos Sanz, 14-Jul-04, This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). "IRIS - An Address Registry (areg) Type for the Internet Registry Information Service", A Newton, 17-Feb-04, This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for IP address information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control", Sally Floyd, Eddie Kohler, 20-Jul-04, This document contains the profile for Congestion Control Identifier 2, TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. "Profile for DCCP Congestion Control ID 3:TFRC Congestion Control", Jitendra Padhye, Sally Floyd, Eddie Kohler, 20-Jul-04, This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly send rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. "Datagram Congestion Control Protocol (DCCP) User Guide", Thomas Phelan, 19-Jul-04, This document is an informative reference discussing strategies for using DCCP as the transport protocol for various applications. The focus is on how applications can make use of the capabilities, and deal with the idiosyncrasies, of DCCP. Of particular interest is how UDP applications, which have traditionally ignored congestion control issues, can adapt to a congestion controlled transport. "Datagram Congestion Control Protocol (DCCP)", Eddie Kohler, 20-Jul-04, This document specifies the Datagram Congestion Control Protocol (DCCP), which implements a congestion-controlled, unreliable flow of unicast datagrams suitable for use by applications such as streaming media, Internet telephony, and on-line games. "DCCP CCID 3-Thin", Eddie Kohler, 20-Jul-04, This document describes the Thin variant of the Datagram Congestion Control Protocol (DCCP) Congestion Control Identifier 3, TCP- Friendly Rate Control (TFRC). The Thin variant is more restricted than CCID 3; it limits allowable options, acceptable feature values, and so forth. CCID 3-Thin packets are still valid DCCP CCID 3 packets. CCID 3-Thin was designed for small clients where a full DCCP implementation would be too expensive. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB", Richard Barr Hibbs, Glenn Waters, 10-Feb-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) servers. "The DHCP Client FQDN Option", Mark Stapp, Yakov Rekhter, 20-Jul-04, This document specifies a DHCP for IPv4, DHCPv4, option which can be used to exchange information about a DHCPv4 client's fully-qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. "Resolution of DNS Name Conflicts Among DHCP Clients", Mark Stapp, 20-Jul-04, DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. "DHCP Lease Query", Richard Woundy, 22-Mar-04, A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option", Ralph Droms, John Schnizlein, 8-Jul-04, A NAS (network access server) may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of configuration parameters to be delivered to the device through its DHCP client. The RADIUS Attributes sub-option enables a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. "NIS Configuration Options for DHCPv6", a Vijayabhaskar, 3-Dec-03, This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers [3], NIS+ Servers [3], NIS Client Domain Name [3], NIS+ Client Domain name [3]. "The IPv4 DHCP Options for the Internet Storage Name Service", Charles Monia, Josh Tseng, Kevin Gibbons, 14-Jul-04, This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. "The Authentication Suboption for the DHCP Relay Agent Option", Mark Stapp, Ted Lemon, Ralph Droms, 14-Jul-04, The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. "DHCP Option for Mobile IP Mobility Agents", Henrik Levkowetz, 3-Feb-04, This document defines a Dynamic Host Configuration Protocol (DHCP) option with sub-options. One sub-option is passed from the DHCP Server to the DHCP Client to announce the presence of one or more Mobile IP Mobility Agents. For each announced Mobility Agent, information is provided which is the same as that of the Mobile IP Agent Advertisement extension to ICMP Router Advertisements. There is also one sub-option which may be used by a DHCP client to provide identity information to the DHCP server. "DHCP Subscriber ID Suboption for the DHCP Relay Agent Option", Richard Johnson, Theyn Palaniappan, Mark Stapp, 9-Apr-04, This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable 'Subscriber-ID' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", Richard Barr Hibbs, Carl Smith, Bernard Volz, Miriam Zohar, 29-Apr-04, DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. It did not provide for authentication of clients and servers, nor did it provide for data confidentiality. This is reflected in the original 'Security Considerations' section of RFC 2131, which identifies a few threats and leaves development of any defenses against those threats to future work. Beginning in about 1995 DHCP security began to attract attention from the Internet community, eventually resulting in the publication of RFC 3118 in 2001. Although RFC 3118 was a mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203, it has had no known usage by any commercial or private implementation since its adoption. The DHC Working Group has adopted a work item for 2003 to review and modify or replace RFC 3118 to afford a workable, easily deployed security mechanism for DHCPv4. This memo provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support our chartered work improving the acceptance and deployment of RFC 3118. "Detection of Network Attachment (DNA) in IPv4", Bernard Aboba, 21-Jul-04, The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This document synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and Link-Local IPv4 addresses. A procedure is specified for detection of network attachment in order to better accommodate mobile hosts. "Authentication of DHCP Relay Agent Options Using IPsec", Ralph Droms, 24-Nov-03, The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines a mechanism for securing the messages exchanged between a relay agent and a server using IPsec (RFC 2401). "Vendor-Identifying Vendor Options for DHCPv4", Joshua Littlefield, 23-Jun-04, The DHCP options for Vendor Class and Vendor-Specific Information can be ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity. "Node-Specific Client Identifiers for DHCPv4", Ted Lemon, 21-Jul-04, This document specifies the format that is to be used for encoding DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol [RFC3315]. "Simple Network Time Protocol Configuration Option for DHCPv6", a Vijayabhaskar, 25-Nov-03, This document describes a new DHCPv6 option for passing a list of SNTP server addresses to a client. "Rapid Commit Option for DHCPv4", Pyungsoo Kim, Bernie Volz, Soohong Park, 28-Jun-04, This document defines a new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4- message exchange, expediting client configuration. "Reclassifying DHCPv4 Options", Bernard Volz, 26-Apr-04, This document revises RFC 2132 to reclassify DHCPv4 option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. "Client Identifier option in server replies", Narasimha Swamy, 2-Feb-04, This document clarifies the use of 'client identifier' option by the clients and servers as mentioned in [RFC2131]. The clarification addresses the issue arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. "DHCP Option for Proxy Server Configuration", Senthil Balasubramanian, 15-Jul-04, This document defines a new Dynamic Host Configuration Protocol (DHCP) option, which can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP, FTP, NNTP, SOCKS, Gopher, SLL and etc. Proxy Server provides controlled and efficient access to the Internet by access control mechanism for different types of user requests and caching frequently accessed information (Web pages and possibly files that might have been downloaded using FTP and other protocols). "Configured Tunnel End Point Option for DHCPv6", Soohong Park, 30-Mar-04, For the newly deployed IPv6 networks to interoperate with vastly deployed IPv4 networks, various transition mechanisms had been proposed. One such mechanism is configured tunnels. This document provides a mechanism by which the DHCPv6 servers can provide information about the various configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks. "DHCPv6 Support for Remote Boot", a Vijayabhaskar, 9-Feb-04, This document provides new DHCPv6 (Dynamic Host Configuration protocol version 6) options for clients, to obtain information about FTP (Trivial File Transfer Protocol) servers and bootfiles needed for booting. "The Extended Remote Boot Option for DHCPv4", a Vijayabhaskar, 9-Feb-04, Single TFTP [2] server for huge number of diskless clients is prone to single point of failure. So, Multiple TFTP servers are needed for high availability. Moreover, some of the clients need multiple bootfiles for boot up. This document provides a new DHCPv4 option for clients to obtain information about multiple TFTP [2] servers and bootfiles. "DHCP: IPv4 and IPv6 Dual-Stack Issues", Tim Chown, 21-Jul-04, A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from DHCPv4 and DHCPv6 servers. "Lifetime Option for DHCPv6", Stig Venaas, Tim Chown, 19-Jul-04, This document describes an option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6, but also useful when there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP server to update its configuration. "Renumbering Requirements for Stateless DHCPv6", Tim Chown, 20-Jul-04, IPv6 hosts using Stateless Address Autoconfiguration are able to automatically configure their IPv6 address and default router settings. However, further settings are not available. If such hosts wish to automatically configure their DNS, NTP or other specific settings the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using such a combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings, e.g. the addition of a new NTP server address, changes in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. Distributed Management (disman) ------------------------------- "Alarm MIB", Sharon Chisholm, Dan Romascanu, 11-Feb-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. "Alarm Reporting Control MIB", Kam Lam, Anni Huynh, Don Perkins, 25-Sep-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", Juergen Quittek, Kenneth White, 19-Jul-04, This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. Detecting Network Attachment (dna) ---------------------------------- "Detecting Network Attachment in IPv6 Goals", JinHyeock Choi, 11-Jun-04, At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. While checking for link change, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Rapid attachment detection is required when a host has on-going data traffic. Current DNA schemes are inadequate to support real-time applications. The existing procedures for advertising network information incur reception delays and do not provide enough information to properly determine the identity of links. For to-be-defined, efficient DNA schemes, a way to correctly represent a link change, a complete and consistent procedure for network information advertisement and a rapid delivery of the advertisements will be necessary. DNS Extensions (dnsext) ----------------------- "A DNS RR for encoding DHCP information (DHCID RR)", Mark Stapp, Ted Lemon, Andreas Gustafsson, 20-Jul-04, It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. "Linklocal Multicast Name Resolution (LLMNR)", Levon Esibov, Bernard Aboba, Dave Thaler, 20-Jul-04, Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. "DNS Security Introduction and Requirements", Roy Arends, Rob Austein, Dan Massey, Matt Larson, Scott Rose, 19-Jul-04, The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. "TKEY Secret Key Renewal Mode", Y Kamite, Masaya Nakayama, 16-Feb-04, This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing secret keys used for TSIG [RFC2845] periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. "Threat Analysis Of The Domain Name System", Derek Atkins, Rob Austein, 5-Apr-04, Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. "Resource Records for the DNS Security Extensions", Roy Arends, 19-Jul-04, This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. "Protocol Modifications for the DNS Security Extensions", Roy Arends, 19-Jul-04, This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. "Domain Name System (DNS) Case Insensitivity Clarification", Donald Eastlake, 20-Jul-04, Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. "DNSSEC NSEC RDATA Format", Jacob Schlyter, 14-May-04, This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, 10-Jun-04, This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. Domain Name System Operations (dnsop) ------------------------------------- "Root Name Servers with Inter Domain Anycast Addresses", Masataka Ohta, 16-Feb-04, This memo describes an operational guideline for millions of name servers to share an interdomain anycast address. It enables people operate as many root name servers as they want and still make them traceable. "Requiring DNS IN-ADDR Mapping", Daniel Senie, 26-Apr-04, Mapping of addresses to names has been a feature of DNS. Many sites, implement it, many others don't. Some applications attempt to use it as a part of a security strategy. The goal of this document is to encourage proper deployment of address to name mappings, and provide guidance for their use. "Observed DNS Resolution Misbehavior", Matt Larson, Piet Barber, 21-Jul-04, This memo describes DNS name server and resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. In some cases we recommend minor additions to the DNS protocol specification and corresponding changes in iterative resolver implementations to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. "Identifying an Authoritative Name Server", David Conrad, 20-Jul-04, With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid. Existing ad hoc mechanisms for addressing this concern are not adequate. This document attempts to describe the common ad hoc solution to this problem, including its advantages and disadvantasges, and to characterize an improved mechanism. "Operational Considerations and Issues with IPv6 DNS", Alain Durand, Johan Ihren, Pekka Savola, 19-Jul-04, This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehaviour, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. "DNS Response Size Issues", Paul Vixie, Akira Kato, 20-Jul-04, With a mandated default minimum maximum message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit. "DNS IPv6 transport operational guidelines", Alain Durand, Johan Ihren, 31-Mar-04, This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. "DNSSEC Operational Practices", Olaf Kolkman, 14-May-04, This document describes a set of practices for operating a DNSSEC aware environment. The target audience is zone administrators deploying DNSSEC that need a guide to help them chose appropriate values for DNSSEC parameters. It also discusses operational matters such as key rollovers, KSK and ZSK considerations and related matters. "Requirements for Automated Key Rollover in DNSsec", Gilles Guette, 9-Feb-04, This document describes problems that appear during an automated rollover and gives the requirements for the design of communication between parent zone and child zone in an automated rollover process. This document is essentially about key rollover, the rollover of one other Resource Record present at delegation point (NS RR) is also discussed. "Common Misbehavior against DNS Queries for IPv6 Addresses", Yasuhiro Morishita, Tatsuya Jinmei, 12-Apr-04, There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication which should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of the known cases and discusses the effect of the cases. "IPv6 Host Configuration of DNS Server Information Approaches", Jae-Hoon Jeong, 19-Jul-04, This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and Well- known anycast addresses for recursive DNS servers. Additionally, it suggests four deployment scenarios considering multi-solution resolution. Therefore, this document will give the audience a guideline of IPv6 DNS configuration to select approaches suitable for their host DNS configuration. Extensible Authentication Protocol (eap) ---------------------------------------- "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", John Vollbrecht, Pasi Eronen, Nick Petroni, Yoshihiro Ohba, 20-Jul-04, This document describes a set of state machines for EAP peer, EAP standalone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and standalone authenticator machines are illustrative of how the EAP protocol defined in [RFC3748] may be implemented. The backend and full/ pass-through authenticators illustrate how EAP/AAA protocol support defined in [RFC3579] may be implemented. Where there are differences [RFC3748]/[RFC3579] are authoritative. The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. "Extensible Authentication Protocol (EAP) Key Management Framework", Bernard Aboba, 19-Jul-04, The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the generation, transport and usage of keying material generated by EAP authentication algorithms, known as "methods". "Network Discovery and Selection Problem", Jari Arkko, Bernard Aboba, 19-Jul-04, The so called network discovery and selection problem affects network access, particularly in the presence of multiple available wireless accesses and roaming. This problem has been the subject of discussions in various standards bodies. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol (EAP) working group at the IETF. The problem is defined and divided into subproblems, and some constraints for possible solutions are outlined. The document presents also some existing mechanisms which help solve at least parts of the problem, and gives some suggestions on how to proceed for the rest. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet Using HTTP AS2", Dale Moberg, Rik Drummond, 14-Feb-04, This document describes how to exchange structured business data securely using HTTP transfer for XML, Binary, Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport) or other data describable in MIME used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original HTTP message. "Compressed Data for EDIINT", Terry Harding, 3-Feb-04, The intent of this document is to be placed on the RFC track as an Informational RFC. The EDIINT AS1 and AS2 message formats don't currently contain any transport neutral provisions for compressing data when utilizing S/MIME as the secure packaging standard. Compressing data before transmission provides a number of advantages including 1. reducing data redundancy, and so reducing opportunities for attacks exploiting redundancy, and 2. reducing the amount of data and so speeding up cryptographic processing such as signing, encryption, archiving, and 3. reducing the overall transmitted message size, reducing both time and bandwidth needed for transport. "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", Terry Harding, Richard Scott, 26-Mar-04, This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content-types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. Entity MIB (entmib) ------------------- "Entity MIB (Version 3)", Keith McCloghrie, Andy Bierman, 23-Jan-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). "Entity State MIB", Sharon Chisholm, David Perkins, 21-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the entity MIB to provide information about the state of the entity. Telephone Number Mapping (enum) ------------------------------- "E.164 Number Mapping for the Extensible Provisioning Protocol", Scott Hollenbeck, 8-Jun-04, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. "IANA Registration for ENUMservices email, fax, mms, ems and sms", Rudolf Brandner, 23-Jun-04, This document registers the 'ENUMservices' [6] 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'tel:', 'mailto:', 'sip:' and 'sips:' as per the IANA registration process defined in the ENUM specification RFC3761 [6]. "IANA Registration for ENUMservices web and ft", Rudolf Brandner, 25-May-04, This document registers the 'ENUMservices' [3] 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification RFC3761 [3]. "Enumservice Registration for Presence Services", Jon Peterson, 21-May-04, This document registers an ENUM service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 12-Jul-04, This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. Internet Fax (fax) ------------------ "A Simple Mode of Facsimile Using Internet Mail", Kiyoshi Toyoda, Hiroyuki Ohno, Jun Murai, Dan Wing, 27-Nov-01, This specification provides for 'simple mode' carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 10, 11], and TIFF for Facsimile [5, 12, 14]. "File Format for Internet Fax", Robert Buckley, Dennis Venable, Lloyd McIntyre, Glenn Parsons, James Rafferty, 3-Jun-04, This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. "Full-mode Fax Profile for Internet Mail: FFPIM", David Crocker, Graham Klyne, 15-Jul-04, Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. "Internet FAX Gateway Functions", K Mimura, K Yokoyama, T Satoh, C Kanaide, 20-Jul-04, An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) and the Internet. This document provides information on recommended behaviors for Internet FAX Gateway functions for email-based Internet Fax. In this context, an offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to the Internet from the GSTN. This document covers the delivery process of data with equipment which may include Internet Fax terminals, PCs on the Internet, and Fax terminals on the GSTN. "Guideline of optional services for Internet FAX Gateway", K Mimura, K Yokoyama, T Satoh, Ken Watanabe, C Kanaide, 14-Apr-03, An Internet FAX Gateway provides functions which translate a facsimile between the general switched telephone network (GSTN) and the Internet. This document provides guidelines of optional services and examples of an Internet FAX Gateway, with respect to the onramp gateway and offramp gateway. This document does not intend to specify the actions to which the IFax offramp and onramp gateways (defined in [3]) conform. This document covers drop duplication, automatic re-transmission, error behavior, when sending a return notice, and the keep log for an offramp gateway. Also covered are examples of authorization by DTMF (Dual Tone Multi-Frequency) and the keep log for an onramp gateway. "SMTP and MIME Extensions For Content Conversion", Kiyoshi Toyoda, Dave Crocker, 30-Jun-04, A message originator sometimes sends content in a form the recipient cannot process. Such content needs to be converted to a related form, with the same or with restricted information, such as changing from color to black and white. In a store-and-forward environment, it can be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content-types, to permit authorized, accountable content form conversion by intermediaries. "IFAX service of ENUM", Kiyoshi Toyoda, Dave Crocker, 29-Jun-04, This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is 'Facsimile using Internet Mail'. For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. "Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration", Lloyd McIntyre, 29-Jun-04, This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Forwarding Element Model", Lily Yang, 19-Jul-04, This document defines the forwarding element (FE) model used in the Forwarding and Control Plane Separation (ForCES) protocol. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements draft [1]. A list of the basic logical functional blocks (LFBs) is also defined in the LFB class library to aid the effort in defining individual LFBs. Extensions to FTP (ftpext) -------------------------- "Extensions to FTP", Robert Elz, Paul Hethmon, 23-Sep-02, This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. Geographic Location/Privacy (geopriv) ------------------------------------- "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses", Henning Schulzrinne, 12-Jul-04, This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option for the civic (country, community and street) location of the client or the DHCP server. "A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, 21-Jul-04, This document defines an authorization policy language for controling access to location information. It extends the authorization framework of the common policy markup language towards location-specific access control needs. "A Presence-based GEOPRIV Location Object Format", Jon Peterson, 30-Jun-04, This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. "A Presence Architecture for the Distribution of Geopriv Location", Jon Peterson, 21-Jul-04, Geopriv defines the concept of a 'using protocol', a protocol that carries Geopriv location objects. Geopriv also defines various scenarios for the distribution of location objects that require the concept of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto Geopriv architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of Geopriv. "A Document Format for Expressing Privacy Preferences", Henning Schulzrinne, 21-Jul-04, This document defines a framework for authorization policies controling access to application specific data. This framework combines common location- and SIP-presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. Global Routing Operations (grow) -------------------------------- "BGP Communities for Data Collection", David Meyer, 22-Mar-04, BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network, and to its peers and customers. With the advent of large scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This document defines standard (outbound) communities and their encodings for export to BGP route collectors. "BGP MED Considerations", Danny McPherson, 19-Jul-04, The BGP MED attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, there are a number of issues which may arise when utilizing MEDs in dynamic or complex topologies. This document discusses implementation and deployment considerations regarding BGP MEDs and provides information which implementors and network operators should be familiar with. "Embedding Globally Routable Internet Addresses Considered Harmful", Dave Plonka, 14-Jun-04, This document means to clarify best current practices in the Internet community. Internet hosts should not contain globally routable Internet Protocol addresses embedded within firmware or elsewhere as part of their default configuration such that it influences run-time behavior. "Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT)", David Meyer, 5-Feb-04, The Risk, Interference, and Fit (RIFT) design team was formed to document the concerns and considerations surrounding the use of Internet routing protocols for functions not directly related to routing of IP packets within the Internet and IP networks. This document is the output of that activity. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol", Robert Moskowitz, 11-Jun-04, This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity, Host Identity Tag (HIT) and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS)attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Managed Objects for the Ethernet Passive Optical Networks", Lior Khermosh, 12-May-04, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing devices and interfaces that conform to the Ethernet Passive Optical Networks (EPON) standards as defined in [802.3ah]. The document contains a list of management entities based on the registers defined in the Institute of Electrical and Electronic Engineers, IEEE Draft 802.3ah-2002 Draft 3.2 Annex 30A and mainly partitioned accordingly. "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", Edward Beili, 19-Jul-04, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. This document proposes an extension to the Ethernet-like Interfaces MIB and MAU MIB with a set of objects for managing an Ethernet in the First Mile Copper (EFMCu) interfaces 10Pass-TS and 2Base-TL defined in IEEE standard 802.3ah. "Ethernet in the First Mile (EFM) OAM MIB", Matt Squire, 21-Jun-04, This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in [802.3ah]. The Ethernet OAM functionality is complementary to SNMP management in that it is focused on a small set of link-specific functions for Ethernet interfaces. This document defines objects for controlling those link OAM functions, and on providing mechanisms to take status and input from Ethernet OAM and feed it into a larger TCP/IP network management system. Internet Architecture Board (iab) --------------------------------- "IAB Concerns & Recommendations Regarding Internet Research & Evolution", Randall Atkinson, Sally Floyd, 11-May-04, This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. "Considerations on Increasing Character Repertoires for Protocol Elements", Ted Hardie, Leslie Daigle, 18-Feb-04, This document describes a set of considerations and strategies to use in increasing the character repertoire available in a protocol element or suite of protocol elements. This document is not meant to provide normative instruction to protocol designers, but does hope to provide guidance on common issues arising from this task. This initial draft does not contain real-world examples for the different strategies outlined below; before final publication, the IAB plans to add such examples and solicits feedback from the community on examples appropriate to this draft. Feedback on this point or the draft as a whole should be sent to the editors or the IAB. "A Survey of Authentication Mechanisms", Eric Rescorla, 31-Mar-04, Authentication is a common security issue for the design of Internet protocols. A wide variety of authentication technologies are avail- able. A common problem is knowing which technology to choose or which of a variety of essentially similar implementations of a given tech- nique to choose. This memo provides a survey of available mechanisms and guidance on selecting one for a given protocol. "Writing Protocol Models", Eric Rescorla, 24-May-04, The IETF process depends on peer review. However, in many cases, the documents submitted for publication are extremely difficult to review. Since reviewers have only limited amounts of time, this leads to extremely long review times, inadequate reviews, or both. In my view, a large part of the problem is that most documents fail to pre- sent an architectural model for how the protocol operated, opting instead to siply describe the protocol and let the reviewer figure it out. "IAB Processes for management of liaison relationships", Leslie Daigle, 14-Jul-04, This document discusses the procedures the IAB uses to select organizations to form and maintain liaison relationships with. It further discusses the expectations that the IAB has of such organizations and of the people assigned to manage those relationships. "Internet Denial of Service Considerations", Mark Handley, 11-May-04, This document provides an overview of possible avenues for denial-of- service attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. "A Survey of Internet Identities", Patrik Faltstrom, Geoff Huston, 28-Apr-04, This memo provides an overview of the various realms of identification used within the Internet protocol suite, with specific observations on the role and purpose of the Domain Name System within this environment. Improved Cross-Area Review (icar) --------------------------------- "An Experiment in Early Cross-Area Review for the IETF", David Partain, 9-Jul-04, This memo captures current working group rough consensus on procedures for improved cross-area early review in the IETF. It is a product of the ICAR working group. This memo describes an experiment to improve early cross-area review in the IETF. Early cross-area review aims to improve quality of IETF work by identifying problems early in document development. Improved quality may, in turn, mean that documents can be processed faster in the IESG. Inter-Domain Multicast Routing (idmr) ------------------------------------- "Distance Vector Multicast Routing Protocol", Tom Pusateri, 3-Dec-03, DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88]. "Distance Vector Multicast Routing Protocol Applicability Statement", Tom Pusateri, 12-May-04, This document provides a framework for the use of Distance Vector Multicast Routing Protocol (DVMRP) Version 3 within a multicast routing domain. It is an interior gateway protocol designed to be used within an autonomous system. Inter-Domain Routing (idr) -------------------------- "A Border Gateway Protocol 4 (BGP-4)", Yakov Rekhter, 17-Jun-04, The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", Jeffrey Haas, Susan Hares, 23-Apr-04, This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269. The origin of this memo is from RFC 1269 'Definitions of Managed Objects for the Border Gateway Protocol (Version 3)', which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB was converted to use the SNMPv2 SMI, as well as updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB in a historical context, provide clarifications of some items and also note errors where the MIB fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB with a new one representing the current state of the BGP protocol and its extensions. Distribution of this memo is unlimited. Please forward comments to idr@ietf.org. "Cooperative Route Filtering Capability for BGP-4", Enke Chen, Yakov Rekhter, 10-Mar-04, This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "Graceful Restart Mechanism for BGP", Srihari Sangli, Yakov Rekhter, Rex Fernando, John Scudder, Enke Chen, 9-Jun-04, This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). "BGP support for four-octet AS number space", Quaizar Vohra, Enke Chen, 16-Mar-04, Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. "BGP Extended Communities Attribute", Srihari Sangli, Dan Tappan, Yakov Rekhter, 31-Mar-04, This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. "Aspath Based Outbound Route Filter for BGP-4", Keyur Patel, Susan Hares, 12-Mar-04, This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4),Second Version", Jeffrey Haas, Wayne Tackabury, Susan Hares, 14-Jan-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that facilitate the management of the Border Gateway Protocol Version 4 (BGP4). Distribution of this memo is unlimited. "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 14-Jul-04, This document defines a new BGP capability termed 'Dynamic Capability', which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. "Subcodes for BGP Cease Notification Message", Enke Chen, V Gillet, 25-Mar-04, This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in co-relating network events and diagnosing BGP peering issues. "Multiprotocol Extensions for BGP-4", Tony Bates, Ravi Chandra, Dave Katz, Yakov Rekhter, 25-May-04, Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. "BGP Graceful Restart - Implementation Survey", John Scudder, 12-Mar-04, This document provides a survey of BGP-4 Graceful Restart implementations. "BGP-4 Protocol Analysis", David Meyer, Keyur Patel, 22-Jun-04, The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. "BGP Security Vulnerabilities Analysis", Sandra Murphy, 25-Jun-03, BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to the BGP protocol to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. "Experience with the BGP-4 Protocol", Danny McPherson, Keyur Patel, 19-May-04, The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. "Autonomous System Confederations for BGP", Paul Traina, 19-May-04, The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. "BGP MIB V1 implementation survey", Susan Hares, 12-Jul-04, This document provides of survey of BGP-4 [BGP4] protocol implementing RFC 1657 MIB agents according to the [BGP-v1-MIB] specification. "BGP 4 Implementation Report", Susan Hares, 12-Jul-04, This document provides a survey of the BGP-4 implementation draft- ietf-idr-bgp4-24.txt. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. "BGP Route Reflection - An Alternative to Full Mesh IBGP", Tony Bates, Ravi Chandra, Enke Chen, 12-May-04, The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed. This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. "Multisession BGP", John Scudder, Chandrashekhar Appanna, 6-May-04, This specification augments "Multiprotocol Extensions for BGP-4" [MP- BGP] by proposing a mechanism to allow multiple sessions to be used between a given pair of BGP speakers. Each session is used to transport routes for one or more AFI/SAFI. This provides an alternative to the current [MP-BGP] approach of multiplexing routes for all AFI/SAFI onto a single connection. Use of this approach is expected to increase the robustness of the BGP protocol as it is used to support more and more diverse AFI/SAFI. "Avoid BGP Best Path Transitions from One External to Another", Enke Chen, Srihari Sangli, 19-May-04, In this document we propose a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one router contribute to the churn. Intrusion Detection Exchange Format (idwg) ------------------------------------------ "Intrusion Detection Mesage Exchange Requirements", Mark Wood, Michael Erlinger, 23-Oct-02, The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. "The Intrusion Detection Message Exchange Format", David Curry, Hervé Debar, 19-Jul-04, The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes a data model to represent information exported by intrusion detection systems, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "The Intrusion Detection Exchange Protocol (IDXP)", Benjamin Feinstein, Gregory Matthews, John White, 23-Oct-02, This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in the Intrusion Detection Message Exchange Format (IDMEF) [2], a companion document of the Intrusion Detection Exchange Format (IDWG) working group of the IETF. Internet Emergency Preparedness (ieprep) ---------------------------------------- "Framework for Supporting ETS in IP Telephony", Ken Carlberg, Ian Brown, Cory Beard, 12-Apr-04, This document presents a framework for supporting authorized emergency related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing service in the PSTN, contribute to a constrained solution space. "ETS Requirements for a Single Administrative Domain", Ken Carlberg, 14-Jun-04, This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document is an extension of the General Requirements of [2] and focuses on a more specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. "A Framework for Supporting ETS Within a Single Administrative Domain", Ken Carlberg, 14-Jun-04, This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting ETS within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. Internet Engineering Steering Group (iesg) ------------------------------------------ "Considerations on the Extensibility of IETF protocols", Scott Bradner, Thomas Narten, 4-Jun-04, This document discusses issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions need to be reviewed by the larger IETF community. The document also recommends that major extensions to IETF protocols only take place through normal IETF processes or in coordination with the IETF. "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", Steven Bellovin, 15-Mar-04, The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, 'Protection of BGP Sessions via the TCP MD5 Signature Option'. RFC 2385 will remain at the Proposed Standard level. "The IESG and RFC Editor documents: Procedures", Harald Alvestrand, 15-Jul-04, This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. This document updates procedures described in RFC 2026 and RFC 3710. Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION", Mark Crispin, Ken Murchison, 24-May-04, This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. "IMAP4 ACL extension", Alexey Melnikov, 19-Jul-04, The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. "IMAP ANNOTATE Extension", Randall Gellens, Cyrus Daboo, 20-Jul-04, The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. "IMAP4 LIST Command Extensions", Barry Leiba, 21-Jul-04, IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. "IMAP Extension for Conditional STORE operation", Alexey Melnikov, Steve Hole, 1-Dec-03, Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalfof the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. This document defines an extension to IMAP (RFC 3501). "Internet Message Access Protocol Internationalization", Chris Newman, 7-Jun-04, Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. Instant Messaging and Presence Protocol (impp) ---------------------------------------------- "Common Presence and Instant Messaging: Message Format", Derek Atkins, Graham Klyne, 20-Jan-03, This memo defines the mime type 'message/cpim', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. "Presence Information Data Format (PIDF)", Hiroyasu Sugano, Shingo Fujimoto, 9-May-03, This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type 'application/pidf+xml' to represent the XML MIME entity for PIDF "Address Resolution for Instant Messaging and Presence", Jon Peterson, 22-Oct-03, Presence and instant messaging are defined in RFC2778 [5]. The Common Profiles for Presence [2] and Instant Messaging [1] define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. "Common Profile for Presence (CPP)", Jon Peterson, 22-Oct-03, Presence is defined in RFC2778 [12]. Today, numerous presence protocols are in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. "Common Profile for Instant Messaging (CPIM)", Jon Peterson, 22-Oct-03, Instant messaging is defined in RFC2778 [5]. Today, numerous instant messaging protocols are in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. Internet and Management Support for Storage (imss) -------------------------------------------------- "Transmission of IPv6 Packets over Fibre Channel", Claudio Desanti, 16-Apr-04, This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. Extended Incident Handling (inch) --------------------------------- "Distributed Denial of Service Incident Handling: Real-Time Inter-Network Defense", Kathleen Moriarty, 15-Mar-04, Network security incidents such as Denial of Service (DoS), system compromises, worms, and viruses typically result in the loss of service, data, and resources both human and system. Security incidents can be detrimental to the health of the network as a whole. Network Providers (NP) need to be equipped and ready to assist in tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across NP boundaries to identify the source(s) of an attack. The various methods implemented to detect and trace attacks must be coordinated on the NPs network as well as provide a communication mechanism across network borders. It is imperative that NPs have quick communication methods defined to enable neighboring NPs to assist in tracking a security incident across the Internet. This proposal integrates current incident detection and tracing practices for network traffic, which could be extended for security incident handling. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the defined protocol and extended to each NP's clients. "The Incident Object Description Exchange Format (IODEF) Implementation Guide", Roman Danyliw, 10-Mar-04, The purpose of this Internet-Draft is to provide implementation guidelines for Computer Security Incident Response Teams (CSIRT) adopting the Incident Object Description Exchange Format (IODEF). "Incident Handling: Real-Time Inter-Network Defense", Kathleen Moriarty, 26-Mar-04, Network security incidents such as Denial of Service (DoS), system compromises, worms, and viruses typically result in the loss of service, data, and resources both human and system. Security incidents can be detrimental to the health of the network as a whole. Network Providers (NP) need to be equipped and ready to assist in tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across NP boundaries to identify the source(s) of an attack. The various methods implemented to detect and trace attacks must be coordinated on the NPs network as well as provide a communication mechanism across network borders. It is imperative that NPs have quick communication methods defined to enable neighboring NPs to assist in tracking a security incident across the Internet. This proposal integrates current incident detection and tracing practices for network traffic, which could be extended for security incident handling. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the defined protocol and extended to each NP's clients. IP over Cable Data Network (ipcdn) ---------------------------------- "Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)", Michael Patrick, William Murwin, 27-Oct-03, This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1 and 2.0. "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management", Wilson Sawyer, 16-Feb-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. "Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus", Stan Green, 22-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP based management of the Baseline Privacy Plus features of DOCSIS1.1 and DOCSIS 2.0 compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be Addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. "Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", Azlina Ahmad, 3-Feb-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB, RFC 2669 [5]. This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. "Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces", David Raftus, 22-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). This document revises RFC 2670. Please see section 10 for a description of the changes from RFC 2670. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. "Network-Based Call Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)", Gordon Beacham, Satish Kumar, Sumanth Channabasappa, 20-Jul-04, 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. The set of objects are consistent with the SNMP framework and existing SNMP standards. "Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices", Eugene Nechamkin, Jean-Francois Mule, 20-Jul-04, 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 and IPCablecom compliant Multimedia Terminal Adapter devices. "Management Event MIB for PacketCable/IPCablecom MTAs", Wim De Ketelaere, Eugene Nechamkin, 18-Feb-04, 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. IP over DVB (ipdvb) ------------------- "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks", Gorry Fairhurst, Bernhard Collini-Nocker, 21-May-04, 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. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. "A Framework for transmission of IP datagrams over MPEG-2 networks", Marie-Jose Montpetit, 9-Jul-04, This document describes a new architecture 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. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. IP Flow Information Export (ipfix) ---------------------------------- "Requirements for IP Flow Information Export", Juergen Quittek, 4-Jun-04, This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes and middleboxes. "Architecture Model for IP Flow Information Export", K Norseth, Ganesh Sadasivan, Nevil Brownlee, 14-Jul-04, This memo defines the IPFIX architecture for the selective monitoring of network traffic flows, and for the export of measured IP flow information from an IPFIX device to a Collector, as per the requirements set out in the IPFIX Requirements document. "Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)", Simon Leinen, 4-Jun-04, This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. "Information Model for IP Flow Information Export", Paul Calato, 18-Feb-04, This document defines and information and data model for the IP Flow Information export (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic measurement process. Although developed for the IPFIX protcol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. "IPFIX Protocol Specifications", Benoit Claise, 21-Jul-04, This document specifies the IPFIX protocol that provides network operators with access to IP flow information. In order to export IP flow information to the IPFIX collecting process, a common method of representing the flow data and a standard means of communicating them from an exporter to a collector required. This document describes how the IPFIX flow record data, options record data and control information (templates for example) are carried over a congestion-aware transport protocol from IPFIX exporting process to IPFIX collecting process. "IPFIX Applicability", Tanja Zseby, 14-Jul-04, This document describes how various applications can use the IP Flow Information Export (IPFIX) protocol. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. IP over Optical (ipo) --------------------- "Impairments And Other Constraints On Optical Layer Routing", John Strand, Angela Chiu, 8-May-03, Optical networking poses a number challenges for GMPLS. Optical technology is fundamentally an analog rather than digital technology; and the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks which impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all- optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. IP over InfiniBand (ipoib) -------------------------- "Definitions of Managed Objects for Infiniband Interface Type", Bill Anderson, Sean Harnedy, 13-Feb-04, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture to deliver scalable performance in data centers. This memo defines a portion of Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IBA defined InfiniBand interfaces. "Definition of Managed Objects for the Infiniband Subnet Management Agent (SMA)", Sean Harnedy, 6-Feb-04, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Subnet Management Agents (SMA). "Definition of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management", Sean Harnedy, 6-Feb-04, This memo describes Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. The intent is that these TEXTUAL CONVENTIONs (TCs) will be imported and used in IPOVERIB related MIB modules "IP over InfiniBand(IPoIB) Architecture", Vivek Kashyap, 4-May-04, InfiniBand is a high speed, channel based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. "Transmission of IP over InfiniBand", Vivek Kashyap, 21-Jan-04, This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link layer address to be used when resolving the IP addresses in 'IP over InfiniBand (IPoIB)' subnets. The document also describes the mapping from IP multicast addresse to InfiniBand multicast addresses. Additionally this document defines the setup and configuration of IPoIB links. "DHCP over InfiniBand", Vivek Kashyap, 9-Mar-04, An InfiniBand network uses a link-layer addressing scheme that is 20-octets long. This is larger than the 16-octets reserved for the hardware address in DHCP/BOOTP message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IP over InfiniBand(IPoIB) network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. "Definitions of Managed Objects for Infiniband Channel Adapters (CA)", Sean Harnedy, 13-Feb-04, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Channel Adapters (CA). "Definitions of Managed Objects for the Infiniband Baseboard Management Agent (BMA)", Sean Harnedy, 16-Feb-04, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Baseboard Management Agents (BMA). "Definitions of Managed Objects for the Infiniband Performance Management Agent (PMA)", Sean Harnedy, 16-Feb-04, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Performance Management Agents (PMA). "Infiniband Subnet Manager(SM) MIB", Edwin Tsang, Carl Yang, Cheng Yang, 9-Mar-04, 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 the InfiniBand Subnet Manager(SM) (http://www.infinibandta.org). Internet Printing Protocol (ipp) -------------------------------- "Internet Printing Protocol: Requirements for IPP Notifications", Roger Debry, Harry Lewis, Thomas Hastings, 23-Jun-04, This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a statement of the requirements for notifications as part of an IPP Service. "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", Robert Herriot, Thomas Hastings, 23-Jun-04, This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew- Subscription, and Cancel-Subscription. "Internet Printing Protocol(IPP): Job and Printer Administrative Operations", Carl Kugler, Harry Lewis, Thomas Hastings, 19-Jul-04, This document specifies the following 16 additional OPTIONAL operations for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [RFC2910, RFC2911] "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", Robert Herriot, Carl Kugler, Harry Lewis, 23-Jun-04, This document describes an extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the 'Internet Printing Protocol (IPP): Event Notifications and Subscriptions' specification (ipp-ntfy). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support ipp-ntfy. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications using the Get-Notifications operation defined in this document. IP Performance Metrics (ippm) ----------------------------- "A One-way Active Measurement Protocol (OWAMP)", Stanislav Shalunov, Benjamin Teitelbaum, 21-Jul-04, With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. The One-Way Active Measurement Protocol (OWAMP) can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. "IP Performance Metrics (IPPM) metrics registry", Emile Stephan, 1-Jul-04, This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF. This memo also defines the rules for adding new IP Performance Metrics that are defined in the future. There are branches for other standards bodies and enterprises defined to encourage all IP performance metrics to be registered here. IANA has been assigned to administer this new registry. "IP Performance Metrics (IPPM) reporting Information Base (MIB)", Emile Stephan, Jessie Jewitt, 20-Jul-04, This memo defines a portion of the Management Information Base (MIB) designed for use with network management protocols in TCP/IP-based internets. In particular, this MIB specifies the objects used for managing the results of the IPPM metrics measures, for pushing alarms, and for reporting the measures results. "Packet Reordering Metric for IPPM", Al Morton, 19-Jul-04, This memo defines metrics to evaluate if a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric with purely receiver analysis orientation. Several examples of evaluation using the various sample metrics are included. An Appendix gives extended definitions for evaluating order with packet fragmentation. Intellectual Property Rights (ipr) ---------------------------------- "A Template for IETF Patent Disclosures and Licensing Declarations", Valerie See, 28-Apr-04, This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. "IETF Rights in Contributions", Scott Bradner, 23-Jun-04, The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC XXXY, replaces Section 10 of RFC 2026. [note to RFC editor: replace XXXY with number of IETF IPR] IP Storage (ips) ---------------- "Bootstrapping Clients using the iSCSI Protocol", Prasenjit Sarkar, Duncan Missimer, Costa Sapuntzakis, 18-Mar-04, iSCSI is a proposed transport protocol for SCSI that operates on top of TCP. This memo describes a standard mechanism to enable clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. "Internet Storage Name Service (iSNS)", Josh Tseng, Kevin Gibbons, 13-Feb-04, This document specifies the Internet Storage Name Service (iSNS) protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Charles Monia, 4-Dec-02, This document specifies an architecture and gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions having the fault isolation properties of autonomous systems and the scalability of the IP network. "Finding iSCSI Targets and Name Servers Using SLP", Mark Bakke, John Hufferd, Kaladhar Voruganti, Marjorie Krueger, Todd Sperry, 4-May-04, The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. "Definitions of Managed Objects for iSCSI", Mark Bakke, Jim Muchow, Marjorie Krueger, Tom McSweeney, 5-Mar-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client using the iSCSI (SCSI over TCP) protocol. "Definition of Managed Objects for FCIP", R Natarajan, Antil Rijhsinghani, 18-Jun-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing FCIP entities, as defined in [FCIP] and used in FC fabrics as described in [FCBB2]. "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", Kevin Gibbons, Josh Tseng, Tom McSweeney, 24-Jun-04, The iSNS protocol provides storage name service functionality on an IP network which is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor and control iSNS Client and Servers, including information about registered objects in an iSNS Server. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. "Definitions of Managed Objects For iFCP", Kevin Gibbons, Charles Monia, Josh Tseng, Franco Travostino, 5-Mar-03, The iFCP protocol provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This draft provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. "Definition of Managed Objects for SCSI Entities", Michele Hallak, Mark Bakke, 20-Jul-04, This memo defines a Management Information Base (MIB), namely managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. "Fibre Channel Management MIB", Keith McCloghrie, 20-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for informantion related to Fibre Channel. "Definitions of Managed Objects for User Identity Authentication", Mark Bakke, Jim Muchow, 10-Dec-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This draft was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB provides only the set of identities to be used within access lists; it is the responsibility of other MIBs making use of this one to tie them to their own access lists or other authorization control methods. "NAA naming format for iSCSI Node Names", Robert Elliott, Marjorie Krueger, Mallikarjun Chadalapaka, 16-Jun-04, Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) world wide naming format defined by InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. IP Security Protocol (ipsec) ---------------------------- "IP Encapsulating Security Payload (ESP)", Stephen Kent, 2-Mar-04, This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). "Negotiation of NAT-Traversal in the IKE", Tero Kivinen, 18-Feb-04, This document describes how to detect one or more network address trans- lation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). "UDP Encapsulation of IPsec Packets", Ari Huttunen, 5-May-04, This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). "Internet Key Exchange (IKEv2) Protocol", Charlie Kaufman, 2-Jun-04, This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. "IP Authentication Header", Stephen Kent, 2-Mar-04, This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). "The Internet IP Security PKI Profile of ISAKMP and PKIX", Brian Korver, Eric Rescorla, 28-Apr-04, ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifications such as IKE, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. "Extended Sequence Number Addendum to IPsec DOI for ISAKMP", Stephen Kent, 16-Feb-04, The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol(ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association. "Using AES CCM Mode With IPsec ESP", Russell Housley, 20-Nov-03, This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", Jeffrey Schiller, 21-Apr-04, The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. "Cryptographic Suites for IPsec", Paul Hoffman, 14-Apr-04, The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. "Security Architecture for the Internet Protocol", Stephen Kent, Karen Seo, 28-Apr-04, This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). "Cryptographic Algorithm Implementation Requirements For ESP And AH", Donald Eastlake 3rd, 13-Jan-04, The IPSEC series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPSEC Security Association (SA). To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. "Initial IANA registry contents", Michael Richardson, 9-Apr-04, This is a non-standards track document that tells IANA how to populate the initial IKEv2 registries. "The Use of Galois/Counter Mode (GCM) in IPsec ESP", David McGrew, 27-Apr-04, This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. IPSEC KEYing information resource record (ipseckey) --------------------------------------------------- "A method for storing IPsec keying material in DNS", Michael Richardson, 19-Jul-04, This document describes a new resource record for Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when establishing an IPsec tunnel with the entity in question. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. IP Security Policy (ipsp) ------------------------- "IPSec Policy Information Base", Man Li, David Arneson, Avri Doria, Jamie Jason, Cliff Wang, Markus Stenberg, 6-Apr-04, This document describes a portion of the Policy Information Base (PIB) for a device implementing the IP Security Architecture. The provisioning classes defined here provide control of IPsec policy. These provisioning classes can be used with other non-IPsec provisioning classes (defined in other PIB modules) to provide for a comprehensive policy controlled mapping of service requirement to device capability and usage. "IPsec Security Policy Database Configuration MIB", Wesley Hardaker, 23-Jan-04, This document defines a SMIv2 Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPSec protocol. The policy-based packet filtering and the corresponding execution of actions is of a more general nature than for IPsec configuration only, such as for configuration of a firewall. This MIB module is designed with future extensibility in mind. It is thus possible to externally add other packet filters and actions to the policy-based packet filtering system defined in this document. "IPsec Security Policy IPsec Action MIB", Wesley Hardaker, 23-Jan-04, This document defines a SMIv2 Management Information Base (MIB) module for configuring IPsec actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IPSec protocol actions on that device. The IPSP IPsec Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. "IPsec Security Policy IKE Action MIB", Wesley Hardaker, 23-Jan-04, This document defines a SMIv2 Management Information Base (MIB) module for configuring IKE actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IKE protocol actions on that device. The IPSP IKE Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. IP Telephony (iptel) -------------------- "CPL: A Language for User Control of Internet Telephony Services", Jonathan Lennox, Xiaotao Wu, Henning Schulzrinne, 29-Apr-04, The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@ietf.org and/or the authors. "Management Information Base for Telephony Routing over IP (TRIP)", David Zinman, Dave Walker, James Jiang, 6-Feb-04, This memo defines a portion of the MIB (Management Information Base) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage for TRIP (Telephony Routing over IP) devices "A Telephony Gateway REgistration Protocol (TGREP)", Manjunath Bangalore, 11-Mar-04, This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a TRIP Location Server, which in turn can propogate that routing information within the same, and other internet telephony administrative domains (ITAD). TGREP shares a lot of similarites with the TRIP Protocol. It has similar procedures and Finite State Machine for session establishment. It also shares the same format for messaages and a subset of attributes with TRIP. "Representing trunk groups in tel/sip URIs", Vijay Gurbani, 12-Jan-04, This document describes a standardized mechanism to convey trunk group- related information in SIP and TEL URIs. An extension to the 'tel' URI is defined for this purpose. "The tel URI for Telephone Numbers", Henning Schulzrinne, 29-Jun-04, This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. "New Parameters for the 'tel' URI to Support Number Portability", James Yu, 19-Apr-04, This document defines several new parameters in the 'tel' Uniform Resource Identifier (URI) to support number portability (NP) for geographical telephone numbers and freephone numbers. The 'rn' parameter carries the routing number for a ported geographical telephone number. The presence of the 'npdi' parameter indicates that NP database dip has been performed on a geographical telephone number. The 'cic' parameter identifies the freephone service provider for a freephone number. The 'rn-context' and 'cic-context' parameters describe the 'rn' and 'cic' parameters respectively when the 'rn' and 'cic' parameters contain information in the 'local' format. IP Version 6 Working Group (ipv6) --------------------------------- "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", Alex Conta, Steve Deering, 3-Jun-04, This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). "Default Router Preferences and More-Specific Routes", Richard Draves, Dave Thaler, 29-Jun-04, This document describes 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. "An analysis of IPv6 anycast", Jun-ichiro Hagino, K Ettican, 30-Jun-03, The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. "IPv6 Host to Router Load Sharing", Robert Hinden, 5-May-04, The original IPv6 conceptual sending algorithm does not do load- sharing among equivalent IPv6 routers, and suggests schemes which can be problematic in practice. This document updates the conceptual sending algorithm so that traffic to different destinations can be distributed among routers in an efficient fashion. "Link Scoped IPv6 Multicast Addresses", Jung-Soo Park, 15-Jul-04, This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-IDs to allocate multicast addresses. When the link- local unicast address is configured at each interface of a host, an interface ID is uniquely determined. By delegating multicast addresses at the same time as the interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in serverless environments. Basically, it is preferred to use this method for the link-local scope rather than Unicast-Prefix-based IPv6 Multicast Addresses [RFC 3306]. "IPv6 Node Requirements", John Loughney, 24-May-04, This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. "IP Forwarding Table MIB", Margaret Wasserman, Brian Haberman, 12-Feb-04, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096. "Management Information Base for the Transmission Control Protocol (TCP)", Rajiv Raghunarayan, 20-Feb-04, 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) in an IP version independent manner. This memo obsoletes RFCs 2012 and 2452. "Management Information Base for the Internet Protocol (IP)", Shawn Routhier, 24-May-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. "Management Information Base for the User Datagram Protocol (UDP)", Bill Fenner, 28-Apr-04, 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 User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. "IPv6 Scoped Address Architecture", Steve Deering, 13-Feb-04, This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids using the syntax and usage of unicast site-local addresses. "Deprecating Site Local Addresses", Christian Huitema, Brian Carpenter, 30-Mar-04, This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. "Unique Local IPv6 Unicast Addresses", Robert Hinden, Brian Haberman, 29-Jun-04, This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. "IP Tunnel MIB", Dave Thaler, 2-Jul-04, 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 tunnels of any type over IPv4 and IPv6 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIBs. "IPv6 Stateless Address Autoconfiguration", Susan Thomson, 21-Jul-04, This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol is specified in RFC 3315 and RFC 3736. "Optimistic Duplicate Address Detection for IPv6", Nick Moore, 29-Jun-04, Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case, and while remaining interoperable with unmodified nodes. "IP Version 6 over PPP", Srihari Varada, 9-Jun-04, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 packets over PPP links as well as the NCP for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. This document is an update to RFC 2472 and, hence, obsoletes it. "Centrally Assigned Unique Local IPv6 Unicast Addresses", Robert Hinden, Brian Haberman, 29-Jun-04, This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. "Neighbor Discovery for IP version 6 (IPv6)", , 16-Jul-04, This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. IS-IS for IP Internets (isis) ----------------------------- "Management Information Base for IS-IS", Jeff Parker, 6-Jul-04, This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. "IS-IS Extensions in Support of Generalized MPLS", Kireeti Kompella, Yakov Rekhter, 27-Oct-03, This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. "M-ISIS: Multi Topology (MT)Routing in IS-IS", Tony Przygienda, Naiming Shen, Nischal Sheth, 25-Jun-04, This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. "Point-to-point operation over LAN in link-state routing protocols", Naiming Shen, 14-Jul-04, The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. "A Policy Control Mechanism is IS-IS Using Administrative Tags", Christian Martin, Brad Neal, Stefano Previdi, 13-Jul-04, This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs) for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. Additionally, the information can be placed in LSPs that have TLVs as yet undefined, if this information is used to convey the same meaning in these future TLVs as it is used in the currently defined TLVs. "TLV for Experimental Use", Philip Christian, 6-May-04, This document defines a TLV that may be used by any individual, company or other organisation for experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. Kerberized Internet Negotiation of Keys (kink) ---------------------------------------------- "Kerberized Internet Negotiation of Keys (KINK)", Matt Thomas, J Vilhuber, 15-Jul-04, The Kerberized Internet Negotiation of Keys protocol (KINK) defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to set up and maintain IPsec security associations using Kerberos authentication. KINK reuses many ISAKMP Quick Mode payloads to create, delete and maintain IPsec security associations which should lead to substantial reuse of existing IKE implementations. Kerberos WG (krbwg) ------------------- "Public Key Cryptography for Initial Authentication in Kerberos", Brian Tung, Clifford Neuman, Matt Hur, Ari Medvinsky, Sasha Medvinsky, John Wray, Jonathan Trostle, 20-Jul-04, This draft describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification (RFC 1510bis [1]). These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by passing cryptographic certificates and associated authenticators in preauthentication data fields. "AES Encryption for Kerberos 5", Kenneth Raeburn, 21-Jul-04, The US National Institute of Standards and Technology has chosen a new Advanced Encryption Standard, which is significantly faster and (it is believed) more secure than the old DES algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. Comments should be sent to the author, or to the IETF Kerberos working group (ietf-krb-wg@anl.gov). "Generating KDC Referrals to locate Kerberos realms", Michael Swift, John Brezak, Jonathan Trostle, 21-Jul-04, The draft documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. "Encryption and Checksum Specifications for Kerberos 5", Kenneth Raeburn, 11-Feb-04, This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. Several mechanisms are also defined in this document. Some are taken from RFC 1510, modified in form to fit this new framework, and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered 'required to implement'. Comments should be sent to the editor, or to the IETF Kerberos working group (ietf-krb-wg@anl.gov). "The Kerberos Network Authentication Service (V5)", Clifford Neuman, 30-Jun-04, This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. "Integrating Single-use Authentication Mechanisms with Kerberos", Clifford Neuman, 15-Jul-04, This document defines extensions to the Kerberos protocol specifi- cation [RFC1510] which provide a method by which a variety of single-use authentication mechanisms may be supported within the protocol. The method defined specifies a standard fashion in which the preauthentication data and error data fields in Kerberos mes- sages may be used to support single-use authentication mechanisms. "Kerberos Set/Change Password: Version 2", Jonathan Trostle, 20-Jul-04, This document specifies an extensible protocol for setting keys and changing the passwords of Kerberos V principals. "The Kerberos Version 5 GSS-API Mechanism: Version 2", Larry Zhu, Karthik Jaganathan, Sam Hartman, 17-Mar-04, This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism. RFC-1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. "A Generalized Framework for Kerberos Preauthentication", Sam Hartman, 20-Jul-04, Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a mechanism called preauthentication for proving the identity of a principal and for better protecting the long-term secret of the principal. This document describes a model for Kerberos preauthentication mechanisms. The model describes what state in the Kerberos request a preauthentication mechanism is likely to change. It also describes how multiple preauthentication mechanisms used in the same request will interact. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP)", Gilles Bourdon, 21-Jul-04, The Layer Two Tunneling Protocol (L2TP) provides a standard method for tunneling PPP packets. This document describes an extension to L2TP, in order to have an efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by such tunnels. "Layer Two Tunneling Protocol (Version 3)", Jed Lau, Mark Townsley, Ignacio Goyret, 9-Jun-04, This document describes 'version 3' of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple layer 2 connections between two IP connected nodes. Additional documents detail the specifics for each link-type being emulated. "Frame-Relay over L2TPv3", Mark Townsley, George Wilkie, Skip Booth, Jed Lau, Stewart Bryant, 26-Mar-04, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame-Relay over L2TPv3, including frame encapsulation, virtual- circuit creation, deletion, and line status change notification. "Fail Over extensions for L2TP 'failover'", Reinaldo Penno, Keyur Parikh, 11-Mar-04, L2TP is a connection-oriented protocol that has shared state between active endpoints. Some of this shared state is vital for operation but may be rather volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid just for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network and improving a remote system's layer 2 connectivity. "HDLC Frames Over L2TPv3", Mark Townsley, 31-Mar-04, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel High Level Data Link Control (HDLC) frames over L2TPv3. "Transport of Ethernet Frames over L2TPv3", Rahul Aggarwal, 7-Jan-04, This document describes transport of Ethernet frames over Layer 2 Tunneling Protocol (L2TPv3). This includes the transport of Ethernet port to port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudo Wires to transport Ethernet frames over an IP network. "L2VPN Extensions for L2TP", Wei Luo, 14-Jul-04, The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering LACs, which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPN in a unified fashion. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Loa Andersson, Eric Rosen, 28-Jun-04, This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Waldemar Augustyn, Yetik Serbest, 4-Feb-04, This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint to multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. "Virtual Private LAN Service", Kireeti Kompella, 18-May-04, Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 VPN; however, in the case of VPLS, the customers in the VPN are connected by a multipoint network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, and proposes a mechanism for signaling a VPLS, as well as for forwarding VPLS frames across a packet switched network. "Virtual Private LAN Services over MPLS", Marc Lasserre, Vach Kompella, 26-Apr-04, This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling demultiplexor labels, extending [PWE3-CTRL] and rudimentary support for availability (multi-homing). It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3- ETHERNET]. "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", Eric Rosen, Vasile Radoaca, 11-Mar-04, [PWE3-CONTROL] specifies a 'signaling protocol' which uses extensions of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-ARCH]. Like any protocol which sets up connections, the signaling protocol provides a method by which each endpoint can identify the other. [L2VPN-FW] describes a number of different ways in which sets of pseudowires may be combined together into 'Provider Provisioned Layer 2 VPNs' (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. Different kinds of L2VPN may have different 'provisioning models', i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a 'discovery process', and once the information is discovered, the signaling protocol is automatically invoked to set up the required pseudowires. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of PPVPN provisioning models, and specifies the semantic structure of the endpoint identifiers required. It further specifies how the endpoint identifiers are carried in the 'Generalized Identifier FEC' of [PWE3-CONTROL]. It is believed that the specified identifiers can also be carried within the L2TP signaling protocol, though this is currently not specified. "Radius/L2TP Based VPLS", Juha Heinanen, Mark Townsley, Stephen Bailey, 21-Jan-04, This memo describes a simple mechanism to implement provider provisioned Virtual Private LAN Service (VPLS) using Radius for PE discovery and L2TP as the control and data plane protocol. "Using RADIUS for PE-Based VPN Discovery", Juha Heinanen, 10-Feb-04, This document describes how in PE-based VPNs, a PE of a VPN can use RADIUS to authenticate its CEs and discover the other PEs of the VPN. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "Service requirements for Layer 3 Virtual Private Networks", Marco Carugi, David McDysan, 20-Jul-04, This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use for the provisioning of a VPN service. This document expresses a service provider perspective, based upon past experience of IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer as well as a service provider perspective. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Ross Callon, Muneyoshi Suzuki, 22-Jul-03, This document provides a framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy De Clercq, 13-Feb-04, This document describes the procedures for a Service Provider to offer Virtual Private Network Services to its customers by provisioning the CE devices on behalf of the customer. The IPsec technology is used to protect the customer traffic. "BGP-MPLS VPN extension for IPv6 VPN", Jeremy De Clercq, Dirk Ooms, Marco Carugi, Francois Le Faucheur, 7-Jun-04, This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method extends the 'BGP/MPLS VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding route distribution in 'Multiprotocol BGP'. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IPsec, IP-in-IP and GRE. "MPLS/BGP Layer 3 Virtual Private Network Management Information Base", Thomas Nadeau, 23-Jun-04, This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multi-protocol Label Switching Layer-3 Virtual Private Networks on a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. "BGP/MPLS IP VPNs", Eric Rosen, 15-Sep-03, This document describes a method by which a Service Provider may use an IP backbone to provide VPNs (Virtual Private Networks) for its customers. This method uses a 'peer model', in which the customers' edge routers ('CE routers') send their routes to the Service Provider's edge routers ('PE routers'). BGP is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute, to the CE routers in a particular VPN, the routes from other the CE routers in that VPN. The CE routers do not peer with each other, hence there is no 'overlay' visible to the VPN's routing algorithm. Each route within a VPN is assigned an MPLS label; when BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the Service Provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route that is the best match to the packet's destination address. This MPLS packet is further encapsulated (e.g., with another MPLS label, or with an IP or GRE tunnel header) so that it gets tunneled across the backbone to the proper PE router. Thus the backbone core routers do not need to know the VPN routes. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider which uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. This document obsoletes RFC 2547. "Use of PE-PE IPsec in RFC2547 VPNs", Eric Rosen, Jeremy De Clercq, Chandru Sargor, 9-Mar-04, In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets traveling from one Provider Edge (PE) router to another generally carry two MPLS labels, an inner label that corresponds to a VPN- specific route, and an outer label that corresponds to a Label Switched Path (LSP) between the PE routers. In some circumstances, it is desirable to support the same type of VPN architecture, but using an IPsec Security Association in place of that LSP. The outer MPLS label would thus be replaced by an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of BGP/MPLS IP VPNs using the IPsec encapsulation. "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Eric Rosen, 5-Feb-04, This document specifies procedures to be used when a Service Provider (SP) provides 'BGP/MPLS IP VPN' service to a customer, and the customer uses OSPF to advertise its routes to the SP. "Use of PE-PE GRE or IP in BGP/MPLS IP VPNs", Yakov Rekhter, Eric Rosen, 14-Apr-04, This draft describes a variation of BGP/MPLS IP VPNs ([BGP-MPLS-VPN]) in which the outermost MPLS label of a VPN packet (the tunnel label) is replaced with either IP or a GRE encapsulation. This enables the VPN packets to be carried over non-MPLS networks. "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", Hamid Ould-Brahim, Eric Rosen, Yakov Rekhter, 13-May-04, In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for both layer-2 VPN architectures and layer-3 VPNs (Virtual Routers –VR [VPN-VR]). This mechanism is based on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for distributing VPN routing information within the service provider(s). "Network based IP VPN Architecture using Virtual Routers", Paul Knight, Hamid Ould-Brahim, Bryan Gleeson, 26-Apr-04, This draft describes a network-based Virtual Private Network (VPN) architecture using the virtual router (VR) concept. Multiple VRs can exist in a single physical device. A VR emulates all the functionality of a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Any routing protocol can be used to distribute VPN reachability information among VRs, and no VPN- related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be configured through layer-2 links or through IP- or MPLS-based tunnels. Traffic from VRs belonging to different VPNs may be aggregated over a 'backbone VR' network, which greatly simplifies VPN provisioning. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers. "Virtual Router Management Information Base Using SMIv2", Elwin Stelzer, S Hancock, Benson Schliesser, Joseph Laria, 20-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In paticular, it defines objects for managing networks using Virtual Routers (VR). "Definition of Textual Conventions for Virtual Private Network (VPN) Management", Benson Schliesser, Thomas Nadeau, 3-Jun-04, This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). "Applicability Statement for BGP/MPLS IP VPNs", Eric Rosen, 11-May-04, This document provides an Applicability Statement for the VPN solution described in [BGP-MPLS-IP-VPN] and other documents listed in the References section. "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", Ananth Nagarajan, 16-Feb-04, This document is an applicability statement for Layer 3 Provider Provisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR) approaches. This document describes how VR-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document. "Framework for PPVPN Operations and Management", Yacine Mghazli, 20-Jul-04, This document provides a framework for Provider Provisioned Virtual Private Networks (PPVPNs) operation and management. This framework intends to produce a coherent description of the significant technical issues which are important in the design of PPVPN management solution. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. "Security Framework for Provider Provisioned Virtual Private Networks", Luyuan Fang, 20-Jul-04, This draft addresses security aspects pertaining to Provider Provisioned Virtual Private Networks (PPVPNs). We first describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. We also describe how these security attacks should be detected and reported. We then discuss the possible user requirements in terms of security in a PPVPN service. These user requirements translate into corresponding requirements for the providers. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, we define a template that may be used to analyze the security characteristics of a specific PPVPN technology and describe them in a manner consistent with this framework. "Applicability Statement for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy DeClercq, 27-Jan-04, This document is an applicability statement for Provider Provisioned CE-based IPsec VPNs, as discribed in [CEVPN]. This document describes how provider provisioned CE-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document [ASGUIDE] and the key security requirements according to the template in section 8 of the VPN security framework document [SEC-FW]. "PPVPN terminology", Loa Andersson, 4-Jun-04, The provider provisioned VPN solutions have attracted a great deal of interest. Memos proposing different and overlapping solutions have been discussed on the PPVPN mailing list and in the Working Group meetings. This has lead to the development of a partly new set of concepts used to describe the set of VPN services. To a certain extent there is more than one term covering the same concept and sometimes the same term covers more than one concept. The terminology needs to be made clearer and more intuitive. This document seeks to fill at least part of that need. "Constrained VPN route distribution", Ronald Bonica, 2-Jun-04, This document defines MP-BGP procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) between different autonomous systems or distinct clusters of the same autonomous system. LDAP (v3) Revision (ldapbis) ---------------------------- "LDAP:String Representation of Distinguished Names", Kurt Zeilenga, 8-Jun-04, The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. "LDAP: The Protocol", Jim Sermersheim, 11-May-04, This document describes the protocol elements, along with their semantics and encodings, for the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). "LDAP: String Representation of Search Filters", Mark Smith, Tim Howes, 14-Jul-04, LDAP search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs and in other applications. "LDAP: Authentication Methods and Connection Level Security Mechanism", Rod Harrison, 21-Jul-04, This document describes authentication methods and connection level security mechanisms of the Lightweight Directory Access Protocol (LDAP). "LDAP: Uniform Resource Locator", Mark Smith, Tim Howes, 15-Jul-04, This document describes a format for an LDAP Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAPv3 referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. "LDAP: Schema for User Applications", Kathy Dally, 19-Jul-04, This document is a integral part of the Lightweight Directory Access Protocol (LDAP) technical specification [ROADMAP]. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as, White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", Kathy Dally, Steven Legg, 21-May-04, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, and whose values may be transfered in the LDAP protocol, has a defined syntax which constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", Kurt Zeilenga, 8-Jun-04, The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document provides a roadmap of the LDAP Technical Specification. "LDAP: Directory Information Models", Kurt Zeilenga, 8-Jun-04, The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. "LDAP: Internationalized String Preparation", Kurt Zeilenga, 8-Jun-04, The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This lead to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. "IANA Considerations for LDAP", Kurt Zeilenga, 8-Jun-04, This document provides procedures for registering extensible elements of Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. LDAP Duplication/Replication/Update Protocols (ldup) ---------------------------------------------------- "The LDUP Replication Update Protocol", Ellen Stokes, 7-Jan-04, The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updateable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAPv3 extended operations and controls. LDAPv3 is described in RFC 2251 [LDAPv3]. Some LDAPv3 extended operations and controls described here are LDAPv3 extended operations used to group related operations. The protocol elements used for grouping are described in LDAPv3: Grouping of Related Operations [GROUPING]. Certain terms used in this document are defined in the document 'LDAP Replication Architecture' [ARCHITECTURE]. "LDAP Client Update Protocol", Rich Megginson, Mark Smith, Olga Natkovich, Jeff Parham, 27-Aug-03, This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. Enhancements to Internet email to support diverse service environments (lemonade) --------------------------------------------------------------------------------- "IMAP4 Channel Transport Mechanism", Lyndon Nerenberg, 20-Jul-04, This specifications defines a method for IMAP4 clients to retrieve message content via an external (i.e. non-IMAP) protocol mechanism. "Goals for Internet Messaging to Support Diverse Service Environments", Jeff Wong, 20-Jul-04, The LEMONADE Working Group -- Internet Messaging to support diverse service environments -- is chartered to provide a new set of enhancements to Internet mail. The enhancements are to facilitate its use by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained with limited resources. The enhanced mail must continue to support the existing service as before. "Internet Message Access Protocol (IMAP) CATENATE Extension", Pete Resnick, 9-Jan-04, The CATENATE extension to the Internet Message Access Protocol (IMAP) allows clients to create messages on the IMAP server which may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message on to a new message without having to first download the data and then upload it back to the server. "Internet Message Access Protocol (IMAP) - URLAUTH Extension", , 9-Jul-04, This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of "URLAUTH". "IMAP Conventions for Message Context", Gregory Vaudreuil, 13-Jul-04, By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. "IMAP4 extension for quick reconnect", Alexey Melnikov, 13-Jul-04, Mobile operators usually charge users for the time their mobile client is connected to the Internet and/or for the amount of information sent/received. Thus a mobile client should minimize time it stays connected to its mail server, which suggests that it should disconnect and reconnect frequently. Also, it is possible that the mobile client unexpectedly leaves area of connectivity, which will require that the client reconnects when connectivity returns. This document defines a quick reconnect IMAP4 extension, which gives a mobile client ability to resume a previously abandoned session, without the need to perform a full synchronization sequence. "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", Randall Gellens, 14-Jul-04, The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in ESMTP and Internet message headers. "Lemonade Server to Client Notifications", Stéphane Maes, 19-Jul-04, Lemonade server to client notifications provides some extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. These notifications support pushing crucial changes actively to a client, rather than requiring the client to initiate contact to ask for state changes. "SMTP Submission Service Extension for Future Delivery", Gregory White, Gregory Vaudreuil, 22-Jul-04, 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. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-term Archive Service Requirements", Carl Wallace, 4-May-04, In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the technical requirements for a long-term archive service to support such scenarios. "Evidence Record Syntax (ERS)", Ralf Brandner, 21-Jul-04, In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. "Notary Services requirements", Tobias Gondrom, 16-Jul-04, Notary services are available today in a wide variety for paper based processes and documents. To define the needs, requirements and future world for notary services in the elctronic world, this document describes use cases and scenarios as base for further discussion and work of the LTANS WG in this area. Multicast & Anycast Group Membership (magma) -------------------------------------------- "Using IGMPv3 and MLDv2 For Source-Specific Multicast", Hugh Holbrook, Bradley Cain, Brian Haberman, 18-Feb-04, The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source- Specific Multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an 'SSM-aware' router and host, and clarifies and, in some cases, modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accomodate source- specific multicast. "IGMPv3/MLDv2 and Multicast Routing Protocol Interaction", Brian Haberman, Jay Martin, 27-Oct-03, The definitions of IGMPv3 and MLDv2 require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates multicast routing protocols to manage and utilize the information. This document will describe how multicast routing protocols will interact with these source-filtering group management protocols. "Considerations for IGMP and MLD Snooping Switches", Morten Christensen, Karen Kimball, Frank Solensky, 5-May-04, This memo describes the recommendations for IGMP- and MLD-snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. "IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, 6-Apr-04, In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This draft describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. "Multicast Source Notification of Interest Protocol (MSNIP)", Bill Fenner, 11-Mar-04, This document discusses the Multicast Source Interest Notification Protocol (MSNIP). MSNIP is an extension to IGMPv3 and MLDv2 that provides membership notification services for sources of multicast traffic operating within the SSM destination address range. "Multicast Group Membership Discovery MIB", Julian Chesterfield, 23-Jun-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. "Multicast Router Discovery", Brian Haberman, Jim Martin, 20-Jul-04, The concept of IGMP snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. Mobile Ad-hoc Networks (manet) ------------------------------ "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", Dave Johnson, 22-Jul-04, The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of 'Route Discovery' and 'Route Maintenance', which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on-demand, allowing the routing packet overhead of DSR to scale automatically to only that needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only 'soft state' in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes, and is designed to work well with even very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. MTA Authorization Records in DNS (marid) ---------------------------------------- "SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message", Eric Allman, 20-Jul-04, This memo defines an extension to the Simple Mail Transfer Protocol SMTP) service, which allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e- mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. "MTA Authentication Records in DNS", Jim Lyon, 20-Jul-04, Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- 'spoofed' in this case means the address is used without the permission of the domain owner. This document describes the following: mechanisms by which a domain owner can publish its set of outgoing MTAs, mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant. "Client SMTP Validation (CSV)", Dave Crocker, 21-Jul-04, Internet mail relies on exchanges between systems that have made no prior arrangement with each other. Widespread abuse of the email system has led operators to demand accountability for the email their receiving SMTP servers are being asked to process. Client SMTP Validation (CSV) provides an economical service that permits a receiving SMTP server to decide whether a sending SMTP client is likely to produce well-behaved traffic, or at least to decide whether the client is sufficiently accountable for its actions. CSV provides a small, simple and useful improvement to Internet mail service accountability. It builds upon the existing practice of service providers that accredit the networks from which sending systems are connecting. "Client SMTP Authorization (CSA)", Douglas Otis, 21-Jul-04, Internet operation has typically required no public mechanism for announcing restriction or permission of particular hosts to operate clients or servers for particular services on behalf of particular domains. What is missing is an open, interoperable means by which a trusted agency can announce authorization for a host to operate a service. The current specification supports this capability for sending SMTP clients. Specifically, is a sending SMTP client permitted to act as a client MTA? Has a separate authority given it permission to perform this service? Client SMTP Authorization (CSA) specifies a DNS-based record that states whether an associated host has permission to operate as a client MTA. "Domain Name Accreditation (DNA)", Dave Crocker, 21-Jul-04, Increased diversity and abuse of access, across the open Internet, mandates additional accountability for sending SMTP clients, in the absence of prior, direct arrangement with receiving SMTP servers. One means for enabling this is by registration with third-party services that vouch for the policies and accountability of SMTP clients accessing SMTP servers. This specification defines a means for an SMTP client to list third-party services that are prepared to vouch for it, and a means for an SMTP server, or its intermediary, to query vouching services. "Behind The Curtain: An Apology for Sender ID", Meng Weng Wong, 24-Jun-04, The architecture of Sender ID follows from a set of design decisions. Those decisions were motivated by philosophical, engineering, and political considerations. This document reviews some of the important choice that distinguish Sender ID from alternative possibilities in the same space. "The SPF Record Format and Test Protocol", Meng Weng Wong, 13-Jul-04, This document defines the format of a record that domains publish to authorize a set of hosts to send mail on its behalf. This document also defines the check_host() function that mail receivers evaluate to see if a particular host is authorized to submit a particular piece of mail. This document only describes the particulars of the syntax and the algorithm of the function. See the MARID Core draft (draft-ietf-marid-core) for how these are used in the context of sending and receiving Internet mail. "The SPF Record Format and Test Protocol", Meng Weng Wong, 13-Jul-04, This document defines the format of a record that domains publish to authorize a set of hosts to send mail on its behalf. This document also defines the check_host() function that mail receivers evaluate to see if a particular host is authorized to submit a particular piece of mail. This document only describes the particulars of the syntax and the algorithm of the function. See the MARID Core draft (draft-ietf-marid-core) for how these are used in the context of sending and receiving Internet mail. MBONE Deployment (mboned) ------------------------- "Source-Specific Protocol Independent Multicast in 232/8", David Meyer, Robert Rockell, Greg Shepherd, 11-Mar-04, IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast [SSM] destination addresses and are reserved for use by source- specific applications and protocols [IANA]. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. "IPv4 Automatic Multicast Without Explicit Tunnels (AMT)", Dave Thaler, Lorenzo Vicisano, 17-Feb-04, Automatic Multicast Tunneling (AMT) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure (MBone) and does not require any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack, or applications, are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers. "Multicast Source Discovery Protocol (MSDP) Deployment Scenarios", Mike McBride, 11-Mar-04, This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM) "Unicast-Prefix-based IPv4 Multicast Addresses", Dave Thaler, 20-Jan-04, This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix- based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", Pekka Savola, Brian Haberman, 2-Jul-04, This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast, and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. "IANA Guidelines for IPv4 Multicast Address Assignments", Zaid Albanna, Kevin Almeroth, Michelle Cotton, David Meyer, 15-Mar-04, The Internet Assigned Numbers Authority is charged with allocating parameter values for fields in protocols which have been designed, created or are maintained by the Internet Engineering Task Force. This document provides guidelines for the assignment of the IPv4 IP multicast address space. "PIM-SM Multicast Routing Security Issues and Enhancements", Pekka Savola, Rami Lehtonen, David Meyer, 28-Jun-04, This memo describes security threats for the larger (intra-domain, or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any Source Multicast (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations to mitigate the identified threats. "Multicast Source Discovery protocol MIB", Bill Fenner, Dave Thaler, 12-Jul-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) [1] speakers. Media Gateway Control (megaco) ------------------------------ "The Megaco/H.248v2 Gateway Control Protocol, version 2", Christian Groves, Marcello Pantaleo, 3-Apr-03, This document describes the second version of the general-purpose gateway control protocol standardized as Megaco in the IETF and as Recommendation H.248 (now H.248.1) in the ITU-T. It is common text with Recommendation H.248.1 (05/02), published by the ITU-T. Megaco v2 includes the corrections to RFC 3015 which resulted in RFC xxxx [draft-ietf-megaco-3015corr-02.txt], plus the following new capabilities: - ability to audit specific properties, events, signals and statistics - use of serviceChange to indicate that capabilities have changed in the Media Gateway - playing a signal on the Root Termination - limiting the number of repetitions of transaction pending - allowing topology to be set per stream - ability to audit context properties - new Nx64K multiplex type - provision for digit buffering when a digit map completes. In addition, the use of the Modem Descriptor was deprecated. A detailed list of changes from draft-ietf-megaco-3015corr- 02.txt/H.248.1 (03/02) to this document is given in Appendix II at the end of this document. "Megaco/H.248 Call flow examples", Madhubabu Brahmanapally, Prerepa Viswanadham, Krishna Gundamaraju, 15-Mar-04, The Megaco/H.248 call flow examples draft illustrates the usage of Megaco - Version 1 protocol [Ref:3] defined between the Media Gateway Controller and Media Gateway. In light of the vast features presently incorporated and continuously evolving features of the protocol, it serves the purpose of representing typical use case scenarios. There are a lot of possible scenarios for usage of MEGACO protocol. It is not the intent of the draft to represent the inter-working functionality among various protocols, however, an attempt is made to depict its usage in such a case for the purpose of completeness in the larger perspective. An attempt has been made to illustrate the supplementary call services using MEGACO. Middlebox Communication (midcom) -------------------------------- "Middlebox Communications (MIDCOM) Protocol Evaluation", Mary Barnes, 21-Nov-02, This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. "MIDCOM Protocol Semantics", Martin Stiemerling, 17-Jun-04, This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. "Definitions of Managed Objects for Middlebox Communication", Juergen Quittek, Martin Stiemerling, Pyda Srisuresh, 21-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC XXXX. Mobility for IPv4 (mip4) ------------------------ "Low latency Handoffs in Mobile IPv4", Karim Malki, 3-Jun-04, Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low- latency Mobile IP handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. "AAA Registration Keys for Mobile IPv4", Charles Perkins, Pat Calhoun, 2-Jun-04, AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. "Problem Statement: Mobile IPv4 Traversal of VPN Gateways", Farid Adrangi, Henrik Levkowetz, 16-Feb-04, Deploying Mobile-IP v4 in networks which are connected to the Internet through a VPN (Virtual Private Network) gateway presents some problems which do not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions. "Mobile IPv4 Challenge/Response Extensions (revised)", Charles Perkins, Pat Calhoun, Jayshree Bharatia, 14-Jun-04, Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays, and does not allow for the use of existing techniques (such as CHAP [10]) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. Furthermore, this document updates RFC 3344 [7] by including new authentication extension called the Mobile-AAA Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization using commonly available AAA infrastructure elements. This Authorization-enabling extension MAY co-exist in the same Registration Request with Authentication extensions defined for Mobile IP Registration by [7]. This document obsoletes RFC 3012. "Experimental Message, Extension and Error Codes for Mobile IPv4", Alpesh Patel, 7-Jun-04, Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purpose, to evaluate enhancements to Mobile IPv4 messages before formal standards proposal. "Mobile IPv4 Dynamic Home Agent Assignment", Miland Kulkarni, Kent Leung, 2-Jul-04, Mobile IP (RFC 3344) uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). This draft proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. "IP Mobility Support for IPv4, revised", , 15-Jul-04, This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. Mobility for IPv6 (mip6) ------------------------ "A Management Information Base for Mobile IPv6", Glenn Keeni, Ken-ichi Nagami, Kazuhide Koide, Sri Gundavelli, 20-Jul-04, This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB , for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent and correspondent node functions of a Mobile IPv6 (MIPv6) entity. "Extension to Sockets API for Mobile IPv6", Samita Chakrabarti, Erik Nordmark, 20-Jul-04, This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API for IPv6. "Preconfigured Binding Management Keys for Mobile IPv6", Charles Perkins, 22-Apr-04, A mobile node and a correspondent node may preconfigure a Binding Management Key for authorizing Binding Updates. "Mobile IP version 6 Route Optimization Security Design Background", Pekka Nikander, 22-Jul-04, This document is a succint account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization Security Design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 Security Design in 2001-2002. The document has two target audiences: (1) MIPv6 implementors so that they can better understand the design choices in MIPv6 security procedures; and (2) people dealing with mobility or multi-homing so that they can avoid a number of potential security pitfalls in their design. "Authentication Protocol for Mobile IPv6", , 8-Jul-04, This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu of IPsec to authenticate mobility messages as defined in the base Mobile IPv6 specification. "Problem Statement for bootstrapping Mobile IPv6", Alpesh Patel, 13-Jul-04, A mobile node needs home address, home agent address and security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document This document defines the problem for how the mobile can be bootstrapped in various deployment scenarios. "Network Access Identifier Option for Mobile IPv6", , 16-Jul-04, This document defines new mobility option to identify mobility entities using a network access identifier. This option can be used in messages containing a mobility header. MIPv6 Signaling and Handoff Optimization (mipshop) -------------------------------------------------- "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, 16-Jun-04, This draft introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 reduces the amount of signalling between the Mobile Node, its Correspondent Nodes and its Home Agent. The Mobility Anchor Point described in this document can also be used to improve the performance of Mobile IPv6 in terms of handoff speed. "Fast Handovers for Mobile IPv6", Rajeev Koodli, 15-Jul-04, Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. During handover, there is a period when the Mobile Node is unable to send or receive packets both due to link switching delay and IP protocol operations. This ``handover latency'' resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies enhancements to reduce the handover latency due to standard Mobile IPv6 procedures. This document does not address improving the link switching latency. "Localized Mobility Management Goals", Carl Williams, 21-Jul-04, This document describes goals for Localized Mobility Management (LMM) for IP layer mobility, such Mobile IP and Mobile IPv6. These goals are intended to guide the design of a protocol specification for LMM. Localized Mobility Management, in general, introduces enhancements to IP layer mobility protocols to reduce the amount of latency in IP layer mobility management messages exchanged between a Mobile Node (MN) and its peer entities. In addition, LMM seeks to reduce the amount of signaling over the global Internet when a mobile node traverses within a defined local domain. The identified goals 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 goals for architecting and deploying LMM schemes. "Mobile IPv6 Fast Handovers for 802.11 Networks", Pete McCann, 15-Jul-04, This document describes how a Mobile IPv6 Fast Handover [2] could be implemented on link layers conforming to the 802.11 suite of specifications [3]. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Session Description Protocol (SDP) Source Filters", Bob Quinn, Ross Finlayson, 22-Jul-04, This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination 'connection' addresses. It defines the syntax and semantics for an SDP 'source-filter' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Charles Perkins, 11-Jun-04, This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. "Connection-Oriented Media Transport in the Session Description Protocol (SDP)", David Yon, 19-Jul-04, This document describes how to express media transport over connection-oriented protocols using the Session Description Protocol (SDP). It defines the SDP TCP protocol identifier, the SDP setup attribute, which describes the connection setup procedure, and the SDP connid attribute, which provides a connection identifier. "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Jari Arkko, Elisabetta Carrara, Fredrik Lindholm, Mats Naslund, Karl Norrman, 9-Apr-04, This document defines general extensions for SDP and RTSP to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the MIKEY key management protocol is also defined. "SDPng Transition", Joerg Ott, Charles Perkins, 15-May-03, The Session Description Protocol (SDP) is today widely used in the Internet to announce as well as negotiate multimedia sessions and exchange capabilities. Having originally been designed for session announcements only, as opposed to announcements and capabilities negotiation announcements, native SDP lacks numerous features to be applicable in many session scenarios. Numerous extensions have been developed to circumvent SDP's shortcomings -- but they have also repeatedly shown its inherent limitations. A successor protocol -- termed 'SDPng' for the time being -- is developed to address the aforementioned needs of Internet applications in a more structured manner. With the huge installed base of SDP-based applications, a migration path needs to be developed to move from SDP to SDPng over time. This document outlines how this migration can be achieved: in general as well as for the various IETF control protocols that potentially make use of SDP and SDPng. "Real Time Streaming Protocol (RTSP)", Henning Schulzrinne, 21-Jul-04, This memorandum is a revision of RFC 2326, which is currently a Proposed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", Magnus Westerlund, 14-Apr-04, The existing Session Description Protocol (SDP) bandwidth modifiers and their values include the bandwidth needed also for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP) and the Real-Time Streaming Protocol (RTSP) and when the involved hosts reside in networks running different IP versions, the interpretation of what lower layer bandwidths are included is not clear. This document defines a bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. "How to Enable Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls", Magnus Westerlund, Thomas Zeng, 21-Jul-04, This document describes six different types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations are given. Further a description on how RTSP relates to firewalls is given. "Session Description Protocol Security Descriptions for Media Streams", Flemming Andreasen, Mark Baugher, Dan Wing, 20-Jul-04, This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. "Session Description Protocol Offer Answer Examples", Alan Johnston, Robert Sparks, 9-Jul-04, This document gives examples of Session Description Protocol (SDP) offer answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. "Requirements for Internet Media Guides", Yuji Nomura, Rod Walsh, Juha-Pekka Luoma, Joerg Ott, Henning Schulzrinne, 22-Jun-04, This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", Jonathan Rosenberg, 22-Jul-04, This document describes a methodology for Network Address Translator (NAT) traversal for multimedia session signaling protocols, such as the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN in peer-to-peer cooperative fashion, allowing participants to discover, create and verify mutual connectivity. "A Framework for the Usage of Internet Media Guides", Rod Walsh, Juha-Pekka Luoma, Hitoshi Asaeda, Henning Schulzrinne, Yuji Nomura, 22-Jul-04, This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols and the need for additional work to create an IMG delivery infrastructure. "The Alternative Network Address Types Semantics for the Session Description Protocol Grouping Framework", Gonzalo Camarillo, 4-Jun-04, This document defines the Alternative Network Address Types (ANAT) semantics for the SDP grouping framework. The ANAT semantics allow offering alternative types of network addresses to establish a particular media stream. IKEv2 Mobility and Multihoming (mobike) --------------------------------------- "Design of the MOBIKE protocol", , 28-Jun-04, This document discusses the potential design decisions in the base MOBIKE (IKEv2 Mobility and Multihoming) protocol. It also tries to provide some background information about different choices and tries to record the decisions made by the working group, so that we do not need to repeat discussion later. Multiprotocol Label Switching (mpls) ------------------------------------ "LSP Hierarchy with Generalized MPLS TE", Kireeti Kompella, Yakov Rekhter, 11-Sep-02, To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. "Link Bundling in MPLS Traffic Engineering", Kireeti Kompella, Yakov Rekhter, Lou Berger, 24-Jul-02, For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct which is described in this document. "Multiprotocol Label Switching (MPLS) Management Overview", Thomas Nadeau, Cheenu Srinivasan, Adrian Farrel, 17-Sep-03, A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This memo describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. "Graceful Restart Mechanism for BGP with MPLS", Yakov Rekhter, Rahul Aggarwal, 2-Feb-04, A mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart is described in 'Graceful Restart Mechanism for BGP' (see [1]). This document extends this mechanism to also minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such it works in conjunction with any of the address famililies that could be carried in BGP (e.g., IPv4, IPv6, etc...) "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Ping Pan, George Swallow, Alia Atlas, 24-Jun-04, This document defines extensions to and describes the use of RSVP to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either or both methods and to interoperate in a mixed network. "Detecting MPLS Data Plane Failures", Kireeti Kompella, 20-Jul-04, This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS 'echo request' and 'echo reply' for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. "Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition", Thomas Nadeau, Shriharsha Hegde, 6-May-04, This memo defines how label switching controlled Frame-Relay and ATM interfaces can be realized given the interface stacking as defined in the MPLS-LSR and MPLS-TE MIBs. "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, 6-Feb-04, 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. "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", Benjamin Black, Kireeti Kompella, 9-Apr-04, Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent, off-line mechanisms. This document specifies experimental extensions to LDP in support of LSP MTU discovery. "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", Yakov Rekhter, Eric Rosen, 23-Jun-04, Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. "Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", Seisho Yasukawa, 20-Jul-04, This document presents a set of requirements for Point-to-Multipoint(P2MP) Traffic Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It specifies functional requirements for solutions in order to deliver P2MP applications over a MPLS TE infrastructure. It is intended that solutions that specify procedures for P2MP TE LSP setup satisfy these requirements. "Definition of an RRO node-id subobject", Jean Vasseur, 2-Feb-04, In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find an MP address in multi-areas or multi-domain routing networks. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this document refers to the 'Facility backup' MPLS TE Fast Reroute method. "MPLS Traffic Engineering Soft preemption", Matthew Meyer, 23-Mar-04, This draft documents MPLS TE Soft Preemption, a suite of protocol modifications extending the current concept of preemption with the goal of reducing/eliminating traffic disruption of preempted TE LSPs. Under present RSVP-TE signaling methods, LSPs are immediately displaced upon preemption. The introduction of a new preemption pending flag helps more gracefully mitigate the re-route process of displaced LSPs. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect overbooked until the LSP can be re-routed. For this reason, the feature is primarily interesting in packet oriented MPLS networks with Diffserv and TE capabilities. "Traffic Engineering Link Management Information Base", Martin Dubuc, Sudheer Dharanikota, Thomas Nadeau, Jonathan Lang, 17-May-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering document. "Label Switching Router Self-Test", George Swallow, Kireeti Kompella, Dan Tappan, 17-Feb-04, This document defines a means of self test for a Label-Switching Router (LSR) to verify that its dataplane is functioning for certain key Multi-Protocol Label Switching (MPLS) applications including unicast forwarding based on LDP [LDP] and traffic engineering tunnels based on [RSVP-TE]. A new Loopback FEC type is defined to allow an upstream neighbor to assist in the testing at very low cost. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] messages are extended to do the actually probing. "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", Adrian Farrel, Dimitri Papadimitriou, Jean Vasseur, 19-Jul-04, Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE). This protocol includes an object (the SESSION_ATTRIBUTE object) which carries a flags field used to indicate options and attributes of the LSP. That flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. "Removing a Restriction on the use of MPLS Explicit NULL", Eric Rosen, 23-Apr-04, The label stack encoding for MPLS (Multi-protocol Label Switching) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack. Multicast Security (msec) ------------------------- "GSAKMP", Hugh Harney, 3-Jun-04, This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. "MSEC Group Key Management Architecture", Mark Baugher, 10-Jun-04, This document defines the common architecture for Multicast Security (MSEC) key management protocols that support a variety of application, transport, and network layer security protocols. It also defines the group SA (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document allow for a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. Comments on this document should be sent to msec@securemulticast.org. "MIKEY: Multimedia Internet KEYing", Jari Arkko, 16-Dec-03, Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. "TESLA: Multicast Source Authentication Transform Introduction", Adrian Perrig, Ran Canetti, Dawn Song, Doug Tygar, Bob Briscoe, 12-May-04, Data authentication is an important component for many applications, for example audio and video Internet broadcasts, or data distribution by satellite. This document introduces TESLA, a secure source authentication mechanism for multicast or broadcast data streams. This document provides an algorithmic description of the scheme for informational purposes, and in particular, it is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. The main deterrents so far for a data authentication mechanism for multicast were the seemingly conflicting requirements: loss tolerance, high efficiency, no per-receiver state at the sender. The problem is particularly hard in settings with high packet loss rates and where lost packets are not retransmitted, and where the receiver wants to authenticate each packet it receives. TESLA provides authentication of individual data packets, regardless of the packet loss rate. In addition, TESLA features low overhead for both sender and receiver, and does not require per-receiver state at the sender. TESLA is secure as long as the sender and receiver are loosely time synchronized. "HMAC-authenticated Diffie-Hellman for MIKEY", Martin Euchner, 26-May-04, This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. "The Use of RSA Signatures within ESP and AH", Brian Weis, 14-Jul-04, This memo describes the use of the RSA Signature algorithm [RSA] as an authentication algorithm within the revised IPSEC Encapsulating Security Payload [ESPbis] and the revised IPSEC Authentication Header [AHbis]. The use of a digital signature algorithm such as RSA provides data origin authentication when a secret key method (e.g., HMAC) cannot do so. For example, when ESP and AH are used to protect IP multicast data flows. Further information on the other components necessary for ESP and AH implementations is provided by [ROADMAP]. "The Use of TESLA in SRTP", Mark Baugher, 21-Jul-04, This memo describes the use of the Timed Efficient Stream loss- tolerant Authentication (TESLA) transform within the Secure Real- time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. "Group Policy Token Version 1 with Application to GSAKMP", Andrea Colegrove, 24-Jun-04, The Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. This document specifies the structure of such a token in order to securely bind system-level security to protocols supporting the management of cryptographic groups. Message Tracking Protocol (msgtrk) ---------------------------------- "Message Tracking Model and Requirements", Tony Hansen, 25-Oct-02, Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. "Message Tracking Query Protocol", Tony Hansen, 10-Mar-04, Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with exten- sions to the ESMTP protocol to provide a complete message tracking solution for the Internet. "SMTP Service Extension for Message Tracking", Eric Allman, Tony Hansen, 1-Apr-03, This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. "An Extensible Message Format for Message Tracking Responses", Eric Allman, 1-Apr-03, Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications [RFC-DSN-SMTP] and Message Disposition Notifications [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME [RFC-MIME] content-type for message tracking status in the same spirit as RFC 1894, 'An Extensible Message Format for Delivery Status Notifications' [RFC-DSN-STAT]. It is to be issued upon a request as described in 'Message Tracking Query Protocol' [DRAFT-MTRK-MTQP]. This memo defines only the format of the status information. An extension to SMTP [RFC-ESMTP] to label messages for further tracking and request tracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. Site Multihoming in IPv6 (multi6) --------------------------------- "IPv4 Multihoming Motivation, Practices and Limitations", Joe Abley, Benjamin Black, Vijay Gill, 13-Jul-04, Multihoming is an essential component of service for enterprises which are part of the Internet. This draft describes some of the motivations, practices and limitations of multihoming as it is achieved in the IPv4 world today. The analysis is done in order to serve as underlaying documentation to the discussions in the "Site multihoming for IPv6" workinggroup of the IETF, who are working to a longerterm solution to some of the issues that arise from doing multihoming in the ways as are described here. "Things MULTI6 Developers should think about", , 25-Jun-04, This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution either. "Threats relating to IPv6 multihoming solutions", Erik Nordmark, 6-Jul-04, This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. "Architectural Approaches to Multi-Homing for IPv6", , 9-Jul-04, This memo provides an analysis of the aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. Network Mobility (nemo) ----------------------- "Network Mobility Support Goals and Requirements", Thierry Ernst, 18-Feb-04, Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions. "Network Mobility Support Terminology", Thierry Ernst, Hong Lach, 18-Feb-04, This document defines a terminology for discussing network mobility problems and solution requirements. Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. "Network Mobility (NEMO) Basic Support Protocol", Vijay Devarapalli, 7-Jun-04, This document describes the Network Mobility (NEMO) Basic Support protocol that enables mobile networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. "NEMO Home Network models", Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli, 22-Apr-04, This paper documents some usage patterns and the associated issues when deploying a Home Network for Nemo enabled Mobile Routers, conforming the NEMO Basic Support draft [7]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the NEMO and NEMO Design mailing lists. "Analysis of Multihoming in Network Mobility Support", Thierry Ernst, 13-Jul-04, This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support. Network Configuration (netconf) ------------------------------- "NETCONF Configuration Protocol", Rob Enns, 22-Jun-04, There is a need for standardized mechanisms to manipulate, install, edit, and delete the configuration of a network device. In addition, there is a need to retrieve device state information and receive asynchronous device state messages in a manner consistent with the configuration mechanisms. There is great interest in using an XML-based data encoding because a significant set of tools for manipulating ASCII text and XML encoded data already exists. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. "BEEP Application Protocol Mapping for NETCONF", Eliot Lear, 7-Jun-04, This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). "NETCONF Over SOAP", Ted Goddard, 7-Jun-04, The device management protocol NETCONF is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of SOAP over HTTP. NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe a SOAP over HTTP binding that, when used with persistent HTTP connections, yields an application protocol sufficient for NETCONF. "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", Margaret Wasserman, 1-Jun-04, This document describes a simple method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. New IETF Standards Track Discussion (newtrk) -------------------------------------------- "Proposals for a New IETF Standards Track", David Black, Brian Carpenter, 12-Jul-04, Discussions in the IETF's "problem" working group reached consensus that the current IETF 3-stage standards track, as implemented, is not working. This draft proposes various alternative multi-step standards tracks for debate in the "newtrk" working group. Network File System Version 4 (nfsv4) ------------------------------------- "XDR: External Data Representation Standard", Mike Eisler, 23-Jun-04, This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. "The Channel Conjunction Mechanism (CCM) for GSS", Mike Eisler, Nevin Williams, 12-Jul-04, This document describes a suite of new mechanisms under the GSS [RFC2743]. Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to authenticate every message transfer, thereby incurring significant overhead due to the costs of cryptographic computation. While hardware-based cryptographic accelerators can mitigate such overhead, it is more likely that acceleration will be available for lower layer protocols, such as IPsec [RFC2401] than for upper layer protocols like RPCSEC_GSS. CCM can be used as a way to allow GSS mechanism- independent upper layer protocols to leverage the data stream protections of lower layer protocols, without the inconvenience of modifying the upper layer protocol to do so. "NFSv4.1: SECINFO Changes", Mike Eisler, 14-Jul-04, This document proposes some changes to security negotiation in NFS version 4 [RFC3530]. It is hoped that these changes will be part of a new minor version of NFS: NFSv4.1. "RPC Numbering Authority Transfer to IANA", Robert Thurlow, 28-May-04, Network services based on RPC [RFC1831] use program numbers rather than well known transport ports to permit clients to find them, and use authentication flavor numbers to define the format of the authentication data passed. The assignment of RPC program numbers and authentication flavor numbers is still performed by Sun Microsystems, Inc. This is inappropriate for an IETF standard protocol, as such work is done well by the Internet Assigned Numbers Authority (IANA). This document defines how IANA will maintain and assign RPC program numbers and authentication flavor numbers. "RPC: Remote Procedure Call Protocol Specification Version 2", Robert Thurlow, 28-Jun-04, This document describes the ONC (Open Network Computing) Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. It is meant to supersede [RFC1831]. "Mapping Between NFSv4 and Posix Draft ACLs", Marius Eriksen, 11-Feb-04, The NFS (Network File System) version 4[rfc3530] (NFSv4) specifies a flavor of Access Control Lists (ACLs) that apply to file system objects. ACLs specify an access level for a number of entities. The NFSv4 ACLs model resembles that of Windows NT. A POSIX draft[posixacl] proposes another, more restrictive ACL model. Many systems implement this proposed standard. Differing in syntax, semantics and extensiveness, it is only feasible to create a correct representation for POSIX ACLs with NFSv4 ACLs. This does not hold for an attempt to represent arbitrary NFSv4 ACLs with POSIX ACLs. "On the Use of Channel Bindings to Secure Channels", Nicolas Williams, 19-Jul-04, This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels at different network layers are the same by binding authentication at one channel to the session protection at the other channel. The use of channel bindings allows applications to delegate session protection to lower layers, which may significantly improve performance for some applications. "NFS RDMA Problem Statement", Thomas Talpey, 2-Jul-04, This draft addresses applying Remote Direct Memory Access to the NFS protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other sources. The potential benefits of RDMA to these implementations are explored, and the reasons why RDMA is especially well-suited to NFS and network file protocols in general are evaluated. "RDMA Transport for ONC RPC", , 2-Jul-04, A protocol is described providing RDMA as a new transport for ONC RPC. The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. "NFS Direct Data Placement", , 2-Jul-04, The RDMA transport for ONC RPC provides direct data placement for NFS data. Direct data placement not only reduces the amount of data that needs to be copied in an NFS call, but allows much of the data movement over the network to be implemented in RDMA hardware. This draft describes the use of direct data placement by means of server- initiated RDMA operations into client-supplied buffers in a Chunk list for implementations of NFS versions 2, 3, and 4 over an RDMA transport. "NFSv4.1: Directory Delegations and Notifications", Saadia Khan, 14-Jul-04, This document proposes adding directory delegations and notifications to NFS Version 4 [RFC3530]. It is hoped that these changes will be part of a new minor version of NFS, such as NFSv4.1. "NFSv4 Session Extensions", Thomas Talpey, 15-Jul-04, Extensions are proposed to NFS version 4 which enable it to support long-lived sessions, endpoint management, and operation atop a variety of RPC transports, including TCP and RDMA. These extensions enable support for reliably implemented client response caching by NFSv4 servers, enhanced security, multipathing and trunking of transport connections. These extensions provide identical benefits over both TCP and RDMA connection types. NNTP Extensions (nntpext) ------------------------- "Network News Transport Protocol", Clive Feather, 22-Mar-04, The Network News Transport Protocol (NNTP) has been in use in the Internet for a decade and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977 and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality and provides a specific mechanism to add standardized extensions to NNTP. "Using TLS with NNTP", Jeffrey Vinocur, Chris Newman, 20-Jan-04, This memo defines an extension to the Network News Transport Protocol [NNTP] to provide connection-based encryption (via Transport Layer Security [TLS]). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity and (optional) certificate-based peer entity authentication are also possible. "NNTP Extension for Streaming Feeds", Jeffrey Vinocur, 2-Feb-04, This memo defines an extension to the Network News Transport Protocol [NNTP] to provide asynchronous transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency. "NNTP Extension for Authentication", Jeffrey Vinocur, 12-Jul-04, This document defines a profile of the Simple Authentication and Security Layer [SASL] for the Network News Transport Protocol [NNTP] protocol and updates/deprecates information contained in Section 3.1 of [NNTP-COMMON]. This extension allows a NNTP client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a secu- rity layer for subsequent protocol interactions during the remain- der of an NNTP session. "RADIUS Extensions for IEEE 802", Paul Congdon, 13-Jul-04, IEEE 802.1X-2004 enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although AAA support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS or Diameter clients (or both). "UDP based PWs", Yakov Stein, 13-Jul-04, The PWE3 charter permits three PSN types, namely "IP (both versions), L2TP, or MPLS". The majority of drafts submitted to the working group have focused on MPLS PSNs, and lesser attention has been given to L2TPv3. Only the TDMoIP drafts have explicitly specified UDP/IP as PSN, and only they stipulate the use of UDP port numbers as PW labels. This draft discusses PWs based on UDP/IP, concentrating on three issues, namely 1) the advisability of using UDP port numbers as PW labels, 2) which UDP port number to use, and 3) what label distribution protocol should be employed. "A Multiplexing Mechanism for the Real-Time Protocol (RTP)", Jon Peterson, Jonathan Rosenberg, 13-Jul-04, This document defines a mechanism for the Real-Time Protocol (RTP) that allows multiple RTP sessions to be demultiplexed at a single port. Accordingly, it also requests that the IANA allocate assigned ports for the use of RTP with three applications: voice, video and text. A similar mechanism is proposed for the Real-Time Control Protocol (RTCP). The use of this mechanism is confined to a strict domain of applicability. "IPv4 Care-of Address Registration", Ryuji Wakikawa, 14-Jul-04, On the Internet, two different IP protocols are deployed such as IPv4 [8] and IPv6 [2]. The Mobile IPv6 Router uses the basic NEMO protocol [3] which is IPv6 protocol specific. During the early period of time that IPv6 transition is occurring it is very likely that a Mobile IPv6 router will move to an IPv4 only access network. When this occurs the Mobile IPv6 Router will no longer be able to operate using the basic NEMO protocol. There has already been some earlier work to provide IPv6 capability over an IPv4 access network for a Mobile IPv6 Router [see [10] [11]]. This draft provides a capability by to maintain IPv6 connectivity for the Mobile IPv6 Individual Submissions (none) ----------------------------- "Securing FTP with TLS", Paul Ford-Hutchinson, Martin Carpenter, Tim Hudson, Eric Murray, Volker Wiegand, 17-Jun-04, This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by [RFC-2246] and the extensions to the FTP protocol defined by [RFC-2228]. It describes the subset of the extensions that are required and the parameters to be used; discusses some of the policy issues that clients and servers will need to take; considers some of the implications of those policies and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817]. "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. "The Java LDAP Application Program Interface", Rob Weltman, Christine Ho, Steven Sonntag, 7-Jun-04, This document defines a Java [JAVA] language application program interface to the Lightweight Directory Access Protocol (LDAP) [LDAPv3], in the form of a class library. "LDAP Proxied Authentication Control", Rob Weltman, 23-Apr-03, This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of as the current authorization identity associated with the connection. "The application/smil and application/smil+xml Media Types", Philipp Hoschka, 13-Sep-02, This document specifies the Media Type for version 1 and version 2 of the Synchronized Multimedia Integration Language (SMIL 1.0 and SMIL 2.0). SMIL allows ntegrating a set of independent multimedia objects into a synchronized multimedia presentation. "The Common Gateway Interface (CGI) Version 1.1", David Robinson, Ken Coar, 21-Oct-03, The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the World-Wide Web since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. "Sieve -- IMAP flag Extension", Alexey Melnikov, 23-Jan-04, Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords. "The vnd and prs Trees for URI Scheme Names", Ian King, Larry Masinter, 8-Sep-03, This document describes a way in which individuals and vendors can define URI schemes in a way that avoids name collisions, but with relaxed registration requirements. This is done by allowing URI schemes that start with 'vnd-' or 'prs-', analogous to similar mechanism MIME media types. "Host Identity Protocol", Robert Moskowitz, Pekka Nikander, Petri Jokela, 10-Feb-04, This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity (HI), Host Identity Tag (HIT), and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS) attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. "Returning Matched Values with LDAPv3", David Chadwick, Sean Mullan, 23-Jul-03, 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. "Xdossier", Manuel Tomas Carrasco Benitez, 19-Jul-04, This is an informational memo for Xdossier. A Xdossier is a data object designed for browsing with web browsers and mappable to XML. It is based on a directory structure containing files in several formats. "LDAP Bulk Update/Replication Protocol", Rod Harrison, Jim Sermersheim, Yulin Dong, 6-Mar-01, The LDAP Bulk Update/Replication Protocol (LBURP) described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server. The protocol groups a set of update operations using the LDAP framed protocol requests defined in [FRAMING] to notify the client that the update operations in the framed set are related. The update operations within the framed set are LDAPv3 extended operations each encapsulating a sequence number and one or more LDAPv3 update operations. The sequence number allows the server to process the update operations in the proper order even when they are sent asynchronously by the client, and the update operations can be grouped within the extended request to maximize the efficiency of client-server communication. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally update the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. "Password Policy for LDAP Directories", Prasanta Behera, Ludovic Poitou, Jim Sermersheim, 18-Feb-04, Password policy as described in this document is a set of rules that controls how passwords are used and administered in LDAP directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts. "Transport of Layer 2 Frames Over MPLS", Luca Martini, Nasser El-Aawar, 4-Jun-04, This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. "Host Identity Protocol Architecture", Robert Moskowitz, 29-Jun-04, This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. "Cisco Systems' Simple Certificate Enrollment Protocol(SCEP)", Xiaoyi Liu, Cheryl Madson, David McGrew, Andy Nourse, 30-Jun-04, This document specifies the Cisco Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations "Netnews Administration System (NAS)", Philipp Grau, Vera Heinau, Heiko Schlichting, 18-Jun-03, The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server-protocol. The database is accessible by news servers and news administrators as well as by news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, to provide detailed information about groups and hierarchies to the user. NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server or news reader software, however, some tasks will be better accomplished with NAS compliant software. "Use of IPsec Transport Mode for Dynamic Routing", Joseph Touch, L Eggert, Yu-Shun Wang, 25-Mar-04, This document addresses the use of IPsec to secure the links of a virtual (private) network (VN/VPN). It describes how virtual links established by IPsec tunnel mode conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses. This document proposes a solution, called IIPtran, in which IPIP encapsulation separate from IPsec is used together with transport- mode IPsec. IPIP tunnel encapsulation occurs as a separate initial step, based on a forwarding lookup of the VN packet. After the forwarding lookup, IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture, by establishing a complete virtual topology with IPIP tunnels that supports static and dynamic routing, and then securing it with IPsec transport mode. The document also discusses how IIPtran compares to several alternative mechanisms for VN routing, and their respective impact on IPsec, routing, policy enforcement and interactions with the Internet Key Exchange (IKE), among other issues. This document is a product of the X-Bone and DynaBone projects at USC/ISI [N5][N8]. Comments are solicited and should be addressed to the authors. "RSVP Proxy", Silvano Gai, Sunil Gaitonde, Nitsan Elfassy, Yoram Bernet, 7-Mar-02, RSVP has been extended in several directions [POLICY], [RSVP-APPID], [DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the applicability of RSVP characterizing it as a signaling protocol usable both inside and outside the Integrated Services [INTSERV] model. With the addition of the 'Null Service Type' [NULLSERV], RSVP is also being adopted by mission critical applications that require some form of prioritized service, but cannot quantify their resource requirements. In cases where RSVP cannot travel end-to-end, these applications may still benefit from reservations that are not truly end-to-end, but that are 'proxied' by a network node on the data path between the sender and the receiver(s). RSVP Receiver Proxy is an extension to the RSVP message processing (not to the protocol itself) in which an intermediate network node originates the Resv message on behalf of the receiver(s) identified by the Path message. "IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff", James Kempf, Peter McCann, Phil Roberts, 16-Mar-04, Recently, there have been a variety of proposals submitted to the Mobile IP Working Group and to other IETF working groups for IP mobility solutions that seek to enhance or replace mobile IP. These proposals, often characterized as micromobility or fast handoff, are addressed primarily at the perceived need of multimedia sessions such as video or voice over IP for faster handoff between radio base stations, and are primarily directed at real time multimedia traffic in 3rd generation cellular access networks. In this paper, we discuss the design of CDMA radio access networks (RANs) and the applicability of IP mobility to soft handoff in a CDMA RAN. We attempt to show that given current IP routing algorithms and the constraints on a CDMA RAN, IP mobility solutions have little, if any, role to play in handoff within the RAN. In contrast, an IP mobility solution is likely to play a big role in fast handoff between RANs, also called hard handoff. While future developments in IP networking may change this situation, IP mobility in CDMA networks currently seems to apply only when the mobile node roams between disconnected RANs rather than between base stations within a RAN or between connected RANs. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 18-Feb-04, This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other Internet Drafts relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. "SILC Packet Protocol", Pekka Riikonen, 18-Feb-04, This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol specified in the Secure Internet Live Conferencing, Protocol Specification Internet Draft [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 11-Feb-04, This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. SKE use best parts of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY Key Determination protocol [OAKLEY]. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol is transparent to the authentication data which means that it can be used to authenticate the user with, for example, passphrase (pre-shared secret) or public key (and certificate) based on digital signatures. "Alternative Certificate Formats for the PKIX Certificate Management Protocols", Mikhail Blinov, Carlisle Adams, 6-May-04, The PKIX (Public-Key Infrastructure (X.509)) Working Group of the IETF (The Internet Engineering Task Force) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the CRMF (Certificate Request Message Format) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX-CMP (PKIX Certificate Management Protocol) and CMC (Certificate Management Messages over CMS). "Session Initiation Protocol (SIP)-H.323 Interworking Requirements", Henning Schulzrinne, Charles Agboh, 18-Feb-04, This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. "Session Initiation Protocol Private Extension for an OSP Authorization Token", Alan Johnston, Diana Rawlins, 1-Jul-04, This draft proposes a private extension to the Session Initiation Protocol (SIP) for carrying OSP (Open Settlements Protocol) authorization tokens in applications such as clearinghouses. "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", Andrew Malis, 19-May-04, 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. "Randomness Requirements for Security", Donald Eastlake, Jeffrey Schiller, Stephen Crocker, 4-Jun-04, Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo- security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the potential number space. "Calling Line Identification for Voice Mail Messages", Glenn Parsons, Janusz Maruszak, 14-Jun-04, This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. "Voice Messaging Client Behaviour", Derrick Dunne, Glenn Parsons, 24-Jul-01, This document defines the expected behaviour of a client to various aspects of a VPIM message or any voice or fax message. "Address Prefix Based Outbound Route Filter for BGP-4", Enke Chen, Srihari Sangli, 10-May-04, This document defines a new Outbound Router Filter type for BGP, termed 'Address Prefix Outbound Route Filter', that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. "Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures", Simon Blake-Wilson, Gregor Karlinger, Yongge Wang, Tetsutaro Kobayashi, 18-Mar-04, This document specifies how to use ECDSA (Elliptic Curve Digital Signature Algorithm) with XML Signatures [XMLDSIG]. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. "The Protocol versus Document Points of View in Computer Protocols", Donald Eastlake, 16-Jun-04, Two points of view are contrasted: the 'paper' point of view, where digital objects of interest are like pieces of paper, and the 'protocol' point of view where objects of interest are composite dynamic protocol messages. While each point of view has a place, adherence to a paper point of view is damaging to protocol design. By understanding both of these points of view, conflicts between them may be clarified and reduced. "The Mobile Application Part SECurity (MAPSEC) Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP)", Jari Arkko, Ronald Blom, 23-Mar-04, The Mobile Application Part (MAP) protocol is a signaling protocol for cellular networks. The MAP Security (MAPSEC) protocol provides a secure way to transport MAP messages. To use MAPSEC, however, Security Associations (SAs) are needed. This document defines how such SAs can be created automatically. We use the Internet Security Association and Key Management Protocol (ISAKMP) as a framework for managing SAs and establishing keys. The framework can be specialized to a particular task. Such a specialization is called a Domain of Interpretation (DOI), and this document defines the MAPSEC DOI. This specialization is very similar to the Internet Key Exchange protocol and the ISAKMP specialization for IP Security, except that non-IP protocols are being negotiated. "Multicast in MPLS/BGP VPNs", Eric Rosen, 26-May-04, In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. "LDAP Control to Specify Chaining Behavior", Jim Sermersheim, Rod Harrison, 3-Feb-04, This document describes a Lightweight Directory Access Protocol (LDAP) request control that allows specification of chaining behavior for LDAP operations. By using the control with various LDAP operations, a directory client (DUA), or directory server (DSA) specifies whether or not a DSA or secondary DSA chains operations to other DSAs or returns referrals and/or search result references to the client. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", Luca Martini, 4-Jun-04, This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM, or Ethernet for transport across an MPLS or IP network. "Domain Name System Uniform Resource Identifiers", Simon Josefsson, 27-Oct-03, This document define Uniform Resource Identifiers for Domain Name System resources. "Explicit Multicast (Xcast) Basic Specification", Richard Boivie, 11-Jun-04, Multicast has become increasingly important with the emergence of network-based applications such as IP telephony and video conferencing. The Internet community has done a significant amount of work on IP multicast over the last decade [1075, 2201, 2236, DEER, DEE2, FARI, HOLB, MBONE, PERL]. However, while today's multicast schemes are scalable in the sense that they can support very large multicast groups, there are scalability issues when a network needs to support a very large number of distinct multicast groups. "Domain Name System Media Types", Simon Josefsson, 10-Mar-04, This document register the media types application/dns and text/dns, in accordance with RFC 2048 [3]. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540 [4]. The text/dns media type is used to identify master files as described in RFC 1035 [2]. "LDAP Cancel Operation", Kurt Zeilenga, 5-Feb-04, This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. "SASL in HTTP/1.1", Magnus Nystrom, Alexey Melnikov, 28-Apr-04, This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. "Definitions of Managed Objects for Network Address Translators (NAT)", Rajiv Raghunarayan, Nalinaksh Pai, R Rohit, Cliff Wang, Pyda Srisuresh, 20-Apr-04, This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. "A Framework for Purpose-Built Keys (PBK)", Scott Bradner, Allison Mankin, Jeffrey Schiller, 9-Jun-03, This memo considers the need to authenticate the source of a network communication where the actual identity of the source is not important but it is important and that successive messages in the communication come from the same source. This memo defines the use of specially generated public/private key pairs, known as Purpose- Built Keys (PBKs), to provide this assurance. This memo is not a full specification of a PBK protocol, but rather a model or framework for development of PBK in applications "Extensible Authentication Protocol Method for GSM Subscriber Identity Modules (EAP-SIM)", Henry Haverinen, Joseph Salowey, 5-Apr-04, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the GSM Subscriber Identity Module (SIM). The mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support and a re-authentication procedure. "Analysis of the Security of BGP/MPLS IP VPNs", Michael Behringer, 4-Jun-04, This document analyses the security of the BGP/MPLS IP VPN architecture that is described in RFC 2547bis [13], for the benefit of service providers and VPN users. The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using ATM or Frame Relay. "The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers, 22-Jul-04, The ARK (Archival Resource Key) is a scheme intended to facilitate the persistent naming and retrieval of information objects. It comprises an identifier syntax and three services. An ARK has four components: [http://NMAH/]ark:/NAAN/Name an optional and mutable Name Mapping Authority Hostport part (NMAH, where 'hostport' is a hostname followed optionally by a colon and port number), the 'ark:' label, the Name Assigning Authority Number (NAAN), and the assigned Name. The NAAN and Name together form the immutable persistent identifier for the object. "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Fred Templin, Tim Gleeson, Mohit Talwar, Dave Thaler, 27-May-04, The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast, Multiple Access (NBMA) model. "SMB Filesharing URL Scheme", Christopher Hertel, 13-Jul-04, The Server Message Block (SMB) protocol is one of the most widely used network file system protocols in existence. This document describes the format of the SMB Uniform Resource Indicator (SMB URI). The SMB URI can be used to indicate SMB workgroups, servers, shares, directories, files, inter-process communications pipes, print queues, and devices; the objects in the SMB network file system space. "SMTP operational experience in mixed IPv4/IPv6 environements", Motonori Nakamura, Jun-ichiro Hagino, 16-Jan-04, This document lists operational requirements for IPv6 SMTP and IPv6-capable MX DNS records. As IPv6 SMTP servers are deployed, it has become apparent that certain configurations are necessary in IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the problems that exist in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. "Additional XML Security URIs", Donald Eastlake, 15-Jul-04, A number of URIs intended for use with XML Digital Signatures, Encryption, and Canonnicalization are defined. These URIs identify algorithms and types of keying information. "SILC Commands", Pekka Riikonen, 18-Feb-04, This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages. "EAP AKA Authentication", Jari Arkko, Henry Haverinen, 9-Apr-04, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys, and runs typically in a UMTS Subscriber Identity Module, a smart card like device. EAP AKA includes optional identity privacy support and an optional re-authentication procedure. "A Search-based access model for the DNS", John Klensin, 18-Feb-04, This memo discusses strategies for supporting 'DNS searching' -- finding of names in the DNS, or references that will ultimately point to DNS names, by a mechanism layered above the DNS itself that permits fuzzy matching, selection that uses attributes or facets, and use of descriptive terms. Demand for these facilities appear to be increasing with growth in the Internet (and especially the web) and with requirements to move beyond the restricted subset of ASCII names that have been the traditional contents of DNS 'Class=IN'. This document proposes a three-level system for access to DNS names in which the upper two levels involve search, rather than lookup (exactly known target), functions. It also discusses some of the issues and challenges in completing the design of, and deploying, such a system. "A Hybrid Authentication Mode for IKE", Moshe Litvin, Roy Shamir, Tamir Zegman, 22-Apr-04, This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectionally authenticated. To make this IKE bi-directionally authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid Authentication mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. "OSPF-xTE: An experimental extension to OSPF for Traffic Engineering", Pyda Srisuresh, Paul Joseph, 15-Mar-04, This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE LSAs to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. Further, When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that Non-TE nodes in the AS are uneffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as SONET/TDM and optical networks. "Simple Explicit Multicast (SEM)", Ali Boudani, Bernard Cousin, 31-Mar-04, In this document, we propose a new multicast protocol called SEM (Simple Explicit Multicast) or simple Xcast. This protocol uses an efficient method to construct the multicast tree and deliver multicast packets. In order to construct the multicast tree, this protocol uses the same mechanism as Xcast+. For the delivery of multicast packets it uses the mechanism of branching routers similar to the mechanism used in REUNITE I and REUNITE II. "A grammar for Policies in a Generic AAA Environment", Arie Taal, 30-Jun-04, In this document the concept of a so-called Driving Policy is pre- sented. A Driving Policy determines the behavior of an AAA server (Authentication, Authorization, Accounting) when it is confronted with a specific message type of the AAA protocol. The first part of this document defines the role of a Driving Policy and how it fits into the AAA concept. According to the model presented, the main task of a Driving Policy is to describe which pre-conditions have to be checked before the corresponding actions, needed to fulfill an incoming AAA request, can be called, and how to deal with the post-conditions of these actions. In the second part a grammar is proposed for these Driving Policies accompanied by the necessary comments about the semantics. "An IPv6 Provider-Independent Global Unicast Address Format", Tony Hain, 27-Jan-04, 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, 14-May-04, This document discusses the expected use of the Provider Independent address format discussed in the companion document [2] in the Internet. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations that should be avoided due to the negative impact on the routing tables. "The 'tag' URI scheme", Tim Kindberg, Sandro Hawke, 4-Jun-04, This document describes the "tag" Uniform Resource Identifier (URI) scheme, for identifiers that are unique across space and time. Tag URIs (also known as "tags") are distinct from most other URIs in that there is no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Unlike UUIDs or GUIDs such as "uuid" URIs and "urn:oid" URIs, tags are designed to be tractable to humans. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible "Expanded Simulation Models for IntServ and DiffServ with MPLS", Mark Pullen, 16-Feb-04, This document describes detailed models for analysis of proposed protocols for Quality of Service (QoS) delivery with IPv4 (including multicast). The models have been developed using the OPNET simulation package. They are intended to allow investigation of performance using proposed protocols and should have wide applicability in the Internet QoS community. We are making these models publicly available with the intention that they can be used to provide expanded studies of Qos delivery for both unicast and multicast, using IntServ, DiffServ, and MPLS. This Internet-Draft is intended to form the basis for an Informational RFC that extends the previous RFC2490. "Opportunistic Encryption using The Internet Key Exchange (IKE)", Michael Richardson, D. Hugh Redelmeier, 19-Jul-04, This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. "RSVP Path computation request and reply messages", Jean Vasseur, 19-Jul-04, 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 Element (PCE), 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 PCE. The PCE 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 PCE may also optionally suggest new constraint values for which one or several paths could be found. There are many situations where a PCE may be used. A typical example is in the context of Inter-area MPLS TE. A head-end LSR could request that a PCE compute one or more paths obeying a specified set of constraints for a TE LSP spanning multiple areas. The PCE could be a centralized path computation Element or an LSR such as an ABR or an ASBR. Another example is the use of a PCE 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. "Multicast DNS", Stuart Cheshire, 16-Feb-04, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absense of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. "Remote Service Discovery in the Service Location Protocol via DNS SRV", Weibin Zhao, 23-Mar-04, Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. "Basic Network Media Services with SIP", Eric Burger, 22-Mar-04, In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well-defined manner. This document describes a mechanism for providing an interoperable protocol interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. "Protected EAP Protocol (PEAP) Version 2", Simon Josefsson, Ashwin Palekar, Daniel Simon, Glen Zorn, 20-Jul-04, The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the Protected Extensible Authentication Protocol (PEAP) Version 2, which provides an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates EAP authentication mechanisms. PEAPv2 uses TLS to protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy. PEAPv2 also provides support for chaining multiple EAP mechanisms, cryptographic binding between authentications performed by inner EAP mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), and fragmentation and reassembly. "Datatypes for WebDAV properties", Julian Reschke, 12-Feb-04, This specification extends the Web Distributed Authoring Protocol (WebDAV) to support both datatyping and some amount of meta information on property values. Protocol elements are defined to let clients and servers specify the datatype and meta information of a property, and to instruct the WebDAV method PROPFIND to return datatype and meta information. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. "The HTTP header for the Platform for Privacy Preferences 1.0 (P3P1.0)", Massimo Marchiori, Ran Lotenberg, 5-Feb-02, The Platform for Privacy Preferences 1.0[4] (P3P1.0) specification describes how to associate a privacy policy with each URI request. Such associations are contained in a so-called policy reference file. This draft describes a new HTTP response header which indicates the location of such policy reference file. This header is intended to be a part of the P3P1.0 framework and should be treated in the full context of the P3P1.0 specification[4]. "'duri' and 'tdb': URN namespaces based on dated URIs", Larry Masinter, 19-Apr-04, This document defines two namespaces of URNs, based on using a timestamp with an (encoded) URI. The results are namespaces in which names are readily assigned, offer the persistence of reference that is required by URNs, but do not require a stable authority to assign the name. The first namespace ('duri') is used to refer to URI- identified resources as they appeared at a particular time. The second namespace ('tdb') is useful as a way of creating URNs that refer to physical objects or even abstractions that are not themselves networked resources. The definition of these namespaces may reduce the need to define new URN namespaces merely for the purpose of creating stable identifiers. "Locating IP-to-Public Switched Telephone Network (PSTN) Telephony Gateways via SLP", Weibin Zhao, Henning Schulzrinne, 16-Feb-04, This document describes how to use the Service Location Protocol (SLP) to locate Internet telephony gateways. It defines the 'service:iptel-gw:' template for the Internet telephony gateway service, and discusses the different usage scenarios and the applicability of SLP for the Internet telephony gateway location. "Multihoming issues in the Stream Control Transmission Protocol", Lode Coene, 6-Jun-03, This document describes issues of the Stream Control Transmission Protocol (SCTP)[RFC2960] in regard to multihoming on the Internet. It explores cases where through situations in the internet, single points-of-failure can occur even when using multihoming and what the impact is of multihoming on the routing tables of the host. "Bounding Longest Match Considered", Russ White, Ted Hardie, 9-Feb-04, Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. "Requirements for the Replacement of AppleTalk Name Binding Protocol", Stuart Cheshire, 16-Feb-04, One of the implicitly understood goals amongst the participants working on 'Multicast DNS', 'Link-Local Multicast Name Resolution', 'Zeroconf Name Service', 'Rendezvous' (or whatever you like to call it) is the ability to retire AppleTalk Name Binding Protocol, NetBIOS naming, and the like, and replace them with an all-IP solution. This document outlines the specific properties required of an IP replacement for AppleTalk Name Binding Protocol. "Registration procedures for message header fields", Graham Klyne, Mark Nottingham, Jeffrey Mogul, 28-Oct-03, This specification defines registration procedures for the message header fields used by Internet mail, HTTP, news and other applications. Please send comments to . To subscribe, send a message with body 'subscribe' to . "Host-Centric IPv6 Multihoming", Christian Huitema, Richard Draves, 11-Feb-04, A way to solve the issue of site multihoming is to have a separate site prefix for each connection of the site, and to derive as many addresses for each hosts. This approach to multi-homing, which we call Host-Centric IPv6 Multihoming, has the advantage of minimal impact on the inter-domain routing fabric, since each site prefix can be aggregated within the larger prefix of a specific provider; however, it opens a number of issues, which we will discuss in this memo, including the problem created by the interaction between ingress filtering and multihoming, which we analyze in detail. We then propose a set of specific solutions that enable host centric multihoming, and we review how these solutions meet the requirements of IPv6 site multihoming. "FTP/TLS Friendly Firewalls", Paul Ford-Hutchinson, 11-Mar-04, This document discusses some of the issues with running FTP, secured with TLS as defined in [FTP-TLS], through firewalls. FTP is known to be a bit of a problem for firewalls (see [RFC-1579] for a discussion of normal FTP and firewalls). Some of the problems have been fixed by adding intelligence into the firewall. With secured FTP, where the control connection is encrypted, some of these techniques fail. Whilst this document confines itself to issues of FTP over TLS, the issues will probably be relevant for most secured FTP protocols that conform to [RFC-2228]. Some of the discussions will also be relevant to any protocol that firewalls do clever things with. "RADIUS Extension for Digest Authentication", Baruch Sterman, 22-Jul-04, Basic and Digest authentication schemes are widely used in protocols such as SIP and HTTP . RADIUS is a protocol for back end authentication. RADIUS supports Basic authentication natively, as well as several other authentication schemes, such as CHAP, but does not support Digest authentication scheme. This document describes an extension to RADIUS for Digest authentication and provides a scenario of Digest user authentication. "An Effective Solution for Multicast Scalability:The MPLS Multicast Tree (MMT)", Ali Boudani, 1-Apr-04, A multicast router should keep forwarding state for every multicast tree passing through it. The number of forwarding states grows with the number of groups. In this paper, we present a new approach, the MPLS multicast Tree (MMT), which utilizes MPLS LSPs between multicast tree branching node routers in order to reduce forwarding states and enhance scalability. In our approach only routers that are acting as multicast tree branching node routers for a group need to keep forwarding state for that group. All other non- branching node routers simply forward data packets by traffic engineered unicast routing using MPLS LSPs. We can deduce that our approach can be largely deployed because it uses for multicast traffic the same unicast MPLS forwarding scheme. We will briefly discuss the multicast scalability problem, related works and different techniques for forwarding state reduction. We discuss also the advantages of our approach, and conclude that it is feasible and promising. Finally, we analytically evaluate our approach. "LDAP 'Who am I?' Operation", Kurt Zeilenga, 8-Jun-04, This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity which the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP 'Who am I?' operation. "A Media Resource Control Protocol Developed by Cisco, Nuance, and Speechworks.", Saravanan Shanmugham, 12-Jan-04, This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks Inc. It is published as an RFC as input for further IETF development in this area. MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers etc. over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP(Session Initiation Protocol) which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol) "Extended RTP Profile for RTCP-based Feedback - Results of the Timing Rule Simulations", Carsten Burmeister, 5-Apr-04, This document describes the results we achieved when simulating the timing rules of the Extended RTP Profile for RTCP-based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well accepted RTP rules regarding allowed bit rates for control traffic. "Considerations for LDAP Extensions", Kurt Zeilenga, 17-Feb-04, The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schema. This document discusses considerations for designers of LDAP extensions. "Traversal Using Relay NAT (TURN)", Jonathan Rosenberg, 20-Jul-04, Traversal Using Relay NAT (TURN) is a protocol that allows for an element behind a NAT or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to run servers on well known ports if they are behind a nat; it supports the connection of a user behind a nat to only a single peer. In that regard, its role is to provide the same security functions provided by symmetric NATs firewalls, but to ``turn'' the tables so that the element on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client. "Extensions to Generalized Multi-Protocol Label Switching in support of Waveband Switching", Richard Douville, 22-Jul-04, Generalized Multi-Protocol Label Switching (GMPLS) extends the MPLS control plane to encompass layer 2, time-division, wavelength and spatial switching. Along with the current development on IP over optical switching, considerable advances in optical transport systems based on the multiple optical switching granularities have been developed. Currently, GMPLS considers two layers of optical granularity using wavelengths and fibers. By introducing an extended definition of waveband switching, this document specifies the corresponding GMPLS extensions, to further integrate optical multi-granularity and benefit from the features of the corresponding switching layers. "Examples of Network Address Translation (NAT) and Firewall Traversal for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Jul-04, This document contains a set of examples about how to establish sessions through Network Address Translators (NATs) using the Session Initiation Protocol (SIP). NAT traversal for SIP is accomplished using Interactive Connectivity Establishment (ICE), which allows the media streams to work, in addition to the SIP extension for symmetric response routing, which allows SIP itself to flow through NAT. The examples cover a range of network topologies and use cases. This variability helps to demonstrate that the ICE methodology always works, and that a common client algorithm, independent of the network topology and deployment configuration, results in the best connectivity. "The Managed Object Aggregation MIB", Glenn Keeni, 18-Feb-04, This memo defines a portion of the Management Information Base (MIB), the AggrMIB, for use with network management protocols in the Internet community. The AggrMIB is used to configure an agent to aggregate the values of a (user) specified set of MO instances and to service queries related to the aggregated MO instances. "SS7 MTP2-User Peer-to-Peer Adaptation Layer Test Specifications M2PA-TEST", Brian Bidulock, 13-Apr-04, This Internet Draft provides information for the Internet community on test cases for testing the SS7 M2P2-User Peer-to-Peer Adaptation Layer [M2PA06] based on the conformance test specifications for SS7 MTP Level 2 [Q.781]. This memo describes the test environment and a detailed description of test cases for validation, compatibility and interoperability testing of the M2PA protocol implemented on the foundation of ITU SS7 MTP Signalling Links [Q.703]. "Registration of GSTN SMS Service Qualifier", Erik Wilde, 15-Jul-04, This memo describes the registration of the Short Message Service (SMS) as a registered IANA service selector for Global Switched Telephone Network (GSTN) numbers. SMS is not available for all GSTN subscribers, but it has proven very popular with users of the Global System for Mobile Communications (GSM), and has also been adapted to other telephone network technologies such as the Integrated Services Digital Network (ISDN). "The 'application/soap+xml' media type", Mark Baker, Mark Nottingham, 18-May-04, This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. "Requirements for transmission of IP datagrams over MPEG-2 networks", Gorry Fairhurst, 8-Jun-04, This document describes a new framework 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. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams, and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. "URI scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 15-Jul-04, This memo specifies a URI (Universal Resource Identifier) scheme 'sms' for specifying a recipient (and optionally a gateway) for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped computer "Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", Martin Stiemerling, 20-Jul-04, This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the MIDCOM semantics described in [RFCXXXX]. Compared to earlier experimental versions of the SIMCO protocol, this version 3 uses binary message encodings in order to reduce resource requirements. "Reply Posting Guidelines in One to Many Communications", John Bambenek, 17-May-04, This document describes the proper methods to use when replying to messages in a One to Many communication environment such as USENET, mailing lists, or bulletin boards. It is recommended that top-posting in a summary reply be used primarily, or if desired and appropriate that middle-posting or conversational-posting be used in a point-by-point reply. "Media Gateway Control Protocol Fax Package", Flemming Andreasen, 20-Jul-04, This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method as well as handle the details of the fax call without Call Agent involvement. "IMEI-based universal IPv6 interface IDs", Francis Dupont, Loutfi Nuaymi, 14-Jun-04, The IPv6 addressing architecture [1] defines a modified EUI-64 format for interface identifiers. These interface identifiers may have global scope when a global token is available (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers). Such a global token, the IMEI (International Mobile station Equipment Identity), is defined for GSM and UMTS terminals [2, 3, 4] and has the same properties than identifiers based on IEEE standards. This document explains the construction of a global IPv6 interface identifier from an IMEI. "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 8-Jun-04, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System (DNS) security extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. "Requesting Attributes by Object Class in the Lightweight Directory Access Protocol", Kurt Zeilenga, 22-Jul-04, The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, or attributes selected by their description. This document extends LDAP to provide a mechanism for LDAP clients to request the return of all attributes of an object class. "LDAP Absolute True and False Filters", Kurt Zeilenga, 4-Feb-04, This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. "Analysis of IDR requirements and History", Avri Doria, Elwyn Davies, 21-Jul-04, This draft is the product of Group B, which is one of, at least, two subgroups in the IRTF-Routing Research Group working on requirements for routing solutions for the future. This document analyses the current state of IDR routing with respect to RFC1026 and other IDR requirements and design efforts. It is the companion document to draft-irtf-routing-reqs-groupb-00.txt, which is a discussion of requirements for the future routing architecture and future routing protocols "RFC 3041 Considered Harmful", Francis Dupont, Pekka Savola, 25-Jun-04, The purpose of the privacy extensions for stateless address autoconfiguration [1] is to change the interface identifier (and the global-scope addresses generated from it) over time in order to make it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Current Distributed Denial of Service (DDoS) [2] attacks employ forged source addresses which can also be in the same prefixes than the real addresses of the compromised nodes used for attacks. Indeed, network ingress filtering defeats DDoS using 'random' forged source addresses. "Lightweight Directory Access Protocol (LDAP): Access Control Administration", Steven Legg, 17-Jun-04, This document adapts the X.500 directory administrative model, as it pertains to access control administration, for use by the Lightweight Directory Access Protocol. The administrative model partitions the Directory Information Tree for various aspects of directory data administration, e.g. subschema, access control and collective attributes. This document provides the particular definitions that support access control administration, but does not define a particular access control scheme. "Lightweight Directory Access Protocol (LDAP): Basic and Simplified Access Control", Steven Legg, 17-Jun-04, An access control scheme describes the means by which access to directory information and potentially to access rights themselves may be controlled. This document adapts the X.500 directory Basic Access Control and Simplied Access Control schemes for use by the Lightweight Directory Access Protocol. "Instructions to Request for Comments (RFC) Authors", Joyce Reynolds, Robert Braden, 20-Jul-04, This memo provides information for authors of Request for Comments (RFC) documents. It summarizes RFC editorial policies and formatting requirements, addresses frequently-asked questions, and serves as a model for constructing a properly formatted RFC. "IP Measurement Protocol (IPMP)", Anthony McGregor, Matthew Luckie, 4-Feb-04, The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. IPMP is tightly constrained and easy to implement. "Preventing SCTP Congestion Window Overgrowth During Changeover", Janardhan Iyengar, 13-Feb-04, SCTP [RFC2960] supports IP multihoming at the transport layer. SCTP allows an association to span multiple local and peer IP addresses, and allows the application to dynamically change the primary destination during an active association. We present a problem in the current SCTP specification that results in unnecessary retransmissions and 'TCP-unfriendly' growth of the sender's congestion window during certain changeover conditions. We present the problem and propose an algorithm called the Split Fast Retransmit Changeover Aware Congestion Control (SFR-CACC) algorithm as a solution. We recommend the addition of the SFR-CACC algorithm to the SCTP specification [RFC2960]. "Mobile IPv6 Authentication, Authorization, and Accounting Requirements", Stefano Faccin, 16-Feb-04, This document describes the motivation why Diameter support for Mobile IPv6 is required and needs to be developped. It analyses the requirements expressed in RFC 2977 which was written both for MIPv4 and MIPv6; and it finally updates the IPv6 requirements for the AAA support for Mobile IPv6 to reflect the latest modifications and evolution of the Mobile IP, AAA and other relevant working groups. "IMAP ANNOTATEMORE Extension", Cyrus Daboo, 20-Apr-04, The ANNOTATEMORE extension to the Internet Message Access Protocol permits clients and servers to maintain "metadata" on IMAP4 servers. It is possible to store data on a per-mailbox basis or on the server as a whole. "How to make IPsec more mobile IPv6 friendly", Francis Dupont, Wassim Haddad, 10-Feb-04, IPsec specifications [1-6] do not work well with any mobility device based on addresses [7]. Mobile IPv6 interaction with IPsec is still far from being well achieved. This is mainly due to bad interpretations of IPsec specifications. HIP (Host Identity Payload) [9] should change this regrettable situation. This document specifies some points where improvements can be made in many current implementations, on the way of making IPsec more suitable for Mobile IPv6. "LDAP Schema for UDDIv3", Bruce Bergeson, Kent Boogert, Vijay Nanjundaswamy, 18-Mar-04, This document defines the Lightweight Directory Access Protocol [(LDAPv3)] Schema for representing Universal Description, Discovery & Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class & attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3 compliant directory. "OSPF Link-local Signaling", Alex Zinin, Barry Friedman, Abhay Roy, Liem Nguyen, Derek Yeung, 7-Jan-04, OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. "OSPF Out-of-band LSDB resynchronization", Alex Zinin, Abhay Roy, Liem Nguyen, 7-Jan-04, OSPF is a link-state intra-domain routing protocol used in IP networks. LSDB synchronization in OSPF is achieved via two methods-- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network. This memo describes a vendor specific mechanism to perform such form of out-of-band LSDB synchronization. "OSPF Restart Signaling", Alex Zinin, Abhay Roy, Liem Nguyen, 7-Jan-04, OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions. This memo describes a vendor specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. "WebDAV SEARCH", Julian Reschke, 9-Feb-04, This document specifies a set of methods, headers, properties and content-types composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) DASL mailing list at www-webdav-dasl@w3.org, which may be joined by sending a message with subject 'subscribe' to www-webdav-dasl-request@w3.org. Discussions of the WebDAV DASL mailing list are archived at URL: http://www.w3.org/pub/WWW/Archives/Public/www-webdav-dasl/. "Enabling Global Service Attributes in the Service Location Protocol", Weibin Zhao, Henning Schulzrinne, 16-Feb-04, This document describes enabling global service attributes in the Service Location Protocol (SLP). A global service attribute describes a service property common to all service types. Its name begins with the 'service-' prefix. It is defined via an attribute template, and can be imported into any service template. A single Service Request (SrvRqst) message can use global service attributes to search services across multiple service types. Global service attributes can be associated with certain special characteristics so as to support advanced discovery scenarios, such as URL changes, multi-access-point services, multi-function devices and replicated services. "application/rdf+xml Media Type Registration", Aaaron Swartz, 5-Apr-04, This document describes a media type (application/rdf+xml) for use with the XML serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. "Interworking SIP and Intelligent Network (IN) Applications", Vijay Gurbani, F Haerens, Vidhi Rastogi, 21-Jun-02, Public Switched Telephone Network (PSTN) services such as 800 number routing (freephone), time-and-day routing, credit-card calling, virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This draft addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this draft describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). "An IPv4 Flowlabel Option", Thomas Dreibholz, 24-May-04, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, 21-Jul-04, This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs where appropriate to identify resources. The approach of defining a new protocol element was chosen, instead of extending or changing the definition of URIs, to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines for the use and deployment of IRIs in various protocols, formats, and software components that now deal with URIs are provided. "GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit", Hamid Ould-Brahim, 13-May-04, This draft describes a suite of port-based Provider-provisioned VPN services called Generalized VPNs (GVPNs) that uses BGP as a VPN auto-discovery and GMPLS as a signaling mechanism. GVPN services are "generalized" as the interfaces on the customer’s and provider ports could be any of the interfaces supported by Generalized MPLS (GMPLS). GVPN services outlined in this document are: (1) a port-based Generalized Virtual Private Wire (GVPW) where the basic unit of service is a Label Switched Path (LSP) between a pair of customer’s ports within a given VPN port-topology. (2) a Generalized Virtual Private Cross-connect (GVPXC) service where the service provider network appears to the customer network as a GMPLS-enabled Virtual Private node. A GVPXC service provides flexible traffic engineering on the client network and eliminates the need for n square routing peering between CEs. Since GVPNs uses GMPLS as the signaling mechanism, and since GMPLS applies to both TDM and Optical interfaces, it results that GVPN services include Optical/TDM VPNs (though they need not be restricted to). "IPv6 Fast Router Advertisement", James Kempf, Mohamed Khalil, Brett Pentland, 20-Jul-04, This document specifies an amendment to the router solicitation handling procedures in RFC 2461 that allow for improved default router aquisition performance when an active IP host moves from one subnet to another. "SMTP Submission Service Extension for Future Delivery", Gregory White, Gregory Vaudreuil, Gregory Vaudreuil, 17-Feb-04, 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. "Registration of mail and MIME header fields", Graham Klyne, Jacob Palme, 11-May-04, This document defines the initial IANA registration for permanent mail and MIME message header fields, per [[[RFC XXXX (xref target='msghdr-registry' /)]]]. "RFC Editor Guidelines on Author Lists", Joyce Reynolds, Robert Braden, 9-May-02, This memo presents a new set of guidelines to govern lists of authors on RFC documents. It is intended to counteract a recent tendency towards author list inflation. "Localized RSVP", Jukka Manner, 20-Jan-04, Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. Even if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources at the access network, especially wireless link resources. Additionally, for mobile nodes the continuity of QoS is disturbed due to end-to-end signalling or slow re-reservations of resources after each handover. This draft proposes a simple enhancement to RSVP, so that initial resource reservations and re-reservations due to host mobility can be done locally in an access network. "User Online Presence and Information Attributes", Pekka Riikonen, 2-Feb-04, This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network. "Stream Control Transmission Protocol (SCTP) Bakeoff Scoring", Randall Stewart, Michael Tuexen, 20-Jul-04, This memo describes some of the scoring to be used in the testing of Stream Control Transmission Protocol (SCTP) at upcoming bakeoffs. "Data Transfer Protocol for Distributed Information Acquisition (DTP/DIA)", Alexei Soloviev, 17-Mar-04, The described in this memo protocol was developed for the application in distributed information measurement systems (IMS) at any stage of communication. It was designed for transmission of measured data from measuring devices to processing and storing equipment. Also it does support common device identification in distributed IMS. Due to its simplicity it can be easily implemented in firmware of any digital measuring device. "SMTP Service Extension for message Media Size declaration", Vladimir Shveidel, Ari Erev, 17-Jun-04, This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby an SMTP client and server may interact to give the server an opportunity to decline or accept a message (perhaps temporarily) based on the client's estimate of the general message size and sizes of the media parts the message contains. "Cisco Systems NetFlow Services Export Version 9", Benoit Claise, 26-Apr-04, This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics "Recommendations for Automatic Responses to Electronic Mail", Keith Moore, 2-Feb-04, This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including 'out of the office' or 'vacation' response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing Session Initiation Protocol SIP-based Distributed Call Control Mechanisms", Warren Marshall, Matt Osman, Flemming Andreasen, David Evans, 16-Jan-03, This document provides an overview of a SIP-based Distributed Call Signaling (DCS) architecture to support carrier class packet-based voice, video, and other real time multimedia services. Companion documents address a specific set of SIP 2.0 protocol extensions and usage rules that are necessary to implement the DCS architecture in an interoperable fashion. The DCS architecture takes advantage of endpoint intelligence in supporting telephony services without sacrificing the network's ability to provide value through mechanisms such as resource management, lookup of directory information and translation databases, routing services, security, and privacy enforcement. At the same time, the architecture provides flexibility to allow evolution in the services that may be provided by endpoints and the network. DCS also takes into account the need to manage access to network resources and account for resource usage. The SIP usage rules defined in the accompanying IDs specifically address the coordination between Distributed Call Signaling and dynamic quality of service control mechanisms for managing resources over the access network. In addition, the DCS architecture defines the interaction needed between network provided call controllers, known as a 'DCS- proxy' for supporting these services. "Fault Notification Protocol for GMPLS-Based Recovery", Richard Rabbat, 1-Jun-04, This draft presents a fault notification protocol for use in a GMPLS- based failure recovery scheme. The protocol guarantees recovery path(s) activation in a bounded time in the event of single resource failures. These failures include fiber cut, transponder failure and node failure. Bounded recovery time is achieved by pre-signaling recovery paths whose nodes can be reached within a specific time, based on the physical capabilities of the nodes and the delay characteristics of the control plane. We propose using a flooding protocol for fault notification to allow for per-failure notification and to speed up the recovery process. We justify choices made for the notification method and the messaging required for the protocol. The draft does not mandate a specific implementation of the Fault Notification Protocol. "Registration of HTTP header fields", Mark Nottingham, 13-Jun-02, This document defines the initial IANA registration for some HTTP message header fields. Discussion of this document Please send comments to . To subscribe to this list, send a message with the subject'subscribe' to . "IPv6 Reverse Routing Header and its application to Mobile Networks", Pascal Thubert, Marco Molteni, 23-Jun-04, NEMO basic support enables Mobile Networks by extending Mobile IP to Mobile Routers. In the case of nested Mobile Networks, this involves the overhead of nested tunnels between the Mobile Routers and their Home Agents, and causes a number of security issues. This proposal alleviates those problems as well as other minor ones, by using a source routing within the mobile nested structure, introducing a new routing header, called the reverse routing header. "Synchronization operations for disconnected IMAP4 clients", Alexey Melnikov, 20-Jan-04, This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the 'driver' portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy. This note describes different strategies that can be used by disconnected clients as well as shows how to use IMAP protocol in order to minimize the time of synchronization process. "BGP Peer Restart Backoff Mechanisms", Susan Hares, 11-Feb-04, 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 those authors is based on the author's lack of knowledge the originators of the expotential back-off. "JXTA v2.0 Protocols Specification", Michael Duigou, 29-Jun-04, The JXTA protocols defines a suite of six XML-based protocols that standardize the manner in which peers self-organize into peergroups, publish and discover peer resources, communicate, and monitor each other. The Endpoint Routing Protocol (ERP) is the protocol by which a peer can discover a route (sequence of hops) to send a message to another peer potentially traversing firewalls and NATs. The Rendezvous Protocol (RVP) is used for propagating a message within a peergroup. The Peer Resolver Protocol (PRP) is the protocol used to send a generic query to one or more peers, and receive a response (or multiple responses) to the query. The Peer Discovery Protocol (PDP) is used to publish and discover resource advertisements. The Peer Information Protocol (PIP) is the protocol by a which a peer may obtain status information about another peers. The Pipe Binding Protocol (PBP) is the protocol by which a peer can establish a virtual communication channel or pipe between one or more peers. The JXTA protocols permit the establishment a virtual network overlay on top of physical networks allowing peers to directly interact and organize independently of their network location and connectivity. The JXTA protocols have been designed to be easily implemented on unidirectional links and asymmetric transports. "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", Francis Dupont, Jean-Jacques Bernard, 29-Jun-04, When a 'NAT traversal' capability is added to a class of signaling protocols which can control some traffic aggregation points, an attack based on a temporary access to the path followed by messages exists. Mobile IP [1] with NAT traversal [5] or IKE [2] with NAT traversal [6], including the IKEv2 [7] proposal, are potentially affected by this kind of attacks. This document claims this vulnerability is an intrinsic property of the NAT traversal capability, so is another point where the usage of NATs is very damaging. "Sieve -- 'body' extension", Jutta Degener, 7-Jan-04, This document defines a new primitive for the 'sieve' language that tests for the occurrence of one or more strings in the body of an e-mail message. "A Protocol for Anycast Address Resolving", Shingo Ata, Hiroshi Kitamura, Masayuki Murata, 18-Feb-04, This document describes a mechanism to realize anycast communication without any modifications of applications and/or underlying protocols. The mechanism, using a DLL (Dynamic Linkable Library) based approach, is called AARP (Anycast Address Resolving Protocol), which resolves the anycast address into the corresponding unicast address prior to establishing the communication. AARP smoothly supports anycasting without change of existing applications. "Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation", Wai Lai, 12-Jan-04, The Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements RFC 3564 specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. "HMAC SHA TSIG Algorithm Identifiers", Donald Eastlake 3rd, 6-Jul-04, Use of the TSIG DNS resource record requires specification of a cryptogrpahic message authentication code. Currently idenfitiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document specifies identifiers for additional HMAC SHA TSIG algorithms. "MIME Type Registration for MPEG-4", Yuen Lim, David Singer, 20-Jul-04, 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. "Configuring BGP to Block Denial-of-Service Attacks", Doughan Turk, 25-Mar-04, This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black- holing can be applied on a selection of routers rather than all BGP- speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. "The 'MFxx' Command Extensions for FTP", David Somers, 6-Feb-04, This document defines extensions to the FTP specification STD9, RFC959, 'FILE TRANSFER PROTOCOL (FTP)'. These extensions provide the ability for a FTP Client to modify the last modification time, the creation time, or multiple facts (last modification time, creation time, operating system permissions, etc.) of a file in the server-FTP process NVFS. These extensions are implemented by three new optional commands: 'MFMT' (Modify File Modification Time), 'MFCT' (Modify File Creation Time), and 'MFF' (Modify File Facts). "BGP Extended Communities Attribute - Implementation Survey", Yakov Rekhter, 11-Mar-04, This document provides a survey of BGP-4 Extended Communities implementations. "Guidelines for MPLS Load Balancing", David Allan, 9-Oct-03, RFC 3031 permits MPLS load balancing while making no specific representations as to implementation requirements. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorithms may separate path test probes from the path of interest. This document proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. "Microsoft EAP CHAP Extensions", Vivek Kamath, Ashwin Palekar, 12-Apr-04, This document defines the Microsoft EAP CHAP Extensions Protocol, Version 2, which encapsulates the MS-CHAP-v2 protocol, defined in [RFC2759], within EAP. "IRC RPL_ISUPPORT Numeric Definition", Edward Brocklesby, 7-Jan-04, This memo presents a way for the server to unobtrusively advertise the ways in which it differs from the IRC (Internet Relay Chat) specification defined in RFC 1459 [6]. It is a primary goal to implement this in a way which is completely backwards-compatible with the original protocol, and also with current non-standard implementations of the ISUPPORT numeric. "A Base-85 Encoding Suitable for XML", Paul Kwiatkowski, 3-May-04, This memo proposes a base85 text encoding for arbitrary binary data that is suitable for use in XML documents. This encoding requires approximately 15/16 of the space of the MIME Base64 encoding that is currently supported as a primitive datatype in the XML Schema definition language. In a UTF-8 encoded XML entity, Base85 therefore has 3/4 of the overhead of Base64. "SDP attribute for qualifying Media Formats with Generic Parameters", Rajesh Kumar, Flemming Andreasen, 20-May-03, This document defines a new SDP attribute called general-purpose media descriptor (gpmd). The gpmd attribute allows the use of new informative parameters, gpmd parameters, to qualify existing media formats. These gpmd parameters are not part of the standard (e.g., MIME) definition of the media format and support for them with a given media format can not be assumed. Their use is therefore limited to cases where they provide information that may be of use to the other party in a session but is not critical to the use of the particular media format. This document also defines a specific gpmd parameter, voice-band data, which can be used to describe a media format as carrying voice-band data. This enables the receiver to optimize its handling of the media received. "Lightweight Directory Access Protocol (LDAP): Directory Administrative Model", Steven Legg, 17-Jun-04, This document adapts the X.500 directory administrative model for use by the Lightweight Directory Access Protocol. The administrative model partitions the Directory Information Tree for various aspects of directory data administration, e.g. subschema, access control and collective attributes. The generic framework that applies to every aspect of administration is described in this document. The definitions that apply for a specific aspect of administration, e.g. access control administration, are described in other documents. "A UUID URN Namespace", Michael Mealling, 11-Mar-04, This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can provide a guarantee of uniqueness across space and time. UUIDs were originally used in the Network Computing System (NCS) [1] and later in the Open Software Foundation's (OSF) Distributed Computing Environment [2]. This specification is derived from the latter specification with the kind permission of the OSF (now known as The Open Group). Earlier versions of this document never left draft stage; this updated version incorporates that information here. "XML Schema for Media Control", Orit Levin, Sean Olson, Roni Even, 18-Feb-04, This document defines an XML Schema for Media Control in a tightly controlled environment. The current version includes commands for managing of video streams only. Implementation of this schema for interactive video applications in SIP environments significantly improves user experience. "Media Gateway Control Protocol (MGCP) Redirect and Reset Package", Bill Foster, Flemming Andreasen, 23-Jul-03, The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be re-directed one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately re-direct endpoints by allowing a list of Call Agents to be specified in a preferred order. "IPv6 Multicast Deployment Issues", Pekka Savola, 10-Feb-04, There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted. "Grace LSA in OSPFv3", Padma Pillay-Esnault, 28-Jan-04, This memo describes the OSPF version 3 specific Grace Link State Advertisement used to perform a graceful restart. "Taxonomy of Route Optimization models in the Nemo Context", Pascal Thubert, Marco Molteni, Chan Ng, 17-Feb-04, Nemo enables Mobile Networks by extending Mobile IP to support Mobile Routers. This paper documents how the MIPv6 concept of Route Optimization can to be adapted for Nemo to optimize: 1) the nested tunnels of the nested Nemo configuration 2) router-to-router within the infrastructure as opposed to end-to- end. "Optimistic Duplicate Address Detection", Nick Moore, 13-Feb-04, Optimistic DAD is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case, and while remaining interoperable with unmodified nodes. "National and Local Characters in DNS TLD Names", John Klensin, 24-May-04, In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about 'multilingual' or 'internationalized' top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique to permit any TLD to be accessed using the characters of any language not merely language- or country-specific 'multilingual' TLDs in the language(s) and script(s) of that country. "PWE3 ATM Transparent Cell Transport Service", Andrew Malis, 4-Jun-04, The document describes a transparent cell transport service that makes use of the 'N-to-one' cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. "EAP support in smartcards", Pascal Urien, 27-May-04, This document will describe the interface to the EAP protocol in smartcards, which could store multiple identities associated to Network Access Identifiers. "Simple Authentication and Security Layer C API", Chris Newman, Alexey Melnikov, 12-May-04, Almost every protocol needs authentication. However, there does not exist an authentication mechanism suitable for all organizations, nor is it likely that a small fixed set of authentication mechanisms will remain suitable. SASL [SASL] provides the on-the-wire framework for authentication (and a security layer) which separates the design of authentication mechanisms from the protocols in which they're used. The SASL protocol model suggests a software architecture where application protocols call a generic API to authenticate which in turn calls a generic plug-in interface for extensible authentication modules. This memo documents the API used in one implementation of this architecture in the hope that it will be useful to others. An associated memo documenting the plug-in interface is forthcoming. "Guidelines for Mandating the Use of IPsec", Steven Bellovin, 25-Mar-04, The Security Considerations sections of many Internet Drafts say, in effect, 'just use IPsec'. While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec should and should not be specified. "GVPLS/LPE - Generalized VPLS Solution based on LPE Framework", Vasile Radoaca, 18-Feb-04, This document describes distributed virtual private LAN service (VPLS) solution over MPLS using LDP signaling. For VPLS solutions, the VPLS Reference Model [VPLS-L2-FRW] introduces two types of models: distributed and non-distributed. While [VPLS] solution presents a non-distributed model, it is recognized that both models may co-exist in the same SP network. This implies a need of signaling mechanisms to support these new classes of solutions. The current draft presents the GVPLS solution that addresses such issues. The term 'Generalized' in this document is used to reflect the unified aspect of the two models. "DCLOR: De-correlated Loss Recovery using SACK option for spurious timeouts", Yogesh Swami, Khiem Le, 9-Mar-04, A spurious timeout in TCP forces the sender to unnecessarily retransmit one complete congestion window of data into the network. In addition, TCP uses the rate of arrival of ACKs as the basic criterion for congestion control. TCP makes the assumption that the rate at which ACKs are received reflects the end-to-end state of the network in terms of congestion. However, ACKs after a spurious timeout don't reflect the end-to-end congestion state of the network; they only reflect the congestion state of a part of the network. In these cases, the slow-start behavior after a timeout can further add to network congestion. In this draft we propose changes to the TCP sender that can be used to solve the problem of both redundant- retransmission and network congestion after a spurious timeout. "Requirements for Assured Service Capabilities in Voice over IP", Michael Pierce, Don Choi, 9-Jan-04, Assured Service refers to the set of capabilities used to ensure that critical communications are setup and remain connected. This memo describes the requirements for such capabilities in support of specific networks such as those used by government agencies, but they could also be applied in commercial environments. "Architecture for Assured Service Capabilities in Voice over IP", Michael Pierce, Don Choi, 9-Jan-04, Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. This memo describes the architecture required to meet the requirements detailed in [Pierce1]. "Examples for Provision of Preferential Treatment in Voice over IP", Michael Pierce, Don Choi, 9-Jan-04, Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. [Pierce1] describes the requirements, one of which is to provide preferential treatment to higher priority calls. IEPS refers to a set of capabilities used to provide a higher probability of call completion to emergency calls made by authorized personnel, usually from ordinary telephones. This also requires some form of preferential treatment. This memo describes some of the methods which may be applied to provide that preferential treatment. "Generalized MPLS Architecture for Multi-Region Networks", Martin Vigoureux, 18-Feb-04, Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments of single switching capability devices e.g. one data plane layer, as such, the complexity raised by such control planes is similar to the one expected in classical IP/MPLS networks. The fundamental reason being that an IP-based control plane protocol suite for Label Switch Routers (LSR) or Optical Cross-Connects (OXC) has exactly the same Level (i.e. single data plane layer) complexity. The present document analyses the various GMPLS signaling and routing aspects when considering network environments consisting of multiple switching data layers e.g. supporting combined Packet/Layer-2 Switching - OXC devices. The examples provide an overview of the tradeoffs in using a GMPLS control plane for combined Ethernet MAC - opaque, service transparent, and/or fully transparent data planes. The intent of this memo is also to demonstrate that these aspects may not be as straightforward as they may first appear. "Selectively Reliable Multicast Protocol (SRMP)", Mark Pullen, 9-Mar-04, The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can be used to carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. "Extensions to BGP to Support Secure Origin BGP (soBGP)", James Ng, 16-Apr-04, There is a great deal of concern over the security of routing systems within the Internet, particularly in relation to the Border Gateway Protocol [BGP], which is used to provide routing information between autonomous systems. This document proposes a system where the origin of any advertisement within BGP can be verified and authenticated, preventing the advertisement of prefix blocks by unauthorized networks, and verifying that the final destination in the path is actually within the autonomous system to which the packets are being routed. "RADIUS Attributes for soBGP Support", Chris Lonvick, 16-Feb-04, This document defines a set of RADIUS attributes designed to support the provisioning of the soBGP protocol. A router will encapsulate the components of a soBGP certificate into a profile composed of ordered TLVs and transport them to a centralized server capable of verifying the associated signature. The certralized will respond notifying the client of the validity of the signed information. "LDAP Content Synchronization Operation", Kurt Zeilenga, Jin Choi, 4-Feb-04, This specification describes the LDAP (Lightweight Directory Access Protocol) Content Synchronization operation. The operation allows a client to maintain a shadow copy of a fragment of directory information tree. It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search operation. "Layer-3 VPN Import/Export Verification", Michael Behringer, Jim Guichard, Pedro Marques, 4-Jun-04, Configuration errors on Provider Edge (PE) routers in Layer-3 VPN networks based on [RFC2547] can lead to security breaches of the connected VPNs. For example, the PE router could be mistakenly configured such that a connected Customer Edge (CE) router belongs to an incorrect VPN. Here we propose a scheme that verifies local and remote routing information received by the PE router before it installs new VPN routes into the Virtual Routing & Forwarding Instance (VRF). The proposed changes affect only the PE routers. "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", Jeremy De Clercq, 23-Apr-04, This document explains how to interconnect IPv6 islands over a Multi-Protocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE) which are Dual Stack in order to connect to IPv6 islands and to the MPLS core which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multi-Protocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. "Securing Nested Tunnels Optimization with Access Router Option", Chan Ng, Takashi Tanaka, 14-Jul-04, Through the establishment of bi-directional tunnels between a mobile router and home agent, global connectivity can be extended to nodes within a network in motion. However, the multiple levels of bi- directional tunnels in nested mobile networks lead to undesirable effects. This memo proposes using a new mobility header option called the Access Router Option to allow a mobile router to inform its home agent the home-address of the access router it is currently attached to. From there, this memo lays out a mechanism that allows mobile routers to securely achieve nested tunnels optimization. "Uniform Resource Identifier (URI): Generic Syntax", Tim Berners-Lee, Roy Fielding, Larry Masinter, 19-Jul-04, A Uniform Resource Identifier (URI) is a compact sequence of characters for identifying an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. "Media Server Control Markup Language (MSCML) and Protocol", Jeff Van Dyke, Eric Burger, Andy Spitzer, 15-Mar-04, Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and IVR functions. This protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. "RADIUS & L2TP Extended NAS-Port AVPs", Neil McGill, 22-Jul-04, This document defines additional Layer 2 Transfer Protocol (L2TP) and Remote Authentication Dial In User Service (RADIUS) Attribute-Value Pairs (AVPs) to communicate Network Access Server (NAS) informational ASCII text and port usage information between L2TP peers during call establishment to facilitate authorization, accounting and logging. "Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications", Glen Marshall, 20-May-04, This document defines the format of data to be collected, and minimum set of attributes that need to be captured, for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. "Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism", Bill Foster, Flemming Andreasen, 25-Jul-03, A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition such as being involved in a transient call when a Call Agent failover occurred could be left in a lockstep state such that events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. "SIP Telephony Device Requirements and Configuration", Ian Butcher, Steven Lass, Dan Petrie, Henry Sinnreich, Christian Stredicke, 15-Jul-04, This informational I-D describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. "The RMX DNS RR and method for lightweight SMTP sender authorization", Hadmut Danisch, 21-May-04, This memo introduces a new authorization scheme for SMTP e-mail transport. It is designed to be a simple and robust protection against e-mail fraud, spam, and worms. It is based solely on organisational security mechanisms and does not require but still allow use of cryptography. This memo also focuses on security and privacy problems and requirements in context of spam defense. This document is part of the LMAP work of the Anti-Spam Research Group (ASRG) of the IRTF. "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 13-Feb-04, This specification defines a set of requirements for new capabilities for instant messaging and presence in SIP-based systems. "Policy Core Extension Lightweight Directory Access Protocol Schema", Angelica Reyes, 21-Jun-04, This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. "DNS-Based Service Discovery", Stuart Cheshire, 16-Feb-04, This document describes a convention for naming and structuring DNS resource records. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of a that desired service, using only standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD. "The EAP GPRS Protocol (EAP-GPRS)", Apostolis Salkintzis, 23-Jan-04, This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. "TIPC: Transparent Inter Process Communication Protocol", Jon Maloy, 2-Feb-04, This document describes TIPC, a special-purpose transport protocol designed for efficient communication within clusters of loosely coupled nodes. "Considerations for IEPREP Related Protocol Packet Flow Models", James Polk, 16-May-03, This document diagrams the packet flows - both signaling and data - of Internet Emergency Preparedness (IEPREP) related protocols. This document serves as a point of reference for the WG when discussing which QoS mechanisms can be employed for each individual (application) protocol packet flow to function properly during congestion events from IP source to IP destination, as well as a potentially different QOS mechanism for a related but separate data flow (if present). "Extended RSVP-TE for Point-to-Multipoint LSP Tunnels", Seisho Yasukawa, Alan Kullberg, 16-Feb-04, This document describes a solution for point-to-multipoint (P2MP) Traffic Engineering (TE) which extends 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC 3209, and 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions', RFC 3473, to support P2MP TE LSPs. A P2MP TE LSP is established by setting up multiple standard point- to-point (P2P) TE LSPs from a sender node and all the downstream branch nodes along the P2P TE LSP to one of the leaf nodes of the P2MP TE LSP. A branched LSP is associated with original trunk LSP by newly defined Association object so that the P2MP LSP tunnel is established over the P2MP path. Because only a single standard LSP will be present on any given link along the P2MP LSP, the defined approach realizes maximum compatibility with existing implementations. The solution supports standard tree operations: setup, graft/join, and prune/leave. As the (G)MPLS signaling is used, the P2MP TE LSP can be built using any switching technology supported by GMPLS. This includes non-packet technologies. "Flexible BGP Communities", Andrew Lange, 10-Mar-04, This document defines a new attribute for BGP called the Flexible Community attribute. Flexible Communities build on the experience and utility of the standard BGP community, and the extended BGP community attributes. This attribute allows operators to associate structured information with a route or set of routes. This information can be then be used to execute routing policy. An enhanced version of communities is necessary to accomodate IPv6, 4- byte ASN's, and introduce a more extensible and flexible policy expression. This document also introduces the concept of Neighbor Classes. A Neighbor Class is applied to a group of BGP neighbors who share certain attributes. For example, the PEER Neighbor Class could be applied to BGP sessions between ASN X and other networks with which ASN X has a non-transit peering relationship. "IP header compression in IPsec ESP", J Vilhuber, 30-Jun-04, This draft outlines how to use IP Header compression over IP tunnels [HCOIP] inside IPsec ESP [ESP]. "Multihoming Using IPv6 Addressing Derived from AS Numbers", Pekka Savola, 2-Feb-04, In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS- number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4. "Address Management for IKE version 2", Francis Dupont, 29-Jun-04, The current IKEv2 proposal [1] lacks an address management feature. As it is compatible with the NAT traversal capability, this document specifies a complete address management with support for multi-homing and mobility, and fulfill mobike working group [2] goals 1, 2, 3, 4, and 6 (for goal 5 look at [3]). "Requirements for Access Control in Domain Name Systems", Tatsuya Baba, 31-Mar-04, This document describes the requirements for access control mechanisms in the Domain Name System (DNS), which authenticate clients and then allow or deny access to resource records in the zone according to the access control list (ACL). "Name Resolution in on-demand MANETS and external IP Networks", Paal Engelstad, Geir Egeland, 2-Feb-04, The most common user applications for data communication (including web browsing and e-mail) lack a method for name resolution in multi- hop wireless ad-hoc networks of mobile nodes (MANETs). While the Domain Name System (DNS) works well on the fixed Internet, it represents a centralized approach to name resolution, which is not suitable for MANETs. This document specifies a straightforward solution for name resolution lookup in on-demand MANETs, i.e. MANETs that are routed with a reactive routing protocol, such as DSR [DSR] or AODV [AODV]. Names are resolved locally within the MANET with a mechanism similar to multicast DNS or LLMNR on a link. Although names resolved locally normally will have preference, MANET nodes that have access to external networks may complement the local name resolution by injecting into the MANET lookup results resolved by a conventional DNS server. The proposed solution applies equally well to IPv4 or IPv6. "A View on IPv6 Transition Architecture", Pekka Savola, 14-Jan-04, The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition doesn't seem to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult. This memo tries to point out some issues that will need consideration in the transition architecture. "Reorder Density and Reorder Buffer-occupancy Density - Metrics for Packet Reordering Measurements", Anura Jayasumana, Nischal Piratla, Abhijit Bare, Tarun Banka, 21-Jul-04, Out of order arrival of packets is a common occurrence on Internet, and it will be more widespread as the link speeds increase. Percentage packet reordering is vague and unclear. A good reorder metric will capture the occurrence and characteristics of reordering comprehensively, and have broader utility than merely distinguishing among different reordered sequences. Two metrics for packet reordering are presented, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to upper bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering. These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust, and orthogonal to packet loss and duplication. "Mobile SCTP with Mobile IP for Transport Layer Mobility", Seok Koh, Qiaobing Xie, 22-Jun-04, Mobile SCTP (mSCTP) is defined as SCTP with the ADDIP extension. The mSCTP can be used for providing seamless handover by exploiting its multi-homing feature. On the other hand, the Mobile IP basically provides the location management. In this document, we discuss the use of mSCTP along with Mobile IP for Internet mobility support in the transport layer. The use of SCTP with Mobile IP is focused on the mobile sessions that are initiated by CN to MN. "Using CMS to Protect Firmware Packages", Russell Housley, 19-Mar-04, This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages. A digital signature is used to protect the firmware package from undetected modification and provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. "IPv6 Address Prefix reserved for Documentation", Geoff Huston, Anne Lord, Philip Smith, 2-Feb-04, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link- local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. "Registration for enumservices voice and video", Rudolf Brandner, 22-Jul-04, This document registers the ENUMservices "voice" and "video" (each of which has a defined sub-type "tel"), as per the IANA registration process defined in the ENUM specification RFC3761[4]. These services are be used to indicate that the contact held in the generated URI can be used to initiate an interactive voice or video/audio call respectively. "A Suggested Scheme for DNS Resolution of Networks and Gateways", Edward Warnicke, 5-Apr-04, This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. "Signaling Tunnel Encapsulation/Deencapsulation Capabilities", Rahul Aggarwal, 11-Feb-04, This document proposes a mechanism for signaling a PE router's tunnel encapsulation capabilities. One example is its capability to encapsulate MPLS using dynamic GRE and/or IP. This is applicable when a MPLS packet is tunneled using dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. For instance the MPLS packet may be a 2547 based MPLS VPN packet [2547bis], a layer 2 packet transported using MPLS [MARTINI], a MPLS tunneled IPv6 packet or a MPLS IPv6 VPN packet [BGP-VPN-IPv6]. Adding such a mechanism has several benefits. It helps in blackhole avoidance and eases transitioning from MPLS tunneling based Layer 3/Layer 2 VPNs to GRE/IP tunneling based Layer 3/Layer 2 VPNs (and vice versa). Such a mechanism is needed where a network may be using MPLS and GRE (or IP) for tunneling, simultaneously in different parts of the network. It can help in encapsulation selection when multiple tunneling technologies are supported. "vCard Extensions for IM", Cullen Jennings, 20-Jul-04, This draft describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. This draft allows a URI that is associated with IM or PP to be specified inside of a vCard. This work is being discussed on the imc-vcard@imc.org mailing list. "Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP)", Raj Jain, Vijay Gurbani, 1-Jun-04, SIP over connection-oriented transport protocol based systems are likely to face certain distinct performance and behavioral issues that are not manifest when SIP is transported over connectionless protocols. Allowing SIP entities to mutually conserve connections over a predictable, extended period of time is one of the leading requirements to help SIP entities deliver their optimal performance in the network. Overall, this document contemplates transport layer connection management issues relating to SIP. Requirements and potential solutions for introducing a backward compatible notion of persistent connections in SIP are presented. "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", Jonathan Lang, Yakov Rekhter, Dimitri Papadimitriou, Jonathan Lang, 18-Feb-04, This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document. "LSP Preemption policies for Diff-Serv-aware MPLS Traffic Engineering", Jaudelice de Oliveira, 21-May-04, When the establishment of a higher priority LSP requires the preemption of a set of lower priority LSPs, a node has to make a local decision on the set of preemptable LSPs and select which LSPs will be preempted, based on a certain objective, in order to accomodate the newly signaled high priority LSP. The preempted LSPs are then rerouted. This draft documents a preemption policy which can be modified in order to stress different objectives: preempt the lowest priority LSPs, preempt the minimum number of LSPs, preempt the exact required bandwidth in order to fit the new LSP. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority and wasted bandwidth is also included. "Textual Conventions for Internet Network Addresses", Michael Daniele, 7-Jun-04, This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. "A Model of IPv6/IPv4 Dual Stack Internet Access Service", Yasuhiro Shirasaki, 27-Apr-04, This memo shows an example of how to provide IPv6 / IPv4 dual stack services to home users. In order to simplify user setup, these service should have mechanism to configure IPv6 specific parameters automatically. We focus on two basic parameters, prefix and addresses of IPv6 DNS servers, and specify the way to deliver them to Customer Premises Equipments (CPE) automatically. This memo is a digest of the user network interface specification of NTT communications' dual stack ADSL access service. "Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB)", Steve Silverman, Steve Silverman, Dan Sullivan, Michael Pierce, Don Choi, 12-Feb-04, Some networks require certain packet flows to be transported with greater priority than others. This draft defines a new PHB (Per Hop Behavior), the Multi-Level Expedited Forwarding (MLEF) PHB. RFC 3246 [3] defines the Expedited Forwarding PHB for applications requiring low latency, but with a single DSCP and treatment. This draft extends that concept and defines a PHB with multiple treatments for packet flows for applications requiring low latency and multiple priority levels. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", Ned Freed, John Klensin, 22-Oct-03, This document specifies various IANA registration procedures for the following MIME facilities: o media types, o external body access types, and o content-transfer-encodings. "The LDAP No-Op Control", Kurt Zeilenga, 4-Feb-04, This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. "IP over InfiniBand: Connected Mode", Vivek Kashyap, 19-Jul-04, This document specifies a method for transmitting IPv4/IPv6 packets and address resolution over the connectd modes of InfiniBand. "Multiple Care-of Addresses Registration", Ryuji Wakikawa, 22-Jul-04, According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, termed the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple access media (i.e. interfaces) simultaneously, in which case multiple active IPv6 care-of addresses would be assigned to the mobile node. We thus propose Mobile IPv6 extensions designed to register multiple care-of addresses bound to a single home address instead of the sole primary care-of address. For doing so, a new identification number must be carried in each binding for the receiver to distinguish between the bindings corresponding to the same home address. Those extensions are targeted to Network Mobility (NEMO) as well as to Mobile IPv6. "A Transport Network View to LMP", Osama Aboul-Magd, 20-Jul-04, The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. "Multi-Homing Issues in Bi-Directional Tunneling", Chan Ng, Julien Charbon, 18-Feb-04, This document describes deployment scenario of multi-homed Network in Motion (NEMO) and attempts to identify issues that arises when supporting multi-homing in NEMO. It is also the objective of this document to build a full taxonomy covering multi-homed scenarios in NEMO, so as to facilitate explorations into this aspect of NEMO. "Protecting Internet Routing Infrastructure from Outsider CPU Attacks", Alex Zinin, 13-May-04, The mechanism described in this document helps to secure an Internet Service Provider's router infrastructure from outsider attacks, including (but not limited to) Distributed denial of service (DDoS) attacks based on CPU and/or queue exhaustion (e.g., TCP SYN flooding and flooding of invalid MD5-signed routing protocol packets.) The presented approach is based on explicitly marking control packets from trusted sources by different link-layer encapsulation and does not require any modifications to user data exchange protocols, ICMP, routing protocols or changes to existing hardware in routers, which allows it to be deployed quickly throughout the Internet. "Certificate Management Service for SIP", Cullen Jennings, 21-Jul-04, This draft defines a Credential Service that uses a SIP subscribe/ notify mechanism to discover other users' certificates and credentials and be notified about changes to these certificates. Other user agents that want to contact that AOR can retrieve these certificates from the server. The result is that widespread deployment of S/MIME in SIP is possible, because no extra expense or effort is required of the end user. This work is being discussed on the sipping@ietf.org mailing list. "Procedures for Modifying RSVP", Kireeti Kompella, Jonathan Lang, 18-May-04, This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types and sub-objects. "SIP/SIMPLE Based Presence and IM Architecture", Avshalom Houri, 18-Feb-04, This document is a initial attempt in creating a document that will describe the architecture of a presence and instant messaging system. The document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, functional model, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. The main changes from the previous version of the document is that sections about functional model and basic call flows were added. "Threshold Validation: A Mechanism for Improved Trust and Redundancy for DNSSEC Keys", Johan Ihren, 22-Jul-04, This memo documents a proposal for a different method of validation for DNSSEC aware resolvers. The key change is that by changing from a model of one Key Signing Key, KSK, at a time to multiple KSKs it will be possible to increase the aggregated trust in the signed keys by leveraging from the trust associated with the different signees. By having multiple keys to chose from validating resolvers get the opportunity to use local policy to reflect actual trust in different keys. For instance, it is possible to trust a single, particular key ultimately, while requiring multiple valid signatures by less trusted keys for validation to succeed. Furthermore, with multiple KSKs there are additional redundancy benefits available since it is possible to roll over different KSKs at different times which may make rollover scenarios easier to manage. "Specifying time intervals in URI queries and fragments of time-based Web resources (BCP)", Silvia Pfeiffer, Craig Parker, 9-Jan-04, This document specifies a syntax for addressing time intervals within time-based Web resources through URI queries and fragments. It suggests a Best Current Practice (BCP) for any time-based Web resource for which temporal subparts may be requested and retrieved. This enables, e.g., direct access to a clip of a video stored on a Web Server, or direct jumps to a specific event within a piece of music. The syntax is not restricted to audio or video Web resources, but covers all kinds of Web resources that contain time-continuous information. "IPv6 Anycast Functionality/Terminology Definition", Satoshi Doi, 11-Feb-04, Today, the use of IPv6 anycast is limited. This is because the usage of IPv6 anycast is still unclear. This document first defines the terminology of anycast not only for the rest of this document, but also for future discussion. Then we describe the usage of IPv6 anycast with several examples. Moreover, we describe the functionalities of anycast. "An Approach for Increasing Root And TLD DNS Servers", Yasuhiro Morishita, 19-Jul-04, Currently, it is thought that the maximum number of DNS servers for a zone is 13. In fact, current root and some TLD zones have 13 DNS servers. But this is not enough for DNS stability and robustness especially root and/or TLD server, therefore, IP anycast [Hardie, 2002] is introduced on some root servers. This draft proposes an another approach for increasing of DNS server hosts without changing DNS protocol by using 'multiple-addresses per host' method. And this draft also considers what is the most suitable number of the IP addresses for one DNS server name. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, 20-Jul-04, The draft presents an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to support Prepaid data services for a wide range of deployments such as Dial, Wireless, WLAN. Consideration for roaming using mobile-ip is also given. "RTSP Stream Switching", Philippe Gentric, 23-Jan-04, Stream switching is a technique used to change the data rate of a media being streamed, typically for the purpose of adaptation to the effectively available bandwidth of the network. A backward compatible and independent RTSP 'SWITCH' command is proposed in order to enable RTSP-based stream switching. "Extensions to LMP for Flooding-based Fault Notification", Toshio Soumiya, Richard Rabbat, 7-Jan-04, This draft describes extensions to the Link Management Protocol (LMP) for use in flooding-based fault notification in optical networks. We focus on networks that use a common control plane (e.g, Generalized Multi-Protocol Label Switching or GMPLS). These extensions implement the Fault Notification Protocol, a flooding-based approach to notifying faults to nodes in the network. We motivate the use of LMP extensions for flooding, define message formats and explain the communication messages that occur using LMP. "The EAP MD5-Tunneled Authentication Protocol (EAP-MD5-Tunneled)", Paul Funk, 5-Apr-04, EAP-MD5-Tunneled is an EAP protocol designed for use as an inner authentication protocol within a tunneling EAP protocol such as EAP- TTLS or EAP-PEAP. It is cryptographically equivalent to standard CHAP and the EAP-MD5-Challenge protocol. It can be used inside an EAP tunnel without exposing the system to the type of man-in-the- middle attack which use of CHAP or the original MD5 Challenge protocol is subject to, yet it is capable of being converted to CHAP credentials at the tunneling endpoint for proxy forwarding to legacy AAA servers, with no modification required of the legacy AAA server. It may also be converted to EAP-MD5-Challenge credentials at the tunneling endpoint for the purpose of proxy; however, the downstream server that terminates the EAP-MD5-Challenge must be modified to provide a challenge that meets certain criteria. "Explicit Resource Control over GMPLS Link Bundles", Anca Zamfir, Zafar Ali, 9-Feb-04, Record Route is a useful administrative tool that has been used extensively by the service providers. When TE links are bundled, identification of label resource in RRO is not enough for the administrative purpose. Network service providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. However, it is not possible to record component link in the RRO. This draft defines the extensions to RSVP-TE [RFC3209] to specify component link identifiers for resource recording purposes. "Delay-Tolerant Network Architecture", Vinton Cerf, 19-Jul-04, This document describes an architecture for delay-tolerant networks, and is a generalization of the architecture originally designed for the Interplanetary Internet: a communication system to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes a generalization of this architecture that addresses a variety of internetworks with operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message-oriented overlay that exists above the transport layer of the networks on which it is hosted. The document presents an architectural overview followed by discussions of services, topology, routing, security, reliability and state management. "Lightweight Mobility Detection and Response (LMDR) Algorithm for TCP", Yogesh Swami, K Le, 15-Jul-04, TCP congestion control is based on the assumption that the end-to- end path of a connection changes very infrequently (most likely due to router failure) after connection establishment. This assumption allows a TCP sender to compute (predict) a new congestion window (cwnd) based on the ACKs from previous cwnd. With host mobility, however, the assumption of 'constant path' does not hold, and the present congestion control and avoidance mechanisms can lead to suboptimal system performance. In this document we describes a TCP option that allows a receiver to inform the sender about subnet change; based on which, the sender can react to optimize performance. "Cisco Support for Lawful Intercept In IP Networks", Fred Baker, Bill Foster, Chip Sharp, 27-Oct-03, For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, Monique Morrow, 27-Jan-04, This document enumerates the OAM message mapping from pseudo wire emulated edge-to-edge services over MPLS and IP transport networks to their native attached services. "Migrating from IP/MPLS to GMPLS networks", Eiji Oki, 21-Jul-04, This document is addressing the migration from Multi-protocol label switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to expand the capacity of the existing MPLS-based infrastructure network, the optical network consisting of L2SC, TDM, LSC, and FSC devices will be deployed, which is controlled by the GMPLS protocols. GMPLS protocols are, however, subtly different from MPLS protocols. In this document we describe possible migration scenarii, the mechanisms to compensate the difference between MPLS and GMPLS protocols, and how the mechanisms are applied to migrate from the MPLS to the GMPLS network. "Reliable Multicast Transport Building Block:Tree based ACK (TRACK) Mechanisms", Dah Ming Chiu, 7-Jan-04, The Reliable Multicast Transport (RMT) Working Group has been chartered to standardize reliable multicast transport services and protocol instantiations, which include the tree-based ACK (TRACK) protocol. This document describes the RMT Building Block for Tree- based ACK (TRACK) mechanisms. It contains functions relating to positive acknowledgments and hierarchical tree construction and maintenance. It might primarily be used as part of the TRACK Protocol Instantiation. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' The TRACK BB mechanisms will operate on the logical ACK-tree that is configured by the TREE BB [10] in the TRACK PI sessions. This document is made based on the guidelines for the RMT BB [5]. "Reliable Multicast Transport Building Block: Tree Auto-Configuration", Seok Koh, 7-Jan-04, The Reliable Multicast Transport (RMT) Working Group has been chartered to standardize reliable multicast transport services and protocol instantiations, which include the tree-based ACK (TRACK) protocol. This document is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' The TRACK BB mechanisms [5] will operate on the logical ACK-tree that is configured by this TREE BB in the TRACK PI sessions. This document is made based on the guidelines for the RMT BB [2] and the recommendations for TREE BB [4]. "Using DNS SRV records to locate whois servers", Miguel Sanz, Gerhard Winkler, 5-Apr-04, Whois servers are used to locate administrative, technical and security contacts for given IP addresses, domain names or other network objects associated with an organisation, e.g. AS numbers. While usually Top Level Domain (TLD) registries run a whois server, there is no generic name for it and it may not even be obvious that the TLD registry's whois server is the right one to ask, since there are TLDs where registration takes place under specialised second level domains (e.g. UK, AT). The Regional Internet Registries (RIR) also provide whois service as part of their coordination task. All this can be solved by central 'master' or 'meta' whois servers, which keep track of all new and changing servers and refer to the DNS registries' or RIRs' whois servers. This document proposes a DNS-based approach which eliminates the need for a central master repository and works down to lower levels in the hierarchy. It is the intent to locate a whois server as close to the target (in terms of hierarchy) as possible, while preserving the opportunity to locate higher level servers for escalation purposes. "RSERPOOL Redundancy-model Policy", Qiaobing Xie, 14-Apr-04, This document defines RSERPOOL Redundancy-model Member Selection Policy parameter and the related procedures. This policy is designed to be flexible and capable of supporting a wide range of advanced redundancy models found in some high availability systems. The design uses the extensibility in RSERPOOL pool load sharing policy. "Lumas-A Language for Universal Message Abstraction and Specification", Peter Cordell, 22-Mar-04, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "SIEVE Include Extension", Cyrus Daboo, 20-Jul-04, The SIEVE [SIEVE] 'include' extension permits users to include one SIEVE script inside another. This can make managing large scripts or multiple sets of scripts much easier, as well as supporting common 'libraries' of scripts. Users are able to include their own personal scripts or site-wide scripts provided by the local SIEVE implementation. "Sieve Extension: Copying Without Side Effects", Jutta Degener, 1-Jun-04, The sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior. This document defines a new keyword parameter, ":copy", to be used with the sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. "Sieve -- 'editheader' extension", Jutta Degener, 7-Jan-04, This document defines three new actions for the 'sieve' language that add, delete, and change e-mail header fields. "The Nortel Networks Ethernet Layer 2 Virtual Private Service Protocol", Marc Holness, Michael Chen, Dinesh Mohan, 20-May-04, This draft specifies an Ethernet Layer 2 Virtual Private Service Protocol using Ethernet addressing hierarchy and service separation. This protocol enables Service Providers to deploy an Ethernet Network and offer scalable and manageable layer 2 Transparent LAN Services (L2TLS). The primary goal of this protocol is to eliminate the need of the Service Provider to manage customer address information and forwarding within its network. Another goal is to allow auto provisioning of VPN service instances within the Service Provider networks. This solution maintains customer benefits of simplicity of access to the VPN, allows efficient utilization of Service Provider network resources, and overcomes distance limitations of customer's LANs. "EAP IKEv2 Method (EAP-IKEv2)", Hannes Tschofenig, Dirk Kroeselberg, 22-Jul-04, EAP-IKEv2 is an EAP method which reuses the cryptography and the payloads of IKEv2, creating a flexible EAP method that supports both symmetric and asymmetric authentication, as well as a combination of both. This EAP method offers the security benefits of IKEv2 authentication and key agreement without the goal of establishing IPsec security associations. "LDAP Multi-master Replication Considered Harmful", Kurt Zeilenga, 4-Feb-04, Over the last few years there has been significant development of Lightweight Directory Access Protocol (LDAP) replication mechanisms supporting a multi-master service model. While multi-master replication may be useful in some situations, the deployment of multi-master replication alters the standard LDAP service model in a manner which can be harmful. Specifically, the LDAP service model properties of atomicity, consistency, isolation, and durability (ACID) would be lost. This memo discusses the LDAP service model, how multi-master replication alters the service model, and how this alteration is harmful to existing directory applications. "Establishing Point to Multipoint MPLS TE LSPs", Rahul Aggarwal, 11-Feb-04, This document describes a solution for point to multipoint (P2MP) Traffic Engineering (TE). The objective is to optimize packet replication and minimize state and intelligence in the core of the network, while performing P2MP TE. The solution relies on RSVP-TE in the core of the network. It is based on setting up a P2MP LSP by merging P2P LSPs in the network. The setup of P2P LSPs is source intiated. Simple enhancements are made to RSVP-TE to facilitate the set up of a P2MP TE LSP. There is no need to run a multicast routing protocol in the network core. There can be various applications for P2MP TE LSPs such as multicast. Specification of how such applications will use a P2MP LSP is outside the scope of this document. "Use of SRV records for POP3, POP3S, IMAP and IMAPS.", Gary Bajaj, 19-Mar-04, DNS records for the mail services POP3, POP3S, IMAP and IMAPS do not currently provide failover switching as do the DNS MX records for SMTP. This document looks at the issues involved and recommends a solution using SRV records. "Routing Policy Specification Language next generation (RPSLng)", Larry Blunk, Joao Luis Damas, Florent Parent, Andrei Robachevski, 19-Jul-04, This memo presents a new set of simple extensions to the Routing Policy Specification Language (RPSL) enabling the language to also document routing policies for the IPv6 and multicast address families currently used in the Internet. "Internet Application Protocol Comparator Registry", Chris Newman, 19-Jul-04, Many Internet application protocols include string-based lookup, searching, or sorting operations. However the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function and the repertoire of comparison functions can be extended in the future. "The LDAP Assertion Control", Kurt Zeilenga, 22-Jul-04, This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control which allows a client to specify that a directory operation should only be processed if the assertion when applied to the target entry of the operation. It can be used to construct 'test and set' and 'test and clear' operations. "The LDAP entryUUID operational attribute", Kurt Zeilenga, 4-Feb-04, This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. "EPP parameters for .pl ccTLD", Tomek Zygmuntowicz, 25-Mar-04, This document is a proposed description of the cooperation protocol between NASK and its Partners. The proposal can be replaced with the new document or can be invalidated. The content of this proposal relates to the documents: , , , , RFC 3375 published by Internet Engineering Task Force. "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", Hee Jung, 11-Jun-04, This document addresses Fast Handover over HMIPv6 networks. The MIPv6 mobility could be more enhanced by combining FMIPv6 with HMIPv6, in which MIPv6 is benefited from all the advantages of the respective schemes. An additional benefit by combining FMIPv6 with HMIPv6 is that the overall handover latency in FMIPv6 will be more reduced since in HMIPv6 the MN sends a location update with the local MAP, rather than the HA and CN that are typically further way. This document describes how to use FMIPv6 for HMIPv6 (F-HMIPv6). The F-HMIPv6 is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the tunnel for fast handover is established between MAP and NAR, rather than between PAR and NAR. For this purpose, the MN exchanges the FMIPv6 messages with MAP, not PAR. The F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages. "NFSv4 RDMA and Session Extensions", Thomas Talpey, Spencer Shepler, 16-Feb-04, Extensions are proposed to NFS version 4 which enable it to support sessions, connection management, and operation atop RDMA-capable RPC. These extensions enable universal support for Exactly-once Semantics by NFSv4 servers, enhanced security, and multipathing and trunking of transport connections. These extensions provide identical benefit over both TCP and RDMA connection types. "Redemption Grace Period Mapping for the Extensible Provisioning Protocol", Scott Hollenbeck, 16-Apr-04, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. "BaseStream - A Simple Typed Stream Format", Frans Lundberg, 30-Apr-04, BaseStream is a simple binary stream format that serves as a common base for binary formats like XML (Extensive Markup Language) provides a base for text formats. The binary format consists of typed and possibly named data elements. An instance of the BaseStream format has a corresponding XML representation that makes it possible to use existing XML tools to view, edit, validate, and transform BaseStream data. "OSPF Tunnel Adjacency", Sina Mirtorabi, Peter Psenak, 20-Jul-04, The OSPF specification requires that intra-area paths are always preferred over inter-area paths, regardless of the path's cost. In some situations this can lead to an inefficient usage of network resources. This document describes a solution that helps to address this problem by creating adjacencies through backbone area that belong to non-backbone areas. "Ad Hoc IP Address Autoconfiguration", Jae-Hoon Jeong, 22-Jul-04, This document specifies the steps a node in ad hoc network takes in deciding how to autoconfigure its IPv4 or IPv6 address in network interface. Because the ad hoc IP address autoconfiguration in this document considers ad hoc network's partition and mergence, the address duplication caused by ad hoc network's mergence can be resolved through address resolution protocol. Also, this document specifies how to resolve the address duplication in order to guarantee the maintenance of upper-layer sessions, such as TCP session. "Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks", Christopher Carroll, Frank Quick, 27-Jan-04, The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS AAA Server via a CDMA2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA). "Mobile SCTP for Transport Layer Mobility", Seok Koh, 15-Jun-04, This document discusses the architecture of mobile SCTP (mSCTP) for IP mobility support. The SCTP is the third transport layer protocol next to TCP/UDP. It can also be used for IP mobility from the multi- homing features. The SCTP with the ADDIP extension (or mSCTP) would provide seamless or soft handover for the mobile host without support of routers or agents in the networks. For location management, the mSCTP could be used along with Mobile IP, Session Initiation Protocol or Reliable Server Pooling. "Router Advertisement Link Identification for Mobile IPv6 Movement Detection", Brett Pentland, 22-Jul-04, This document defines a mechanism by which Access Routers on a link may automatically assign a consistent identifier to this link to aid in Movement Detection. This assists Movement Detection by allowing a Mobile Node to rapidly determine whether it has moved to a new link upon reception of a Router Advertisement containing this identifier. "Considerations for DNS Resource Records", Eric Hall, 30-Mar-04, This document discusses some common design considerations for DNS resource records and data models. "Bidirectional Forwarding Detection", Dave Katz, David Ward, Juin-Hwey Chen, 19-May-04, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. "Extensions to IS-IS for Advertising Optional Router Capabilities", Acee Lindem, 11-Feb-04, It is useful for routers in an IS-IS domain to know of the capabilities of their neighbors, and/or of other routers in the domain. This draft proposes extensions to IS-IS for advertising optional router capabilities. In particular it defines an optional Router Capability TLV for IS-IS. "Operational Security Requirements for IP Network Infrastructure", George Jones, 23-Apr-04, This document defines a list of operational security requirements for the infrastructure of large ISP IP networks (routers and switches). A framework is defined for specifying 'profiles', which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. "The Continuous Media Markup Language (CMML), Version 2.0", Silvia Pfeiffer, Craig Parker, 13-Jan-04, This specification defines the Continuous Media Markup Language (CMML), version 2.0, an XML-based [1] markup language for time-continuous data. It is a sister document to the specification of the Annodex [12] annotation, indexing and hyperlinking format for time-continuous data. Its tags provide for the creation of structured and unstructured annotations as well as hyperlinks and addressable named anchor points for clips of time-continuous data. As well as enabling the creation and storage of such meta data in XML files, the CMML is an authoring language for Annodex [12] streams through its import tags. The tag names in use in CMML are similar to the ones in XHTML [3]. At this point in time, the right to produce derivative works is not granted to the IETF as the authors are uncertain about the necessity to create a working group. The specification is not encumbered by patents. The Annodex format is protected by a trade mark to prevent the use of the term 'Annodex' for any related but non-conformant and therefore non-interoperable technology. Conformant technology is encouraged to use the term 'Annodex' when refering to the file format. Notice the change to CMML 2.0 from the previous version of this Internet-Draft, replacing CMML 1.0. "Multicast Listener Discovery Authentication protocol (MLDA)", Tsunemasa Hayashi, 4-May-04, This memo documents a multicast CDN (Content Delivery Network) issues, and describes requirement and discussion points when we solve them. Here, we need a method of precise user accounting (logging) of a user activity to a multicast group and of user access control to a multicast group to protect to subscribe from an illegal access. In this case, it is needed to authorize a user access to a multicast group on the CDN, and to get information of user action (Join/Leave) to a multicast group. The key is how a control process of group membership synchronizes with an AAA process (authentication, authorization and accounting), because we can get a user access information at an AAA server. This depends on the network model of the multicast CDN service. Last of all, we introduce an example of solution MLDA (Multicast Listener Discovery Authentication protocol). "Teredo: Tunneling IPv6 over UDP through NATs", Christian Huitema, 14-Jun-04, We propose here a service that enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays"; the Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet; the relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". "The Annodex annotation format for time-continuous bitstreams, Version 2.0", Silvia Pfeiffer, Craig Parker, 13-Jan-04, This specification defines a file format for annotating and indexing time-continuous bitstreams for the World Wide Web. The format has been named 'Annodex' for annotating and indexing. The Annodex format enables the specification of named anchor points in time-continuous bitstreams together with textual annotations and hyperlinks in URI [4] format. These anchor points are merged time-synchronously with the time-continuous bitstreams when authoring a file in Annodex format. The ultimate aim of the Annodex format is to enable an integration of time-continous bitstreams into the browsing and searching functionality of the World Wide Web. At this point in time, the right to produce derivative works is not granted to the IETF as the authors are uncertain about the necessity to create a working group. The specification is not encumbered by patents. The Annodex format is protected by a trade mark to prevent the use of the term 'Annodex' for any related but non-conformant and therefore non-interoperable technology. Conformant technology is encouraged to use the term 'Annodex' when refering to the file format. Notice the change to Annodex 2.0 from the previous version of this Internet-Draft, replacing Annodex 1.0. "Alternative Decision Making Processes for Consensus-blocked Decisions in the IETF", Ted Hardie, 28-Apr-04, This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot come to consensus on the decision itself. This document describes alternative mechanisms which can be used to come to a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools which can be used when required. "Avoid BGP Best Path Transition from One External to Another", Enke Chen, Srihari Sangli, 19-Jan-04, In this document we propose an algorithm that would help improve the overall network stability by avoiding BGP best path transition from one external to another (under certain conditions) "Implementing Bridged Line Appearances (BLA) Using Session Initiation Protocol (SIP)", Anand Kumar, V Venkataramanan, 10-Mar-04, This document describes a proposal for implementing Bridged Line Appearance for SIP phones. "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", Jae-Hoon Jeong, 16-Feb-04, This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router relays the prefix of its Care-of address to its mobile nodes by playing the role of ND-proxy. Through binding updates associated with the network prefix of an access network, the mobile nodes can perform route optimization. In addition, this document explains how mobile nodes can optimize its DNS name resolution through RA-based DNS discovery. By announcing the address of local recursive DNS server, mobile router allows mobile nodes to optimize their DNS name resolution. "Real-time Certificate Status Facility for CMS - (RTCS)", Peter Gutmann, 9-Apr-04, This document describes how the Cryptographic Message Syntax may be used for communicating certificate status information in a manner suitable for use with CMS data and CMS-related messaging mechanisms such as S/MIME. "WHOIS Protocol Specification", Leslie Daigle, 1-Apr-04, This document updates the specification of the WHOIS protocol, thereby obsoleting RFC954 [1]. The update is intended to remove the material from RFC954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC954. "History of the IEEE 802/IETF Relationship", Les Bell, Dan Romascanu, Bernard Aboba, 9-Jan-04, Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and AAA applications. This document describes the history of that cooperation, and the policies and procedures that have developed in order to coordinate between the two organizations. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", Vesa Torvinen, Jari Arkko, Mats Naslund, 2-Sep-03, HTTP Digest is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exist not just with HTTP Digest but also with other IETF protocols that use tunneled authentication. This document defines version 2 of the HTTP Digest AKA algorithm. This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. "Bridge-like Neighbor Discovery Proxies (ND Proxy)", Dave Thaler, Mohit Talwar, 17-Feb-04, Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. "End-Host Mobility and Multi-Homing with Host Identity Protocol", Pekka Nikander, 14-Jul-04, This document specifies end-host mobility and multi-homing mechanisms for the Host Identity Protocol. "P2P CHAT - A Peer-to-Peer Chat Protocol", Frank Strauss, Sherrie Schmidt, 9-Jul-04, This memo presents a protocol for a peer-to-peer based chat system. Messages can be cryptographically signed and encrypted allowing authentic and closed group communication. This work is the output of a practical course on distributed systems at the Technical University of Braunschweig. It is experimental work that is not intended to go to the IETF standards track. "Registration of Internationalized Domain Names: Overview and Method", John Klensin, 6-Jul-04, IETF has introduced standards-track mechanisms to enable the use of 'internationalized, i.e., non-ASCII, names in the DNS and applications that use it. This has led, in turn, to concerns that characters with similar meanings or appearance could cause user confusion and opportunities for deliberate deception and fraud. Part of this problem can be addressed by limiting, on a per-zone (or per-registry) basis, the specific characters that can be used to be a subset of the list allowed by the standard and by creating 'reservations' of labels that might create confusion with those that are permitted. The model for doing this for languages that use characters that originated with Chinese has been extensively developed in another document. This document discusses some of the issues in that design and relates them to considerations and mechanisms that might be appropriate for other languages and scripts, especially those involving alphabetic characters. "Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option", Steven Legg, 16-Jun-04, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e. data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, which can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. "Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options", Steven Legg, 16-Jun-04, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e. data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document introduces a new category of attribute options, called transfer encoding options, which can be used to specify that the associated attribute values are encoded according to one of these other methods. "MCOP operation for first hop routers", Rami Lehtonen, 15-Jun-04, This draft defines Multicast Control Protocol (MCOP) operation for first hop routers. In this context, MCOP may be used as a tool for multicast network management. MCOP provides multicast network remote management with centralized information database located at Multicast Control Server (MCS). It allows gradual, group and network specific multicast network deployment. The control is done by MCOP enabled first hop routers, Multicast Control Clients (MCC), based on the information received from the MCS. MCC can filter IGMP/MLD reports and multicast packets before they reach the IGMP/MLD processing layer or multicast routing stack of the router. MCOP is independent of multicast routing protocols. "Multicast Control Protocol (MCOP) over COPS", Heikki Vatiainen, 15-Jun-04, This document defines a COPS Client-Type for Multicast Control Protocol (MCOP) and the encapsulation for transmitting MCOP messages over COPS. The document also defines message formats when MCOP over COPS is used for MCOP operation for first hop routers. "Internet Message Access Protocol (IMAP) - URLAUTH Extension", Mark Crispin, Chris Newman, 29-Jun-04, This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can create 'signed' URLs which can be used to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of 'URLAUTH'. "iSeries Telnet Enhancements", Thomas Murphy, 21-May-04, This draft describes the interface to the IBM iSeries Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described. By allowing a Telnet client to select the device name, the iSeries Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are 1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing, 2) connecting PC and network printers as clients and 3) auto-signon using clear-text, DES/SHA encrypted passphrase exchange. Applications may need to use system API's on the iSeries in order to xtract Telnet session settings from the device name description. Refer to the Retrieve Device Description (QDCRDEVD) API described in the iSeries System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates. This draft describes how the IBM iSeries Telnet server supports Work Station Function (WSF) printers using iSeries Display Station Pass- Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. "IPv6 Transition/Co-existence Security Considerations", Pekka Savola, 18-Feb-04, The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6 grouped in three categories: issues due to IPv6 protocol itself, issues due to transition mechanisms, and issues due to IPv6 deployment. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy Manipulation", Petri Koskelainen, Hisham Khartabil, 5-Feb-04, This document describes conference policy data elements and the mechanisms to manipulate them at a server via Conference Policy Control Protocol (CPCP). Extensible Markup Language (XML) Configuration Access Protocol (XCAP) is used to implement CPCP. This document specifies an XML Schema and XCAP application usage that are needed to implement CPCP. "RTP Payload Format for 3GPP Timed Text", Jose Rey, 5-Feb-04, This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is time-lined decorated text media format based on the ISO (International Standardisation Organisation) Base Media File Format. As of today, 3GPP timed text contents can be downloaded via HTTP and synchronised with audio/video contents. There is however no available mechanism for streaming 3GPP timed text. In the following sections the problems of streaming timed text are addressed and a payload format for streaming 3GPP timed text over RTP is specified. "Configuration Guidelines for DiffServ Service Classes", Fred Baker, 8-Jul-04, This paper summarizes the recommended correlation between service classes and their usage, with references to their corresponding recommended Differentiated Service Code Points (DSCP), traffic conditioners, Per-Hop Behaviors (PHB) and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioner PHBs and AQM be used for a certain service class, but as a policy it is useful that they be applied consistently across the network. "NFS RDMA Problem Statement", Thomas Talpey, 12-Feb-04, This draft addresses applying Remote Direct Memory Access to the NFS protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other sources. The potential benefits of RDMA to these implementations are explored, and the reasons why RDMA is especially well-suited to NFS and network file protocols in general are evaluated. "RTCP Summary Report Delivery to SIP Third Parties", Alan Johnston, 20-Jul-04, This document discusses the motivation and requirements for the delivery of RTCP extended reports and other summary reports to non-participants in the session. Several solution mechanisms are also discussed and compared. "Optical Transport Network Failure Recovery Requirements", Richard Rabbat, 2-Feb-04, This document focuses on requirements for control-plane based recovery from data-plane failures in optical transport networks that use an IP-based (GMPLS) control plane. It aims to gather and systematically lay out the requirements so that they can serve as a coherent basis for work on solution and protocol enhancements and developments. "REFER extensions", Sean Olson, 21-Jul-04, The REFER extensions presented in this draft are usage of Feature parameters with REFER and the ability to suppress an implicit subscription with REFER. The extensions have been discussed in SIPPING WG and are targeted to become SIP WG items. "Message Composition", Chris Newman, 11-Feb-04, The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. The chunking extension provides a way for a client to compose a message for submission from a series of client provided pieces. This specification further extends the chunking facility so that a client can compose a message from additional sources. For example, a client could use this facility to forward a message from an IMAP server or forward a web page as an attachment to a new message. "Secure Origin BGP (soBGP) Certificates", Brian Weis, 14-Jul-04, This document describes the format of digital certificates that are used by the Secure Origin BGP (soBGP) extensions to BGP, as well as acceptable use of those certificates. Included are certificates providing authentication, authorization, and policy distribution. "LDAP Read Entry Controls", Kurt Zeilenga, 17-Feb-04, This specification describes controls which can be attached to a Lightweight Directory Access Protocol (LDAP) update request to obtain copies of the target entry before and/or after the requested update is applied. "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", K. Lee, 18-Feb-04, This document describes how to support Route Optimization for Mobile Nodes in IPv6 Mobile Network. The support is provided by Prefix Delegation. Mobile Router gets a prefix from an access router using Prefix Delegation protocol and advertises the delegated prefix to its subnet. Each Mobile Nodes makes its care-of address from the prefix and performs binding update. It allows the Mobile Nodes to communicate with Correspondent Nodes directly, avoiding ingress filtering. "Threat Analysis on NEMO Basic Operations", Souhwan Jung, 21-Jul-04, This document describes potential security threats to NEMO basic operations. The threats are mostly related to the integral use of IPsec and IP-in-IP tunnel between MR and HA. Other threats related to the operations of multiple MRs, and potential DoS attacks on MR and HA are also investigated. "GXcast: Generalized Explicit Multicast Routing Protocol", Ali Boudani, 31-Mar-04, Recently several multicast mechanisms were proposed that scale better with the number of multicast groups than traditional multicast does. These proposals are known as small group multicast (SGM) or explicit multicast (Xcast). Explicit multicast protocols, such as the Xcast protocol, encode the list of group members in the Xcast header of every packet. If the number of members in a group increases, routers may need to fragment an Xcast packet. Fragmented packets may not be identified as Xcast packets by routers. In this paper, we show that the Xcast protocol does not support the IP fragmentation and we show also that avoiding fragmentation induces hard-coded limits inside the protocol itself in terms of group size. First, we describe the Xcast protocol, the Xcast+ protocol (which is an extension of Xcast) and we compare these two protocols with traditional multicast protocols.We propose then a generalized version of the Xcast protocol, called GXcast, intended to permit the Xcast packets fragmentation and to support the increasing in the number of members in a multicast group. "IPv6 Address Assingment and Route Selection for End-to-End Multihoming", Kenji Ohira, 20-Jul-04, In this document, we propose a way of address assignment and route selection suitable for "Host-Centric" multihoming, where an end node plays the main role of multihoming. "Recommendations for using MIME body parts in SIP", Cullen Jennings, 20-Jul-04, This document describes conventions for using MIME body parts in SIP messages. It uses a transport encoding of 'binary' since SIP messages are always passed over an 8bit clean transport. "Media Objects Markup Language (MOML)", Tim Melanchuk, Garland Sharratt, 16-Feb-04, The Media Objects Markup Language (MOML) is used to define media processing objects which execute on media servers. It defines a set of primitive media objects (called primitives) and provides tools to group primitives together and specify how they interact with each other. Clients use MOML to create precisely tailored media processing objects which may be used as parts of application interactions with users or conferences or to transform media flowing internal to a media server. IVR is an example of an application interaction with a user. "Media Sessions Markup Language (MSML)", Tim Melanchuk, Garland Sharratt, 16-Feb-04, The Media Sessions Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. Clients can use it define how media sessions interact on a media server and to apply services to individual or groups of users. MSML can be used, for example, to control media server advanced conferencing features, create sidebars, and insert media processing objects into media streams. As well, clients can use it with other languages such as the Media Objects Markup Language (MOML) or VoiceXML to interact with individual users or with groups of conference participants. "The Calling Party's Category tel URI Parameter", Rohan Mahy, 18-Feb-04, This document specifies a new parameter for the tel URI that represents the Calling Party's Category, a parameter used in SS7 ISUP signaling. "Benchmarking Methodology for MPLS Protection Mechanisms", Scott Poretsky, 20-Jul-04, This draft describes the methodology for benchmarking MPLS protection mechanisms. An overview of existing MPLS Protection terminology and functionality is provided as as background for the methodology. The methodology can be applied to any MPLS Protection mechanism such as Headend Reroute, Standby LSP, Fast Reroute Detour Mode, and Fast Reroute Bypass Mode. The data plane is measured to obtain the benchmarking metrics. Discussion is included to explain the differences between MPLS Protection mechanisms, the network events that cause failover, and the benefits of measuring the data plane for black-box MPLS Protection benchmarking. Measurements can be used to compare failover performance of different Label-Switched Routers and evaluate the different MPLS protection mechanisms. "Two Stage Standardization Approach", Spencer Dawkins, Charles Perkins, Dave Crocker, 21-May-04, RFC 2026 specifies a three-stage Standards Track. As currently practiced, IETF standards track documents typically attain only the first stage. This proposal discusses the problems caused by the disparity between documented procedures and actual practice, and proposes a two-step standard track. "Media Policy Manipulation in the Conference Policy Control Protocol", Rohan Mahy, Nermeen Ismail, 18-Feb-04, The SIP conferencing framework defines a model for tightly-coupled conferencing signaled via the Session Initiation Protocol (SIP), in which a Conference Policy Control Protocol is used to manipulate policies relevant to a specific conference, such as conference membership policy, authorization policy, and media layout. This document describes a logical model, which can apply to any session setup protocol, to describe media processing in a tightly-coupled conference. It also defines specific protocol semantics and a specific syntax to manipulate that model. "Address Resolution for IP datagrams over MPEG-2 networks", Gorry Fairhurst, Marie-Jose Montpetit, 15-Jul-04, This document describes mechanisms to bind IPv4/IPv6 addresses and flows to MPEG-2 Transport Streams (TS). While methods currently exist to perform these bindings, for MPEG-2 systems to become true subnetworks of the general Internet, protocols are required to signal IPv4/v6 addresses to the link receivers and transmitters. This is known as Address Resolution (AR), or Neighbour Discovery (ND). Although AR is often associated with Ethernet [RFC803], it is essential to the operation of any L2 network. MPEG-2 transmission networks often utilize broadcast media (e.g. satellite or cable) where the mapping may take into account issues related to network operations and traffic engineering. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and specific transmission multiplex. Address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In this document the different mechanisms used for address resolution for MPEG-2 are reviewed and guidelines for future developments of efficient schemes are given. "Resource Mapping for GMPLS with Heterogeneous Interfaces", Jun Choi, 18-Feb-04, The new forms of label used in GMPLS to deal with the widening scope of MPLS into the optical and time domain are collectively referred to as a 'Generalized Label' related to resource. In this draft, we describe the relationship of labels and resources. We also describe the resource mapping methods for GMPLS with heterogeneous interfaces. Particularly we present the methods for resource mapping at incoming and outgoing switching interface where data flows with label of a different granularity are aggregated into the data flow of large bandwidth. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, 16-Feb-04, One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router (MR) for use on the links in the mobile network. DHCPv6 prefix delegation can be used for this configuration task. "End-to-middle security in the Session Initiation Protocol(SIP)", Kinji Ono, Shinya Tachimoto, 17-May-04, Some services provided the intermediaries depend on the ability to inspect the message bodies in the Session Initiation Protocol (SIP). When sensitive information is included in them, a SIP User Agent needs to protect it from all intermediaries except the certain selected intermediaries. This document proposes a mechanism for securing information passed between an end user and a selected intermediary using S/MIME. This also proposes a mechanism for the discovery of an intermediary that needs to inspect an S/MIME-secured message body. "Signaling Extension for the End-to-End Restoration with SRLG", Jun Choi, 18-Feb-04, This draft describes the concept of the SRLG-based logical ring configuration and recovery method using the ring-SRLG for the purpose of restoration in mesh networks. In this restoration architecture, backup paths can be easily established through the end-to-end path, which follows the logical ring configuration. It guarantees the establishment of backup path disjointed from the working path. We also propose the GMPLS signaling extension for the end-to-end restoration based on the SRLG-based logical ring configuration. "GMPLS Extensions to support Multi-Granularity Optical Cross-Connect with Heterogeneous Optical Interfaces", David Kim, 16-Feb-04, This document defines information needed when GMPLS signaling is used on the multi-granularity of optical cross-connect (MG-OXC) over Generalized Multiprotocol Label Switching (GMPLS) networks because existing documents deal only with singular wavelength OXC. The basic optical label handlings (including add, drop, swap, merge, and stack) are required for using the MG-OXC in GMPLS networks. Also the protocol related to signaling is extended for supporting the MG-OXC. "Memorandum for multi-domain Public Key Infrastructure (PKI) Interoperability", Masaki SHIMAOKA, 8-Jul-04, This memo is used to share the awareness necessary to deployment of multi-domain PKI. Scope of this memo is to establish and clear the trust relationship and interoperability between plural PKI domains. Both single-domain PKI and multi-domain PKI are established by the trust relationships between Certification Authorities (CAs). Typical and primitive PKI models are specified as single-domain PKI. Multi- domain PKI established by plural single-domain PKI is categorized as multi-trust point model and single-trust point model. Multi-trust point model is based on trust list model, and single-trust point model is based on cross-certification model. "Extra class LSP service using protecting resources in GMPLS networks", Katsuhiro Shimano, 16-Feb-04, This document provides the problem statement on a extra class LSP ser- vice and addresses the issues. The extra class LSP uses the resource reserved but not allocated for the protecting LSPs in the pre-planned LSP re-routing without extra-traffic (including shared mesh) recovery method. Network utilization is improved because the resource reserved for the protecting LSPs are used for the extra class LSPs. The extra class LSP is preempted less frequently than the conventional priority mechanism using setup and holding priorities because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. This document pro- poses the extra class LSP service using the resource reserved but not allocated for the protecting LSP at the provisioning phase. This docu- ment addresses the issues on the extra class LSP: (1) advertisement of available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended connections. "Addition of GOST Ciphersuites to Transport Layer Security (TLS)", Grigorij Chudov, Serguei Leontiev, 1-Apr-04, This document is intended to register new cipher suites for the Transport Layer Security (TLS) protocol, according to the procedure specified in section A.5 of [TLS], and to register a new TLS extension, according to section 5 of [TLSEXT]. Those cipher suites are based on Russian national cryptographic standards - key derivation algorithms based on GOST R 3410-94 and GOST R 3410-2001 public keys, GOST 28147-89 encryption algorithm and GOST R 34.11-94 digest algorithm. "Requirements for transport of video control commands", Andrea Basso, Orit Levin, Nermeen Ismail, 20-Jul-04, A variety of video communication services such as video conferencing and video messaging rely on the capability of video encoders and decoders to exchange control commands. This document outlines this set of commands as well as the requirements for their transport. "iSCSI Extensions for RDMA Specification", Mike Ko, 15-Jul-04, iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI [iSCSI] by layering iSCSI on top of the Remote Direct Memory Access Protocol (RDMAP). The iWARP protocol suite provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as defined by the iWARP protocol suite. "Filters for Mobile IPv6 Bindings (NOMADv6)", Koojana Kuladinithi, 3-Jun-04, Filters for Mobile IPv6 Bindings (NOMADv6) introduces a set of extensions for MIPv6 protocol that allows the intelligent use of multiple points of attachment simultaneously, on a mobile node. It specifies a set of rules (filters) that are transmitted to binding agents, who in turn use this information to determine whether and where to route flows associated with the mobile node. In this manner, it is possible for a mobile node to distribute flows or packets of a flow among its available points of attachment or to request that such flow is dropped before traversing the Internet fabric, with or without notification to their source. These extensions mirror a similar extension defined for Mobile IPv4 (NOMADv4) but has been extended to cater to the behavior of IPv6. "A No Soliciting SMTP Service Extension", Carl Malamud, 22-Mar-04, This Internet-Draft proposes an extension to SMTP for an electronic mail equivalent to the real-world 'No Soliciting' sign. In addition to the service extension, a new message header and extensions to the existing 'received' message header are described. "A URN Namespace for the TV-Anytime Forum", Wataru KAMEYAMA, 23-Apr-04, This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Thomas Schmidt, Matthias Waehlisch, 12-Feb-04, This document introduces handover mechanisms for mobile IPv6 multicast listeners and mobile multicast senders. Operations are based on a Mobile IPv6 environment with local mobility anchor points. These local anchor points are conformal with a Hierarchical Mobile IPv6 infrastructure. Handover latencies in the proposed scheme remain bound to local link switching delay and local IP address updates by means of latency hiding techniques. The mechanisms described in this document may also be used for simple seamless handovers in unicast communication. The M-HMIPv6 protocol operations utilize the existing HMIPv6 and MIPv6 messages, without defining any new control messages. "An Idea for an Alternate IETF Standards Track", Scott Bradner, 26-Mar-04, The discussion in the problem working group reached consensus that the current IETF 3-stage standards track, as implemented, is not working. This is a proposal for an alternate, also 3-stage, standards track that I feel better matches current reality. This is a republication of an ID originally published in June 2003 "ESMTP and LMTP Transmission Types Registration", Chris Newman, 19-Aug-03, This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the 'with' clause of a Received header in an Internet message. "Datamover Architecture for iSCSI (DA)", Mallikarjun Chadalapaka, 20-Jul-04, iSCSI is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. The Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. The new Datamover protocol provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition would help map iSCSI to generic RDMA-capable IP fabrics in the future comprising TCP, SCTP, and possibly other underlying network transport layers. "Home Agent Filtering for Mobile IPv6", Nicolas Montavont, Thomas Noel, 23-Jan-04, Mobile IPv6 allows a MN to receive incoming packets to its home address while it is away from its home network. In a heterogeneous environment, a MN may have multiple interfaces, each with different characteristics. While a MN is in a visited network, due to the performance of the interfaces or to the user preferences, the MN may want to forbid the redirection from its home agent of a kind of flow, or to indicate a target CoA for a kind of flow. In this draft, we propose new mobility options that allow a MN to advertise filters to its home agent. A filter is associated with a CoA, in such a way that the MN can register several CoA and can register several filters for one CoA. A filter may indicate that a flow which maps to a filter must be dropped or must be redirected to the indicated CoA. "Preconfigured DNS Server Addresses", Masataka Ohta, 18-Feb-04, This memo describes how to make addresses of DNS servers preconfigured in clients. Well known anycast addresses, which are assigned to DNS servers, should be preconfigured to resolvers of clients. It is also explained why anycast does not offer redundancy. "Mobility management for Dual stack mobile nodes A Problem Statement", George Tsirtsis, Hesham Soliman, 16-Feb-04, This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how current MIPv4 and MIPv6 could be extended so that they can support mobility management for a dual stack node. "IPv6 DNS Discovery based on Router Advertisement", Jae-Hoon Jeong, 20-Jul-04, This document specifies the steps an IPv6 host takes in deciding how to configure the address of recursive DNS server for DNS name resolution. The way of discovering recursive DNS server is based on Router Advertisement message. "Support of address families in OSPFv3", Sina Mirtorabi, 28-Jan-04, This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. "Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS", Eric Rosen, 11-Mar-04, Certain L2VPN architectures [IPLS, VPLS] rely on there being a full mesh of pseudowires [PWE3-ARCH] among a set of entities. This mesh is used to provide a 'LAN-like' service among the entities. If one or more of these pseudowires is absent, so that there is not really a full mesh, various higher layers (from routing to bridge control protocols) that expect a LAN-like service may fail to work as expected. Therefore it is desirable to have procedures that enable the pseudowire endpoints to determine automatically whether there is really a full mesh or not. It is also desirable to have procedures that cause the L2VPNs to adapt to pseudowire failures. This document proposes a set of procedures to meet these goals. Detailed protocol encodings are not present, but will be added in future versions. "The XML Enabled Directory: Schema Language Integration", Steven Legg, Daniel Prager, 15-Jun-04, This document defines the means by which an Abstract Syntax Notation One (ASN.1) specification can incorporate the definitions of types and elements in specifications written in other Extensible Markup Language (XML) schema languages. References to XML Schema types and elements, RELAX NG named patterns and elements, and Document Type Declaration element types are supported. "The XML Enabled Directory: Schema Operational Attributes", Steven Legg, Daniel Prager, 15-Jun-04, This document defines additional subschema operational attributes for the XML Enabled Directory (XED) that allow user defined attribute syntaxes to be imported into a directory server. User defined syntaxes specified in XML Schema, RELAX NG or Abstract Syntax Notation One (ASN.1), or specified as a document type declaration (DTD), are supported. "ASN.1 Schema: An XML Representation for ASN.1 Specifications", Steven Legg, Daniel Prager, 17-Jun-04, This document defines a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One ASN.1 specifications called ASN.1 Schema. ASN.1 Schema completely avoids the numerous ambiguities inherent in the ASN.1 language, therefore ASN.1 Schema documents are much easier to parse and manage than original ASN.1 specifications. "Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration", P. Jones, 2-Jun-04, This document defines the MIME sub-type audio/t38. The packetization and usage of this MIME type, which is intended for use within SDP, is specified within ITU-T Recommendation T.38. "Requirements for Inter-Domain Routing", Avri Doria, 20-Jul-04, These requirements for routing architectures are the product of two sub-groups with the IRTF Routing Research Group. They represent two individual and separate views of the problem and of what is required to fix the problem. While speaking of requirements, the document is actually a recommendation to anyone who would create a routing architecture for the Internet in the coming years. "Registering Internationalized Domain Names under .PL", Andrzej Bartosiewicz, 13-Apr-04, This document describes rules of Internationalized Domain Name (IDN) registration under .PL - county code top level domain name (ccTLD). All the rules are based on the idea that the Registry registers the ACE (ASCII Compatible Encoding) label version of the IDN instead of IDN's Unicode form. This document also includes the list of accepted Unicode code points for IDN registration uder '.PL' ccTLD. "Late Media in the Session Initiation Protocol", Christian Stredicke, 9-Feb-04, 'Late Media' is presented after a dialog is disconnected or when the dialog is temporarily without media. The 'Late-Media' header indicates under which circumstances late media should be rendered. "Dual Stack Transition Mechanism", Jim Bound, 30-Apr-04, The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant network. Nodes will still need to communicate with IPv4 nodes that do not have a Dual IP layer supporting both IPv4 and IPv6. The Dual IP Layer Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. "Compound Procedures for SPAM Control", Curtis Kularski, 27-Jan-04, This document gives instructions for implementing a mail system that will reduce the amount of SPAM received by the end users. The instructions specify disposable and single-purpose mailboxes that will allow for the source of SPAM to be easily identified. "AMTP - Authenticated Mail Transfer Protocol", William Weinman, 26-Apr-04, This document is the specification of a protocol for Internet electronic mail transfer. It replaces Simple Mail Transfer Protocol (SMTP) with a more secure derivative called Authenticated Mail Transfer Protocol (AMTP). "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, David Ward, 19-May-04, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. It further describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on this draft should be directed to rtg-bfd@ietf.org. "Registration and Administration Guideline for Chinese Domain Names", XiaoDong Lee, 16-Feb-04, Non-ASCII characters are adopted into Internationalized Domain Names (IDN, described in [RFC3490], [RFC3491] and [RFC3492]), so it is possible for users to access Internet with their native languages, which are mostly not English. Many languages have their special requirements which haven't been solved in IDN RFCs, for example, the requirement about Chinese domain names (CDN)' variant equivalence for Chinese users. Chinese variant equivalence itself is very complicated. The basic requirement is that users think Simplified Chinese (SC) domain name is equal to its Traditional Chinese (TC) form, and when they register SC domain names, they do want the Traditional forms, and hope others could access their sites by other forms, and vice versa. Based on [IDNADMIN], this document put forwards a solution for Chinese domain name registration and administration to solve Simplified Chinese and Traditional Chinese domain name equivalence. This solution is suitable for any IDN Zone manage or registrar who provide Chinese domain names service. According to [IDNADMIN], this solution is IDL-based (Internationalized Domain Label). "Requirements for Ad Hoc IP Address Autoconfiguration", Jae-Hoon Jeong, 21-Jul-04, Ad hoc network has no built-in infra-structure for communication among mobile nodes and operates in a stand-alone fashion, or may be connected to the public Internet. All the nodes in ad hoc network have the capability to maintain all the resources of the network in a distributed fashion. One of the most important resources is the set of IP addresses configured with an addressing scheme. When a new node joins a network, it has to be assigned an IP address as part of its initialization. Since ad hoc network's topology may change unpredictably, it is important to provide a resilient method for providing IP address autoconfiguration. This document specifies the requirements for IP address autoconfiguration in ad hoc networks which have dynamic network topology. "Gateway and address autoconfiguration for IPv6 adhoc networks", Christophe Jelger, 23-Apr-04, Adhoc networks are formed by the spontaneous collaboration of wireless nodes when no networking infrastructure is available. When communication to the Internet is desired, one or more nodes must act as gateways for the adhoc network. In this case, global addressing of adhoc nodes is required. This document specifies a protocol (node behaviour, information propagation, message format) which allows nodes in an adhoc network to discover a gateway/prefix pair which is used in order to build an IPv6 global address and, when necessary, to maintain a default route towards the Internet. "Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)", David Black, Keith McCloghrie, Juergen Schoenwaelder, 9-Jul-04, SNMP and the Internet-Standard Management Framework are widely used for management of communication devices, creating needs to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), there is a need for a uniform way to indicate how to contact the device for management. URLs fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols. This document defines a simple URI scheme so that SNMP can be designated as the protocol used for management. This scheme also allows URI specification of individual MIB object instances. "The Session Initiation Protocol Conference Bridge Transcoding Model", Gonzalo Camarillo, 10-Feb-04, This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "Definitions of Early URI Schemes", Paul Hoffman, 20-Apr-04, This document specifies many Uniform Resource Identifier (URI) schemes that were originally specified in RFC 1738 [RFC1738]. Some of these schemes are specified more fully in this document. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the schemes on standards track. "The XML Enabled Directory: Protocols", Steven Legg, Daniel Prager, 24-May-04, This document defines semantically equivalent Extensible Markup Language (XML) renditions of the Lightweight Directory Access Protocol (LDAP) and X.500 directory protocols for use by the XML Enabled Directory (XED). "GSS-APIv2 Extension for Storing Delegated Credentials", Nicolas Williams, 20-May-04, This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. "Two Rate Three Color Marker for Differentiated Services", Osama Aboul-Magd, Sameh Rabie, 7-Oct-03, This document describes a two rate three color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling and guarantee afforded to the in- profile traffic. Furthermore this marker doesn’t impose peak rate shaping requirements on customer edge (CE) devices. "Requirements for Session Initiation Protocol (SIP) Exploder Invocation", Gonzalo Camarillo, 14-May-04, This document describes the need for SIP exploders and provides requirements for their invocation. Additionaly, it defines a framework which includes all the SIP extensions needed to meet these requirements. "XMPP URI Format", Peter Saint-Andre, 12-Apr-04, This document defines a URI scheme for use in addressing entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). "General Router Management Protocol (GRMP) Version 1", Weiming Wang, 4-Jun-04, This document defines the General Router Management Protocol (GRMP) Version 1. This protocol is based on an open programmable router architecture defined in the ForCES requirements and in the ForCES framework. GRMP protocol is designed to meet all the requirements for the ForCES protocol at Fp reference point in the architecture, where the ForCES protocol acts as a base protocol and ForCES FE model as a data model for this protocol. "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", David Mills, 17-Sep-03, This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. SNTP Version 4 clarifies certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868. The only significant protocol change in SNTP Version 4 is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) (RFC-1883) and OSI (RFC-1629) addressing. However, SNTP Version 4 includes an anycast mode and a public-key based authentication scheme designed specifically for broadcast and anycast applications. The authentication scheme extension is described in another RFC. Until a definitive specification is published, these extensions should be considered provisional. In addition, this memo introduces the kiss-o'-death message, which can be used by servers to suppress client requests as circumstances require. This memorandum obsoletes RFC-1769, which describes SNTP Version 3, and RFC-2030, which describes SNTP Version 4. "The 'active' URI scheme", Tony Butterfield, 18-Jun-04, A new URI scheme, "active", is defined. It allows processing results to be referenced uniquely and invariantly by compounding their dependencies into a URI. "BUB: Binding Update Backhauling", Wassim Haddad, 14-Feb-04, Mobile IPv6 [1] defines two different modes to handle the mobility problem (i.e., mobile node moving accross different networks and changing its IP address). The two modes had been mainly designed for scenarios involving one mobile node and one static node (correspondent node). This document answers issues related to scenarios involving two mobile nodes (i.e., the correspodent node is also a mobile node). The document addresses also the double jumping problem where two mobile nodes move at the same time (i.e., switch to new subnets). The document proposes a new mode called 'BUB' (Binding Update Backhauling) allowing a more secure, reliable and optimized exchange of Binding Updates (BUs) between two mobile endpoints. "PRIVATE VLANS: Addressing vlan scalability and security issues in a multi-client environment", Sanjib HomChaudhuri, Marco Foschiano, 18-Jun-04, This document describes the concept of layer 2 isolation among devices that are members of the same layer 2 domain. A vlan is a layer 2 broadcast domain in which all devices can establish direct communication with one another at layer 2. As a consequence, devices that are connected to the same vlan have an implicit trust relationship with each other. If 'untrusted' devices are introduced into a vlan, security issues may arise because trusted and untrusted devices end up sharing the same broadcast domain. The traditional solution to this kind of problem is to assign a separate vlan to each device that is concerned about layer 2 security issues. That however is not a scalable solution. The mechanism proposed in this document can offer total layer 2 isolation between devices connected to the same vlan. What that means is that, on the one hand, each customer will enjoy the benefits that come with a separate dedicated vlan, while on the other hand the service provider will enjoy the benefit of consuming as few as two vlan identifiers. "The 'info' URI Scheme for Information Assets with Identifiers in Public Namespaces", Herbert Van de Sompel, 13-Jul-04, This document defines the 'info' Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the 'info' URI scheme are regulated by an 'info' Registry mechanism. "Peer Prefix Limits Exchange in BGP", Vasile Radoaca, Mo Miri, Luyuan Fang, Susan Hares, Srikanth Chavali, 29-Apr-04, This document proposes a mechanism to allow BGP peers to coordinate the setting of a limit on the number of prefixes which one BGP speaker will send to its peer. Coordination can prevent disruption of the peering session or discarding of routes, which can occur when a maximum prefix limit is configured on the 'receiving' peer, and the 'sending' peer exceeds the limit. "The TV-Anytime Content Reference Identifier (CRID) Uniform Resource Locator", Nigel Earnshaw, 21-Oct-03, The Uniform Resource Locator (URL) scheme 'CRID:' has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms including the Internet. "Peer-to-Peer communication across Middleboxes", Bryan Ford, Pyda Srisuresh, Dan Kegel, 14-Jun-04, This memo documents the methods used by the current peer-to-peer (P2P) applications to communicate in the presence of network address translators (NAT). In addition, the memo suggests guidelines to application designers and NAT implementers on the measures they could take to enable immediate, wide deployment of P2P applications with or without requiring the use of special proxy, relay or midcom protocols. "Uniform Resource Locator Schemes for Internet Relay Chat Entities", Simon Butcher, 27-Jan-04, This document specifies two URL (Uniform Resource Locator) schemes, using the URI (Uniform Resource Indicator) names 'irc' and 'ircs', for the location of IRC (Internet Relay Chat) servers. These URLs allow for easy location of an IRC server, optionally also specifying an IRC channel to join, or a person's nickname to contact upon connection. "IPv6 DAD Optimization Goals and Requirements", Soohong Park, Youn-Hee Han, 7-Jun-04, In order to generate a unique address, IPv6 nodes perform the Duplicate Address Detection (DAD) procedure. Payload packets can not be sent or received before this procedure is complete. In an environment where frequent movements are expected, this delay can be problematic. As the reduction or removal of the delay would be useful, an optimized version of DAD has been proposed. This document suggests the requirements for such "Optimized DAD" protocol as well as considerable solutions. "Network Discovery and Selection within the EAP Framework", Farid Adrangi, 12-Mar-04, This document proposes a solution for Service Network discovery and selection that could be implemented within the existing EAP specification framework. The purpose of Service Network discovery and selection here is to help a WLAN client using EAP for authentication to decide whether or not to connect to a WLAN Access Network, and help it select the most appropriate Mediating Network as a next hop for routing AAA packets in roaming situations where the WLAN Access Network has agreements with more than one Mediating Network affiliated with the client’s Home Service Network. The proposed solution has 3 components: a delivery mechanism for conveying Access Network and Service Network Information to a WLAN client, a data model/syntax for structuring the information in a generic manner, and a method by which the WLAN client can indicate its selection to the WLAN Access Network. "Optimizing Mobile IPv6 (OMIPv6)", Wassim Haddad, Suresh Krishnan, 16-Feb-04, Mobile IPv6 protocol introduced the route optimization mode to allow a direct exchange of data packets between the mobile node (MN) and the correspondent node (CN). This memo is a proposal to optimize the Mobile IPv6 solution, by reducing the handoff latency and the number of signaling messages. "Deflate transmission mode for FTP", Jeff Preston, Tim Saunders, 2-Jun-04, This document defines an optional extension to RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 1985). It specifies a new 'deflate' transmission mode designed to increase network bandwidth by compressing data using existing techniques. "Internationalization of Email Addresses", John Klensin, 29-Jan-04, Internationalization of electronic mail addresses is, if anything, more important than the already-completed effort for domain names. In most of the contexts in which they are used, domain names can be hidden within or as part of various types of references. Email addresses, by contrast, are crucial: use of names of people or organizations as, or as part of, the email local part is, for obvious reasons, a well-established tradition on the network. Preventing people from spelling their names correctly is, in the long term, inexcusable. At the same time, email addresses pose a number of special problems -- they are more difficult than simple domain names in some respects, but actually easier in others. This document discusses the issues with internationalization of email addresses, explains why some obvious approaches are incompatible with the definitions and use of Internet mail, and proposes a solution that is likely to serve users and the network well for the long term. "A Session-Based Security Model (SBSM) for version 3 of the Simple Network Management Protocol (SNMPv3)", David Perkins, Wesley Hardaker, 20-Jul-04, This document describes a Session Based Security Model (SBSM) for use within version 3 of the Simple Network Management Protocol (SNMPv3). The security model is designed to establish a "session" between two interacting SNMPv3 entities, over which SNMP operations can be sent securely. It provides a number of security properties not previously available in defined SNMPv3 security models, such as public key based identity authentication, limited life-time keying, and the ability to make use of previously implemented and deployed security infrastructures for purposes of identification and authentication. "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", Adam Costello, 15-Apr-04, Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. "Preparation of Internationalized Strings ('stringprep')", Paul Hoffman, Marc Blanchet, 14-Apr-04, This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. "LDP signaled LSPs for external prefixes", Luyuan Fang, Ina Minei, Nischal Sheth, 26-Mar-04, In order to create forwarding state for a FEC received from a downstream LSR, LDP requires the presence of a matching entry in the routing table. This document describes a mechanism that allows the creation of LDP signaled LSPs for prefixes which are not present in the routing table. This draft is applicable to address prefix FECs and host FECs associated with either IPv4 or IPv6 prefixes. "Internationalizing Domain Names in Applications (IDNA)", Patrik Faltstrom, Paul Hoffman, Adam Costello, 14-Apr-04, Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so- called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. "IS-IS TE Procedures for Learning Local Addresses", Rahul Aggarwal, Nischal Sheth, 21-Jul-04, This document describes procedures that enable a router to populate its Traffic Engineering Database (TED), with local addresses of other routers, that are not advertised in IS-IS TE extensions. The only addresses belonging to a router that are advertised in IS-IS TE LSAs are the router's local addresses on links enabled for TE and the Router ID. The described procedures enable a router to compute traffic engineered MPLS LSPs to a given router's loopback and non-TE capable interface addresses. "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", Paul Hoffman, Marc Blanchet, 14-Apr-04, This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). "A Bound End-to-End Tunnel (BEET) mode for ESP", Pekka Nikander, 1-Jul-04, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "An information model for Kerberos version 5", Leif Johansson, 19-Jul-04, This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, 20-Jul-04, Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. "IMAP Extension for SASL Initial Client Response", Robert Siemborski, 13-Apr-04, To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. "SMTP Service Extension for Authentication", Robert Siemborski, 13-Apr-04, This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554 and replaces it as a Proposed Standard. "POP3 SASL Authentication Mechanism", Robert Siemborski, 13-Apr-04, This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. In order to consolidate all of the authentication related information for POP3 into a single document, this document obsoletes RFC 1734 and RFC 3206, replacing them as a Proposed Standard. It also updates information contained in Section 6.3 and Section 8 of RFC 2449. "Requirements for MPLS over GMPLS-based Optical Networks (MPLS over GMPLS)", Xu Shao, 13-May-04, MPLS over GMPLS-based optical networks (MPLS over GMPLS) is a subset of IP over optical networks. To be more specific, in this draft it refers to the technology of interconnection between MPLS networks and GMPLS-based optical networks with an overlay model or an interdomain model. It is an important milestone in the evolutionary roadmap from IP over static WDM to a peer model of network interconnections. The most significant feature of the requirements for MPLS over GMPLS is a much more dynamic interface between the two layers. The draft discusses the evolutionary roadmap of IP over optical networks and then highlights the significance of the concept of MPLS over GMPLS. Some new requirements will be identified, including multi-lightpath connections, MPLS network topology dynamic changes and dynamic traffic grooming and so on. It is these requirements that bring some challenges to the present routing, signaling and UNI protocols. "Transport Layer Security Protocol Compression Using LZS", Robert Friend, 7-Jun-04, The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. "Examples of basic Nemo usage", Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli, 16-Feb-04, This paper documents some practical scenarios and the associated issues when deploying Mobile Routers, conforming the Nemo Basic Support draft [6]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the Nemo and Nemo Design mailing lists. "NSIS Transport Layer Protocol Considerations and Implementation", Thanh Luu, 24-May-04, The working group NSIS (Next Step In Signaling) is created to define a new signaling protocol. This signaling protocol will be generic and applicable to the most of present and future signaling applications. Some of these signaling applications are resource reservation, communication protocol for middlebox, VPN, etc. The intention of NSIS is to re-use, where appropriate, the protocol mechanisms of RSVP while at the same time simplifying it and applying a more general signaling model. NSIS signaling protocol is composed of two layers. NTLP (NSIS Transport Layer Protocol) layer is responsible for transporting signaling messages. NSLP (NSIS Signaling Layer Protocol) is the upper layer that contains functionality such as message formats and sequences, specific to a particular signaling application. NSIS signaling protocol is composed of two layers. NTLP (NSIS Transport Layer Protocol) layer is responsible for transporting signaling messages. NSLP (NSIS Signaling Layer Protocol) is the upper layer which contains functionality such as message formats and sequences, specific to a particular signaling application. This document outlines the proposal of implementation for NTLP which can satisfy the requirements defined in the NSIS working group. "Virtual Broadband Access Server Protocol for communicating between BAS and IP-DSLAM", Abel Wang, Wenxiu Xu, Yanqing Lu, Lei Cao, Rong Zhang, Tao Zhang, 15-Apr-04, The virtual broadband access server (VBAS) protocol looks BAS and IP-DSLAM as a whole and provides an applicable method for communicating between BAS and IP-DSLAM. This document describes a communication process, which is added in the existing access control modes. It also describes how to encapsulate VBAS packets over Ethernet. "PWE3 Congestion Control Framework", Eric Rosen, Stewart Bryant, Bruce Davie, 12-May-04, Insofar as pseudowires may be used to carry non-TCP data flows, it is necessary to provide pseudowire-specific congestion control procedures. These procedures should ensure that pseudowire traffic is 'TCP-compatible', as defined in RFC 2914. This document attempts to lay out the issues which must be considered when defining such procedures. "Trusted Transitive Introduction Model", Max Pritikin, 19-Jul-04, We describe the 'out-of-band' exchange of data in a classical enrollment protocol as a Trusted Transitive Introduction (TTI) between two end entities and an introducer, thus distinguishing introduction from enrollment. This document describes the three system entities in the trusted transitive introduction model and the data exchanges between them. Three introduction stages are defined and examined in the context of a 'TTI over HTTP' introduction. "Real-Time Transport Protocol (RTP) Payload and File Storage Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec", Sassan Ahmadi, 18-May-04, This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of VMR-WB speech data in storage mode applications such as email. A MIME type registration is included, for VMR-WB, specifying use of both the RTP payload and the storage formats that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. "GMPLS - Communication of Alarm Information", Lou Berger, 2-Feb-04, This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. "Link-layer Hints for Detecting Network Attachments", Alper Yegin, 18-Feb-04, Certain link-layer technologies are capable of providing various link status information to the IP module. Link-layer event notifications (triggers) along with optional auxiliary data (hints) can help the IP module make expedited decisions regarding configuration changes. This draft provides a non-exhaustive catalogue of triggers and hints from well-known link-layer technologies. "MRCP Extensions: Media Resource Control Protocol Extensions", Daniel Burnett, 6-Jan-04, 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 document captures the extensions required to implement Voice Enrollment, Speaker Verification and Hotword recognition as well as to augment the recognizer functionality using MRCP. The extensions are largely orthogonal to existing features of MRCP and to each other, with an eye towards backwards compatibility with existing features and independence of the extensions from each other to simplify integration. "PIM-SM Extensions for Supporting Remote Neighbors", Rahul Aggarwal, Tom Pusateri, 21-Jul-04, This document describes protocol extensions to PIM-SM for supporting PIM-SM neighbors that are not directly connected. The mechanism described herein makes use of PIM-SM Hello messages that are directed to the remote neighbor. Following the discovery of the remote neighbor PIM-SM Join and Prune messages can be exchanged. "Interaction between GMPLS RSVP-TE and LCAS", Young Hwa Kim, 16-Feb-04, This document describes interaction aspects between a signaling protocol and the LCAS. The signaling protocol handled by IETF could be GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. The LCAS protocol handled by ITU-T is a protocol that is used to change the bandwidth capacity of a virtual concatenated signal used by transport networks (i.e. SDH and OTN), which should be initiated only in a unidirection by EMS or NMS systems. However, the GMPLS signaling protocol have a feature of being capable of controlling bi- directional connections on a LSP. In current, there is no interaction between the signaling protocol and the LCAS. In this document, when a signaling protocol such as the GMPLS RSVP-TE and the LCAS are used together within a single node and a bi-directional connection is required on the same route, relevant requirements and encoding methods are identified. "OSPFv2 Wireless Interface Type", Jeff Ahrenholz, 19-May-04, This draft defines enhancements to the OSPFv2 protocol to support a new interface type for wireless, broadcast-capable, multi-hop networks. This interface type uses an unreliable flooding mechanism to distribute LSAs within a wireless subnet. This draft also defines rules for LSA distribution for edge routers that may have a mix of interface types on different subnets. "SIP Conventions for Voicemail URIs", Cullen Jennings, 19-Jul-04, At the previous meeting, the working group consensus was that Cullen could not move this draft forward as an individual submission. However, there was no consensus to adopt it as a WG item. This version of the draft carefully documents exactly what it is that Cullen may not move forward. "The Standard Hex Format", Joachim Strombergson, 14-Jul-04, This document specifies the Standard Hex Format (SHF), a new, XML-based open format for describing hexadecimal data. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport and vendor neutral format. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, 10-Jun-04, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", Michael Tuexen, 19-Jul-04, This document describes a new chunk type, several parameters and procedures for SCTP. This new chunk type can be used to authenticate SCTP chunks by using a secret shared between the sender and receiver. The new parameters can be used to establish a shared secret if one is not pre-known between the two peers. "Security Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, 13-Feb-04, This document defines a new security precondition for the Session Description Protocol precondition framework described in RFC 3312. A security precondition can be used to delay session establishment or modification until media stream security has been negotiated successfully. "Proposed Real-Time Transport Protocol Management Information Base Version 2", Alan Clark, 20-Jul-04, 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 Real-Time Transport Control Protocol Extended Reports (RTCP XR) VoIP Metrics (RFC3611). "A MIME Encoding for Spam Inoculation Messages", Bill Yerazunis, 16-Feb-04, This document describes in detail a method for encapsulating an email message or text sample for the purpose of training (or 'inoculating') a mail filter. The sample messages or text (the 'payload') provide the contextual information necessary for the filter to reject ('spam') or accept ('non-spam') the message being inoculated, or messages similar in design. RFC 1521 defines the MIME format. This document expands on this by adding an 'inoculation' MIME subtype, and also adds additional header fields necessary to the functionality being provided. This message format is designed to enable different mail filters of different design to communicate inoculations with one another using the MIME subtype introduced. "Observations on the Applicability of the Fault Notification Protocol", Richard Rabbat, Ching-Fong Su, Vishal Sharma, 16-Jun-04, The Fault Notification Protocol (FNP) is a set of procedures designed to enable time-bounded failure notification in networks using an IP- based control plane. This document discusses the applicability of FNP in the context of optical transport networks. It highlights the protocol?s principles of operation, and then describes the network, node, fault, and operational models in optical networks for which the protocol is designed. It also discusses the relationship to higher layers, and issues of scalability. Some guidelines for deployment are also provided. "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", Thomas Narten, Randy Bush, 21-Jul-04, IETF procedures generally require that a standards track RFC may not have a normative reference to a document at a lower standards level. For example a standards track document may not have a normative reference to an informational RFC. There are needs for exceptions to this rule, often caused by the IETF using informational RFCs to describe non-IETF standards, or IETF-specific modes of use of such standards. This document clarifies the procedure used in these circumstances. "Session-Independent Policies for the Session Initiation Protocol (SIP)", Volker Hilt, 17-May-04, Session policies are often independent of a specific session and generally apply to sessions during a certain period of time. This draft defines a document format for session-independent session policies. It also discusses the use of policy documents with the user agent profile delivery framework. "Interworking of RFC 3473 and 3474", Lyndon Ong, 16-Feb-04, This document defines interworking procedures between [RFC 3473] (Generalized MPLS (GMPLS) RSVP-TE) and [RFC 3474] (GMPLS RSVP-TE Usage and Extensions for ASON) signaling. RFC 3474 extensions are used in ITU-T Recommendation [G.7713.2]. Two basic interworking scenarios are discussed. RFC 3474 was intended to use the same basic mechanisms as and to be backwards compatible to RFC 3473. Some objects in 3474 are carried transparently over an RFC 3473 network, in accordance with RSVP procedures for unrecognized objects. Other objects must be mapped or generated at the interworking point. The mechanisms described in this document are applicable to any types of interfaces common to RFC 3473 and Recommendation G.7713.2, esp. time-division multiplexed, lambda or fiber switching interfaces. "The Extended LDAP Data Interchange Format (ELDIF)", Andrew Sciberras, 26-May-04, This document extends the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) to permit Extensible Markup Language (XML) encoded directory attribute values to be represented in a human readable format, instead of Base64. "Example call flows using SIP security mechanisms", Cullen Jennings, 16-Feb-04, This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementors build interoperable SIP software. It is purely informational. To help facilitate interoperability testing, it includes certificates used in the example call flows and a CA certificate to create certificates for testing. Warning - this is a very early draft of this document. The call flows in it have not been verified against multiple versions of the software and have reasonable odds of being wrong. "Remote Call Control in SIP using the REFER method and the session-oriented dialog package", Rohan Mahy, 17-Feb-04, This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. This functionality is most useful for collections of loosely coupled User Agents that wish to present a coordinated user experience. It does not require a Third-Party Call Control controller to be involved in any of the manipulated dialogs. "A NAT/Firewall NSLP security infrastructure", Miquel Martin, Marcus Brunner, Martin Stiemerling, Cedric Aoun, 16-Feb-04, This document proposes a security infrastructure for the NAT/FW traversal NSLP of the NSIS protocol. We begin with a description of the problem, followed by the proposed solution, based on public key infrastructure. The document finally deals with examples that clarify the proposed methods. "Real-Time Transport Protocol (RTP) Payload Format and Adaptive Multi-Rate Wideband plus (AMR-WB+) Audio Codec", Johan Sjoberg, 16-Feb-04, This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate Wideband plus (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB codec providing additional modes designed to give higher quality of music and speech than the original modes. The payload format is designed according to the principles outlined in the existing payload formats for AMR and AMR-WB, RFC3267 [9]. A MIME type registration is included for AMR-WB+. "Ad hoc On-Demand Distance Vector (AODV) Routing", Charles Perkins, 12-Feb-04, The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and unicast route determination to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as ``counting to infinity'') associated with classical distance vector protocols. "Expedited Flooding for Restoration in Shared-Mesh Transport Networks", Richard Rabbat, 6-Feb-04, Optical transport networks require fast restoration mechanisms with tight time bounds in order to recover from resource failures in a timely manner. These failures may include fiber cuts, transponder failure and node failures. Time-bounded recovery is challenging in mesh-based transport networks with shared protection. This draft discusses some currently available mechanisms and their limitations, and explains the need for an expedited flooding mechanism to accomplish this objective. The draft also highlights some challenges, mitigating factors, and possible solutions in the implementation of an expedited flooding protocol. "Server To Server Notification Protocol Requirements", Gev Decktor, 13-Feb-04, This memo suggests a set of requirements for the implementation of a protocol in which a messaging system (e.g. email server, voice mail system, etc.) submit alerts, which describe potential notification events, regarding an end user mailbox status change (e.g. new message has arrived, mailbox is full, etc.). These alerts are sent to a notification service, which may, in turn, generate an end user alert notification. "A Name Munging Protocol", John Klensin, 14-Jul-04, As one works on internationalization issues for DNS, email, and other protocols, it becomes clear that the various encodings and transformations required, while not intrinsically difficult, can be an impediment to rapid conversion of applications to international form and to rapid prototyping of new applications. This document proposes a new, lightweight, protocol that can be used to make such conversions, rather than incorporating the needed tables and algorithms into each application. "Soft Permanent Virtual Circuit Interworking between PWE3 and ATM", George Swallow, 12-Jul-04, This document defines interworking between Private Network Node Interface (PNNI) SPVC signaling and the Label Distribution Protocol [LDP] as extended by [PWE3-CP] and [L2VPN-SIG]. "Neighbor Discovery for IP version 6 (IPv6)", Thomas Narten, 18-Feb-04, This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. "Filters for Mobile Ad hoc Networks (NOMADHOC)", Koojana Kuladinithi, Niko Fikouras, Carmelita Goerg, 10-May-04, Filters for Mobile Ad hoc networks (NOMADHOC) introduces a set of extensions applicable to a range of on-demand ad hoc networking protocols that allow an ad hoc node to distribute its active flows across multiple routing paths. These extensions are based on the filter structure defined in NOMAD to enable a filtering behavior at the originator and the destination nodes. "Threats relating to IPv6 multihoming solutions", Erik Nordmark, Tony Li, 9-Jun-04, This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. "Generalized MPLS (GMPLS) RSVP-TE Signaling in support of Layer-2 Label Switched Paths (L2 LSP)", Dimitri Papadimitriou, 23-Jun-04, Most efforts on Generalized MPLS (GMPLS) have been focused to environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.). There is minimal documentation on GMPLS support of Layer-2 Label Switched Paths (L2 LSPs), e.g. native Ethernet LSPs. This document details GMPLS capabilities for supporting L2 LSPs in several network environments including overlays. As such, it provides a reference detailing the applicability of GMPLS for Ethernet switching environments in support of various deployment scenarios, including the integrated (e.g. multi LSP-region networks), the augmented/peer and the overlay model (e.g. Generalized VPN (GVPN) and user-network interfaces (GMPLS UNI)). "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", Tim Chown, 22-Jul-04, Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, including the scenario of early deployment prior to availability of IPv6-capable switch-router equipment, where IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. "Inter Home Agents Protocol (HAHA)", Ryuji Wakikawa, Vijay Devarapalli, Pascal Thubert, 16-Feb-04, This document describes an inter Home Agents (HAHA) protocol to provide multiple Home Agents support for both Mobile IPv6 and the Nemo Basic Support protocol. The HAHA protocol provides Home Agent redundancy and load-balancing for both protocols. The HAHA protocol allows multiple Home Agents to be placed at different links. It also allows a Mobile Node/Router to utilize multiple Home Agents simultaneously. The protocol consists of 3 mechanisms, Home Agent List management, Binding Synchronization, and Home Agent Switching. A Mobile Node/Router picks one Home Agent as its primary Home Agent and registers with it. The primary Home Agent synchronizes the binding cache information with other Home Agents. Any of Home Agents can intercept a packet meant for the Mobile Node/Router and tunnel the packet directly to its current Care-of address. Alternatively, the Home Agent can tunnel the packet to the primary Home Agent. "Standards, What Standards?", John Loughney, 18-Feb-04, The current problem working group has identified problems with they way in which the IETF manages the document series. This document discusses some of the problems caused by the current state of affairs and lays out some steps to correct the problems. "Control plane architecture in GMPLS networks", Kohei Shiomoto, 18-Feb-04, This document addresses control plane architecutre in GMPLS enabled IP- Optical networks. Two different control plane architectures are consid- ered: symmetical and asymmetrical control plane architectures. Addressing (router-ID, control plane address, and TE link address) and RSVP message handling (routing, HOP and ERO objects processing) are discussed for both architectures.The document also recommends normal practises for identification of TE links. Interwork between symmetrical and asymmetrical control plane is addressed. "IPv6 Implications for TCP/UDP Port Scanning", Tim Chown, 20-Jul-04, The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP port scanning to discover open or running services on a host will potentially become far less computationally feasible, due to the larger search space in the subnet. This document discusses that property of IPv6 subnets, and describes related issues for site administrators of IPv6 networks to consider. "Hierarchical Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", Byung-Yeob Kim, Kyeong-Jin Lee, Jung-Soo Park, Hyoung-Jun Kim, 18-Feb-04, Stateless Autoconfiguration enables IPv6 hosts to send a request for a prefix, a network identifier to a router on the subnet. Using this ability a host can configure its IPv6 address. Likewise, by defining a way to request for a prefix to an upper level router, a router can get a prefix to be assigned to its subnet. This document describes a protocol for prefix delegation between routers. It allows routers get prefixes from its upstream routers, enabling the entire network and its belonging hosts autoconfigure their own addresses. "Framework of requirements for real-time text conversation using SIP", Gunnar Hellstrom, Arnold Van Wijk, Radhika Roy, 17-Feb-04, This document provides the framework of requirements for text conversation with real time character-by-character interactive flow over the IP network using the Session Initiation Protocol. The requirements for general real-time text-over-IP telephony, point-to- point and conference calls, transcoding, relay services, user mobility, interworking between text-over-IP telephony and existing text-telephony, and some special features including instant messaging have been described. "NAT/Firewall NSLP Migration Considerations", Cedric Aoun, Marcus Brunner, Martin Stiemerling, Miquel Martin, Hannes Tschofenig, 22-Jul-04, This document discusses migration issues towards NSIS NAT/FW NSLP enabled NATs and Firewalls. In particular traversal of NSIS unaware NATs and NSIS proxy scenarios are addressed. This document will serve as input to the NSIS NATFW NSLP document. "Multihoming without IP Identifiers", Erik Nordmark, 8-Jul-04, This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution relies on verification using the existing DNS to prevent redirection attacks, while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does not introduce a "stack name" type of identifier, instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address. "Policy Based Mobile IP Handoff Decision (POLIMAND)", Stefan Aust, 18-Feb-04, A hand-off is the process during which a node is handed off between two mobility agents. Mobile IP hand-offs occur as a consequence of lower layer (i. e., link-layer) hand-offs that signify a location switch between two IP networks. For the duration of a Mobile IP hand-off, a mobile node is unable to send or receive traffic. The length of this disruption is considered critical because it can affect the performance of communications. An additional factor that is closely bound with that of Mobile IP hand-offs is that of agent selection. That involves the selection of the most suitable mobility agent from which a mobile node should receive service. With the help of link-layer information such as signal strength, signal quality and throughput it is possible to accelerate Mobile IP hand-offs on one side and on the other to lead to the selection of the best possible mobility agent. This draft describes a policy based Mobile IP handoff decision method (POLIMAND) that allows for enhanced Mobile IP handoffs and optimal agent selection based on link layer information. "Session Initiation Protocol (SIP) Event Notification Throttles", Aki Niemi, 20-Jul-04, This memo specifies a throttle mechanism for limiting the rate of Session Initiation Protocol (SIP) event notifications. This mechanism can be applied in subscriptions to all SIP event packages. "A Uniform Resource Name(URN)Namespace for the International Press Telecommunications Council (IPTC)", Michael Steidl, 11-Nov-03, This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council, IPTC. These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. "Problem Statement: Home Agent Reliability", Jahanzeb Faizan, 16-Feb-04, In Mobile-IPv6, Mobile Node is dependent on a single Home Agent for the seamless roaming over the Internet. Mobile-IPv6 also allows deployment of multiple Home Agents on the subnet for providing continuous service to Mobile Node in case of serving Home Agent failure. But switching of service from the failed Home Agent to another functional Home Agent on the Home Subnet is problematic and the base Mobile-IPv6 specifications does not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions. "Partial Document Changes (PATCH Method) for HTTP", Lisa Dusseault, 19-Jul-04, Several applications extending HTTP require a feature to do partial resource modification. Existing HTTP functionality only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. "FLUTE Interoperabtility Testing Guidelines", Harsh Mehta, 23-Jun-04, This memo describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirection Transport (FLUTE) protocol. "An interim solution to the Path MTU discovery problem for IPsec gateways", Michael Richardson, 19-Jul-04, Path MTU discovery depends upon proper respect for the Don't Fragment (DF) bit. IPsec gateways often present an Maximum Transmission Unit (MTU) constraint, and therefore must send ICMP Fragment Needed messages when the DF bit is set. This document proposes to ignore it in certain cases. "Load Balance for Distributed Home Agents in Mobile IPv6", Hui Deng, 31-Mar-04, This document specifies the load balance of mechanism which take account of not only the mobile node registration information but also data the tunneled data traffic information to effectively release and prevent the formation of the traffic bottleneck at the home agent. "Secure and Dynamic Allocation of Home Address for MIPv6", Mohamed Khalil, Haseeb Akhtar, Alpesh Patel, Kent Leung, 2-Mar-04, Static configuration of the MN's (Mobile Node) home address is a very cumbersome task and a provisioning nightmare for the Service Providers. With millions of subscribers, a typical Service Provider stands to incur considerable expenses in order to manually configure all of its MN's home address. The ability to dynamically and securely allocate MN's home address, therefore, can immensely aid in providing a cost-effective and efficient device management alternative to the Service Providers. This draft provides a simple method for dynamically allocating MN's home address in a secure manner. "Alternative Designs for OSPF Extensions for Mobile Ad Hoc Networks", Richard Ogier, 21-Jul-04, This draft discusses alternative candidate techniques for the design of an an extension of OSPF to support mobile ad-hoc network (manet) interfaces. Several design decisions need to be made before such an extension can be specified, including (1) defining the set of relay nodes used for flooding LSAs, (2) defining the set of LSAs that each node is responsible for relaying/reporting, and (3) defining the mechanism used to efficiently deliver each LSA to all nodes. "Using SRV Resource Records to Automatically Configure Email Clients", Eric Hall, John Klensin, 14-Jul-04, This document specifies SRV resource records for Internet-based message-submission and message-retrieval services, and also defines behavioral rules for messaging clients to use when automatically locating the messaging servers associated with a known mail domain. "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Pekka Savola, 29-Jan-04, This memo describes a set of operational procedures, a UDP encapsulation for configured tunnels, and one implementation mechanism to provide a very simple and straightforward way to easily manage IPv6-over-IPv4 configured tunnels between an ISP and a customer. The configured tunnels work even if the IPv4 addresses change dynamically, or are private addresses; the procedure provides at least a /64 prefix per customer and requires no administrative set-up. NAT traversal is also supported. "RTP Payload for Text Conversation", Gunnar Hellstrom, 14-Jul-04, This memo describes how to carry real time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. "Tunneling IPv6 with private IPv4 addresses behind NAT devices", Liu Min, Wu Xianguo, Cai Yibing, Jin Mingye, Li Defeng, 11-May-04, The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. However, classic tunneling methods do not work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device. We propose here a service, called Silkroad, to enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity. It can provide IPv6 connectivity through all existing NAT types and does not require any update of them. In addition, Silkroad does not need special IPv6 addressing prefix and can provide the users with permanent/temporary IPv6 addresses. "PMTU-Options: Path MTU Discovery Using Options", Michael Welzl, 11-Feb-04, This document describes an experimental enhancement of Path MTU Discovery that has the potential of reducing loss, speeding up convergence, reducing load in routers which would otherwise need to generate a large amount of ICMP messages, and alleviating certain additional problems (interactions with tunnels, Black Hole Detection). The idea is to use an IP Option which queries routers for their MTU before starting a Path MTU Discovery process. The result retrieved in this is used as an upper limit for Path MTU Discovery. To this end, it is fed back to the source either at the packetization layer (recommended) or at the IP layer. "Non-hierarchical MAP Discovery and Selection in HMIPv6", Youngjun Park, 29-Jan-04, This memo introduces an alternative dynamic MAP (Mobility Anchor Point) discovery and selection procedure for HMIPv6 (Hierarchical Mobile IPv6). A new dynamic MAP discovery method is defined in order to change the size of MAP domain. Subsequent MAP selection algorithm enables to locate MAP on the closest and highest level of hierarchical structure of routers. Addressed method is beneficial not only for the performance of localized mobility management but also for the location privacy. Also it gives flexible domain designing capability to the operators. "GMPLS Signaling Procedure For Egress Control", Lou Berger, 23-Jan-04, This note clarifies the procedures for the control of a label used on an egress output/downstream interface. Such control is also know and 'Egress Control'. Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and [RFC3473]. This note does not modify GMPLS signaling mechanisms and procedures and should be viewed as an informative clarification of [RFC3473]. "Access Router Information Protocol (ARIP)", Kyungjoo Suh, 6-Feb-04, This document defines Access Router Information Protocol (ARIP) whereby a mobile host can improve the handoff performance by exchanging, in advance, the information among geographically adjacent access router(AR)s. This protocol does not need a certain assumption of network topology so that it can be applied to heterogeneous networks as well as homogeneous networks. This document also describes a framework to minimize the handoff latency with the aid of ARIP. Therefore, ARIP can be combined with the protocol such as Fast Handovers (for Mobile IPv6) which tries to minimize the handoff latency. "Providing a Session Initiation Protocol (SIP) Application Server with a List of URIs", Gonzalo Camarillo, 30-Mar-04, This document describes how a user agent can provide an application server with a list of URIs. The way the application server uses the URIs in the list is service specific. "Elliptic-Curve Diffie-Hellman Key Exchange for the SSH Transport Level Protocol", Douglad Stebila, 3-May-04, This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Secure Shell (SSH) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement and ECDH with cofactor multiplication key agreement in the SSH Transport Layer protocol. "Designated Mailers Protocol", Gordon Fecyk, 5-May-04, This document describes the Designated Mailers Protocol (DMP); a proposal for identifying computer systems authorized to act as Simple Mail Transfer Protocol (SMTP) clients for an e-mail domain. "Threats for Basic Network Mobility Support (NEMO threats)", Alexandru Petrescu, 12-Jan-04, This document describes security threats related to the network mobility base protocol (NEMO). Threats of Mobile IPv6 for Mobile Hosts are only briefly touched when in need of support of related NEMO threats. The NEMO signalling between MR and HA, as well as the forwarding information at HA and nested mobility configurations are considered to be the main sensitive points of the protocol. Existing tools of Mobile IPv6 protection between MH and HA (IPsec), dynamic routing protocol authentication, NEMO prefix table, ingress filtering checks at HA and tunnel encapsulation limiting are presented as protocol features affording protection against threats. NEMO threats for which there are no protections are briefly mentioned. "SOBER-128: A Fast Stream Cipher with Simultaneous Message Authentication Code", Michael Paddon, 6-Feb-04, SOBER-128 is a fast software-oriented stream cipher based on simple 32-bit operations. Keys of up to 128 bits and optional nonces of arbitrary length are supported. SOBER-128 may be configured to calculate an arbitrary length Message Authentication Code (MAC) as part of the encryption or decryption process. Source code for SOBER-128 is freely available, and use of this source code, or independent implementations, is permitted for any purpose under a fee free license. "Nexthop Fast ReRoute for IP and MPLS", Naiming Shen, 22-Jul-04, This document describes a mechanism called NFRR (Nexthop Fast ReRoute) to perform fast re-route for any type of traffic in the event of a link/node failure or a nexthop unreachable. The protected traffic can be IP, MPLS, unicast or multicast. The re-routed traffic can either be destined to the nexthop router or to the next-nexthop router. RSVP explicitly routed LSPs are used as a tool to perform the local patch for minimizing the packet loss. "MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements", Fred Baker, 16-Feb-04, The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: 'Architecture for Assured Service Capabilities in Voice over IP' and 'Requirements for Assured Service Capabilities in Voice over IP'. Responding to these are four documents: 'Reason Header Field for the Session Initiation Protocol', 'Extending the Session Initiation Protocol Reason Header to account for Preemption Events', 'Communications Resource Priority for the Session Initiation Protocol', and the 'Multi-Level Expedited Forwarding Per Hop Behavior' (MLEF PHB). MLEF, as currently defined, has serious problems, which this draft seeks to discuss. "Implementing MLPP for Voice and Video in the Internet Protocol Suite", Fred Baker, 16-Feb-04, The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: 'Architecture for Assured Service Capabilities in Voice over IP' and 'Requirements for Assured Service Capabilities in Voice over IP'. Responding to these are three documents: 'Reason Header Field for the Session Initiation Protocol', 'Extending the Session Initiation Protocol Reason Header to account for Preemption Events', 'Communications Resource Priority for the Session Initiation Protocol'. What remains to this specification is to provide a Call Admission Control procedure and a Per Hop Behavior for the data which meet the needs of this architecture. "IEVE Statistics", Madan Velayudham, 18-Feb-04, This draft describes a mechanism of collecting the statistical information about sieve action on the received mail. It introduces GETSTAT and RESETSTAT commands to [MSIEVE] to get and reset the statistic information about the sieve actions. "Service Authentication Architecture Using Extensible Authentication Protocol (EAP) Key", Hiroyiki Ohnishi, 18-Feb-04, In a public wireless Local Area Network (WLAN) access service using Mobile IP, network elements, such as access points, access routers, home agents and mobility anchor points, are required to authenticate the user to prevent unauthorized usage. Therefore, a mobile node needs to execute the authentication process many times to use the Mobile IP function. It will increase the connection delay. The connection delay can be reduced by using a preshared key as an authentication method. But it is necessary to share the symmetric secret key between network element (NE) and mobile node (MN) in advance. It is impossible for the MN to configure the key of all network elements in advance. In this document we discuss a secure access architecture using an Extensible Authentication Protocol (EAP) key as a shared key between NEs and an MN. "Discovering LDP Next-Nexthop Labels", Naiming Shen, 22-Jul-04, This document specifies extensions to LDP in support of next-nexthop label discovery. The next-nexthop label information can be used to fast re-route LDP LSP traffic into an explicitly routed tunnel for nexthop node protection in the case of a link or node failure. "Requirements for Proposed Changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4)", Richard Barr Hibbs, 14-Apr-04, This memo describes the requirements of Internet-Drafts proposing changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4). These requirements specifically cover documentation expected whenever message formats or client state transitions are modified. "Things MULTI6 Developers should think about", Eliot Lear, 25-May-04, This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution either. "Virtual Home Agent Reliability Protocol (VHAR)", Hesham El-Rewini, Mohamed Khalil, Jahanzeb Faizan, 12-Apr-04, Current specifications of Mobile IPv6 does not provide Home Agent Reliability in the home link. The aim of this draft is to introduce Virtual Home Agent Reliability Protocol as the solution. In this protocol multiple Home Agents coexist on the same home link and share the same Global IP address. Only one of them is active at a time and serves the Mobile Node. The Home Agent failure and failover mechanisms are completely transparent to the Mobile Node which is required for minimal service interruption time. This protocol does not introduce any new Mobile IPv6 message over the air interface and thus helps reducing the overall overhead. Current specifications of Mobile IPv6 does not provide Home Agent Reliability in the home link. The aim of this draft is to introduce Virtual Home Agent Reliability Protocol as the solution. In this protocol multiple Home Agents coexist on the same home link and share the same Global IP address. Only one of them is active at a time and serves the Mobile Node. The Home Agent failure and failover mechanisms are completely transparent to the Mobile Node which is required for minimal service interruption time. This protocol does not introduce any new Mobile IPv6 message over the air interface and thus helps reducing the overall overhead. "Calendar Server Extensions for WebDAV (CalDAV)", Lisa Dusseault, 20-Jul-04, In the five years since WebDAV [3] was standardized, at least three groups have used WebDAV as a basis to provide Internet calendar access with a minimum of development effort. However, each group decided independently how the calendaring data model would map to the WebDAV data model and how to deal with features such as recurrance and queries for free-busy times. This draft proposes a standard data model mapping and a few extensions to WebDAV that make WebDAV-server-based calendaring work well for clients while requiring a minimum of new work (particularly on clients). "Robust XML Encoding Rules for ASN.1 Types", Steven Legg, 16-Jun-04, This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. "PANA: SNMP usage for PAA-2-EP interface", Yacine Mghazli, 16-Feb-04, The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client (PaC) successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group mandates the use of Simple Network Management Protocol (SNMP) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMP as the PAA-2-EP protocol. "IETF Session Minutes and Presentation Materials -- Post Meeting WG Chair Duties and Responsibilities", David Meyer, 10-Mar-04, RFC 2418 outlines the procedures for IETF Session operation. However, it contains little information about post-IETF meeting working group chair responsibilities. In particular, it gives little guidance with respect to either form or submission deadlines for the artifacts of the meeting, namely, session minutes and presentation materials. This document addresses those issues. "Tags for Identifying Languages", Addison Phillips, Mark Davis, 30-Jun-04, This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and a construct for matching such language tags, including user defined extensions for private interchange. This document replaces RFC 3066 (which replaced RFC 1766). "Gap Analysis for Meeting Emergency Telecommunications Service (ETS) Requirements with DIFFSERV and MPLS in a Single IP Telephony Domain", Janet Gunn, Dennis Berg, Pat McGregor, 6-Jan-04, This document presents a gap analysis for meeting ETS requirements using DIFFSERV and MPLS with reference to one particular network scenario: implementing Internet Telecommunications Disaster Recovery (ETS) service in the context of IP Telephony in a private IP network designed, engineered and managed with telephony (using DIFFSERV and MPLS) as the dominant application. "iCalendar Scheduling", Doug Royer, 7-Jan-04, A proposal to specify booked persistent data in calendar stores to track 'SEQUENCE' and 'DTSTAMP' property values for CUAs with direct access to calendar stores. With iMIP the iCalendar CUA's do not see the others stored CS data. With WebDAV, HTTP, or FTP access, the CUA can see into the public data of other calendars. The storage of persistent data mandated by [iTIP] has not been standardized yet. This memo proposes a way to standardize on those persistent items. Also included are ways to make the various ways of using the [iCAL] and [iTIP] 'RECURRENCE-ID' property work between vendors and to document the procedures to work with 'RECURRENCE-ID's. "UDT: A Transport Protocol for Data Intensive Applications", Yunhong Gu, Robert Grossman, 7-Jan-04, This document proposes UDT, or UDP based Data Transfer protocol, which can be used in high bandwidth-delay product (BDP) networks to utilize the abundant network resource efficiently. Potential users are people who work with distributed data intensive applications, such as scientific computing on computational grids. The current widely used TCP version (TCP Reno with SACK option) does not work well in such environments due to its slow discovery and recovery to the available bandwidth as the network BDP increases, as well as due to its fairness problem when concurrent TCP flows have different RTTs. UDT is an application layer solution by adding congestion control and reliability control to UDP. UDT combines rate control and window control and it uses bandwidth estimation techniques to dynamically configure the control parameters. "Requirements for ECRTP over MPLS", Jerry Ash, 27-Jan-04, VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP). We consider using MPLS to route ECRTP compressed packets over an MPLS LSP without compression/decompression cycles at each router. Such an ECRTP over MPLS capability can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous VoIP flows that use header compression at each router. "MPLS Inter-area Traffic Engineering requirements", JP Vasseur, 7-Jan-04, This document lists the detailed set of requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) which could serve as a guideline to develop the required set of protocol extensions. "Discovering PIM-SM Next-Nexthop Downstream Nodes", Naiming Shen, 19-Jul-04, This document specifies extensions to PIM-SM in support of next-nexthop downstream node discovery. This next-nexthop node information can be used for PIM to fast re-route multicast traffic onto explicitly routed tunnels, for downstream node protection in case of outbound link or nexthop node failure. "DHCP Proxy Server Micro-block Allocation Scheme For IP Address Pool Management", Naiming Shen, 3-Feb-04, A new DHCP address allocation mechanism called Micro-blocking is proposed in this document. It is used for DHCP proxy servers or routers working with DHCP servers to maximize the IP address allocation efficiency while improve dynamic routing scalability in provider's networks. A DHCP sub-option within the relay agent information option 82 is defined in this document. This simple DHCP extension can be applied as a simple IP address-pool management among multiple IP devices. "LIN6: A Solution to Multihoming and Mobility in IPv6", Fumio Teraoka, 9-Jan-04, LIN6 is a protocol supporting multihoming and mobility in IPv6. LIN6 introduces the node id, not the interface id, for each node. Each node can be identified by its node id no matter where the node is connected and no matter how many interfaces the node has. In the IPv6 layer, 64-bit node id called LIN6 ID is used while 128-bit node-id called LIN6 generalized ID is used above the Transport layer. TCP connections and security associations can be preserved even if the node moves to another subnet or the node changes the using interface in a multihoming environment without modifying TCP or IPsec. In comparison with Mobile IPv6, LIN6 has several advantages in terms of header overhead and fault tolerance. "Simple Policy Control Protocol", Roland Hedberg, 10-Jan-04, "Transition from RFC2131-style to RFC3315-style Client Identifiers for DHCPv4", Ted Lemon, 12-Jan-04, This document explores ways for a node that is configured using DHCP and that has in the past been configured using one of the client identification schemes described in RFC2131 and RFC2132 to make the transition to using the identification scheme described in RFC3315 and in draft-ietf-dhc-3315-id-for-v4.txt. "On Demand Tunneling For Multihoming", Iljitsch van Beijnum, 12-Jan-04, This document describes a protocol to negotiate and subsequently use tunnels on demand, and the use of such tunnels to achieve scalable multihoming. The tunnels may run over either IPv4 or IPv6 transport, and the payload may consist of any upper layer protocol that can be used with IPv4 or IPv6. Tunnels are defined end-to-end, which means that a single outer or 'locator' address pair maps to a single inner or 'identifier' address pair. In order to avoid unnecessary overhead, tunneled packets (in the absence of option headers) only carry an outer header, an upper layer header and payload data. There is no inner header containing the original addresses; this information is reconstituted from the state associated with the tunnel where required. Additional mechanisms are used to provide basic security for the mapping between inner and outer addresses and to avoid unnecessary overhead and delays for short-lived sessions, and to facilitate rehoming in the event of a reachability problem. This document is a first draft, and as such doesn't contain a full protocol specification as higher-level changes are expected. "The 'dns' Media Type Registration Tree", Mark Nottingham, 12-Jan-04, This document specifies the 'dns' media subtype registration tree, which is intended to ease the deployment of new Internet applications and their associated media types without the need for coordination with a central registry. "Enhancing SMTP Mail Services To Minimize SPAM", Christopher Laforet, 13-Jan-04, Unwanted Email ('SPAM') is a constantly growing scourge of the Internet. SPAM takes full advantage of the open system that was created in the spirit of cooperation that represents the original underpinnings of the Internet. Understanding that making airtight mail systems without completely destroying old software, the authors of this proposal considered the continued operation of these legacy systems while tightening up the current standards. This new proposal calls for a new DNS resource record type and a new standard of operation for organization mail- exchangers. Using this new resource record along with other standard DNS resources provides system operators to minimize exploitable inbound SPAM pathways into their systems. "Datagram Transport Layer Security", Eric Rescorla, 19-Jul-04, This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the TLS protocol and provides equivalent privacy guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. "SixXS Heartbeat Protocol", Jeroen Massar, 13-Jan-04, This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers. "Layer 2 VPNs Over Tunnels", Kireeti Kompella, 13-Jan-04, Virtual Private Networks (VPNs) based on Frame Relay or ATM circuits have been around a long time. While these VPNs work well, the costs of maintaining separate networks for Internet traffic and VPNs and the administrative burden of provisioning these VPNs have led Service Providers to look for alternative solutions. In this document, we present a VPN solution where from the customer's point of view, the VPN is based on Layer 2 circuits, but the Service Provider maintains and manages a single network for IP, IP VPNs, and Layer 2 VPNs. "The SEED Encryption Algorithm", Jongwook Park, 14-Jan-04, This document describes the SEED encryption algorithm which has been adopted to most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm(Section 2), the S-boxes(Appendix A), and a set of test vectors(Appendix B). "8+8 Addressing for IPv6 End to End Multihoming", Masataka Ohta, 15-Jan-04, This memo describes 8+8 address format, which is an IPv6 address format with locator/ID separation useful for end to end multihoming. A 16 byte address of an end is separated into two 8 byte fields: locator, which is used to route packets to a link to which the end is attached, and ID, which is used to globally identify the end. Locators are assigned from (top level) ISPs to sites (and lower level ISPs) in hierarchical and aggregatable manner that a multihomed site (and ISPs) receive multiple locators from upstream ISPs. A usual host in a multihomed site (or a singly homed site under a multihomed ISP) is expected to have an ID and multiple locators and transport layer protocols are expected to handle multiple locators of the host and its peer. "RTP Retransmission Using Reactive FEC", Colin Perkins, 15-Jan-04, This memo describes how the RTP Payload Format for Generic Forward Error Correction can be combined with the Extended RTP Profile for RTCP-based Feedback to provide a solution for retransmission of lost RTP packets. Such a retransmission format is expected to be useful to improve the reliability of real-time applications with relaxed delay bounds, for example non-interactive streaming audio/video. "Hierarchical Mobile Router Advertisement for nested mobile networks", Hosik Cho, 15-Jan-04, This document describes needs for hierarchical mobile router advertisement for nested mobile networks. When ingress and egress interfaces of a Mobile Router are both wireless, the MR cannot distinguish the Router Advertisement of the parent MR from the RA of the child MR. To maintain hierarchical information of wireless nested mobile networks, RA message needs to be extended to deliver additional information for hierarchy. "Multiple protocol support in getnameinfo API", Jun-ichiro Hagino, 5-Feb-04, IPv6 basic API [Gilligan, 2003] defines protocol-independent API for address-to-string conversion, i.e. getnameinfo(3). Current specification, however, assumes that there are two transport-layer protocols - TCP (SOCK_STREAM) and UDP (SOCK_DGRAM), specifically in port number-to-service name conversion. The assumption prohibits getnameinfo(3) from supporting other transport-layer protocols, such as SCTP or DCCP. This document proposes a backward-compatible update to getnameinfo(3) specification to allow the use of other transport-layer protocol in port number-to-service name conversion. This document does not define any new (wire-level) protocol. "A Supplementary Scheme for New Care-of Address Configuration and Confirmation in FMIPv6", Youn-Hee Han, 16-Jan-04, This document proposes a new care-of address (NCoA) configuration and confirmation scheme for the Mobile IPv6 fast handover protocol (FMIPv6). The goal of this proposal makes FMIPv6 address configuration and confirmation 'very fast' and its confirmation result 'always successful'. The proposed scheme can become a supplementary function implemented in only nodes which play a role of new access router in FMIPv6. "BGP/MPLS IP VPNs over Layer 2 Tunneling Protocol ver 3", Mark Townsley, 16-Jan-04, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document describes a variation of 'BGP/MPLS IP VPNs' in which the outermost MPLS label of a VPN packet is replaced with an L2TPv3 encapsulation, enabling the VPN packets to be carried over an IP network. "MAC Forced Forwarding: An ARP proxy method for ensuring traffic separation between hosts sharing an Ethernet access network", Torben Melsen, 16-Jan-04, This document describes a mechanism to ensure layer-2 separation of LAN stations accessing an IP gateway over a shared Ethernet segment. The mechanism - called 'MAC forced forwarding' - implements an ARP proxy function that in effect directs all upstream traffic to the IP gateway, also if a station is trying to obtain direct Ethernet connectivity to another station within the same IP subnet but located at another end-user premise. "MAC Forced Forwarding: An ARP proxy method for ensuring traffic separation between hosts sharing an Ethernet access network", Torben Melsen, Steven Blake, 31-Mar-04, This document describes a mechanism to ensure layer-2 separation of LAN stations accessing an IPv4 gateway over a shared Ethernet segment. The mechanism - called 'MAC Forced Forwarding' - implements an ARP proxy function that prohibits MAC address resolution between hosts located within the same IP subnet but at different customer premises, and in effect directs all upstream traffic to the IP gateway. The IP gateway provides IP-layer connectivity between these same hosts. "TCP Configurable Signature Option", Kapil Sood, 16-Jan-04, This RFC proposes a generic and configurable signature option for TCP. This work extends the practice defined in TCP MD5 Signature Option for BGP sessions [RFC-2385]. This RFC describes a new TCP Configurable Signature Option that allows any TCP-based application to enhance security in TCP connections. This option is configurable because it allows implementers to choose the digest mechanism of choice for each TCP connection. This digest mechanism constructs a signature for each TCP segment, using a (preferably) connection specific shared secret key and components from TCP header and data. "Inter-Area MPLS Path Protection", A DAchille, 21-Jan-04, This document describes a mechanism to establish end-to-end disjoint LSPs in a multiple area domain, as required for inter-area end-to-end protection. This mechanism relies on the joint computation of the working and backup LSPs segments in each area. A new RSVP-TE object called the Associated Route Object, ARO, is defined and used in the signaling messages in support of this scheme. "XML+RPC - XML marshalled Remote Procedure Calls", Mario Salzer, 20-Jul-04, This document describes a method to make use of remotely available application logic and data processing by sending explicit procedure calls encoded in simple and plattform-independent XML messages over a HTTP connection. Despite other RPC (Remote Procedure Call) implementations it is not encoded as binary data, and concentrates on the most basic functionality. Therefore it is easier to implement and compatible with various programming languages and data representation systems. "Ncc in SMTP", Arun Sankar, 11-Mar-04, This draft presents a mechanism to simplify one of the cumbersome aspects of mailing. The basic intention is to minimize the complication when a mail needs to be sent to n - m mail IDs i.e. send it to a group Id of n and exclude m from the alias [ALIAS] list. "A Proposal for a Tag Value field in OSPF", Wojciech Dec, 22-Jun-04, This document proposes a method for encoding in Open Shortest Path First (OSPF) Internal and External Link State Advertisements (LSA) a Tag Value field containing user tag information associated with each link or prefix described within an LSA. "BGP Proxy Community Community", Sharad Agarwal, 21-Jan-04, This document describes a Flexible BGP Community Attribute that encodes a request for a remote AS to send another community to a specified neighbor when announcing the route. "6to4 Reverse DNS", Geoff Huston, 14-Apr-04, This memo describes a potential mechanism for entering a description of DNS servers which provide 'reverse lookup' of 6to4 addresses into the 6 to4 reverse zone file. The proposed mechanism is a conventional DNS delegation interface, allowing the client to enter the details of a number of DNS servers for the delegated domain. The client is authenticated by its source address and is authorised to use the function if its /48 prefix corresponds to the delegation requested. "PIM-SM Multicast Routing Security Issues and Enhancements", Pekka Savola, Pekka Savola, Rami Lehtonen, David Meyer, 23-Jan-04, This memo describes security threats for the larger (intra-domain, or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any Source Multicast (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model enhanced by the Embedded RP group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations to mitigate these threats. "Considerations on HIP based IPv6 multi-homing", Pekka Nikander, 15-Jul-04, The Host Identity Protocol implements the identifier locator separation by introduing a new name space and a new layer to the IP stack. The new structure insulates the transport layer protocols from the internetworking layer, thereby allowing transport sessions to remain unaffected even if the underlying IP addresses change. That, in turn, seems to make it easier to solve the so called site multi-homing problem than without introducing such an indirection layer. This document discusses how the proposed HIP mobility and multi-homing solution, described separately, would fit to the IETF multi6 working group requirements. "Enhancements to OSPF Graceful Restart for Heterogeneous Environments", Sriganesh Kini, 23-Jan-04, Reliability is a fundamental concern for the network. As a solution to improve network stability, the non-stop forwarding paradigm depends on protocol recovery based on graceful restart techniques. One of the proposed graceful restart techniques for [OSPF], a widely deployed IGP, is described in [OSPF-GR]. This technique has a limitation of not being backward compatible, in the sense that if a neighbor does not support the helper mode described in [OSPF-GR], the graceful-restart procedure will fail (i.e., revert to normal restart). For large multi-vendor networks, this scenario is fairly common. In this draft, we describe techniques that can achieve OSPF graceful restart even if a neighboring router does not support the helper-mode of [OSPF-GR]. "A Cleaner SMTP Envelope for Internet Mail", John Klensin, 23-Jan-04, During the last few years, a number of proposals for extensions or improvements to email have run into trouble with a side-effect of mail relaying. In the current Internet Mail model, every SMTP server is required to break strict layering by inserting one or more additional 'trace' headers into the message headers which are actually part of the SMTP payload. Since the headers are altered in transit, header-signing is not an available option, various anti-spam and internationalization strategies are infeasible or much more complex, and so on. This document proposes to change the Internet mail model to place the in-transit trace information in the envelope, removing the requirement that relaying systems modify the message payload. "Comment responses for Marker PDU Aligned Framing for TCP Specification", Paul Culley, 23-Jan-04, This draft is a response to comments about draft-ietf-rddp-mpa-00 received on the RDDP reflector, the response is long enough to warrant a draft. Comments on connection startup sequence, rejecting a connection, and allowing 'Active/Active' connections. "Message Submission", Mark Crispin, 6-Feb-04, This document describes a set of strategies to allow clients to submit new email messages incorporating content which resides on locations external to the client. This is the so-called 'IMAP Pull' approach currently being considered by the LEMONADE working group as one solution to the 'forward without download' problem (that is, as a means for clients to send new messages consisting of or containing all or parts of previously received messages without having to download and upload the data). Some of the strategies in this document rely upon extensions to other protocols; specifically URLAUTH and CATENATE in the IMAP protocol (RFC 3501) and BURL in the SUBMIT protocol (RFC 2476). "Encapsulating MPLS in IPsec", Rahul Aggarwal, 27-Jan-04, In various applications of MPLS, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. MPLS-in-IP and MPLS-in-GRE encapsulations have already been specified by the MPLS WG. In some cases, in addition to IP and GRE tunnels, it may be desirable to use IPsec for transporting MPLS packets securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions. This draft describes procedures for encapsulating MPLS packets in IPsec. "MPing: A Ping Utility for IP Multicast", Kamil Sarac, Kevin Almeroth, 27-Jan-04, This document describes a mechanism for discovering multicast reachability between end systems within/between multicast enabled networks. It uses request/response messages to verify multicast reachability between the local site and a remote site. With this utility, multicast users can test if they can successfully join a multicast group of a remote source and receiver its data. "Proactive Approach for Detecting Network Attachment", E Shim, 28-Jan-04, We propose a Proactive Approach for Detecting Network Attachment (DNA). In the approach, the mobile node caches information about adjacent access points and access routers using the Candidate Access Router Protocol and uses the cached information to check the new subnet after the mobile node establishes a new air link. This enables the mobile node to determine immediately after the new link setup whether the mobile node needs to proceed further for new IP configuration for the link. "Applicability Statement of NSIS Protocols in Mobile Environments", Roland Bless, 22-Jul-04, Mobility of an IP-based node affects routing paths, and as a result, can have a dramatic effect on protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocols, and how the protocols operate in different scenarios, and together with mobility management protocols. "Optimized Mobile IPv4 UDP Encapsulation", Sami Vaarala, 28-Jan-04, This document specifies an extension to Mobile IPv4 UDP encapsulation (RFC 3519) which enables optimization of overhead when UDP encapsulation is used, and most of the mobile node's data traffic is destined to one particular correspondent node. "OSPF Multi-Area Adjacency", Sina Mirtorabi, Peter Psenak, Acee Lindem, Anand Oswal, 15-Mar-04, This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. "Network-initiated Handover Framework for FMIPv6", Youngjun Park, 28-Jan-04, In this memo, a framework provides network-initiated handover to FMIPv6 MN (mobile node) in IEEE 802.11 wireless LAN is suggested. Basic concept and mechanism of layer-2/layer-3 handover and IAPP are introduced. Suggested framework is integration of these three protocols and additional primitives. "Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site", Kenji Ohira, 29-Jan-04, This document describes a method of automatic hierarchical IPv6 address assignment of a multi-link site with prefix delegation (PD) option enabled DHCPv6. This protocol is mainly designed to provide an effective list of addresses which a host will have for multi-address model multihome solutions. "Fibre-Channel Domain Management MIB", Vinay Gaonkar, Keith McCloghrie, Silvano Gai, Claudio Desanti, 21-Jul-04, 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 information related to a Fibre Channel network's Domain Management. At present, this memo is a work item of T11.5 (http://www.t11.org). The plan is that it will later become a work item of the IETF's IMSS working group. "Fibre-Channel Name Server MIB", Claudio Desanti, 20-Jul-04, 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 information related to the Fibre Channel network's Name Server function. At present, this memo is a work item of T11.5 (http://www.t11.org). The plan is that it will later become a work item of IETF's IMSS working group. "The EAP-PSK Protocol: a Pre-Shared Key (PSK) EAP Method", Florent Bersani, 9-Jul-04, This document specifies an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a pre-shared key (PSK). This PSK is used by a unique underlying cryptographic primitive, a block cipher, which is instantiated with AES-128. EAP-PSK provides a secure communication channel within EAP in case the authentication is successful. This channel is used to implement protected result indications and may be used by future extensions. EAP-PSK is designed to be easy to deploy and well-suited for authentication over insecure networks such as IEEE 802.11. It is proposed as a replacement for MD5-Challenge. "Guide to Mapping IPv4 to IPv6 Subnets", Christian Schild, 29-Jan-04, This document is intended to be a guide for network administrators of enterprise sized sites that employ the Internet Protocol Version 4 (IPv4) and who would like to introduce the Internet Protocol Version 6 (IPv6) dual-stack. It applies to scenarios where IPv4 subnets must be mapped to IPv6 subnets for management purposes while keeping the option to create IPv6 subnets in parallel and independently in the future with almost no restrictions; it is not meant to be applied to scenarios where a native IPv6 address plan can be created easily and without the need to map IPv4 subnets. "Considerations in Validating the Path in Routing Protocols", Russ White, Bora Akyol, Nick Feamster, 16-Apr-04, A good deal of consideration has gone into, and is currently being given to, validating the path to a destination advertised by an adjacent router or peer, such as [S-BGP], [SOBGP-DEPLOY], and [IRV]. Since much of this effort has been focused on BGP, this draft discusses some issues with this work in terms of BGP. One of the primary assumptions in much of this work is that the authentication of a given advertisement received by a specific BGP speaker is the same as authorization to use the path advertised. In other words, it is generally assumed that if a BGP speaker receives an advertisement for which the AS Path can somehow be verified, the speaker is authorized to transit traffic along the path specified contained in the update, and the traffic forwarded to the destination contained in the update will actually follow the path advertised. This draft shows these two assumptions cannot be held to be true in a path vector routing system. "Basic Transition Mechanisms (RFC 2893bis) Implementation and Interoperability Report Template", Pekka Savola, 2-Feb-04, This memo is a checklist and a template to verify the implementation status and the interoperability of implemented features of Basic Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893bis), to gather the implementation results to advance, and revise if necessary, RFC 2893bis to Draft Standard. "Identification of Component Links of Unnumbered Interfaces", Adrian Farrel, 2-Feb-04, This document provides a means to identify component links that are bundled within an unnumbered interface. This feature is required during Generalized Multiprotocol Label Switching (GMPLS) establishment of Label Switched Paths (LSPs) that utilize such component links. Similarly, it is useful in error reporting for such LSPs. "Multiprotocol Label Switching Pre-emption", Adrian Farrel, 9-Apr-04, Multiprotocol Label Switching (MPLS) signaling is documented in 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC 3209, using mechanisms inherited from 'Resource ReserVation Protocol -- Version 1 Functional Specification', RFC 2205. MPLS includes the concept of pre-emption where, for administrative reasons such as contention for system resources, a new Label Switched Path (LSP) may displace an existing LSP. This document clarifies the procedures for MPLS pre-emption in the light of implementation experience. The procedures in this document update those described in RFC 2205 and RFC 3209, but apply only to RSVP-TE used in the MPLS context. "Multi-Homing Tunnel Broker (MHTB)", Marcelo Bagnulo, 2-Feb-04, RFC 3178 [1] describes a solution to provide site multi-homing support in IPv6. RFC 3178 multi-homing solution uses tunnels between the different ISPs and the multi-homed site to provide alternative paths in case that one of the exit links is down, protecting the multi-homed site from outages in the direct link with its providers. However, the wide adoption of RFC 3178 multi-homing solution implies the manual configuration of numerous tunnels on the ISPs, which may impose an important workload in ISP network administrators. This note proposes the usage of Multi-Homing Tunnel Brokers to automatically configure the ISP tunnel endpoint in order to ease the adoption of the solution. "A Concise Guide to the Major Internet Bodies", Alex Simonelis, 2-Feb-04, Who steers the Internet? Despite its loose organization, certain protocols and parameters are essential for a computer to operate on the Internet. The bodies responsible for those protocols and parameters can be said to steer the Internet in a significant sense. This document is a summary of those bodies and their most important characteristics. "Vendor-Specific Suboption for the DHCP Relay Agent Option", Mark Stapp, 9-Jul-04, This memo defines a new Vendor-Specific suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in DHCP messages it forwards, as configured by its administrator. "RTP payload format for ATRAC family", Mitsuyuki Hatanaka, Matthew Romaine, Jun Matsumoto, 12-Jul-04, This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Codec (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document includes support for data fragmentation and elementary redundancy measures. "Requirements for MANET Interworking with Wired Multicast Networks", Pedro Ruiz, 2-Feb-04, A Mobile Ad hoc Network (MANET) is formed by the spontaneous association of wireless and mobile devices capable of communicating among them even when there is no networking infrastructure available. Several unicast Internet gateway mechanisms have been proposed within the IETEF MANET WG. However, the particular nature of the IP Multicast model poses some additional requirements which need to be satisfied by candidate solutions. This document aims at identifying the requirements that a multicast solution for MANET interworking with a fixed IP Multicast network should satisfy. "Multihoming: the SCTP solution", Lode Coene, 19-Jul-04, This document describes the multhoming solution used in SCTP. It compares the SCTP solution with the goals set out in "Goals for IPv6 Site-Multihoming Architectures" [11]. The document also tries to answer the questions posed in "Things MULTI6 developers should think about" [1]. "The HMAC-MD5 and HMAC-SHA-1 HTTP Digest Algorithms Tokens", Ted Hardie, 8-Apr-04, RFC 3230 sets out a process for registering HTTP Digest algorithm values with IANA. This document registers the tokens 'hmac-md5' and 'hmac-sha-1'. "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Exampl", Soohong Park, 2-Feb-04, This document describes a mechanism that extends Mobile IPv6 protocol to smoothly manage handovers for Mobile Nodes equipped with multiple interfaces and moving across different and heterogeneous links. For this purpose, the document provides indications on how to use the link events information to optimize L3 movement detection. "TLC-FM : Transport Layer Common Framework for Multihoming", Arifumi Matsumoto, 2-Feb-04, The existing transport protocols aren't designed to work well on multi-homed and multi-addressed hosts. TLC-FM is a transport layer common framework, which stores multihoming related information and provides common functions and multihoming functions for all the transport protocols. In this framework, address information for each remote host and some routing information for each next-hop is stored and shared by each transport protocol. Also in this framework, incoming packet's address fields are re-written from the on-wire address to the original one that is expected by transport protocols. This is true for outgoing packets as well. "The SIEVE mail filtering language – refuse extension", Matthew Elvey, Alexey Melnikov, 28-Jun-04, This memo defines the SIEVE mail filtering language [SIEVE] "refuse" extension. A Joe-job is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by the bounces, MDNs and messages with complaints. With the Sieve "reject" action, MDNs contribute to the flood of Joe-job spam to victims of Joe-jobs; SMTP level refusals usually don't. With "refuse", Sieve gains the ability to simply not accept an email during the SMTP transaction (instead of accepting it and then sending an MDN [MDN] back to the alleged sender using "reject"). "Crypto Based Host Identifiers", Iljitsch van Beijnum, 2-Feb-04, Abstract This memo specifies a 64-bit crypto-based host identifier that can be used as an interface identifier in protocols that allow address agility, such as [ODT]. The cryptographic nature of the host identifier makes it possible to determine whether a correspondent is legitimately using said host identifier or not. The host identifiers can be used as regular interface identifiers in protocols that don't require an identifier that is separate from locators, or they can be expanded to 128-bit IPv6 address like values for use with protocols that do need such an identifier-only value. "Communicating With Transport Intermediaries: Discussion and Framework", Melinda Shore, 3-Feb-04, In an increasingly complex internet it is becoming more common for endpoints to want to influence the behavior of network devices, and for those devices to want to communicate with endpoints for autho- rization and policy discover. Frameworks and protocols are evolv- ing for communication with application intermediaries and with net- work edge policy enforcement devices. One area that has received relatively little attention to date is communication between end- points and transport intermediaries. This document presents a problem statement and an overview of different communication mod- els. "Sockets Direct Protocol (SDP) for iWARP over TCP", James Pinkerton, 3-Feb-04, This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' "TCP Configurable Message Authentication Code (MAC) Option", Kapil Sood, 3-Feb-04, This RFC proposes a generic and configurable message authentication code (MAC) option for TCP. This work extends the practice defined in TCP MD5 Signature Option for BGP sessions [RFC-2385]. This RFC describes a new TCP option that allows any TCP-based application to enhance security in TCP connections. This option is configurable because it allows implementers to choose the digest mechanism of choice for each TCP connection. This digest mechanism constructs a MAC for each TCP segment, using a (preferably) connection specific shared secret key and components from TCP header and data. "The MIME Message/i18n Media Type", John Klensin, 3-Feb-04, Efforts to design an internationalization model for electronic mail frequently encounter situations in which an internationalized message -- perhaps one containing some headers with characters coded in UTF-8 -- must be converted and transported over a traditional, 7-bit infrastructure. This document provides a specification, building on the design of message/rfc822, for encapsulating messages with internationalized headers and/or body part content types. This specification is one of a group intended to provide a modified and extended email environment for fully internationalized email. If approved, it is expected to update the discussion of 'message/' content types in RFC 2046. "LDP graceful restart for planned outages", Ina Minei, 3-Feb-04, This document proposes an enhancement to the LDP graceful restart procedures defined in RFC 3478. The proposed extension allows operators to apply graceful restart only when the restart is planned (as oppossed to both planned and unplanned restart). "SCAF - Simple Caller Authorization Framework", Hadmut Danisch, 3-Feb-04, This memo describes a framework for simple caller authorization. It is a generalization of the RMX draft[1], which was designed to protect against e-mail fraud and spam. This new draft describes a general mechanism suitable for other protocols used in the Internet or other networks. It is designed to be simple and to not make use of any kind of secret, and to establish a cheap, robust, and lightweight authorization scheme. It is intended to be used for low security requirements. "Inter-area and Inter-AS MPLS Traffic Engineering", JP Vasseur, 4-Feb-04, This document proposes a set of signaling and routing mechanisms to establish and maintain generalized (packet and non-packet) MPLS Traffic Engineering Label Switched Path (MPLS TE LSPs) that span multiple areas or Autonomous Systems.. Each mechanism is described along with its applicability to the set of requirements. "EAP Method Requirements for Wireless LANs", Dorothy Stanley, Jesse Walker, Bernard Aboba, 12-Jul-04, The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and it is being presented as an IETF RFC for informational purposes. "A COPS Client-Type for Traffic Engineering", Christian Jacquenet, 4-Feb-04, This draft specifies a COPS (Common Open Policy Service) client-type designed for the enforcement of IP Routing and Traffic Engineering (TE) policies. The usage of this TE COPS client-type relies upon the activation of the COPS protocol for policy provisioning purposes. "Threats Relating to Transport Layer Protocols Handling Multiple Addresses", Masataka Ohta, 4-Feb-04, This document lists security threats related to IPv6 multihoming solutions, transport layer protocols of which are expected to handle multiple addresses of a host and an identity of the host is recognized not necessarily by a single address. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. "A Roadmap for TCP Specification Documents", Martin Duke, 4-Feb-04, This document contains an early draft of a 'road map' for the Requests for Comment (RFC) documents relating to TCP (Transmission Control Protocol), STD 7. This roadmap is intended to provide a brief summary of the RFC documents that define the current "NFSv4.1: Directory Delegations and Notifications", Saadia Khan, 4-Feb-04, This document proposes adding directory delegations and notifications to NFS Version 4 [RFC3530]. It is hoped that these changes will be part of a new minor version of NFS, such as NFSv4.1. "RSVP Graceful Restart Extensions", Reshad Rahman, 4-Feb-04, This document describes the extensions needed by certain features for the purpose of RSVP Graceful Restart (defined in[RFC3473]). One of these extensions refers to the ability of a node to recover the ERO in the case it has performed an ERO expansion before control plane restart. Also a small modification is proposed in the basic procedure to support simultaneous multiple node restarts in a network. Specifically, a node should use a non-zero Recovery Time while in the recovery phase. This allows a node to determine at restart time if any of its neighbors has previously restarted and it is currently in the recovery phase. "Protocol Extensions for ECRTP over MPLS", Jerry Ash, 3-May-04, VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP). We consider using MPLS to route ECRTP compressed packets over an MPLS LSP without compression/decompression cycles at each router. Such an ECRTP over MPLS capability can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use header compression at each router. In this draft we propose to use RSVP-TE extensions to signal the header compression context and other control messages between the ingress and egress LSR. We re-use the methods in ECRTP to determine the context. "Threat for Multi-homed Mobile Networks", Seungho Choi, 5-Feb-04, In mobile networks, the Mobile Router (MR) is an operational main entity. With multiple MRs, mobile networks can provide the stability of service. And, there already exist various multi-homing scenarios. However, because of mobility and MR-HA relations, there are several security problems in multi-homed mobile networks. In this draft, we identify threats to multi-homed mobile networks. And we will illustrate several scenarios of Denial-of-Service (DoS) attacks, Redirection attacks, and Replay attacks. "Light Weight AP Handover Protocol (LWAPHP)", Kiranjit Sidhu, 5-Feb-04, This document describes the Light Weight Access Point Handover Protocol (LWAPHP) which is a protocol allowing the access router to anchor and manage 802.11 handovers of the stations between a collection of wireless Access Points. The protocol like IEEE's IAPP aims to ensure that a station is connected to a single access point and provides an efficient context transfer mechanism during handover using neighbor graphs. "Analysis: HTTP Authentication for SIP", Hisham Khartabil, 5-Feb-04, The Session Initiation Protocol (SIP) provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. RFC 3261 fails to indicate the behaviour of SIP intermediaries and User Agents in certain scenarios. This documents presents such scenarios, analysis the currently available text, and where possible, offers a solution. "SIEVE Email Filtering: MIME Extension", Cyrus Daboo, 5-Feb-04, This document describes the SIEVE Email Filtering 'mime' extension which adds a new test for testing the values of MIME headers in a message. "Early Binding Updates for Mobile IPv6", Christian Vogt, 5-Feb-04, The long latency associated with Mobile IPv6's home-address and care-of-address tests can significantly impact delay-sensitive applications. We propose a modified binding-update procedure that evades the latency of both address tests. The modified binding update runs in half, or less, of the time that a standard binding update takes. Moreover, the modified binding update is nearly equivalent to the standard procedure with respect to security, and it increases the resources required at the correspondent node only marginally. The modification is realized as an optional, and fully backward-compatible, extension to Mobile IPv6. "Early IANA Allocation of Standards Track Codepoints", Kireeti Kompella, Alex Zinin, 24-Jun-04, This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the 'Standards Action' IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. "Conveying a Conference Policy Uniform Resource Identifier (URI) in the Session Initiation Protocol (SIP)", Hisham Khartabil, 18-May-04, The Session Initiation Protocol (SIP) defines the Call-Info header field. This header field delivers additional information about the originator or recipient of a SIP request. Information in the Call-Info is generally a Uniform Resource Identifier (URI), and the exact purpose of this URI is described with the "purpose" parameter. This document introduces a new purpose parameter value of "conf-policy" that can be used by a conference server to indicate to a conference participant User Agent (UA) that the URI carried in the Call-Info header field is a URI for accessing the conference policy of a particular conference. "DHCP Option for Configuring IPv6-in-IPv4 Tunnels", Pyungsoo Kim, Soohong Park, 21-Jul-04, This document provides a mechanism by which the DHCPv4 servers can provide information about the configured IPv6-in-IPv4 tunnel end-points. The IPv4/IPv6 dual-stack nodes can use this information to set up a configured tunnel to the tunnel end-point to obtain IPv6 connectivity. "An IP Forwarding Policy Information Base", Mohammed Boucadair, 5-Feb-04, This draft specifies a set of Policy Rule Classes (PRC) for the enforcement of an IP forwarding policy by network devices. Instances of such classes reside in a virtual information store, which is called the IP Forwarding Policy Information Base (PIB). The corresponding IP forwarding policy provisioning data are intended for use by a COPS-PR TE Client-Type, and they complement the PRC classes that have been defined in the Framework PIB. "The BGP QOS_NLRI Attribute", Geoffrey Cristallo, 5-Feb-04, This draft specifies an additional BGP4 (Border Gateway Protocol, version 4) attribute, named the 'QOS_NLRI' attribute, which aims at propagating QoS (Quality of Service)-related information associated to the NLRI (Network Layer Reachability Information) information conveyed in a BGP UPDATE message. "DoS vulnerability of TCP by acknowledging not received segments", Arturo Azcorra, Carlos Bernardos, Ignacio Soto, 5-Feb-04, TCP relies in communication peers to implement congestion control by hosts voluntary limiting their own data rate. Nevertheless this assumption introduces unsolved DoS attack opportunities. A DoS attack can be easily performed by a host that acknowledges TCP segments not yet received (maybe even not sent). This document presents and briefly describes the problem, already identified and pointed before, but also shows than it can be easily performed (with very interesting results) and proposes some server-side modifications to TCP stack in order to make this attack more dificult to perform. "Mixmaster Protocol Version 2", U Moeller, 25-May-04, Most e-mail security protocols only protect the message body, leaving useful information such as the identities of the conversing parties, sizes of messages and frequency of message exchange open to adversaries. This document describes Mixmaster version 2, a mail transfer protocol designed to protect electronic mail against traffic analysis. "Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur, 5-Feb-04, This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for support of structure-agnostic [PWE3-SATOP] and structure- aware [PWE3-CESoPSN], [PWE3-TDMoIP] pseudowires. "An approach for Routing at Flow level", Christophe Proust, 5-Feb-04, This document proposes an approach that aims at load balancing flows among multiple routes that are estimated to be slightly loaded. Mainly, it designs a router-based, end-to-end, congestion control mechanism by means of a piggybacking procedure which is distributed both in routers and terminals. This document proposes a set of functional extensions that might be applied to the IPv4 protocol and to the ISIS routing protocol "State update during a SIP dialog", John Elwell, 2-Jul-04, This document examines the need for updating state information, such as remote party identity, during a SIP dialog. It explores existing mechanisms that might be appropriate and proposes minor clarifications to existing RFCs and drafts to achieve this. "Node ID based RSVP Hello: A Clarification Statement", Reshad Rahman, Danny Prairie, Dimitri Papadimitriou, Zafar Ali, 16-Apr-04, Use of node-id based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than RSVP Hellos, use of node-id based Hellos is optimal for detecting signaling adjacency failure for RSVP- TE. Nonetheless, this implied behavior is unclear and this document formalizes use of node-id based RSVP Hello sessions as a best current practice (BCP) in some scenarios. "IS-IS extensions for advertising router information", JP Vasseur, 19-Jul-04, This document defines a new optional IS-IS TLV named CAPABILITY TLV, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. "Protected Entertainment Rights Management (PERM)", John Gildred, 28-Jun-04, This document describes the Protected Entertainment Rights Management (PERM) protocol for management of usage rights to digital entertainment content. PERM is not intended to replace existing copy protection and conditional access systems. Rather it is intended to complement such systems by providing standardized methods of device and user authentication, content protection and content rights management across heterogeneous data networks. PERM does not impose any content usage policy upon an implementation of the PERM protocol. PERM defines a common method for policy enforcement, and implementors are free to design and enforce their own policy by using the features and conventions of the PERM protocol. "Congestion Notification Process for Real-Time Traffic", Jozef Babiarz, 20-Jul-04, This memo specifies the usage of Explicit Congestion Notifications (ECN) markings for real-time flows that use UDP, such as voice, video conferencing and multimedia streaming. This memo tries to reuse as much of RFC 3168, "The Addition of Explicit Congestion Notification to IP", as possible. However, we found it necessary to introduce new ECN semantics for real-time UDP flows. For real-time UDP flows, this memo describes how the network performs ECN marking when congestion is experienced, but it is left up to the application designers to define how end systems should react to ECN bit marking. For illustration purpose, an example is provided showing how ECN for real-time UDP flows can be used for admission control of VoIP flows. "OAM Procedures for VPWS Interworking", Mustapha Aissaoui, 20-Jul-04, This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). "ECN Nonces for Stream Control Transmission Protocol (SCTP)", Sourabh Ladha, 6-Feb-04, This document describes the addition of the ECN-nonce RFC3540 [5] to the Stream Control Transmission Protocol (SCTP) RFC2960 [8]. The ECN-nonce reduces the vulnerability of ECN senders to misbehaving receivers that conceal congestion signals like ECN marks and packet losses. The ECN-nonce approach is different in SCTP because SCTP uses chunks for extensible protocol features and is selective acknowlegement (SACK)-based; this document describes those differences. In particular this document describes (1) protocol extensions in the form of a single new parameter for the INIT/ INIT-ACK chunks and a single bit flag in the SACK chunk, and (2) rules governing the sender and receiver side implementation. This document outlines a minimum response that an SCTP sender should apply after detecting a misbehaving receiver. "PANA Framework", Prakash Jayaraman, 6-Feb-04, PANA design provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. This I-D defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: using PANA over DSL networks and WLAN networks. "The BU-trigger method for improving", Killyeon Kim, 6-Feb-04, In Mobile IPv6 environment, TCP connections between MN (mobile node) and CN (correspondent node) suffer a significant degradation in performance in the form of poor throughput and very high interactive delays during handoff. This note describes an optional modification of TCP's congestion control mechanism for performance enhancement by using Binding Update messages to invoke TCP's congestion control processing. This modification is applied to TCP of CN side, and no additional processing requirement is added to MN to save MN's power. "Definitions of Supplemental Entity Managed Objects", Kaj Tesink, 6-Feb-04, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it describes additional objects that supplement those defined in the Definitions of Managed Objects for the Entity MIB document [RFCzzzz]. "Fast Multicast Protocol for Mobile IPv6", Kyungjoo Suh, 6-Feb-04, This document defines the Fast Multicast Protocol for Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile node (MN) can receive multicast data with reduced loss and delay after handoffs. The proposed protocol can be implemented by the simple modification of the Fast Handovers protocol [1] so that it can be easily applied to the Fast Handovers for Mobile IPv6. This document does not need a certain assumption of a specific multicast routing protocol, so that any existing multicast routing protocol can be used with the proposed protocol. "Guidelines for IPFIX Implementations on Middleboxes", Juergen Quittek, 6-Feb-04, This memo gives recommendations for the implementation of IP Flow Information eXport (IPFIX) metering processes and IPFIX exporting processes on middleboxes, such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc. Middlebox functions potentially change properties of traffic flows passing the box, for example NATs change addresses in header fields and firewalls change the numbers of packets and bytes belonging to a traffic flow. An IPFIX implementation on a middlebox should reflect this by the way it selects and reports the observation point and by the way it measures and reports traffic flows. "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", Pasi Eronen, Hannes Tschofenig, 6-Feb-04, This document specifies new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties, and do not require any public key operations. "Partial Publication of Presence Information", Mikko Lonnfors, 17-May-04, The size of the published presence information document may be large. As specified in "Event State Publication Extension to the Session Initiation Protocol (SIP)" a presence user agent publishes a full event state of presence information in every publication operation which modifies the current event state. This is done regardless of which presence information has been changed compared to the earlier publications. "Implementation and Performance of Flooding-based Fault Notification", Richard Rabbat, 6-Feb-04, This memo presents the observations and results obtained from two test-beds designed to study and evaluate the performance and feasibility of rapid fault notification via flooding. Flooding-based fault notification [2,3] is an alternative to signaling-only notification approaches, which has the advantages of: scalability and the ability to meet bounded recovery-time constraints, if needed. We implemented flooding-based notification at both the transport and packet layers. For optical transport networks the flooding mechanism (e.g. [3]), was realized using enhancements to the Link Management Protocol (LMP), while for packet/MPLS networks the flooding was realized using enhancements to Open Shortest Path First (OSPF). We present experiences and performance measurements from these implementations on FreeBSD/Linux platforms, and also present the protocol enhancements that were made to LMP and OSPF, respectively, to realize the rapid flooding function. "IS-IS MPLS Traffic Engineering capabilities", JP Vasseur, 6-Feb-04, This document proposes IS-IS traffic engineering capability sub-TLVs related to various MPLS Traffic Engineering capabilities. These sub- TLVs are carried within the IS-IS CAPABILITY TLV. "Reoptimization of MPLS Traffic Engineering loosely routed LSP", JP Vasseur, Yuichi Ikejiri, 9-Jul-04, This document defines a mechanism for the reoptimization of loosely routed MPLS Traffic Engineering LSPs. A loosely routed LSP follows a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and zero or more strict hop(s). "Control Protocol Extensions for Setup of TDM Pseudowires", Sasha Vainshtein, 21-Jul-04, This document defines extension to the PWE3 control protocol [PWE3- CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of TDM pseudowires. "Location-switch for Call Processing Language (CPL)", Xiaotao Wu, Henning Schulzrinne, 9-Feb-04, This document introduces two switch nodes named location-switch and location-relation-switch to the Call Processing Language (CPL). The new nodes enable CPL to handle location-based services. "Soft-Handoff-Supporting Motion-Prediction-and-QoS-Negotiation-Based Fan- Shaped Flexible Resource Reservation and Rerouting Mechanisms in Mobile Wireless Internet", Xingwei Wang, 9-Feb-04, Considering movement characteristics of mobile users, the authors have proposed a kind of soft-handoff-supporting motion-prediction- and-QoS-negotiation-based fan-shaped flexible resource reservation mechanism, which can provide QoS guarantees to mobile user effectively. The signaling overhead for handoff gets effective control by reverse rerouting mechanisms, being much advantageous than partial rerouting and complete rerouting. Combining the above two mechanisms, soft handoff can be guaranteed and high resource utilization can be attained in the mobile wireless Internet. Simulation has shown the proposed mechanisms are both efficient and effective. "SMTP Operational Experience in Mixed IPv4/v6 Environments", Motonori Nakamura, Jun-ichiro Hagino, 11-May-04, This document talks about SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the problems that exist in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. "A Flexible Method to Validate SMTP Senders in DNS", John Levine, 26-Apr-04, Flexible Sender Validation (FSV) is a lightweight validation technique to detect and deter some kinds of e-mail address forgery. It publishes information in the DNS about IP addresses authorized to send mail for a domain, one in a family of IP based mail validation proposals dating back to Paul Vixie's original in 2002[5]. FSV uses redundant copies of IP data to permit both efficient use by very high-volume mail servers, and simple implementation on low to moderate volume mail servers. "Ad-Hoc URI List Management in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 9-Feb-04, This document defines two mechanisms to manage ad-hoc URI lists in SIP. In the first mechanism, the user agent sends an updated version of the entire list to the server. In the second mechanism, the server provides the user agent with a URI (e.g., http) that can be used to manipulate the list using an out-of-band mechanim (e.g., XCAP). We define the Associated-List-Manipulation header field that carries a URI that allows manipulating an ad-hoc list. "A Transaction Event Package for the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 9-Feb-04, SIP provides a SIP Events notification framework that is extensible throught the addition of event packages. This document defines a transaction event package for the SIP Events notification, along with a data format used in notifications for this package. The transaction package allows users to subscribe to a resource in an application server and receive notifications about the changes in state of transactions the application server initiates as part of a service. Additionally, we define a new SIP Associated-Transactions-State header field that allows a server to return a subscrible URI that provides transactions notification information. "Refering to Multiple Resources in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 9-Feb-04, This document defines extensions to the SIP REFER method so that this method can be used to refer to multiple resources. These extensions include the use of pointers to URI-lists in the Refer-To header field, the use of bodies to describe the requests to be sent by the server, and the use of a new event package to report the state of several transactions. "RMD (Resource Management in Diffserv) QoS-NSLP model", Attila Bader, 9-Feb-04, This draft describes a local QoS model, denoted as Resource Management in Diffserv (RMD) QoS model, for NSIS that extends the IETF Differentiated Services (Diffserv) architecture with a scalable admission control and resource reservation concept. The specification of this QoS model includes a description of its QoS parameter information, as well as how that information should be treated or interpreted in the network. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", Markus Isomaki, 9-Feb-04, This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is mainly intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs based on which it builds the overall presence state for the presentity. "Signalling Interworking for ATM Virtual Private Wire Service", Matthew Bocci, 19-Jul-04, This Internet Draft describes the ATM Forum method [8] for control plane interworking for Asynchronous Transfer Mode (ATM) pseudo wires, where Provider Edge nodes (PEs) on both sides of an MPLS Packet Switched Network (PSN) connect edge ATM networks using the Private Network-Network Interface (PNNI)[10] or the ATM Inter-Network Interface (AINI) [11]. In this method, ATM signalling and routing messages are tunnelled over the PSN using dedicated pseudo wires, enabling ATM pseudo wires carrying user traffic to be established and release dynamically by ATM. The method does not require changes to existing IETF defined protocols in order to support all features of PNNI and AINI. "OSPF MPLS Traffic Engineering capabilities", JP Vasseur, 9-Feb-04, This document proposes OSPF traffic engineering capability TLVs and is composed of several sub-TLVs related to various MPLS Traffic Engineering capabilities. These OSPF TE capability TLVs are carried within the OSPF router information LSA (opaque type of 4, opaque ID of 0). "FTP Extensions for recursive and archived file transfers", Rajesh Somasundaran, 9-Feb-04, This document describes some extensions to the File Transfer Protocol [1]. These extensions will allow the protocol recursive and archived file transfers. The following new service commands are introduced for FTP: STRC (Store Recursive) RERC (Retrieve Recursive) STAR (Store Archive) REAR (Retrieve Archive) DLST (Directory List) "Connectivity Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, 9-Feb-04, This document defines a new connectivity precondition for the Session Description Protocol precondition framework described in RFC 3312. A connecitivity precondition can be used to delay session establishment or modification until media stream connectivity has been verified successfully. "Display of Internationalized Mail Addresses Through Address Mapping", Paul Hoffman, 9-Feb-04, Mailbox names often represent the names of human users. Many of these users throughout the world have names that are not normally represented by the users with just the ASCII repertoire of characters, and would therefore like to use their real names in their mailbox names. This protocol describes how mail clients can be enhanced to display mailbox names in non-ASCII characters through the use of a new RFC 2822 header field called 'Address-map'. "Host Identity Protocol (HIP) Rendezvous Mechanisms", L Eggert, 22-Jul-04, This document discusses rendezvous mechanisms for the Host Identity Protocol (HIP). Rendezvous mechanisms, such as HIP Rendezvous Servers, improve operation when HIP nodes are multi-homed or mobile. They can also facilitate communication between HIP and non-HIP nodes. Possible rendezvous mechanisms differ in performance, compatibility, and impact on the HIP and Internet architectures. "Deterministic Route Redistribution into BGP", Enke Chen, 9-Feb-04, In this document we propose an enhancement to the BGP route selection algorithm that would make the interaction of redistributed routes and other BGP routes deterministic, thus facilitating the deployment of various routing requirements. The proposed enhancement is backward compatible. "Definition of an IS-IS Link Attribute sub-TLV", JP Vasseur, 9-Jul-04, This document defines a sub-TLV called ‘‘Link-attributes’’ carried within the TLV 22 and used to flood some link characteristics. "Procedure for Handling Liaison Statements Between Standards Bodies", Fred Baker, 9-Jul-04, This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF/ISOC to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. "Interworking between Session Initiation Protocol (SIP) and QSIG for call transfer", JF Rey, 9-Feb-04, This document specifies call transfer interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. "Problems identified associated with the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 20-Jul-04, This draft describes several problems that have been identified with the Session Initiation Protocol's non-INVITE transaction. "Actions addressing identified issues with the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 20-Jul-04, This draft describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFCs 3261 and 3263. "Webspacelets - compact webspace units", Hadmut Danisch, 9-Feb-04, This draft proposes to pack collections of static web objects belonging together such as HTML pages, graphics etc. into single archive files and to transport and treat them as a single compact object. "RTP No-Op Payload Format", Flemming Andreasen, 9-Feb-04, This document defines an no-op payload format for the Real-time Transport Protocol (RTP), and a mechanism to request an immediate RTCP report. This can be used to verify RTP connectivity and to keep Network Address Translator (NAT) bindings and Firewall pinholes open. "Future work addressing issues with the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 9-Feb-04, This draft explores several possible remedies for a set of issues that have been identified with the Session Initiation Protocol's non-INVITE transaction. These proposed solutions are in rough form and have not yet accumulated working group consensus. They range from minor extensions to protocol behavior to fundamentally changing the non-INVITE transaction model. "Remote Authentication Dial In User Service (RADIUS) Redirection", Avi Lior, 20-Jul-04, In certain scenarios there needs to be a method to force the users traffic to a specific location. This document describes several methods that are available to be used with Remote Authentication Dial In User Service (RADIUS) Protocol and defines three new RADIUS attributes: NAS-Filter-Rule, Redirect-Id and Redirect-Rule. "Framework for PNNI to PSN Interworking", David Watkinson, 20-Jul-04, This document defines the framework for interworking mechanisms between PNNI signaled ATM networks and the set of Public Switched Networks (PSN) supported by this working group. "pNFS Problem Statement", Garth Gibson, 20-Jul-04, This draft considers the problem of limited bandwidth to NFS servers. The bandwidth limitation exists because an NFS server has limited network, CPU, memory and disk I/O resources. Yet, access to any one file system through the NFSv4 protocol requires that a single server be accessed. While NFSv4 allows file system migration, it does not provide a mechanism that supports multiple servers simultaneously exporting a single writable file system. This problem has become aggravated in recent years with the advent of very cheap and easily expanded clusters of application servers that are also NFS clients. The aggregate bandwidth demands of such clustered clients, typically working on a shared data set preferentially stored in a single file system, can increase much more quickly than the bandwidth of any server. The proposed solution is to provide for the parallelization of file services, by enhancing NFSv4 in a minor version. "Mobile IPv6 and Firewalls", Franck Le, 20-Jul-04, Firewalls are an integral aspect of a majority of IP networks today given the state of security issues, threats and vulnerabilities to data networks. IP networks today are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. IPv6 networks are growing at a slow rate. Firewalls for IPv6 networks are still maturing and in development. The IETF has recently standardized Mobile IPv6 which adds mobility support to IPv6. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks today do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will hamper large-scale deployment of the protocol. This document presents in detail some of the issues that people deploying IPv6 networks which include firewalls should consider when expanding the scope to support Mobile IPv6 as well. The issues are not only applicable to firewalls protecting corporate networks, but are also applicable in 3G mobile networks such as GPRS/UMTS and cdma2000 networks where packet filters are implemented in the GGSN in GPRS/UMTS networks and the PDSN in cdma2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG. "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", Alper Yegin, Hannes Tschofenig, Dan Forsberg, 9-Feb-04, DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. "Transporting Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 9-Feb-04, This document defines how to send information encoded in the CPIM Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP). "Identification of Services in RPID (Rich Presence Information Data)", Adam Roach, 9-Feb-04, This document describes a system by which one can identify certain classes of service using the capabilities published in presence documents. By identifying the probable presence of such services, the chances of a succesful rendezvous are increased. "NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept", Jerry Ash, 11-Feb-04, This draft describes a proof-of-concept example of NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. The example is based on standardization work in the ITU-T of QoS signaling requirements. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. Together with the NSIS Transport Layer Protocol (NTLP), the NSLP provides functionality similar to RSVP and extends it. This draft provides a proof-of-concept example of the NSIS NSLP for QoS signaling. The example is based on standardization work in the ITU-T on QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in terms of the QoS-signaling model and Qspec template given in the 'NSLP for QoS Signaling' specification [QoS-SIG]. "Administrative Control of RSVP Hello and Graceful Restart Procedure", Zafar Ali, 9-Feb-04, Ability to administratively shutdown RSVP Hellos and Graceful Restart (GR) procedure without impacting the traffic is a desirable network operation. Furthermore, there are applications that run RSVP Hellos with intervals on the order of milliseconds. This poses a requirement to reduce the number of RSVP messages to a minimal required count. Fortunately RSVP Hellos are not mandatory and are only required to run when needed. This allows applications to remove an RSVP Hello session, when it is not needed. This ID proposes a procedure to remove RSVP Hello and/ or GR sessions for administrative or optimization purposes. "Web OF Physical Objects Uniform Resource Identifiers", Syed shariyar, 2-Mar-04, This document defines Uniform Resource Identifiers for Physical Objects and human.It provides a proposal for the implementation of the Concept, ”Physical resources as well as humans should be accessible over the Internet and an information object is on the web if it can have a URI ”. It emphasizes on the fact that people should be able to access the physical resources,they possess or even humans,from anywhere in the world through a common standard(URI) e.g. accessing a car from a remote location,or finding the location of the child via URI.As URIs are needed in RDF,XML,so by using them for ubiquitous resources we could easily integrate the world of ubiquitous computing and semantic web i.e. Ubiquitous Semantic Web. "Quarantine Model Overview for IPv6 Network Security", Satoshi Kondo, 21-Jul-04, In the current Internet, a site is often secured by firewall, which filters bogus traffic from outside at the border of the site. This 'Border Defense Model', however, has lots of potential security issues, and also prevents a deployment of next-generation Internet applications and services. This memo surveys the security issues of the Border Defense Model', and proposes a network architecture 'Quarantine Model', to prevent that security issues and promote a deployment of the next-generation Internet. "Interoperability of the 'audio/mpa-robust' RTP Payload Format", Ross Finlayson, 9-Feb-04, In order for the 'audio/mpa-robust' RTP payload format specification to advance from Proposed Standard to Draft Standard, it is required to demonstrate interoperability for all functionality described by the specification. This document describes the interoperability shown between different implementations of this specification. "Transmission of IPv6 Packets over WiFi Networks", Soohong Park, Syam Madanapalli, O. Rao, 9-Feb-04, WiFi networks use radio technologies defined by IEEE in 802.11x to provide secure, reliable, fast wireless connectivity. A WiFi network can be used to connect computers to each other, to the Internet, and to Wired Ethernet Networks. "Updating the Connected Party in SIP", Cullen Jennings, 9-Feb-04, Communication systems often have situations in which the party at the far end of the call changes, making it necessary to have a way to notify the near end of the new identity at the far end. This draft discusses ways to update this "A SIP application using INFO message for IP premise control", Choon Kyu Kim, 9-Feb-04, This document describes the INFO usage for IP-surveillance application. SIP is used as a means of incorporating terminals of different vendors. In this draft, mid-control commands, for example, retrieving server images or saving images in the server are defined and delivered as session names of INVITE messages. IN addition to that, INFO definitions specific to the application are described. For example, camera control like PTZ(Pen, Tilt, Zoom) information is defined for the purpose of standardization of controls. "Interoperability between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) Extensions for Instant Messaging and Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 29-Apr-04, This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of instant messages and presence information between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. "INFO Usage Examples for Network-based Mid-Call Service", Jinkyung Hwang, 9-Feb-04, This document describes the INFO usage examples for network based mid-call service. Mid-call based services are for example, Call Transfer, Call Waiting, and Three-Way Calling. Other possible mid- call services are useful and important, even more in IP multimedia network. The cases described in SIP service examples (draft-ietf- sipping-service-examples-05) are Terminal-basis. Since the service procedures are fixed in the Terminal, the features are not extensible. This document propose network-based mid-call control mechanism with INFO and show examples that simple mid-call request (INFO) from the Terminal, the network application server provide various mid-call services by prompting user through the Media Server, according to the subscription information of the user. "Requirements for the Resilience of Control Plane in GMPLS", Young Hwa Kim, 9-Feb-04, This document describes requirements for providing the resilience capability of control plane (in other words, control network) in GMPLS. As known in generally, control plane consist of control entities, control channels, and control nodes. This contribution, as a document that proposes a framework to provide the resilience capability of control plane, include terminologies, basic concepts of control networks, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP. "Operational Approach to achieve IPv6 multihomed network", Katsuyasu Toyama, 9-Feb-04, This document proposes an operational solution of IPv6 mulithoming. This approach is that a group of providers administrates cooperatively one prefix and one autonomous system number (ASN) for only their multihoming customers; each multihomed customer is assigned a longer prefix, such as /48, but only address block of /32 allocated by RIR is advertised through the providers of the group to the global IPv6 Internet. This approach does not need allocation of provider-independent address block to each customer who needs multihomed network, and therefore saves IPv6 address space. "A model for IETF Process Experiments", John Klensin, Spencer Dawkins, 14-Apr-04, The IETF has designed process changes over the last ten years in one of two ways -- announcement by the IESG, sometimes based on informal agreements with limited community involvement, and awareness, and formal use of same mechanism as is used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. There is a middle ground. This document proposes a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than the ones that have been attempted previously. "Narrowing IESG Process Flexibilities", John Klensin, 9-Feb-04, One basic model for IETF operations is that the IESG is given general guidance in specific procedural documents but sufficient discretion and flexibility to adapt the rules and make new ones in order to make the IETF work smoothly. This model underlies a number of reform proposals, including recent ones from this author. However, there has been an undercurrent of suspicion from some members of the community -- suspicion that the IESG is abusive of that discretion and cannot be trusted. Those suspicions have, to some extent, been reinforced by questions about IESG-adopted procedures that seem to contradict procedures approved by the community and documented in BCPs. The community cannot move forward with models based on both trust and distrust in the IESG's ability, and level of responsibility, to do its job. In an attempt to focus this part of the debate, this document proposes to dramatically narrow IESG's scope of authority and discretion. In particular, it proposes to move the IESG, procedurally, onto an 'anything not explicitly required is forbidden' model, and, indeed, a very narrow and punitive member of that family. While the author believes this would be a terrible idea, it appears to be time that the community either focuses on it and moves in this direction or stops wasting time hinting about it. "Mobile IPv6 AAA Problem Statement", Hiroyiki Ohnishi, 9-Feb-04, Mobile IP achieves that Mobile Node(MN) moves from one subnet to another. If MN moves across different administrative domains in a commercial network, Mobile IPv6 requires AAA's support. This document describes the problem statement to use AAA functions in Mobile IPv6. "Marking Mail Transfer Agents in reverse DNS with TXT RRs", Markus Stumpf, 28-May-04, In contrast to other more extensive approaches to deal with unsolicited email, commonly called "spam", this memo discusses a very simple authentication scheme. It uses marking of hosts in reverse DNS (IN-ADDR.ARPA and IP6.ARPA zones) to allow the receiving mail transfer agents to decide whether the connecting (sending) host is a designated mail transfer agent (MTA) or not. Despite being a weaker scheme than most of the other proposals currently discussed, it can reduce the amount of spam and viruses/ worms significantly and has the advantage that it can be implemented based on existing and well-established Internet technology like DNS without any changes to that technology. "Attributes for Access Network Location and Ownership Information", Farid Adrangi, 9-Feb-04, This document describes RADIUS Authentication, Authorization, Accounting (AAA) attributes that are used to convey the Access Network’s operational ownership and Location Information to a Home Service Network. "Access Network Bandwidth Capability", Farid Adrangi, 21-Jul-04, This document describes bandwidth profile parameters and a protocol framework that enables an AAA server to specify the parameters that should be allocated by the access network for duration of an authorized user session. "The Archived-At Email Header", Martin Duerst, 21-Jul-04, This memo defines a new email header, Archived-At:, to provide a direct link to the archived form of an individual mail message. "VPLS Applicability", Marc Lasserre, X Xiao, Cesar Garrido, Yetik Serbest, 21-Jul-04, Virtual Private LAN Service (VPLS) is a layer 2 VPN service that provides multipoint connectivity in the form of an Ethernet emulated LAN, while usual L2 VPN services are typically point-to-point. Such emulated LANs can span metropolitan area networks as well as wide area networks. "NAT Classification Results using STUN", Cullen Jennings, 20-Jul-04, IETF has several groups that are considering the impact of NATs on various protocols. Having a classification of the types of NATs that are being developed and deployed is useful in gauging the impact of various solutions. This draft records the results of classifying NATs using the STUN protocol. This work is being discussed on the midcom@ietf.org mailing list. "SIMPLE Instant Messaging Sessions (SIMS)", Cullen Jennings, 9-Feb-04, This document defines a protocol for conveying binary MIME content in near-real time, peer-to-peer or through one or more relays, with the opportunity for store and forward. SIMS (SIMPLE Instant Messaging Sessions) can be used as a standalone protocol, or in conjunction with a rendezvous or session setup protocol such as SIP. While SIMS was originally envisioned as an alternative to the Media Session Relay Protocol (MSRP), one section of this document describes how these ideas could be applied as MSRP extensions for features such as chunking, relay connection multiplexing, and prevention of head-of-line blocking. "IP/LDP Local Protection", Alia Atlas, 9-Feb-04, This document defines an architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failure until the router has converged. When computing the primary next-hop for a prefix, a router S also determines an alternate next-hop which can be used if the primary next-hop fails. The alternate can be either a loop-free alternate, which goes to a neighbor whose shortest path to the prefix does not go back through the router S, or a U-turn alternate, which goes to a neighbor whose primary next-hop to the prefix is the router S, and which has itself a loop-free node-protecting alternate, which thus does not go through router S to reach the destination prefix. "OSPFv2 Extensions for Link Capabilities and IP/LDP Local Protection", Alia Atlas, 9-Feb-04, This document proposes an extension to OSPF Version 2 for advertising link capabilities using the extensions defined for traffic engineering. The link capabilities are defined there for future extensibility. To support the signaling requirements of IP Local Protection [IP- LOCAL-PROTECT], this document defines two bits in the proposed link capabilities extension. Additionally, this document reserves a bit in the Router Capabilities TLV defined in [OSPF-RTR-CAP]. This document specifies additional information that can inserted in OSPF LSAs to convey link capabilities that may be useful in certain applications. In particular, a router may indicate that zero or more of its links may be used by an upstream router as an alternate, SPT- disjoint path to an arbitrary destination D. Additionally, a router may convey that zero or more of its links are capable of breaking a U-turn, which may be described as a single-hop forwarding loop between two router's. This means that a router can detect the presence of a forwarding loop by recognizing that traffic to a destination is being received from a neighbor to which it has forwarding state pointing back to the same neighbor for that destination. In such a situation, it will switch to a loop-free node-protecting alternate until new primary forwarding state has been installed, thus breaking the U-turn. Therefore, the immediate applicability for these two link capabilities is in support of local protection in the event of a link and/or node failure while the OSPF area is reconverging onto a new topology. "ISIS Extensions for Signaling Local Protection Capabilities", Alia Atlas, 9-Feb-04, This document specifies additional information that can inserted in IS-IS LSPs to convey link capabilities that may be useful in certain applications. In particular, an IS may indicate that zero or more of its links may be used by an upstream IS as an alternate, SPT-disjoint path to an arbitrary destination D. Additionally, an IS may convey that zero or more of its links are capable of breaking a U-turn, which may be described as a single-hop forwarding loop between two IS's. This means that a router can detect the presence of a forwarding loop by recognizing that traffic to a destination is being received from a neighbor to which it has forwarding state pointing back to the same neighbor for that destination. In such a situation, it will switch to a loop-free node-protecting alternate until new primary forwarding state has been installed, thus breaking the U-turn. Therefore, the immediate applicability for these two link capabilities is in support of local protection in the event of a link and/or node failure while the IS-IS area is reconverging onto a new topology. "Technique for Method-Specific Fast EAP Rekeying", Charles Clancy, 10-Feb-04, A technique for fast rekeying with EAP is described here. The actual implementation is specific to each EAP method, but in general a master session key can be evolved with each client association such that the authentication requires as many packets exchanges as a 'canned success'. The concept is explained, with a specific implementation described for EAP-TLS with 802.11i. "Emergency Services for Internet Telephony Systems", Henning Schulzrinne, Brian Rosen, 20-Jul-04, Summoning emergency help is a core feature of telephone networks. This document describes how the Session Initiation Protocol (SIP) can be used to provide advanced emergency services for voice-over-IP (VoIP). The architecture employs standard SIP features and requires no new protocol mechanisms. DNS is used to map civil and geospatial locations to the appropriate emergency call center. "Multi-party Message Sessions using the Message Session Relay Protocol", Aki Niemi, Miguel Garcia-Martin, 10-Feb-04, The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a session, established using the Session Initiation Protocol (SIP). This document describes how MSRP can be used to create multi-party message sessions using the tightly coupled conferencing model. It defines conventions and extensions for enabling features similar to many existing services in the Internet, e.g., Internet Relay Chat (IRC) based chat rooms, such as setting up nicknames, sending private messages to a subset of the multy-party conferece, etc. "The AAA and AAAS Uniform Resource Identifier (URI) schemes", Miguel Garcia-Martin, 10-Feb-04, This memo normatively defines the ABNF of the AAA and AAAS URI schemes and provides instructions to IANA to register them in the namespace of registered URI schemes. "Update to RFC 2418 Regarding the Management of IETF Mailing Lists", Margaret Wasserman, 1-Jun-04, This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. "Emergency Call Information in the Domain Name System", Brian Rosen, 21-Jul-04, Location of a caller is essential to processing an emergency call. Location is needed to correctly route the call, and to correctly dispatch help to the right place. Location can be specified in geographic (lat/lon/altitude) or civil (country/provin ce/city/ street/floor/room) forms. Determining which Emergency Response Center (ERC) should receive the call requires comparing the callers location to a service area boundary description, which may require location in geo form. Dispatching a call generally requires a civil location. There is a need for a way to translate a civil to a geo or vice versa to the resolution of a room. There is also a need to publish the service area boundary of the ERC and the emergency responders. Further, there is a need for a database of legal civil addresses (sometimes called a Master Street Address Guide) that civil locations may be verified against to assure correctness, and uniformity of naming so that dispatch is accurate. The memo proposes a new DDDS application and a new POLY RR to assist emergency calls. "Lightweight MTA Authentication Protocol (LMAP) Discussion and Applicability Statement", Alan DeKok, 20-Apr-04, Lightweight MTA Authentication Protocol (LMAP) is the general term for a family of proposed protocols to help address the spam problem by permitting domains to publish the set of SMTP clients which may use their name in the EHLO/HELO and MAIL FROM fields. SMTP servers can use this information to determine if a client is consensually using a domains name. This document discusses the applicability, and the costs and benefits of wide-spread deployment of the protocol family. "How to Gain Prominence and Influence in Standards Organizations", Donald Eastlake 3rd, 10-Feb-04, Following some simple guidelines can make it easier for you to gain prominence and influence in most standards organizations. "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", Florent Parent, Marc Blanchet, 15-Jun-04, A tunnel broker with the Tunnel Setup Protocol(TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negociate the tunnel with the broker. The negociation involves authentication, authorization, tunnel information such as IP addresses, prefixes when the client is a router, DNS information such as the NS for the inverse zone corresponding to the delegated prefix, etc. Some parameters may be proposed by the broker, such as the transport over UDP IPv4 where an IPv4 NAT is found in the path between the client and the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker [3]. "Signaling Protocol for Access Service Network using LDP", Masahiro Matsuda, 22-Mar-04, Access Service Network is a Network Access Provider's network. In Access Service Network, subscribers can connect to various ISPs/VPNs by specifying appropriate authentication information. This draft describes a signaling protocol based on PWE3 control protocol [PWE3- SIG] for Access Service Network which uses IEEE 802.1x as a user authentication protocol. The protocol sets up a special kind of VPLS which does not forward broadcast/multicast Ethernet frames between subscribers for better security. "Mapping ICE (Interactive Connectivity Establishment) to RTSP", Thomas Zeng, 10-Feb-04, This memo describes a mapping from ICE (Interactive Connectivity Establishment) to RTSP for the purpose of Network Address Translator (NAT) traversal for RTSP protocol. In order to become compatible with ICE, the Transport header in RTSP is extended with new syntax elements. This memo presents a few examples RTSP coversations that uses ICE for NAT/firewall traversals. "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", Joseph Salowey, 10-Feb-04, This document defines the EAP based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST enables secure communication between a client and a server by using the EAP based Transport Layer Security (EAP-TLS) to establish a mutually authenticated tunnel. However, unlike current existing tunneled authentication protocols, EAP-FAST also enables the establishment of a mutually authenticated tunnel by means of symmetric cryptography. Furthermore, within the secure tunnel, EAP encapsulated methods can ensue to either facilitate further provision of credentials, authentication or authorization policies by the server to the client. "Bidirectional Forwarding Detection Management Information Base", Thomas Nadeau, Zafar Ali, 10-Feb-04, This draft 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 Bidirectional Forwarding Detection (BFD) protocol [BFD]. "Benefits and Motivation for Session Mode Instant Messaging", Rohan Mahy, 10-Feb-04, The SIMPLE working group describes one or more messages sent completely independently as 'pager-mode' messages, whereas messaging associated with as part of a 'session' with a definite start and end is called session mode messaging. The SIMPLE community has received numerous comments and complaints from the larger IM community that session mode is more complex than pager mode messaging. However, session mode messaging has a number of benefits which are not available in pager mode, but these benefits have not been widely articulated and this value is not well understood outside the SIP/ SIMPLE community. This document attempts to describe the benefits of session mode, such as explicit rendezvous, integration with other media, direct client-to-client operation, and brokered privacy and security, in an accessible manner. "A Unified Proposal for Server-to-Server Presence and Instant Messaging", Rohan Mahy, 10-Feb-04, Standardization of Instant Message and Presence Protocols in the IETF has resulted in multiple protocols. There are significant industry and technical advantages to standardizing a unified approach for server-to-server Instant Messaging and Presence. This document proposes a server profile which uses SIP to exchange presence and setup sessions, and XMPP for message transport. "Extension for EAP Authentication in IKEv2", Pasi Eronen, 6-May-04, IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using e.g. one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on other methods than public key signatures. "The Kerberos Network Authentication Service (Version 5)", Tom Yu, 21-Jul-04, This document describes version 5 of the Kerberos network authentication protocol. It describes changes to the protocol which allow for extensions to be made to the protocol without creating interoperability problems. "Detecting Network Attachment in IPv6 Goals", JinHyeock Choi, 10-Feb-04, Upon establishing a new link-layer connection, a host may or may not have valid IP configuration for Internet Connectivity. A host may determine whether its IP configuration is valid by checking Network Layer link change. With the information gathered, a host may decide if their own configuration needs to be updated and initiate a new configuration in case of link change. This procedure is described as Detecting Network Attachment. "Media Mixer Control for XCON", Cullen Jennings, 20-Jul-04, Media Policy is the mechanism by which a client manipulates the media streams of a conference, within limits established by the convener of the conference and the conference server the conference is established on. This document describes how media policy is realized, using a combination of predefined templates a convener can select from that specify interactive controls clients can manipulate and flow graphs that allow a customized template to be dynamically defined by the convener. "GEOPRIV support for RADIUS", Hannes Tschofenig, 10-Feb-04, Network access servers are increasingly capable of providing user and device location information to AAA servers. This enables the AAA server to make additional authorization decisions based on the location of the user or access device. The home or visited network may also use the location information for other purposes (e.g., acting as a location server). This document provides guidelines for the encoding and transport of location information using the RADIUS protocol which are compliant with the Geopriv requirements for security and privacy. "MIPv6 Authorization and Configuration based on EAP", Gerardo Giaretta, 20-Jul-04, This draft defines an architecture, and related protocols, for performing dynamic Mobile IPv6 authorization and configuration relaying on a AAA infrastructure. The necessary interaction between the AAA server of the home provider and the mobile node is realized using EAP, exploiting the capability of some EAP methods to convey generic information items together with authentication data. This approach has the advantage that the access equipment acts just as a pass-through for EAP messages and therefore does not play any active role in the Mobile IPv6 negotiation procedure, which makes the solution easier to deploy and maintain. "IPv4 and IPv6 Dual-Stack Issues for DHCPv6", Tim Chown, Stig Venaas, Christian Strauf, 10-Feb-04, A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions. "Sender Policy Framework (SPF) A Convention to Describe Hosts Authorized to Send SMTP Traffic", Mark Lentczner, 17-May-04, Email address forgery is a problem on the Internet today. Domain owners want to control the use of their names in email, but are helpless because they lack the means. This document introduces a language for domains to make email-related declarations in DNS. It defines in detail one possible sender authentication scheme for domains to describe the hosts from which they send mail. SMTP receivers can use this scheme to detect sender forgery. "Instance Identifiers for SIP User Agents", Cullen Jennings, 10-Feb-04, There are places in building SIP [2] based communications systems where it is useful to have a stable identifier for particular user agents that are used for user communications. This draft defines a convention for names that can be used to satisfy these needs. "LDAP Turn Operation", Kurt Zeilenga, 10-Feb-04, This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or 'turn') the roles of client and server for subsequent protocol exchanges in the session. "A Mission Statement for the IETF", Harald Alvestrand, 14-Jun-04, This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. "IETF Administration Restructuring: Motivation", Harald Alvestrand, 10-Feb-04, This document follows up the observations and recommendations outlined in the IAB Advisory Committee report ([1]) with a statement of purpose for the administration restructuring proposed in [3]. A high level definition of the IETF's purpose can be found in [2]. All 4 documents are meant to be read collectively. "A Proposal for IETF Administrative Restructuring", Leslie Daigle, 10-Feb-04, This document outlines a proposal for an administrative oversight entity for the collection of activities that allow the IETF to carry out its work. The current description of the IETF's work can be found in [2]. The proposal is based on the observations and recommendations outlined in the IAB Advisory Committee report ([1]). The motivation for this proposal is described separately ([3]). These 4 documents must be read together for completeness. "Route tags in OSPFv3", Sina Mirtorabi, 10-Feb-04, This document describes a mechanism to carry a route tag in OSPFv3. Currently only external LSA can carry a tag. This document propose a method to carry tags for intra and inter area prefixes. "OSPFv3 Destination Address Filter", Acee Lindem, 19-May-04, OSPFv2 has been criticized for it vulnerability to Denial of Service (DOS) attacks. With OSPFv3, it is a simple matter to filter on the destination address at an implementation dependent level in order to limit the scope of DOS attacks to directly attached routers. Unlike hop limit checking mechanisms, it is compatible with the existing OSPFv3 behavior. However, this level of protection will preclude the deployment of virtual links in topologies where the filtering is applied. "Centralized Conferencing (XCON) Media Models", Eric Burger, 10-Feb-04, This document describes various models for endpoint control of media policy for centralized conferencing services. The models include detailed mixer control, as in H.248, individual end-point negotiation, and participant roles, as in MSCML. "Centralized Conferencing (XCON) Media Models", , 10-Feb-04, This document describes various models for endpoint control of media policy for centralized conferencing services. The models include detailed mixer control, as in H.248, individual end-point negotiation, and participant roles, as in MSCML. "ENUM Implementation Issues and Experiences", Lawrence Conroy, 12-Feb-04, This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is 'out there' and the potential pitfalls in interpreting the set of documents that specify the protocol. "SIP URI List Index", Tom Hiller, 20-Jul-04, This draft extends the schema of the resource list specified in draft-ietf-simple-xcap-list-usage-01 by defining an index attribute (membercode). It also defines two MIME types that refer to subsets of a resource list. These MIME types can be used to identify subsets of a resource list for use with SIP requests. "Push Extensions to the IMAP Protocol (P-IMAP)", Stéphane Maes, 13-Jul-04, Push Extensions to the IMAP protocol (P-IMAP) defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. The first enhancement of P-IMAP is extended support to push crucial changes actively to a client, rather then requiring the client to initiate contact to ask for state changes. In addition, P-IMAP contains extensions for email filter management, message delivery, and maintaining up-to-date personal information. Bindings to specific transport are explicitly defined. "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Xiaobao Chen, Mark Watson, Martin Harris, 30-Jun-04, This document provides an analysis of certain inter-working problems between IPv6 nodes running Mobile IPv6, at least one of which is connected to a GPRS/UMTS network. The inter-working problems are caused by some specific packet filtering operations at the edge of the GPRS/UMTS network which are applied to control access to the GPRS/UMTS services and network resources. However, we believe that other scenarios may exist in which similar packet filtering operations may be applied and that similar problems would arise in these, more general, scenarios. "Support for the DNS address family in the APL DNS RR", Peter Koch, 10-Feb-04, Although Domain Names are not addresses in a strict sense, they are sometimes used to describe a group of related or proximate systems in a network similar to address prefixes. This document extends [RFC3123] by specifying the address family dependent part for Domain Names to be used in the DNS APL resource record. "Restricted S-expressions for use in a generalized authorization service", Roland Hedberg, 10-Feb-04, This document describes restricted S-expressions as they are used for storing and querying for access rights within the SPOCP (Simple POlicy Control Protocol) project. We describe the restrictions we have made to basic S-expressions and also the theory that allows us to use S-expressions in a policy engine. "Edge Handovers for Mobile IPv6", Nick Moore, 14-Jul-04, Edge Handovers (EH) is an interoperable enhancement to Mobile IPv6 to reduce handover latency for movement within an edge network, and to reduce handover signalling outside the edge network. EH does this by tunnelling traffic within the edge network, allowing a mobile node to maintain a stable Care-of Address while moving. "A note about 3rd party bombing in Mobile IPv6", Francis Dupont, 10-Feb-04, Mobile IPv6 [1] introduces some new kinds of reflection attacks, as known as 3rd party bombing. This memo analyses these attacks and makes some recommendations: the goal is to avoid anything, including in new optimized mechanisms, which can make the life of bad guys easier. "XML Schema definition for IDMEF message", Kohei Ohta, 10-Feb-04, The purpose of this document is to define a message format of IDMEF in XML Schema. "MT Tunnel Discovery and RPF check", IJsbrand Wijnands, Gargi Nalawade, 22-Jul-04, Multicast Tunnels are built between Provider Edge (PE) routers to allow multicast communication between different site's of a VPN. The MT tunnel has a destination MDT group address that is unique to the VPN. All routers that act as PE's and are configured for a specific VPN join the VPN MDT multicast group in the backbone of the provider network to be able to receive each others packets. Each router is also a sender to the MDT group. How the forwarding of the MDT packets is achieved is depending on the PIM mode of the MDT group. This can be either PIM-Bidir, PIM-SM or PIM SSM. The proposal in this document is related specifically to PIM SSM mode. "Client Globally Unique ID for SIP", Brian Stucker, 10-Feb-04, A number of applications using the Session Initiation Protocol (SIP) protocol require or can be enhanced by being able to uniquely identify a particular user agent (UA) instance in the network. This document describes an extension to SIP that allows clients to generate globally unique identifiers (GUID) for use within SIP based applications, providing an example of their use. "Presence Authorization Rules", Jonathan Rosenberg, 10-Feb-04, Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. "MDT SAFI", Gargi Nalawade, 22-Jul-04, There is a need for transporting MDT attributes within and across Autonomous Systems. This draft defines a new Address-Family that can be used to do the distribution. "RTP Profile for TCP Friendly Rate Control", Ladan Gharai, 10-Feb-04, This memo specifies a profile called "SIMPLE Session and Relay IM Protocol Requirements", Rohan Mahy, 10-Feb-04, This document defines requirements for sessions of messages in SIMPLE. These requirements apply to the Message Session Relay Protocol (MSRP). "Inter-domain Requirements for SIMPLE", Orit Levin, 21-Jul-04, This document identifies a SIP/SIMPLE profile for inter-domain communications and documents best current practices regarding security and 'good citizenship' behavior that operators should use when interconnecting SIP/SIMPLE clouds. The purpose of this document is to serve as the reference for the SIP/SIMPLE community towards inter-domain interoperability and also to identify new requirements specific to the inter-domain interface. "Extensions to GMPLS RSVP Graceful Restart", Arun Satyanarayana, Lou Berger, Dimitri Papadimitriou, 20-Jul-04, This document describes extensions to the RSVP Graceful Restart mechanisms defined in [RFC3473]. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in [RFC3209], and extensions for state recovery on nodal faults defined in [RFC3473]. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in [RFC2961], to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's. "DHCPv6 IPv4 Information Options", Cristian Cadar, 10-Feb-04, To ease the management of a site, the Dynamic Host Configuration Protocol (DHCP) is often used. DHCP exists both for the Internet Protocol Version 4 (DHCPv4 for IPv4) and Version 6 (DHCPv6 for IPv6). To avoid possible pitfalls that occur if both DHCP versions are used and to avoid redundancy, IPv4 Information Options may be transmitted using DHCPv6 as described in this document. In dual-stack IPv4/IPv6 scenarios that employ DHCPv6, DHCPv4 can be completely replaced by using the DHCPv6 IPv4 Information Options. "BGP-based Auto-Discovery for L2VPNs", Susan Hares, Wei Luo, Paul Unbehagen, Vasile Radoaca, 10-Feb-04, This document defines a mechanism of using BGP for the discovery of L2VPN membership information. The L2VPN membership information can be used by a L2VPN signaling protocol to set up pseudowires for L2VPNs, such as VPWS and VPLS. "An Extensible Markup Language (XML) Representation for Expressing Policy Capabilities", Jonathan Rosenberg, 19-Jul-04, An important component of presence and location services is policy. Policy systems allow the presentity or location target to grant access to specific pieces of information to specific watchers or requestors. These policy systems can be extremely simple, allowing a user to accept or block requests based solely on the identity of the requestor, to extremely complex, allowing for time based rules that grant or deny specific pieces of information. Policy systems often support vendor proprietary features. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines an Extensible Markup Language (XML) based format for expressing such capabilities. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, 10-Feb-04, This document presents a validation of QoS-NSLP by adapting an existing QoS model, controlled-load service from IntServ, for signaling with QoS-NSLP. It describes how to signal for controlled- load service with QoS-NSLP, and clarifies the features necessary for a QoS model description. " QoS-guaranteed MPLS-based NBVPN with centralized resource controller", Defeng Li, 10-Feb-04, This document focuses on the QoS problem in NBVPN, analyses the QoS requirement for NBVPN, the insufficiency of QoS guarantee in the current NBVPN schemes in the related IETF work group, and proposes a QoS-guaranteed NBVPN reference model with centralized resource controller, in this model, some new concepts are introduced, such as VPN Logical Bearer Network(VPN-LBN), VPN Centralized resource controller(VPN-CRC); and mechanism of guaranteeing the VPN QoS is explained in details, including address space, isolation between VPNs, VPN route distribution, forwarding, interface requirement signaling requirement, hybrid QoS-VPN, intra-domain VPN, inter-domain VPN. "Requirements for Inter-area MPLS Traffic Engineering", Jean-Louis Le Roux, 10-Feb-04, This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) which could serve as a guideline to develop the required set of protocol extensions. "Attributes for Access Network Location and Ownership Information", Farid Adrangi, 10-Feb-04, This document describes RADIUS Authentication, Authorization, Accounting (AAA) attributes that are used to convey the Access Network?s operational ownership and Location Information to a Home Service Network. "Simple Policy Control Protocol over TCP/IP", Roland Hedberg, 10-Feb-04, The SPOCP protocol has been described in [SPOCP]. The description is done in general terms and is not done in such a way that implementers can directly implement the protocol. To make that possible there has to be a mapping defined between the more abstract description and a bits on the wire description. This document represents one possible mapping. "Multi-Instance(MI) support in LDP", Albert Tian, 10-Feb-04, Many of the routing protocols today can support multiple topologies or multiple instances [ISISMT] [OSPFV3] [OSPFMT]. In such an environment, prefix, address family, and topology/instance together define an FEC. But the current LDP specificaiton is not sufficient to allow multi-topology/multi-instance to share the same LDP session. In this document we introduce a concept of 'Label Binding Instance' to LDP so that FECs can be unambiguiously identified in a multi- topology/multi-instance routing environment. "An Extensible Markup Language (XML) Representation for Expressing Presence Policy Capabilities", Jonathan Rosenberg, 20-Jul-04, An important component of presence services is policy. Policy systems allow the presentity to grant access to specific pieces of information to specific watchers. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines a set of Extensible Markup Language (XML) elements for expressing presence policy capabilities. "IPv6 Detecting Network Attachment Based on Access Point ID", Zhigao Chen, 10-Feb-04, This document describes an IPv6 network attachment detection mechanism in which access routers disseminate the identifiers of on- link access points reported by hosts. By caching the identifiers, hosts assess the likelihood of an L3 link change right after an access point change. The hosts are hence able to quickly determine whether an existing IP address configuration can be reused or a new one should be acquired. The mechanism aims to achieve fast L3 connectivity re-establishment with less signaling overhead. "Fragmentation MTU Extension for Mobile IPv4", Sami Vaarala, Nuutti Kotivuori, 10-Feb-04, This document specifies a vendor specific extension which allows a Mobile IPv4 node (MN, FA, or HA) to indicate its preferred maximum packet size for receiving encapsulated data packets. The intent is to work around problems in firewall configuration and implementation which prevent use of fragmentation and may arbitrarily limit maximum working packet size without useful error indications. The extension applies especially to UDP encapsulation where fragmentation occurs before encapsulation. "Support of Internet Connectivity for AODV", Hyun-Wook Cha, 11-Feb-04, In this document, we propose another solution to support Internet connectivity for AODV. In the design of our solution, several important limits of existing solutions are considered. Especially, new route determination and forwarding algorithms are proposed. Proposed route determination algorithm supports dynamic switching between default route and host route in a sender node through which enhanced performance can be achieved under frequent topological changes. And proposed forwarding algorithm supports next hop forwarding for default routes towards multiple gateways. "The Network Access Identifier", Bernard Aboba, 19-Jul-04, In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during, for instance, PPP and wireless LAN authentication. 'Roaming' may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP 'confederations' and ISP-provided corporate network access support. This document is a revised version of RFC 2486 which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. "Ad Hoc IP Address Autoconfiguration for AODV", Jae-Hoon Jeong, 22-Jul-04, This document specifies the steps a node running AODV in ad hoc network takes in deciding how to autoconfigure its IPv4 or IPv6 address in network interface. Because the ad hoc IP address autoconfiguration in this document considers ad hoc network's partition and mergence, the address duplication caused by ad hoc network's mergence can be resolved through address resolution protocol. Also, this document specifies how to resolve the address duplication in order to guarantee the maintenance of upper-layer sessions, such as TCP session. "DNS Service for Mobile Ad Hoc Networks", Jae-Hoon Jeong, 11-Feb-04, This document specifies an architecture of DNS service system for mobile ad hoc network which might be connected to the Internet. The resolution of DNS names of mobile nodes within mobile ad hoc network is performed by multicast DNS and that of DNS names of nodes in the Internet is performed through DNS autoconfiguration of recursive DNS server. In the former, each mobile node plays a role of DNS name server for the DNS resource records associated with DNS name of which authority it has. The latter allows mobile node to receive the global Internet service, such as web service, by providing global DNS resolution in mobile ad hoc network connected to the Internet. These two kinds of DNS name resolution are processed automatically without the intervention of users in mobile ad hoc network. Also, this document specifies how to authenticate DNS message as well as how to provide ad hoc users with service discovery based on multicast DNS. "Functionality Classifications for Control and Provisioning of Wireless Access Points (CAPWAP)", Hong Cheng, 22-Jul-04, This document describes classifications for wireless local area network (WLAN) functionality. The main benefit of a consistent system of classification is accommodating the diversity of WLAN designs as seen in the Control and Provisioning of Wireless Access Points framework. This draft describes policies with which classifications may be used. The document analyzes various WLAN architectures and recent standardization efforts to derive key requirements for a CAPWAP WLAN protocol. It is envisioned that protocol development based on these requirements will enable interoperability among the various WLAN designs. "Mobile IPv6 Node traversal of IPv4 subnets using automatic tunnels", Shu Yamamoto, 11-Feb-04, This draft presents Mobile IPv6 [1] operation in IPv4 networks by using existing automatic tunneling method. A mobile IPv6 node uses Mobile IPv6 to maintain connectivity while moving between IPv6 subnets. Not all access networks will transition to IPv6 at once. Therefore, seamless Mobile IPv6 connectivity is not guarantied since a mobile IPv6 node may roam into an IPv4 only network. We describe a scheme, named GLOB6, to allow mobile IPv6 nodes to traverse IPv4 subnets by using automatic tunneling. ISATAP [2] is an example automatic tunneling mechanism described in this document to enable Mobile IPv6 connectivity over IPv4 networks. The draft concludes with a brief description of how the scheme can be applied to certain 3G networks as well as WLAN deployments as part of an overall strategy for the realization of global mobility - a main feature of IPv6. "EAP Bluetooth Application", Hahnsang Kim, 11-Feb-04, Bluetooth protocol suite defines a set of security mechanisms between its devices. All the authentication procedure is based on the knowledge of a shared secret called PIN. Bluetooth suggests to use systems such as Diffie-Hellman method or others else to initiate the PIN between two unknown devices. This draft proposes a simple mechanism that help two entities already presented to an AAA infrastructure share the PIN and start secured Bluetooth communications with Bluetooth Security protocols. "Mobility related issues for the QoS NSLP", Hong Cheng, 11-Feb-04, The draft listed out some of the issues related to IP mobility that may have impact on the design and implementation of the NSIS protocols. These issues, namely, the multiple flow support and the ping-pong type of movement, needs to be considered in the context of the QoS NSLP protocol design, so that the NSIS framework would not break when they present. "Key reuse in Secure MIME for the Session Initiation Protocol(SIP)", Kumiko Ono, 11-Feb-04, SIP uses Secure MIME (S/MIME) Cryptographic Message Syntax (CMS) EnvelopedData to protect SIP messages for confidentiality. While SIP can be encrypted with different keying materials for each message, it usually requires a public key operation for each message and the computational cost of such operations are relatively expensive. This draft proposes a method of bidirectional key exchange to reuse keying materials for S/MIME-secured messages in a dialog and use a symmetric key mechanism instead of an asymmetric key mechanism such as a public key operation. The proposed mechanism also achieves the sharing of keying material among multiple entities in a simple way. "Detecting Network Attachment Terminology", Shu Yamamoto, 11-Feb-04, The DNA working group is working on solutions for hosts to detect their IP layer connectivity and configuration status quickly which in turn would allow it to reconfigure the IP link faster than today. This document aims at providing definitions for key terms used by the group. "The GLI system architecture", Yasuhito Watanabe, 21-Jul-04, In this document, overview of the Geographical Location Information (GLI) system is described. It manages the latest geographical location information and identifier of mobile nodes on the Internet. Each node registers its geographical location information to this system, and users can look-up identifiers of nodes by specifying location as a key, and vice versa. This system was designed with consideration of privacy protection of mobile nodes and scalability. "EDNS NSID Extension", Rob Austein, 19-Jul-04, With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which actually responded is to have the name server include this information in the response itself. This note proposes a protocol enhancement to support this functionality. "Pre CRN discovery from proxy on candidate new path", Takako Sanda, 18-Feb-04, NSIS WG has been discussing the ways to minimize/avoid QoS interruption during handover. One solution is to install new path before MN's move (fast state installation). This document proposes a procedure of pre CRN discovery for fast state installation by using proxies on candidate new paths. An example of fast state installation is shown. "Framework for Common Endpoint Locator Pools", Dave Crocker, 11-Feb-04, Classic Internet transport protocols use a single source IP Address and a single destination IP Address, as part of the identification for an individual transport data flow. This is problematic for multihomed hosts and for mobile hosts, collectively needing 'multiaddressing' support. The basic goal, then, is to find a method for multiaddressing that makes the smallest possible change to the architecture and to current systems, while maintaining flexibility for different emerging solutions. This draft proposes a framework for methods for creating Common Endpoint Locator Pools that can be used by and among the proposed solutions. "Fault Management for Virtual Private LAN Services", Ali Sajassi, 11-Feb-04, "Performance Management for Virtual Private LAN Services", Dinesh Mohan, 11-Feb-04, "Problem Statement: HIP operation over Network Address Translators", Martin Stiemerling, 21-Jul-04, This memo investigates issues for Host Identity Protocol (HIP) nodes that communicate over a network path that inlcudes Network Address Translators (NATs). There are two groups of issues: Operating HIP itself across NATs and operating the IPsec-based data transmission initiated by HIP across NATs. For both groups problems are summarized. "Terminology for Benchmarking LDP Data Plane Convergence", Thomas Eriksson, 20-Jul-04, This document defines new terms for benchmarking of LDP convergence. These terms are to be used in future methodology documents for benchmarking LDP Convergence. Existing BMWG terminology documents such as IGP Convergence Benchmarking [3] provide useful terms for LDP Convergence benchmarking. These terms are discussed in this document. Applicable terminology for MPLS and LDP defined in MPLS WG RFCs [1] and [2] is also discussed. "NATFirewall NSLP Intra-realm considerations", Cedric Aoun, 21-Jul-04, This document discusses NAT/FW NSLP issues and solutions for cases where NATFW NSLP NEs within the same addressing realm communicate with each other. The document will serve as input to the NSIS NAT/FW NSLP document to meet these intra-realm communications' requirements. "Framework for Layer 1 Virtual Private Networks", Tomonori Takeda, 22-Jul-04, This document provides a framework for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs. The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. "DB Exchange for OSPFv2 Wireless Interface Type", Thomas Clausen, 11-Feb-04, This memo describes a mechanism providing database exchange and reliable transmission capabilities in a way which is adapted to link state routing on ad hoc networks. This mechanism is specified in this document for wireless OSPF interfaces as specified in draft- spagnolo-manet-ospf-wireless-interface-00.txt. A signature exchange technique is proposed, providing a very compact way for the nodes to communicate and compare the state of their respective link-state databases. Upon receiving such a signature, a node can quickly detect if a discrepancy is present and, furthermore, determine which information must be exchanged in order to alleviate this discrepancy. "MIME Type Registrations for Standard MIDI Files and Downloadable Sounds", Magnus Westerlund, 11-Feb-04, This document serves to register and document standard MIME types for Standard MIDI Files, Scalable Polyphonic MIDI and Downloadable Sounds. "BGP Assign AFI/SAFI numbers", Susan Hares, 11-Feb-04, This document describes mechanisms for assigning the AFI/SAFI values for short-term use while BGP specifications are under development. These short-term AFI/SAFI values will be assigned for temporary use to a particular enterprise while BGP specifications are under development. After 1 year, if the BGP specification has been adopted as an IDR draft, the lease will be renewed. If the draft has not be adopted, the AFI/SAFI value returns to the pool of Enterprise AFI/SAFI. This draft a means to assign these short- term AFI/SAFI values. " A guideline on message headers and URI in SIP/SIMPLE framework", Ashir Ahmed, 11-Feb-04, SUBSCRIBE, NOTIFY and PUBLISH methods in SIP are responsible for carrying presence information to a target destination. Message headers (Request-line, To, From, Contact etc.) indicate SIP entities that are identified by a URI. This document clarifies the indication of the message headers and provides a guideline on URI usage in the header fields. The authors hope that this document will be useful for SIP/SIMPLE implementers, interoperability testers, designers, and protocol researchers. "Generalized MPLS Recovery Resource Sharing", Geng-Sheng Kuo, Qing Huang, 11-Feb-04, Many protection and restoration (P&R) techniques are proposed to protect LSP in GMPLS networks. Provisioning better P&R capability requires that more recovery resources be allocated on protection LSP, which may lead to resource waste in GMPLS networks. This draft presents a scheme of recovery resource sharing with traffic balancing for GMPLS LSP P&R. Its focus is on the discussions of working and protection LSPs selection and shared resource allocation and release. "Interdomain Trust-Relationships for SIP-based Roaming", Harry Behrens, 11-Feb-04, This draft describes an authentication mechanism which can be used to enable users of VoIP to globally roam between any number of ITSPs (Internet Telephony Service Providers) without needing to have a prior customer or billing relationship with all of them. This enables profiles and one- line-billing. Providers using this authentication mechanism do neither need full-mesh trust relationships or roaming agreements with every other possible provider nor do they need to rely on a centralized brokerage entity to process calls. The Home Network (HN), which handles all AAA for a user attempting to use an ITSP's service is determined through a unique identifier submitted by the user. This Network Access Identifier [RFC2486] contains information about the trust domain or trust realm the user belongs to. Based on a simple discovery mechanism a provider can establish a trust path to this home network. Once this is established, the provider can authenticate the user and check his credit with the home network. Accounting and rate information will be sent to the home network for mediation and processing. "Dynamic Host Configuration Protocol (DHCP) Relay Agent MIB for IPv4", a Vijayabhaskar, 11-Feb-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol Relay Agent for IPv4 and Bootstrap Protocol (BOOTP) Relay Agent. "Additional cryptographic algorithms for use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 algorithms", Vladimir Popov, 31-Mar-04, This document describes cryprographic algorithms and parameters, supplementary to GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94, for use in internet applications. "Possible Deployment Scenarios for IPv6 Anycasting", Shingo Ata, 11-Feb-04, Today, the use of anycasting is quite limited. In this document we list possible deployment scenarios in IPv6 anycasting. We consider three conditions based on the region of anycasting, and list possible scenarios. For each scenario we also clarify example applications as well as technical issues to be resolved. "LTCP: A Layering Technique for Improving the Performance of TCP in Highspeed Networks", Sumitha Bhandarkar, 15-Jul-04, This document proposes Layered TCP (LTCP for short), a simple layering technique for the congestion window response of TCP to make it more scalable in highspeed networks. LTCP is a two dimensional congestion control framework - the macroscopic control uses the concept of layering to quickly and efficiently make use of the available bandwidth whereas microscopic control extends the existing AIMD algorithms of TCP to determine the per-ack behavior. This document provides the general intuition and framework for the LTCP protocol modifications. Using a simple design, the effectiveness of using layering for improving the efficiency without sacrificing the convergence properties of TCP, is illustrated. The chosen design is evaluated using mathematical analysis, ns-2 based simulations and emulation on a Linux testbed. The results show that LTCP has promising convergence properties, is about an order of magnitude faster than TCP in utilizing high bandwidth links, employs few parameters and is easy to understand. The flexible framework opens a whole class of design options for improving the performance of TCP in highspeed networks. This document is an effort to solicit more experimentation and feedback from the broader networking community. "Statistical Inter-flow Field Behaviour for Context Replication in ROHC-TCP", Chia Yuan Cho, 12-Feb-04, Context replication increases header compression gains by reducing the redundancy between flows via efficient replicate (IR-CR) packets. The optimum design of IR-CR packet formats requires elaborate understanding of the inter-flow redundancy. As context replication is most well-suited for TCP, this document presents a statistical analysis of TCP/IP inter-flow field behaviour. Based on the analysis, recommendations on ROHC-TCP packet format specifications for context replication are made. It is also shown that inter-flow field behaviour is inherently and significantly asymmetrical, and various ways of handling it are considered. Finally, based on the inter-flow behaviour of TCP Window field, it is noted that current encoding methods do not compress it efficiently. "Weak Identifier Multihoming Protocol (WIMP)", Jukka Ylitalo, 6-Jul-04, Weak Identifier Multihoming Protocol Framework (WIMP-F) is a wedge layer 3.5 framework to be applied with different kind of routable application layer identifiers (AIDs) and layer 3.5 context identifiers (CIDs) presented in Group-F. WIMP-F consists of context establishment and re-addressing exchanges that are protected with one-way hash chains and a technique called as secret splitting. The hash chain protects a host from re-direction attacks, but not directly from an CID or AID theft. The ownerships can be provided in variable ways presented in other Multi6 drafts. "SIP NSIS Interactions for NAT/Firewall Traversal", Miquel Martin, 22-Jul-04, The NSIS NAT/FW NSLP provides traversal facilities for other application layer protocols. This document describes the interactions between SIP and NSIS signaling, to enable two NSIS aware SIP end applications to communicate normally through a network of NSIS Aware nodes, in a variety of NAT topologies. "Requirements for an IPsec Certificate Management Profile", Chistopher Bonatti, 20-Jul-04, This informational document describes and identifies the requirements for a profile of a certificate management protocol to handle Public Key Certificate (PKC) lifecycle interactions between Internet Protocol Secuity (IPsec) Virtual Private Network (VPN) Systems using IKE (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed so that they meet the needs of enterprise scale IPsec VPN deployments. It is intended that a standards track profile will be created that fulfills these requirements "DHCPv6 Option for Midcom Middlebox", Joel Tran, Soumaya Cherkaoui, 2-Apr-04, The Dynamic Host Configuration Protocol version 6[RFC3315] provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Midcom Protocol need to know the presence of Midcom middleboxes, such as firewalls and network address translators, in order to enable communication across theses devices. A DHCPv6 option provides a means for these entities to determine the Midcom middleboxes IPv6 address or the domain name. "DHCP option for IPv6 SIP Proxy address", Ernie Tacsik, 2-Mar-04, This document defines a new Dynamic Host Configuration Protocol (DHCP-for-IPv4)site-specific (i.e. 'Private Use') option that contains a list of IPv6 addresses for SIP proxy server(s) [RFC 2939]. This list of IPv6 SIP Proxy Server(s) may be used by a 3GPP2 mobile to locate an IPv6 SIP Proxy Server(s), and which may additionally indicate the version of IP the IMS supports. "Transmission of IP Datagrams over Token-Rail Ethernet", Lance Dodd, 2-Mar-04, This memo describes an experimental method for the transmission of IP datagrams oven token-rail ethernet. This specification is primarily useful in Metropolitan Area Networks, but can be applied in economies of scale (N, HO, WIDE, O, and others). This is an experimental, not recommended standard. Distribution of this memo is unlimited. Much of the rural United States while enjoying many modern conveniences is still quite limited in the available choices for broadband internet connectivity. This could be remedied by the use of an infrastructure that has existed virtually untapped for its communications potential. The continued advances in DSP technology, multiple frequency encoding and general alloy based metallurgy leads to the inevitable conclusion: using encoded signals transmitted over the information super railway could provide much needed relief to users in rural areas. "Forming Intuitive Email Addresses", Predrag Pale, Kristijan Cerovski, 2-Mar-04, This memo presents a proposal for an efficient and simple way of forming email addresses. The goal is to achieve easier, more productive communication between email users, in particular by aking addresses intuitive and thus easy to remember, or guess-enabled on material-world data about the correspondent, as well as independent from technical or organizational specifics of email services. "Forming Intuitive Email Addresses", Predrag Pale, Kristijan Cerovski, 31-Mar-04, This memo presents a proposal for an efficient and simple way of forming email addresses. The goal is to achieve easier, more productive communication between email users, in particular by aking addresses intuitive and thus easy to remember, or guess-enabled on material-world data about the correspondent, as well as independent from technical or organizational specifics of email services. "IPv6 distributed security requirements", Jordi Palet, Alvaro Vives, G Martinez, A Gomez, 21-Jul-04, The security policies currently applied in Internet with IPv4, doesn’t longer apply for end-to-end security models which IPv6 will enable. Today, each network is often secured by a unique device (i.e. security gateway or firewall), that becomes a bottleneck for the end- to-end security model with IPv6. In addition, users and devices start to be nomadic, moving between different networks that could have different security policies. A distributed and dynamic approach is consequently required. "Network Access Identifier Option for Mobile IPv6", Alpesh Patel, Kent Leung, Haseeb Akhtar, Mohamed Khalil, Kuntal Chowdhury, 2-Mar-04, This document defines new mobility option to identify mobility entities using a network access identifier. This option can be used in messages containing a mobility header. "Authentication Protocol for Mobile IPv6", Alpesh Patel, Kent Leung, Mohamed Khalil, Kuntal Chowdhury, 25-May-04, This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu of IPsec to authenticate mobility messages as defined in the base Mobile IPv6 specification. "Iowa Internet Annoyance Logging Protocol(IIALP) pronounced I'-alp", George Davey, Dan Arthur, Paula Davey, 19-May-04, This draft describes a system by which Internet Annoyances can be logged quickly and automatically using IIALP (Iowa Internet Annoyance Logging Protocol). The annoyance logs on a particular IIALP Server are condensed and forwarded up the IIALP hierarchy to central Root IIALP Servers for central annoyance queries. Serial numbers and TTL values keep the individual reports organized and dated. One unique complaint per IP per epoch period prevents flooding. Differences in detail and propagation parameters exist between Root and Subordinate IIALP Servers to allow for more detail to be kept at the originating IIALP Server. Transmission Echoes, Redundant Handshaking, and Hierarchy Structure eliminate erroneous reporting. Routers and software running IIALP can use IIALP to create dynamic black hole lists for abusing Internet assets exceeding a set limit. IIALP allows for an infinite number of different types of annoyances to exist but has concise templates for common annoyances such as SPAM. IIALP is a centralized logging system for Internet annoyance event reporting. "DNS QTYPE to retrieve IPv4 and IPv6 address", T. T. Sajitha, 9-Mar-04, This document proposes a new query type to be used in the DNS [RFC1035] implementation. This is used to retrieve all the IPv4 as well as IPv6 addresses of a host using a single query. "Address Management for Mobile SCTP Handover", Moon Jeong Chang, Meejeong Lee, Seok Koh, 9-Mar-04, This document describes an address management module for mobile Stream Control Transmission Protocol (mSCTP). The module is used for a mobile node to manage the IP addresses associated with an mSCTP association. The address management module utilizes the link layer signal strength information in order to determine when to add or delete end-point IP addresses of a mobile node and how to change the primary path from the mSCTP association when a handover happens. "Cogny protocol - A protocol for peer-to-peer content sharing systems", Yasuaki Takebe, 9-Mar-04, This document describes Cogny protocol that is a SOAP-based protocol for peer-to-peer content sharing systems. Unlike general purpose peer-to-peer protocols such as JXTA protocol, Cogny protocol is specialized to support centralized peer-to-peer content sharing systems. So it is much simpler and easier to implement than JXTA protocol. Because Cogny protocol is specialized to content sharing systems, it defines application layer functions necessary to them. One of them is a content transfer protocol that keeps consistency of content. Cogny protocol defines encryption method for it. Another is efficient full-text search. Cogny protocol defines a cache method for full-text search. "RTP Payload Format for the Speex Codec", Greg Herlein, 9-Mar-04, Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP) and a preliminary method of using Speex within H.323 applications. "The Mobile IPv6 Bootstrapping Problem", James Kempf, Jari Arkko, 9-Mar-04, This document discusses the creation of a security association between a mobile node and a home agent that is previously unknown to it. This problem is called the bootstrapping problem. The document discusses several different usage scenarios, as well as related issues involving informing the mobile node of changes in the home network topology and mobility management service. Limitations of the base Mobile IPv6 protocol in dealing with the scenarios are outlined. "Multi-homing for small scale fixed network Using Mobile IP and NEMO", Kenichi Nagami, 19-Jul-04, Multi-homing technology improves the availability of host and network connectivity. Since the node and network behavior of mobile networking and fixed networking are different, the different architecture has been discussed and proposed. This document proposes the common architecture both for mobile and fixed networking environment, using the mobile IP and NEMO. The proposed architecture only requires a modification of the mobile IP and NEMO so that multiple-CoA can be used. In addition, multiple HAs which are located in different place, are required for redundancy. "Design of the MOBIKE protocol", Tero Kivinen, 10-Mar-04, This document discusses the potential design decisions in the base MOBIKE (IKEv2 Mobility and Multihoming) protocol. "MOBIKE protocol", Tero Kivinen, 10-Mar-04, This document describes the base MOBIKE (IKEv2 mobility and multihoming) protocol. The base protocol contains protocol to notify the other end about the address changes and rules how to change to use new IP-addresses. "Pilot: Working Group Chair Followup of DISCUSS Comments", David Meyer, 4-May-04, As of this writing, many efforts aimed at streamlining various IETF processes are underway. One such effort is the Process and Tools, or PROTO Team. The PROTO Team is an IESG-driven activity focused on improving the work flow of approval of documents, and the tools that support this work flow. This document describes a pilot process designed by the PROTO Team to streamline document flow by allowing working group chairs to coordinate the resolution IESG DISCUSS comments. "Careful Additional Review of Documents (CARD) by Senior IETF Reviewers (SIRS)", Brian Carpenter, Dave Crocker, 10-Mar-04, IETF specifications do not receive formal review until they are submitted to the IESG. Hence, significant problems with a specification often are not detected until considerable effort has been wasted and changes to fix the problems are difficult to add. The procedure described in this document is intended to solve, or palliate, a number of related problems that have been observed in the IETF process. The basic model is to create a team of Senior IETF Reviewers (SIRS), and have all documents receive a certain number of reviews by SIRs, prior to being submitted for publication. Review at a very early stage is strongly encouraged. "EAP shared key methods documentation template", Florent Bersani, 11-Mar-04, This document proposes a template for authors of EAP methods that rely on shared keys, to document their work. Since EAP methods have proliferated but only 4 are currently standardized and since no simple shared key EAP method seems to be widely available to replace EAP-MD5 that has been deprecated for security reasons, this template is the first step towards standardizing such an EAP method. This document is indeed intended to help gather information on the existing related work before requesting that a new work item be opened at IETF to standardize a replacement for EAP-MD5. "A Not So Wild Sheep Chase - Definition of Shepherding", Allison Mankin, 11-Mar-04, This draft looks at IETF document shepherding. Currently this is done largely by the Area Directors, though good working group chairs will recognize tasks they already perform here. "Evaluation of v6ops Tunneling Scenarios and Mechanisms", Pekka Savola, Jonne Soininen, 20-Apr-04, This memo analyses the v6ops scenarios/analysis work (Unmanaged, 3GPP, ISP and Enterprise) for their requirements for tunneling solutions, and analyses the proposed mechanisms on how they might fit in these requirements, and discusses possibilities for choosing solution(s). "Foreign Agent Error Extension for Mobile IPv4", Charles Perkins, 11-Mar-04, This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. The new extension option allows a foreign agent to supply an error code without disturbing the data supplied by the Home Agent within the Registration Reply message. In this way, the mobile node can verify that the Registration Reply message was generated by the Home Agent even in cases where the foreign agent is required by protocol to insert new status information into the Registration Reply message. "Advanced History Collection Framework", Shailaja Yadawad, Hemanth Kumar, Hemanth Yamijala, Raja Shekar, 12-Mar-04, This draft defines a portion of the Management Information Base for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for configuring and controlling the history collection of user specified Data, which is an ASN.1 INTEGER based object. "Cost optimization based on Enterprise-ENUM", Andrzej Bartosiewicz, 12-Mar-04, This paper presents an extension of NAPTR Resource Records and an application of the local DNS (called in further part of this document 'Enterprise -ENUM') in order to keep information required for costs optimization of telecommunication connections. The optimization should cover the cost reduction through the selection of cheapest form of telecommunication connections for the calling party (a person initializing a telecommunication connection). "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Howard Holgate, 23-Mar-04, The Point-to-Point Over Ethernet (PPPoE) Protocol [3] provides a standard method for encapsulating Point-to-Point Protocols (PPP) [1] over Ethernet. This document extends the PPPoE protocol with a credit based flow control mechanism and Link Quality Metric report. The PPPoE specification is also extended to allow TLV Tags in the PPP Session Stage. These extensions are optional to retain backwards compatibility and at the same time provide for future extendibility. "Lightweight Underlay Network Ad hoc Routing (LUNAR) Protocol", Christian Tschudin, 12-Mar-04, The Lightweight Underlay Network Ad hoc Routing (LUNAR) Protocol is intended for use by mobile nodes in small size wireless ad hoc networks. LUNAR operates at layer 2.5. It emulates a single-hop IP subnet with unicast as well as broadcast communication primitives. DHCP and ARP messages are intercepted and serve as hooks for self- configuration of IP addresses as well as the mapping of IP addresses to the underlying layer 2.5 multihop routes. "Multipoint Relay Flooding for Manets", Thomas Clausen, Pascale Minet, Charles Perkins, 15-Mar-04, This document describes the MultiPoint Relay Flooding (MPRF) protocol for maintenance of efficient flooding structures in mobile ad-hoc networks. The protocol is an adaptation of the classical flooding algorithm, with the difference that many nodes are relieved of the responsibility to relay flooded messages while still ensuring that all nodes receive the messages. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which are the only nodes needed to forward messages during the flooding process. This technique substantially reduces the message overhead as compared to the more straightforward and well-known flooding mechanism, where every node retransmits each message just once, upon receiving the first copy of the message. The protocol is particularly suitable for dense networks. "Area Review Teams for Early Cross-functional Reviews", Alex Zinin, 15-Mar-04, This document contains a proposal for cross-functional IETF review process that can be initiated at early stages of a document life cycle. The approach is based on existing experience with area directorates and other expert groups within the IETF. "IMAP4 POSTADDRESS extension", Alexey Melnikov, 15-Mar-04, The POSTADDRESS extension of the Internet Message Access Protocol [IMAP4] permits a client to discover an email address that can be used to send messages to an IMAP mailbox. "Terminology for Describing Internet Connectivivy", John Klensin, 14-Jul-04, As the Internet has evolved, many types of arrangements have been advertised and sold as 'Internet connectivity'. Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, has cause considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. "Overview of the eXtensible Service Discovery Framework (XSDF)", Manuel Urueña, David Larrabeiti, 22-Mar-04, This document provides an overview of the eXtensible Service Discovery Framework (XSDF). It defines a collection of extensible protocols and agents for the dynamic location of network services. XSDF Service Discovery Framework is scalable and can be deployed from unmanaged LANs up to Internet-wide Service Location. XSDF also provides several mechanisms to select among the available services discovered. This allows service providers to implement load sharing or active/backup policies among multiple servers providing the same service. "Protocol Pilot: Workgroup Chair Followup of AD Evaluation Comments", Henrik Levkowetz, David Meyer, 11-May-04, This document describes a pilot implementation of a protocol change within the IETF. The essence of the change is to have workgroup chairs handle the feedback of AD (Area Director) Evaluation comments on a draft to the authors (and workgroup if necessary) and make sure that needed draft changes are made, and the AD notified when a new draft which resolves the comments is available. "Extensions to OSPF to Support Mobile Ad Hoc Networking", M Chandra, 20-Jul-04, This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. "Message Submission BURL Extension", Chris Newman, 14-Jul-04, The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command which can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. "MT-OSPF: Multi Topology (MT) Routing in OSPF", Peter Psenak, 23-Mar-04, This draft describes the extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for different classes of service, in-band management network or incongruent topologies for unicast and multicast. M-ISIS [1] describes a similar mechanism for ISIS. "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", Manuel Urueña, David Larrabeiti, 23-Mar-04, This document defines the common Attributes and Elements employed by the eXtensible Service Discovery Framework (XSDF) protocols. It defines the data elements employed to encode Service information, as well as the common procedures and operations for all XSDF protocols. For example it includes the XSDF Agent initialization process, and details the rules for the creation, transmission, reception and processing of XSDF protocols' messages. "eXtensible Service Location Protocol (XSLP)", Manuel Urueña, David Larrabeiti, 23-Mar-04, This document specifies the eXtensible Service Location Protocol (XSLP), a lightweight protocol that allows User Agents to obtain Service information from Directory Agents, even from remote domains. Also, XSLP allows User Agents to perform multicast queries to the Service Agents inside the same organization. XSLP is the main protocol of the eXtensible Service Discovery Framework (XSDF). "eXtensible Service Registration Protocol (XSRP)", Manuel Urueña, David Larrabeiti, 23-Mar-04, This document specifies the eXtensible Service Registration Protocol (XSRP), a lightweight protocol that allows Service Agents to register Service information at Realms managed by one or more Directory Agents. Then, User Agents will be able to obtain that Service information from Directory Agents. XSRP is one of the protocols of the eXtensible Service Discovery Framework (XSDF). "eXtensible Service Subscription Protocol (XSSP)", Manuel Urueña, David Larrabeiti, 23-Mar-04, This document specifies the eXtensible Service Subscription Protocol (XSSP), a lightweight protocol that allows XSDF Agents to be subscribed to the Service information repository. XSDF subscribed Agents are notified when any change occurs. Directory Agents from the same Realm are subscribed among them in order to synchronize the common Service repository. XSSP is one of the protocols of the eXtensible Service Discovery Framework (XSDF). "eXtensible Service Transfer Protocol (XSTP)", Manuel Urueña, David Larrabeiti, 23-Mar-04, This document defines the eXtensible Service Transfer Protocol (XSTP), a lightweight protocol that allows Directory Agents from a common Realm to download all the available Service information (for example, at startup), in order to share the same view of their Service information repository. XSTP is one of the protocols of the eXtensible Service Discovery Framework (XSDF). "eXtensible Binary Encoding (XBE32)", Manuel Urueña, David Larrabeiti, 23-Mar-04, This document defines the eXtensible Binary Encoding (XBE32). It has been designed to represent hierarchical data in a compact and extensible format. Data elements are binary encoded inside Type-Length-Value (TLV) structures, which are 32-bit aligned to be easily parsed by computers. XBE32 is NOT a binary encoding for XML documents, but an encoding format for small, lightweight network protocols. "ATM Pseudo-Wire Extensions for L2TP", Mark Townsley, Sanjeev Singh, 21-Jul-04, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines an extensible tunneling protocol, how to transport layer 2 services over IP network. This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudo-Wires and guidelines for transporting various ATM services over an IP network. "Working Group Snapshot (WGS)", Spencer Dawkins, 25-Mar-04, This proposal defines an optional label that can be affixed to an Internet-Draft, for working group internal synchronization. It is pointedly not an IETF standards label. Rather it is an optional part of the working group evelopment process, permitting the working group to synchronize on a particular version of a draft. "Addressing FTC DIARRUCA Concerns", Carl Malamud, 25-Mar-04, The U.S. Congress, having hit a home run with the do-not-call list, has decided that since computers are like telephones, a do-not-email list ought to win them the pennant. You have an opportunity to block that metaphor. The FTC has issued an Advanced Notice of Proposed Rulemaking and has given the public until March 31, 2004 to respond. This document tells you how and explains the issues. "Dual Stack Mobile IPv6", Hesham Soliman, George Tsirtsis, 25-Mar-04, This specification adds IPv4 extensions to Mobile IPv6 to allow dual stack mobile nodes to roam within the Internet using Mobile IPv6 only while simultaneously maintaining connections using their IPv4 and IPv6 home addresses. "Mobile IPv4 NAI-based Home Address Assignment", Naveen PaulKandasamy, Kent Leung, 25-Mar-04, With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to the Mobile Nodes during the initial registration. Though the concept of NAI-based home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for achieving such a NAI-based home address assignment has not been outlined. More particularly, the Home Agent and Mobile Node behaviors including the error recovery mechanisms for various scenarios related to NAI- based home address assignment have not yet been specified. This document specifies a procedure that the Mobile IP entities should follow in order to facilitate NAI-based home address assignment under various circumstances. "Prototype of a Generic AAA Server", Cees de Laat, 30-Jun-04, In this document a prototype of an AAA (Authentication, Authorization, Accounting) server is presented. The prototype is build in accordance with the RFCs 2903, 2904 and 2905. As the AAA concept is a multi-tier concept we have chosen for JAVA Enterprise Beans (J2EE) to build the prototype. New techniques and protocols supported by the J2EE platform are discussed. Web service standards like SOAP are explored. A general architecture of an AAA server is outlined in Enterprise JavaBeans (EJB) component architecture. "DHCPv4 Option for Midcom Middlebox", Joel Tran, 2-Apr-04, The Dynamic Host Configuration Protocol [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Midcom Protocol need to know the presence of Midcom middleboxes, such as firewalls and network address translators, in order to enable communication across theses devices. A DHCPv4 option provides a means for the entities to determine the Midcom middleboxes IPv4 address or domain name. "Establishing Reachability Behind NATs", Melinda Shore, 26-Mar-04, One of the most persistent, difficult problems introduced with NATs is voluntary reachability -- a NATted device making itself avail- able to the public internet. This paper is an overview of the cur- rent status of reachability, a decomposition of the problem and a proposal for going forward. "Ad-Hoc Conferencing in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Alan Johnston, 30-Mar-04, This document describes how to create a conference using SIP ad-hoc methods and a URI list. In particular, we describe a mechanism that allows a client to provide a conference server with the initial list of participants for an ad-hoc conference. "Subscriptions to Ad-Hoc Resource Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Adam Roach, 30-Mar-04, This document describes how to create subscriptions to ad-hoc resource lists in SIP. This is done by having the SUBSCRIBE request that requests the creation of the subscription carry a URI list. "Transmission of IPv4 and ARP Packets over Fibre Channel", Claudio DeSanti, Craig Carlson, 31-Mar-04, This document specifies a way of encapsulating IPv4 and ARP packets over Fibre Channel, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. "Email Submission Between Independent Networks", Carl Hutzler, Dave Crocker, Pete Resnick, Robert Sanderson, Eric Allman, 31-Mar-04, Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. Consequently the document offers recommendations for constructive operational policies between independent operators of email transmission services. The document will seek BCP status. Comments and discussion of this document should be addressed to the ietf-smtp@imc.org mailing list. "Requirements for assisted tunneling", Alain Durand, Florent Parent, 31-Mar-04, This document defines requirements for a tunnel set-up protocol that could be used by an ISP to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity without having to upgrade its access network. "DNS Discovery for global connectivity in IPv6 Mobile Ad Hoc Networks", Soohong Park, 31-Mar-04, This document proposes the mechanism of DNS Discovery for global connectivity based on modified manet Router Advertisement message in IPv6 mobile ad hoc networks. "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", Pasi Eronen, Hannes Tschofenig, 31-Mar-04, This document describes how existing NAT Traversal functionality could be leveraged to better support mobility and multihoming for IKEv2. The purpose is not to specify a finished solution, but rather to provide input for discussions in the MOBIKE WG. In particular, this draft raises questions to what extent the complexity present in the two other MOBIKE protocol proposals is actually necessary. These questions are not answered in this document, but are to be discussed in the MOBIKE WG. "XHTML+Voice - application/xhtml+voice+xml", Gerald McCobb, 2-Apr-04, This document describes the registration of the MIME sub-type application/xhtml+voice+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. The XHTML+Voice 1.2 language specification is maintained by the VoiceXML Forum at . "An LDAP Schema for CMU SASL auxiliary properties plugins", Alexey Melnikov, 2-Apr-04, The CMU SASL implementation of the RFC 2222 defines an API for auxiliary properties (auxprop) plugins. Auxprop plugins can store properties. A property can be a user password in cleartext or in a hashed form used by a particular SASL mechanism, or any other information associated with the user. This document describes a schema for the storage of auxprop properties in an LDAP directory server. "Authenticated Service Identities for the Extensible Authentication Protocol (EAP)", Jari Arkko, Pasi Eronen, 2-Apr-04, A common arrangement in network access is the separation of the actual network access device (such as a wireless LAN access point) from the authentication servers. In the Extensible Authentication Protocol (EAP) framework, different authentication methods can provide varying security properties. If the EAP methods support authentication of service identities, it becomes possible for the clients to verify not only that the access device is trusted, but also that the parameters advertised by the access device are correct. "EAP shared key methods: a tentative synthesis of those proposed so far", Florent Bersani, 2-Apr-04, The purpose of this draft is to gives a broad picture of the existing proposed EAP methods, with a focus on shared key EAP methods. Indeed, it is the belief of the author that a standard replacement for EAP- MD5 (that is deprecated due to security reasons) is needed. By listing the existing shared key EAP methods, the goal is to gather consensus that such a multiplication of methods is detrimental and that a single methods retaining the best of the existing proposals could and should be drafted. "SMTP Service Extension for Inline DSNs", Eric Hall, 3-May-04, This memo describes a mechanism for the negotiation and transfer of per-recipient notification responses in SMTP. "Declaring the State of an Internet Draft", Alex Rousskov, 5-Apr-04, This memo describes a mechanism to relay the state(s) of an Internet Draft to the reader. This mechanism may be used, in part, to encourage or discourage review submission, test suite creation, and prototype implementation of the entire draft or its portions. The state of the draft is declared using a human-friendly notation suitable for automated extraction of standard states. "Multiple recipient MESSAGE requests in the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Gonzalo Camarillo, 6-Apr-04, This document specifies how to request a MESSAGE exploder to send a copy of a MESSAGE to a set of destinations. The client sends a SIP MESSAGE request with a URI list to the MESSAGE exploder, which sends a similar MESSAGE request to each of URIs included in the list. "Requirements for Assured Service Capabilities in Voice over IP", Michael Pierce, 6-Apr-04, Assured Service refers to the set of capabilities used to ensure that critical communications are established and remain connected. This memo describes the requirements for such capabilities in support of real-time communications for voice using specific networks such as those used by government agencies, but they could also be applied in commercial environments. "Architecture for Assured Service Capabilities in Voice over IP", Michael Pierce, 6-Apr-04, Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. This memo describes the architecture required to meet the requirements detailed in [Pierce1]. "Examples for Provision of Preferential Treatment in Voice over IP", Michael Pierce, 6-Apr-04, Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. [Pierce] describes the requirements, one of which is to provide preferential treatment to higher priority calls. IEPS refers to a set of capabilities used to provide a higher probability of call completion to emergency calls made by authorized personnel, usually from ordinary telephones. This also requires some form of preferential treatment. This informational memo describes some of the methods which may be applied to provide that preferential treatment. "Review of MSRP Delivery Mechanisms", Orit Levin, 6-Apr-04, This paper shows that the currently defined per-message hop-by-hop mechanism doesn22t scale for large deployments and is not feasible for scalable IM conferencing. Instead, the paper proposes to replace this mechanism with an MSRP layer "per TCP connection keep-alive mechanism". This paper also reinforces the need for the end-to-end mechanism to be defined in the core MSRP specification and to become the abstraction for all MSRP applications regardless the underlying topology in use. "Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB)", Steve Silverman, Dan Sullivan, Michael Pierce, Don Choi, 6-Apr-04, Some networks require certain packet flows to be transported with preferential treatment over others of the same type. This draft defines a new PHB (Per Hop Behavior), the Multi-Level Expedited Forwarding (MLEF) PHB. RFC 3246 [3] defines the Expedited Forwarding PHB for applications requiring low latency, but with a single DSCP and treatment. This draft extends that concept and defines a PHB with multiple treatments for packet flows for applications requiring low latency and multiple priority levels. "Relaxing SMTP's "deliver or notify" rule", Robert Zinn, 8-Jun-04, Current SMTP RFCs are interpreted by some as requiring non delivery notice to be sent, even when the "reverse-path" is forged by a virus. Some ISPs are now dropping such messages silently. Silent dropping of such messages should be encouraged under certain circumstances, however this should not be taken as a permananet carte-blanch to silently discard any message that one does not like. "Using algorithms GOST R 34.10-2001, GOST R 34.10-94 and GOST R 34.11-94 for XML Digital Signatures", Grigorij Chudov, Serguei Leontiev, 7-Apr-04, This document specifies how to use Russian national cryptographic standards GOST R 34.10-2001, GOST R 34.10-94 and GOST R 34.11-94 digital signatures and public keys with XML Signatures [XMLDSIG]. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. "Client SMTP Validation (CSV)", Dave Crocker, David Crocker, 15-Jun-04, Internet mail relies on exchanges between systems that have made no prior arrangement with each other. For reasons of history and expediency, the current service provides a level of accountability for participating hosts that is no longer adequate. This makes it impossible to vet MTAs or find recourse when their operation causes problems. Client SMTP Validation (CSV) provides an economical service that permits an SMTP server to decide whether messages sent by the client SMTP are likely to be well-behaved, or at least to decide whether the client is sufficiently accountable for its actions. CSV provides a small, simple and useful improvement to Internet mail service accountability. It builds upon the existing practise of service providers that accredit the networks from which sending systems are connecting. "Qos Signaling for PW", Himanshu Shah, 8-Apr-04, This document discusses how a tail-end PE can signal the Quality of Service parameters of the local Attachment Circuit to the head-end PE for appropriate Pseudowire generation from head to tail end PE. "Storage Resource Broker URI Scheme Registration", Lucas Gilbert, 8-Apr-04, This document is the Storage Resource Broker (SRB) group recommendation for a SRB Uniform Resource Identifier (URI) which may be used to resolve the address of a network entity to which SRB calls may be directed. This document is published as an Internet Draft for ease of access and registration with the Internet Assigned Numbers Authority (IANA). "Session Initiation Protocol (SIP) Conferencing", Ranjit Avasarala, Nataraju Alilaghatta, Sreeram Kanumuri, Ravikiran Basavaraj, 15-Apr-04, This document describes the conference service using Session Initiation Protocol. This document explains a mechanism for initiating, modifying and terminating a SIP based conference session. It also explains procedures for adding and removing participants in the conference. "Mobility Support For TCP", Wesley Eddy, 9-Apr-04, Once a TCP connection is established, there are no mechanisms for dynamically rebinding the connection to new IP addresses or port numbers. During the lifetime of a TCP connection, a mobile host's transition between networks (and the corresponding change in its IP address) will break any established TCP connections. As a remedy, this document presents an extension of TCP with support for dynamic bindings of IP addresses and port numbers. Compatibility with existing TCP implementations is maintained, and reasonable steps are taken to prevent remote-redirction attacks. "Add anycast in mobile ipv6 router message", Yunyong Zhang, Yunjie Liu, Zhijiang Zhang, 9-Apr-04, The memo tries to add anycast mechanism in current ICMP router solicitation message and router advertisement message so as to use one compound message to get both care-of address and unicast address of server. "Minimum TCP connections based anycast routing protocol", Yunyong Zhang, Yunjie Liu, Zhijiang Zhang, 9-Apr-04, The memo tries to construct a minimum TCP connections based IPv6 anycast routing protocol, so as to avoid the congestion problem of the nearest server and improve the network performance. "H.350 Directory Services", Tyler Johnson, Sakae Okubo, Simão Ferraz de Campos, 12-May-04, The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. Specific differences between this text and the original include: 1. This text contains a Security Considerations section (section 9) not found in the original. 2. This text includes an additional reference to RFC 2798 which defines inetOrgPerson and userSMIMECertificate. 3. This text does not contain the non-normative appendices found in the original. These appendices include implementation considerations and graphics for system implementers. "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 24-Jun-04, Mobile IPv6 [1] uses IPsec [2] to protect signaling between the mobile node and the home agent [3]. This document defines how IPsec could be used between the mobile node and correspondent nodes, including home address option validation (aka. triangular routing), protection of mobility signaling for routing optimization and suitable configurations. "A Consolidated Overview of Version 3 of the Simple Network Management Protocol (SNMPv3)", David Perkins, 12-Apr-04, This document describes a Session Based Security Model (SBSM) for use within version 3 of the Simple Network Management Protocol (SNMPv3). The security model is designed to establish a "session" between two interacting SNMPv3 entities, over which SNMP operations can be sent securely. It provides a number of security properties not previously available in defined SNMPv3 security models, such as public key based identity authentication, limited life-time keying, and the ability to make use of previously implemented and deployed security infrastructures for purposes of identification and authentication. "Moving documents to Historic: A procedure", Harald Alvestrand, Eliot Lear, 14-Apr-04, This document describes a procedure for performing the downgrading of old Proposed and Draft standards described in RFC 2026 without placing an unreasonable load on groups charged with performing other tasks in the IETF. It defines a new group, called the 'Commission for Protocol Obsolesence', which shall recommend to the IESG downgrading or progressing documents on the IETF standards track. Ultimate decisions still rest of with the IESG, with appeal to the IAB. "BGP Cease Subcode - Implementation Report", Enke Chen, 14-Apr-04, This document provides an implementation report for the BGP Cease Subcodes. "GRSVP-TE signaling extension to move Management created LSP to Control Plane and vice versa.", Diego Caviglia, Francesco Lazzeri, Nicola Ciulli, 5-May-04, This memo introduces a new flag in the Administrative Status object, namely the 'Fake' flag. This flag SHOULD be used in order to move under the Control Plane (CP) domain LSPs that were created by the Management Plane (MP), and vice versa. The result of the Fake flag in GRSVP-TE is twofold: at the end of the set-up signaling flow, an LSP that was created by Management Plane is moved under to Control Plane domain. Similarly, at the end of a deletion procedure the LSP that was under the Control Plane domain is moved under the Management Plane domain. "EAP CAVE Authentication", Zhiming Li, Nora Dabbous, JunHyuk Song, Jain Wang, 15-Apr-04, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the cdma Universal Identity Module (UIM). The mechanism includes network authentication, user anonymity support and a re-authentication procedure. "Cross Area Late Review", Harald Alvestrand, 15-Apr-04, This document gives an outline of a way to put together review teams for documents in late review (pre-approval time). It is intended as input to the ICAR WG. Comments are welcome, and can be directed to the editor or to the ICAR mailing list "Evaluation of v6ops Auto-discovery for Tunneling Mechanisms", Jordi Palet, Miguel Diaz, 14-Jun-04, Tunneling is commonly used in several IPv6 transition mechanisms. To be able to automate setting up tunnels, one critical component is being able to automatically determine the tunnel end-point for the tunneling mechanism. This memo analyses the different approaches for configuring the IPv6 tunnel endpoint on a node. "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6)", Wassim Haddad, Lila madour, Jari Arkko, Francis Dupont, 21-Jun-04, This memo suggests a new and enhanced route optimization security mechanism for Mobile IPv6 (MIPv6). The primary motivation for this new mechanism is the reduction of signaling load and handoff delay. The performance improvement achieved is elimination of all signaling while not moving, and 33% of the per-movement signaling. "ISATAP Extensions for Mobility, Multihoming and Efficiency Improvement (IEMMEI)", Fred Templin, 10-May-04, The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks via automatic tunneling using a link abstraction similar to the Non-Broadcast, Multiple Access (NBMA) model. This document describes operational extensions for ISATAP that enable a dynamic tunnel endpoint management abstraction similar to the ATM Permanent/Switched Virtual Circuit model. Nodes can use these extensions to realize mobility, multihoming and efficiency improvements. "Registration of Netnews header fields", Charles Lindsey, Graham Klyne, 6-Jul-04, This document defines the initial IANA registration for permanent Netnews message header fields, per [[[RFC XXXX/ draft-klyne-msghdr-registry-07]]]. "DNS Naming Convention for Outbound Internet Email Servers", April Lorenzen, 20-Apr-04, This document offers a recommended standardized FQDN (Fully Qualified Domain Name) naming convention pattern for servers used to send outbound internet email. The purpose is to allow inbound internet email servers to recognize outbound email servers designated as authorized or unauthorized by those in control of DNS for the sending server IP addresses. "DNSSEC Resolver Interface to Applications", R Gieben, Gilles Guette, Olivier Courtay, 20-Apr-04, This document describes an interface between a DNSSEC aware resolver and an application. This interface will define which kind of information a DNSSEC aware resolver is able to send back to an application. The basic question we want to answer is: 'What does an application want to know from a secure aware resolver?'. In Section 4 we define an error bit array. The secure aware resolver will set specific bits in the array. With the added information in the error array, the application can have extra control on what to do with bogus data. When something goes wrong during the secure resolving process the application may also want to know where in the DNS tree this happened. With a simple error array one can not convey this information. A possibility might be to give the application the owner name of the DNS node where the validation failed. This document is written in the hope that it will lead to a discussion within the IETF on the resolver-application interaction(s). "TCP Abort Timeout Option", L Eggert, 14-Jul-04, The TCP Abort Timeout Option allows conforming TCP implementations to exchange requests for individual, per-connection abort timeouts. The TCP abort timeout controls how long transmitted data may remain unacknowledged before a connection is aborted. TCP implementations typically use a single, system-wide timeout value. Using individual, per-connection timeouts allows established TCP connections to survive extended periods of disconnection. "Expanded Address Allocation for Private Internets", Tony Hain, 21-Apr-04, This document updates RFC 1918 and identifies additional IPv4 address space for use in private networks. "An Agreement Between the Internet Society and the Jabber Software Foundation Regarding the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 21-Apr-04, In 2002, the Jabber Software Foundation (JSF) contributed specifications for existing technologies to the Internet Standards Process conducted by the Internet Engineering Task Force (IETF). These specifications, which define the Extensible Messaging and Presence Protocol (XMPP), have recently been approved as Proposed Standards by the IETF. This memo consitutes offical public record of an agreement between the JSF and the Internet Society to acknowledge the transfer of change control over the aforementioned specifications from the JSF to the IETF. "Transmission of IPv6 Packets over 802.11/WLAN Networks", Soohong Park, Syam Madanapalli, O. Rao, 22-Jul-04, This document describes the transmission of IPv6 packets over WLAN with several considerations such as stateless address autoconfiguration (i.e., forming addresses and DAD issue), NDP Source and Target Link Layer Address Option formats and etc. "IPv6 Security Problem Statement", Alvaro Vives, Jordi Palet, 21-Jul-04, Today, each network is often secured by a unique device (i.e. security gateway or firewall) that becomes a bottleneck for the end-to-end security model with IPv6. The deployment of IPv6 enabled devices and networks bring some issues, which must be addressed by security administrators in order to guarantee at least the same level of security that is obtained nowadays with IPv4 and network-based (including perimetral-based) security schemes, allowing at the same time all the IPv6 advantages. "Evaluation of IPv6 Auto-Transition Algorithm", Jordi Palet, Miguel Diaz, 21-Jul-04, This memo evaluates a method called "auto-transition" to ensure that any device can obtain IPv6 connectivity at any time and whatever network is attached to, even if such network is connected to Internet only with IPv4 or already offers IPv6 but with poor performance. "Home Subnet Prefix or the Home Agent discovery for Mobile IPv6", Kuntal Chowdhury, Mohamed Khalil, Haseeb Akhtar, 22-Apr-04, This document proposes a method that would allow the dynamic discovery of the HAs (Home Agents)in the Mobile IPv6 while eliminating the need for the static provisioning of the MN (Mobile Node) with its home link prefixes of the home subnet. "Digest Authentication Examples for Session Initiation Protocol (SIP)", Paul Smith, Ian Clarkson, 22-Apr-04, RFC3261 [2] recommends that SIP requests be authenticated using HTTP Digest authentication as defined in RFC2617 [3], and many vendors have successfully added this function to their products. However implementation bugs are still being observed both at interoperability events and in the field. This document provides worked examples of Digest authentication usage in SIP. It is intended to help new SIP implementers, and to provide a common set of test authentication examples against which an implementation may be checked. "Using Working Group Review Committees", Mark Allman, James Kempf, 22-Apr-04, This document sketches a potential quality control mechanism for the IETF in the form of working group review committees. The idea is to form a small committee per working group that will provide document review and advice throughout the working group's lifetime. "Internet Relay Chat (IRC) Client to Client Protocol (DCC2) Connection Negotiation", Dan Smith, 23-Apr-04, The Direct Client Connection v2 (DCC2) connection negotiation specification describes how to establish connections between individual IRC clients. This draft describes a direct client connection protocol which supports the publishing of supported protocol options and connection negotiation. The DCC2 protocol is intended to be part of the IRC Client to Client Protocol (CTCP) framework. "Mediating Network Discovery in the Extensible Authentication Protocol (EAP)", Farid Adrangi, 18-Jun-04, This document defines a mechanism to enable a wireless client to discover roaming partners of an access network over EAP. The purpose is to help a wireless client select the most appropriate roaming partner as a next hop for routing of AAA packets. This solution is especially useful in roaming scenarios where the access network does not have a direct relationship with the wireless client's home network - i.e., when AAA packets can not be directly routed from access network to the home network. "Neighbor MR Authentication and Registration Mechanism in Multihomed Mobile Networks", Seungho Choi, 26-Apr-04, In multihomed mobile networks, multiple Mobile Routers can be deployed to provide fault recovery or load sharing. Also, each Mobile Router (MR) can have a bi-directional tunnel with its own Home Agent (HA). In this multihomed mobile network scenario, the neighbor root MR can replace or share the operation of another MR. Therefore, MRs should cooperate with each other to provide session continuity or load sharing. We present an authentication and registration mechanism without introducing extra signaling messages. Using the Return Routability procedure of Mobile IPv6 and the Binding Update message with the neighbor MR registration option, the MR can authenticate and register the neighbor MR to its own HA. And the HA can use this registered neighbor MR information to provide fault recovery or load sharing. "Configured Tunnel End-Point Configuration using DHCPv4", Soohong Park, 8-Jul-04, The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This uses a DHCPv4 option to percolate the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 networks through IPv4. "User Session Tracking in RADIUS", Glen Zorn, 8-Jul-04, This document defines a pair of new messages and a new attribute designed to allow RADIUS servers to cleanly track user sessions. "DNS Based Blacklists and Whitelists for E-Mail", John Levine, 28-Apr-04, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become a de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. "Guidelines for Management of DNS Blacklists for Email", Yakov Shafranovich, 28-Apr-04, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of of IP addresses or domains. This memo discusses guidelines for management of public DNS blacklists. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list. "Generalized Traffic Engineering Protocol", Eiji Oki, 28-Apr-04, This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between a Constrained Shortest Path First (CSPF) engine and a GMPLS controller (GMPLS CNTL). A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols such as routing and signaling protocols and controls a GMPLS node. The CSPF engine provides a function of traffic engineering, which calculates LSP routes and judges whether a new lower-layer LSP should be established. "Inter-Area IP Route Attribute in IS-IS", Naiming Shen, 28-Apr-04, This document describes an extension to the IS-IS protocol to allow some routing attributes to be associated with advertised inter-area prefixes. The extension allows routers to learn this routing information without the knowledge of the link-state topology in another IS-IS level. The initial applications for this extension are inter-area IP MPLS fast reroute for node protection and inter-area TE LSPs. "IPv6 Multicast for Mobile Networks with MLD-Proxy", Christophe Janneteau, 28-Apr-04, This document addresses the problem of delivering IPv6 multicast traffic to nodes inside a mobile network. An approach based on the deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] in the mobile network, combined with the use of MLD [2][3] between the mobile router (MR) and the visited network, is proposed. Such a configuration allows multicast support for mobile networks, without the need to run a multicast routing protocol. In addition of being simple to implement and deploy, this approach provides global mobility in the Internet, and optimal multicast routing with nested mobile networks, while optimizing network and radio resources. This document does not specify new protocols, nor extensions to existing protocols. "Mobile IP v4 Home Network Access Identifiers", Henrik Levkowetz, 28-Apr-04, This document defines a Mobile IP v4 extension sub-type to be used to carry a NAI to uniquely identify the Home Network of a Mobile Node. "Prefix Limit Based Outbound Route Filter for BGP-4", Keyur Patel, 28-Apr-04, The BGP specification allows for "the ability to impose an (locally configured) upper bound on the number of address prefixes the speaker is willing to accept from a neighbor". In this specification, we define a new Outbound Route Filter type for BGP, termed "Prefix Limit Outbound Route Filter", which the speaker can use to communicate that upper bound to its peer. The peer is then required to abide by the limit. This is expected to have benefits in terms of resource consumption and more importantly, transparency of operation. "Stream Control Transmission Protocol (SCTP) Security Threats", Randall Stewart, 28-Apr-04, Stream Control Transmission Protocol RFC2960 [2] is a multi-homed transport protocol. As such, unique security threats exists that are addressed in various ways within the protocol itself. This document attempts to detail the known security threats and there countermeasures as detailed in the current version of the SCTP Implementors guide (SCTP-IG). It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP-IG. "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", Jonathan Lennox, 20-Jul-04, This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new protocol identifier, TCP/TLS. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate which will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. "Domain-based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", Leslie Daigle, 30-Jun-04, This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol to target server and port, dynamically. [Note to be removed for RFC publication: this work was originally referred to as "napstr", and draft-daigle-napstr-04 is the immediate precursor of draft-daigle-snaptr-00.] "IPv6 Prefix Delegation Using ICMPv6", Shankar Raman, 29-Apr-04, This document describes a Prefix Delegation Mechanism which delegates IPv6 prefixes to a subscriber's network (or "site") by an Internet Service Provider (ISP). It uses ICMPv6 messages to handle Prefix Delegation between the Delegating Router and the Requesting Router. "A Framework for Inter-Domain MPLS Traffic Engineering", Adrian Farrel, 12-Jul-04, This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. "RADIUS Dynamic Authorization Server MIB", Stefaan De Cnodder, 15-Jun-04, 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 the RADIUS client functions that support the dynamic Authorization extensions as defined in RFC 3576. "An approach to Call Park/Retrieve using SIP", Michael Procter, 30-Apr-04, Call Park and Call Retrieve are useful telephony services that are normally found on traditional PBXs. Implementing these services using the Session Initiation Protocol (SIP) in the way described in the SIP Service Examples draft [1] is straightforward, but suffers from a useability problem when implemented using SIP User Agents resembling traditional business telephones. This draft discusses a simple extension to cater for this style of endpoint. "Route Optimization Scheme based on Path Control Header", Jongkeun Na, 30-Apr-04, In this memo, we propose a unified Route Optimization (RO) scheme that can solve several types of RO problem by using Path Control Header (PCH) Piggybacking. In our scheme, Home Agent (HA) does piggyback the PCH on the packet which is reversely forwarded from Mobile Router (MR). That enables any PCH-aware routing facility on the route to make a RO tunnel with MR using the Care-of address of MR contained in the PCH. By applying to some already known NEMO RO problems, we show that our scheme can incrementally optimize the routes via default HA-MR tunnel through the simple PCH interpretation. "The APPLICATION/MBOX Media-Type", Eric Hall, 14-Jul-04, This document requests that the application/MBOX media-type be authorized for allocation by IANA, according to the terms specified in RFC 2048 [RFC2048]. "RBridges: Transparent Routing", Radia Perlman, 20-Jul-04, This design provides the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. This allows zero configuration of the switches within the campus, and allows nodes to move around within the campus without changing IP addresses. This capability is often provided today with bridges. Bridges do accomplish this goal. However, bridges have disadvantages: routing is confined to a spanning tree (precluding pair-wise shortest paths), the header on which the spanning tree forwards has no hop count, spanning tree forwarding in the presence of temporary loops spawns exponential copies of packets, nodes can have only a single point of attachment, and the spanning tree, in order to avoid temporary loops, is slow to start forwarding on new ports. The design in this paper avoids these disadvantages of bridges while maintaining the advantages. This design works for both IPv4 and IPv6. This document is a work in progress; we invite you to participate on the rbridge mailing list at http://www.postel.org/rbridge "Mobile IPv4 Flow Mobility Problem Statement", Nicholas Fikouras, 4-May-04, Internet capable mobile or portable devices are already a modern commodity while it is becoming all the more common that such devices are hosts to more then one wireless interface. The aim of this document is to show that a mobile user may make best use of this property by using multiple wireless interfaces in parallel. This would incline that the mobile user can distribute active flows across the available wireless interfaces and is able to seamlessly transfer them between the wireless interfaces in mid-session without interruption. "Secure Mobility Dimensions", Atul Sharma, 10-May-04, Several solutions to internet mobility have been offered. But the solutions are sometimes for different kinds of mobility with different kinds of requirements. It becomes confusing to see these disparate types of mobility being discussed in the same vein. This document is an attempt to delineate and classify different types of network mobility. This attempt shall help us in understanding already existing mobility solutions and at the same time help us in proposing new solutions. Adding security to mobility adds a new dimension by itself. Various types of secure mobility are discussed closely following the types of mobility. "Dynamic Authorization Client MIB", Stefaan De Cnodder, 15-Jun-04, 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 the RADIUS dynamic authorization client (DAC) functions that support the dynamic authorization extensions as defined in RFC3576. "ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks", Joseph Touch, 6-May-04, Recent attacks on core Internet infrastructure indicate an increased vulnerability of TCP connections to spurious resets (RSTs). TCP has always been susceptible to such RST spoof attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. Finally, it proposes an extension to IPsec configuration called ANONsec that intends to efficiently and scalably secure any transport protocol from such off-path third-party spoofing attacks. "RADIUS Error Messages", Glen Zorn, 8-Jul-04, This document describes new RADIUS protocol elements designed to allow the communication of packet and attribute errors between RADIUS servers and clients. "BGP Route Reflection - Implementation Report", Enke Chen, 10-May-04, This document provides an implementation report for the BGP Route Relection. "Light Weight Access Point Protocol (LWAPP)", , 11-May-04, Wireless Access Points are not strictly Layer 2 bridges. Such devices may be much simpler, barely more than radios. They may also perform some additional or higher layer functions such as those performed by switches and routers. For example, in IEEE 802.11 networks, Access Points can function as Network Access Servers. This is one reason Access Points may have IP addresses and function as IP devices. "DoS vulnerability of TCP by acknowledging not received segments", Arturo Azcorra, 25-May-04, TCP relies in communication peers to implement congestion control by hosts voluntary limiting their own data rate. Nevertheless this assumption introduces unsolved DoS attack opportunities. A DoS attack can be easily performed by a host that acknowledges TCP segments not yet received (maybe even not sent). This document presents and briefly describes the problem, already identified and pointed before, but also shows than it can be easily performed (with very interesting results) and proposes some server-side modifications to TCP stack in order to make this attack more difficult to perform. These modifications do nor cause interoperability issues. "Automated Updates of DNSSEC Trust Anchors", Michael StJohns, 19-Jul-04, This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against single key compromise of a key in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor. This mechanism, if adopted, will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. "A Simple Approach to Data Source Authentication for Multicast Security", Atul Sharma, 11-May-04, Data source authentication is an important requirement to provide multicast security. Data source authentication assures that the member claiming to send the data is the actual sender. An imposter member should not be able to claim to be the sender of the data. This document proposes a scheme by which data source authentication can be acheived. This approach does not use digital signatures or assume any time synchronization between the sender and the receivers. Instead of directly authenticating a multicast communication, it is split into a 1-to-1 authenticated unicast to GCKS followed by an authenticated multicast by GCKS. Message Authentication Codes (MACs) are used instead of digital signatures in both the authenticated unicast and the authenticated multicast. "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Russ White, 12-May-04, There is a great deal of concern over the security of the Border Gateway Protocol, which is used to provide routing information to the Internet and other large internetworks. This draft provides an architecture for a secure distributed registry of routing information to address these concerns. The draft begins with an overview of the operation of this system, and then follows with various deployment scenerios, starting with what we believe will be the most common deployment option. "Multiple recipient MESSAGE requests in the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Gonzalo Camarillo, 12-May-04, This document specifies how to request a MESSAGE exploder to send a copy of a MESSAGE to a set of destinations. The client sends a SIP MESSAGE request with a URI list to the MESSAGE exploder, which sends a similar MESSAGE request to each of URIs included in the list. "LDAP: Additional Matching Rules", Alexandre Pauzies, 12-May-04, This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). Thoses matching rules are simple adaptations of existing LDAP matching rules allowing a more flexible match on non-ASCII strings. "Nested Nemo Tree Discovery", Pascal Thubert, Nicolas Montavont, 12-May-04, The purpose of this paper is to describe a minimum set of features that extends the Nemo basic support in order to avoid loops in the nested Nemo case. As a result, Mobile Routers assemble into a tree that can be optimized based on various metrics. "Repeated Authentication in IKEv2", Yoav Nir, 12-May-04, With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Russ White, 12-May-04, There is a great deal of concern over the security of the Border Gateway Protocol, which is used to provide routing information to the Internet and other large internetworks. This draft provides an architecture for a secure distributed registry of routing information to address these concerns. The draft begins with an overview of the operation of this system, and then follows with various deployment scenerios, starting with what we believe will be the most common deployment option. "Extensions to BGP Transport soBGP Certificates", James Ng, 12-May-04, There is a great deal of concern over the security of routing systems within the Internet, particularly in relation to the Border Gateway Protocol [BGP], which is used to provide routing information between autonomous systems. This document proposes a system where the origin of any advertisement within BGP can be verified and authenticated, preventing the advertisement of prefix blocks by unauthorized networks, verifying that the final destination in the path is actually within the autonomous system to which the packets are being routed, and proving the validity of the AS Path contained in the update. "A Generalized Mechanism for Control of Unwanted Application Communications", Chistopher Bonatti, 12-May-04, This draft describes a new anti-spam technique that could be applied to e-mail or (in principle) any push-mode application. It includes a discussion of problem background, a description of the proposed technique, and an analysis of the effectiveness of the approach. "Licklider Transmission Protocol", Scott Burleigh, 15-Jul-04, This document describes the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links in challenged internet environments exhibiting extremely long message round-trip times (RTTs), frequent interruptions in connectivity, and high bit error rates. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting 'long-haul' reliable transmission in interplanetary space, but might have applications in other environments as well. In an Interplanetary Internet setting deploying the Bundling protocol being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports, is stateful, has no negotiation or handshakes, and supports out-of-transmission-order data delivery. "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, 12-May-04, This document specicies the Binary Floor Control Protocol (BFCP). BFCP is used between conference participants and floor control servers, and between floor chairs and floor control servers. "CAPWAP Tunneling Protocol (CTP)", Inderpreet Singh, 14-May-04, With the overwhelming choice of proprietary implementations of centralized control and management of wireless access points and access controllers there is a great demand for a standard protocol and architecture that enables the deployment of large scale wireless networks. This document describes the CAPWAP Tunneling Protocol, a protocol that allows for the centralized control and provisioning of a large number of wireless access points from access controllers. It is supported by an architecture where the MAC layer of the RF technology is terminated within the AP. This allows for the protocol to be extensible to multiple radio technologies. It assumes an IP connection between the access points and access controllers and has signaling primitives to enable wireless station mobility between access points. Therefore, seamless Layer 3 subnet mobility is enabled by this protocol. "Mobility Agent Identity Extension for Mobile IPv4", Sri Gundavelli, Kent Leung, 14-May-04, This document specifies a new extension that can be used by any mobility agent operating Mobile IPv4 protocol in the Mobile IP Registration messages for offering its identity to the other mobility agent receiving the message. This is a generic extension that can be used in the Registration Request or Reply message and can be used by the Home Agent, Foreign Agent and the mobile node. "Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE signaling using Bundled Traffic Engineering (TE) Links", Zafar Ali, 14-May-04, This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE signaling. It extends the TLV definitions of [RFC3471] to provide the means to identify component links of unnumbered link bundles within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects. It also defines the extensions to GMPLS RSVP-TE in support of component link identifiers for explicit resource control and recording over link bundles. "Indicating redirection reasons in SIP", John Elwell, 14-May-04, This examines the need for signalling additional information concerning the reason for redirection in SIP and proposes two possible solutions. "Design Choices When Expanding DNS", Patrik Faltstrom, 14-May-04, This note discusses how to extend the DNS with new data, for a new application. A discussion which too often circulate around reuse of the TXT record. It lists different mechanisms to accomplish the extension to DNS, and comes to the conclusion use of a new RR Type is the best solution. "Requirements for MIPv4 Mobility Agents Support of Emergency Telecommunication Service", Ken Carlberg, Charles Perkins, 14-May-04, This document presents a list of requirements for the IPv4 Mobile IP (MIP) protocol to support Emergency Telecommunications Service (ETS). "Considerations for Session-specific SIP Session Policies", Volker Hilt, 14-May-04, This draft intends to trigger discussions within the SIP community on how to implement session-specific policies in SIP. In particular, we discuss why the piggyback model, which was proposed previously, does not meet important requirements. "DNS Extension for SRV-Client Address Authorization (SRV-CAA)", Douglas Otis, 17-May-04, Typical use of DNS records enables resolving a server address, but this record extension authorizes clients to initiate a specific protocol. This document simply extends definitions for fields of a DNS SRV record as defined in [RFC2782] and appends '_c' to the label in the Proto field. This extension enables administrative control of a domain referenced by a client as it enables verification of permitted client addresses. This record extension is useful to authorize a client for a specific protocol and possibly useful for confirming veracity of a return path also referenced by a client. Although an in-addr.arpa IP address reverse DNS query may assert a domain, the domain referenced within client identification may be an alias and thus not match. In addition, specific protocol authorization for the client can not be deduced and reverse DNS information is optional, typically administered separately or not delegated, and thus often providing information of limited value. "Internet Mail Architecture", David Crocker, 8-Jul-04, Over its thirty year history, Internet mail has undergone significant changes in scale and complexity. The first standardized architecture for email specified a simple split between the user world and the transmission world, in the form of Mail User Agents (MUA) and Mail Transfer Agents (MTA). Over time each of these has divided into multiple, specialized modules. Public discussion and agreement about the nature of the changes to Internet mail has not kept pace, and abuses of the Internet mail service have brought these issues into stark relief. This draft offers clarifications and enhancements, to provide a more consistent base for community discussion of email service problems and proposed email service enhancements. "Privacy Enhanced Local Ethernet Network with Protocol Anonymization", Laszlo Keri, 17-May-04, The privacy requirement of anonymity is much harder to achieve than security goals like confidentiality or authentication, since network routing has to take place between well known spots of the network. There are solutions providing anonymity on the Internet implemented on the application level, but there's also a possibility to achieve local anonymity on Ethernet networks without the introduction of new anonymous protocols by following a protocol anonymizing approach described in this document. Protocol anonymization is a simple network operation mode, which can provide local client anonymity on Ethernet networks under certain circumstances by eliminating the host identification capabilities of widely used local network protocols. "Additional authorization identity syntax for Kerberos-aware Directories", Alexey Melnikov, 17-May-04, This document defines new LDAP authorization identity syntax for Kerberos-aware Directories. "Conference Policy Authorization Rules", Aki Niemi, 18-May-04, Authorization is a key component in conference policy. Authorization rules specify who is allowed to join a conference, see floors and request them, subscribe to conference-information and so on. This document proposes an Extensible Markup Language (XML) document format for conference authorization rules. This draft is intended for discussion purposes only, and in case this approach is taken, it would need to be merged with the on-going Conference Policy Control Protocol (CPCP) work. "EAP-Double-TLS Authentication Protocol", Mohamad Badra, Pascal Urien, 18-May-04, EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a full TLS handshake is used to mutually authenticate a client and server and to share a secret key. EAP-Double-TLS extends this authentication negotiation by using the secure connection established by the TLS Pre Shared Key (PSK) handshake to exchange additional information between client and server. The secure connection established by the PSK handshake may then be used to allow the server and the client to securely exchange their identity (X509 certificates) and to update security attributes for next sessions (session ID and master secret). EAP-Double-TLS enables client’s anonymity, and allows client and server to establish keying material for use in the data connection between the client and the authenticator. The keying material is established implicitly between client and server based on the TLS PSK handshake. "Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)", Mark Delany, 18-May-04, "DomainKeys" creates a domain-level authentication framework for email by using public-key technology and the DNS to prove the provenance and contents of an email. This document defines the base framework of digitally signing email on a per-domain basis. Subsequent documents leverage this base framework to prove and validate email delivery paths as well as extend signing to facilitate per-user authentication. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of "spam" and "phishing". While this document presents technical details, it is not yet intended as a definitive or final specification, rather, the intent is to define a framework and sufficient technical detail to promote experimental deployment with a view to evolving into a comprehensive authentication standard for email. "Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, 18-May-04, Performing an approximation in some form of multicast distribution tree accounting proves to be useful for billing and debugging. The Population Count extensions to PIM, documented in this draft, provide an efficient method to achieve this. "SMTP Client Address Authorization (SMTP-CAA)", Douglas Otis, 19-May-04, The helo/ehlo domain reported by a client at the beginning of an SMTP [RFC2821] session has largely been ignored without reliable means to verify this information. To properly recognize a domain sending mail, the domain of the client must be verifiable. This document utilizes a DNS SRV record that extends the definitions for fields of this record as defined in [RFC2782] where the label becomes unique by appending a label of "__caa" following the Proto field. Server verification of permitted client addresses becomes possible as a method to confirm the domain of a client without having prior information shared. Cooperation between client and server domains utilizing this method exclude third party masquerades as originating from within cooperative domains. Initially only a notice of Unknown or Unconfirmed will be added to mail from uncooperative domains unless the domain is determined to be not valid, where then the mail will be refused. This added notice provides assurance the server is checking client domains in addition to alerting users to the level of mail compliance on received mail. Once use of this method is common practice in conjunction with other means for confirming the client domain, mail may be refused if the client and/or domain fails these confirmation checks. "Applying Cryptographically Generated Addresses to BUB (BUB+)", Wassim Haddad, 19-May-04, This memo describes a method to exploit the Cryptographically Generated Address (CGA) features in highly mobile environment. The draft introduces a new optimization to the "Binding Update Backhauling (BUB)" proposal, which eliminates the need for running a return routability (RR) procedure at the beginning and improves its security. "TCP Adaptive User TimeOut (AUTO) Option", Fernando Gont, 19-May-04, The original TCP specification (RFC 793) defines a "USER TIMEOUT" parameter that sets the policy as to when a user connection should be aborted. However, TCP provides no means of letting users suggest an abort policy to a remote peer dynamically. Even though a fixed policy may work well in many cases, there are a number of scenarios where a fixed USER TIMEOUT value may be inappropriate, and some means of setting the abort policy dynamically may be necessary for TCP to be used effectively in such scenarios. This document defines a new TCP option, which lets a TCP peer suggest a USER TIMEOUT value to a remote TCP during the connection-establishment phase, and modify it during the life of a connection, thus adapting TCP's connection-abort policy as necessary. "Guideline for use of XML with iCalendar elements", Tim Hare, 20-May-04, This memo defines a guideline for using XML to represent calendaring information that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by [RFC 2445] and the protocols defined by [RFC 2446], [RFC2447] and [CAP]. This memo applies to all [RFC 2445] extensions and modifications. "Data Content for SIP User Agent Profile Delivery", Martin Dolly, 20-Jul-04, This document defines the data content for providing profile data to SIP user agents in support of the framework defined in I-D.ietf-sipping-config-framework-03.txt and is intended to be input to the data sets defined by draft-petrie-sipping-profile-datasets-00.txt "A TLS Hello Extension for Ticket Based Pre-Shared Keys", Nancy Cam-Winget, 20-May-04, This document describes a TLS extension that makes use of a pre- established ticket to distribute the shared secret for establishing a TLS session. The mechanism uses extensions to the TLS session resume hello exchange. In particular the ticket enables the client to maintain state so the server does not have to maintain per-client session state. The use of a hello extension allows fallback to a full ciphersuite handshake. Considerations for the initial establishment of the ticket material are discussed. "Request to Move RFC 1863 to Historic", Pekka Savola, 20-May-04, This memo requests moving RFC 1863, A BGP/IDRP Route Server"M alternative to a full mesh routing, to Historic status. This memo"M also Obsoletes RFC 1863. "Stackable Generic Security Service Pseudo-Mechanisms", Nicolas Williams, 20-May-04, This document defines and formalizes the concept of stackable pseudo- mechanisms for the Generic Security Service Application Programming Interface (GSS-API) and introduces a framework to support stackable pseudo-mechanisms and mechanism compositing. Stackable GSS-API pseudo-mechanisms allow for the composition of new mechanisms that combine features from multiple mechanisms. Stackable mechanisms that add support for Perfect Forward Security (PFS), data compression, additional authentication factors, etc... are facilitated by this document. "Stack Aware Architectures for Mobile Ad hoc Networks", Mukundan Venkataraman, Puneet Gupta, 20-May-04, Any operating protocol functions on the basis of a communication stack. While a layered approach towards a comprehensive stack development amends itself very well to division of labour and abstraction of problems, care must be taken to ensure that layers are so designed that they leverage benefits of using one another. In other words, layers should be so designed such that they are highly optimised for usage with one another. An essential feature of pervasive computing will be Mobile Ad hoc NETworks (MANETs). The two primary constraints to system design in MANETs are bandwidth and energy. We bring out the essential properties of layers in any general stack which make it highly efficient and practicable. We call this a “stack aware” architecture. We go on to exemplify this with the case of “helper nodes” in a MANET topology, and discuss the potential benefits of having them as a necessary ingredient for routing. We also bring out their significance in every layer of the integrated stack, using the OSI layers as a reference model. "Caller ID for E-mail", Robert Atkinson, 20-May-04, When e-mail is handed off today from one organization to another, as a rule no authentication of the sender of the e-mail or the computers delivering it on the sender’s behalf takes place. There are some simple steps which can be taken to significantly alleviate this problem, steps which mimic within the e-mail infrastructure the caller ID mechanism found in today’s telephone system. This proposal specifies that in addition to today’s practice of publishing in DNS the addresses of their incoming mail servers, administrators of domains also publish the addresses of their outgoing mail servers, the addresses of the computers from which mail legitimately originating from that domain will be sent. This information will then be used in enhancements to software that receives incoming mail to verify that computers handing off a message to them in fact are authorized to do so by the legitimate administrator of the domain from which the message is purported to have been sent. "IP Fast Reroute using tunnels", Stewart Bryant, 20-May-04, This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. The draft also describes the mechanisms needed to prevent the packet loss caused by loops which normally occur during the reconvergence of the network following a failure. "Web Distributed Authoring and Versioning (WebDAV) Locking Protocol", Julian Reschke, 15-Jul-04, This document specifies a set of methods and headers ancillary to HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, RFC2518) for the management of resource locking (collision avoidance). It updates those sections from RFC2518 that specify WebDAV's locking features. "IP Fast Reroute Framework", Mike Shand, 21-May-04, This document provides a framework for the development of IP fast re- route mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Christian Vogt, 21-May-04, The latency associated with Mobile IPv6's Return Routability test can have an adverse impact on delay-sensitive applications. Early Binding Updates mitigate this issue by already using a new care-of address in parallel with testing it. We propose and analyze a credit-based mechanism that prevents misuse of Early Binding Updates for amplified flooding attacks and discourages such misuse for non-amplified flooding attacks. "Credit-Based Authorization for Binding Lifetime Extension", Jari Arkko, Christian Vogt, 21-May-04, Mobile IPv6 return routability mechanisms require home and care-of address keygen tokens to be used to authorize a binding update to correspondent nodes. The current rules dictate that such authorization be performed every seven minutes, using tokens at most three and half minutes old. This requirement results in an average signaling traffic of around 7 bits per second when the hosts are not moving around. This traffic load by itself is neglible, but can be problematic for hosts in standby mode. We present a secure and lightweight extension of return routability that can reduce this signaling load to around 0.1 bits per second, and require hosts to wake up much less frequently. "Certificate Revocation Revisited Internet X.509 Public Key Infrastructure", Ed Gerck, 24-May-04, PKIX certificate revocation protocols are primarily described in RFC3280. This Document revisits limitations on determining the revocation status of a certificate. Ambiguous aspects of revocation and revocation delegation are resolved. An objective point of view is introduced as a reference that does not depend on the observer (e.g., the RP). The revocation status of a certificate issued by a conforming CA is shown to be always well-defined from a relying party's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately determinable at any period in time. The limitations on determining the revocation status of a certificate have nothing to do with the eventual result of the determination process by a relying party. The limitations have to do with the efforts for that determination, which may require a large (actually unspecified) amount of time and work. Some practices are also suggested, allowing a relying party to determine the revocation status of a certificate with higher reliability in less time. The same considerations apply to determinations of status "change" processes, including certificateHold and removefromCRL. "Valuable Antique Documents: A Model for Advancement", John Klensin, 24-May-04, RFC 2026 and some of its predecessors require that Proposed and Draft Standards either advance in grade within a reasonable period of time or that they expire and be moved to Historic. That procedure has never been followed on a systematic basis. A new procedure has been proposed that would make that action easier for protocols that have not gotten any real acceptance. In the interest of symmetry, fairness, and an orderly attic, it is worth noting that there are a number of protocol descriptions which have been at less than Full Standard level for a long time but which have proven their value by the traditional criteria of multiple interoperable implementations This document provides a procedure for upgrading such documents to Full Standards without creating an unreasonable burden on authors purely to meet the needs of procedural rituals or placing an unreasonable load on groups charged with performing other tasks in the IETF. "EAP lower layer attributes for AAA protocols", David Mariblanca, 22-Jun-04, This document defines a new AVP to be transported in RADIUS or Diameter when EAP is carried over these protocols. The purpose of this AVP is to determine which layer 2 protocol was used to encapsulate the EAP messages at the point they were initiated. "ICAR Proposed EArly Review (PEAR)", David Partain, 25-May-04, This memo proposes a lightweight and incremental approach to improving early cross-area review in the IETF. This proposal has two specific goals. Firstly, the current perception is that the IETF standardization process is bogged down and takes far too long. One factor in this slowness appears to be the workload placed upon the IESG when documents are brought to them. Given that one role of the IESG has been to provide cross-area review, offloading some portion of that work may increase the speed of the process. Secondly, cross-area review done early in the process may be a good tool for identifying significant problems with a Working Group's efforts long before the documents reach the IESG. As such, the early cross-area review can improve the quality of the output from the Working Group by sifting the wheat from the chaff. "SIP Conferencing: Sub-conferences and Sidebars", Brian Rosen, 22-Jul-04, This document discusses the creation, management of operation of sub-conferences in a centralized conferencing architecture, also known as 'sidebars'. This work uses the SIP Conferencing Framework and builds on the descriptions of sub-conferences in that document. Examples of SIP and XCON protocols are given. "Proposals for a New IETF Standards Track", David Black, Brian Carpenter, 25-May-04, Discussions in the IETF's "problem" working group reached consensus that the current IETF 3-stage standards track, as implemented, is not working. This draft proposes various alternative multi-step standards tracks for debate in the "newtrk" working group. "RADIUS Attributes Extension", Farid Adrangi, 21-Jul-04, This document describes additional Remote Authentication Dial In User Service (RADIUS) [1] attributes for use of RADIUS AAA (Authentication, Authorization, Accounting) in both Wireless and wired networks. It contains an IPv4 address type control mechanism, mobile IPv4 home agent discovery mechanism, and a RADIUS capabilities discovery mechanism. "Source Routed MPLS LSP using Domain Wide Label", Albert Tian, 21-Jul-04, One advantage that MPLS provides is that it allows traffic to be directed through an explicit path that deviates from IP routing. Such ability is widely used in traffic-engineering and fast-reroute. Currently signaling protocols such as RSVP is needed to establish and maintain such an explicit Label Switched Path. When there are a large number of such signaled LSPs in the network, the aggregated signaling and maintenance overhead can be significant. In this paper, we propose a way to establish a source routed explicit path with zero signaling overhead. The scheme uses a stack of labels and requires domain wide LDP FEC to label bindings. "Security Threats for the NAT/Firewall NSLP", Ali Fessi, 19-Jul-04, Opening a firewall pinhole or creating a NAT binding is a very security sensitive issue. This memo identifies security threats and security requirements that need to be addressed for the NATFW NSLP. Generic security threats to the NSIS protocols have been already discussed in the NSIS Working Group. "AYIYA: Anything In Anything", Jeroen Massar, 8-Jul-04, This document defines a tunneling protocol that can be encapsulated in any other protocol. Using authentication tokens multiple tunnels can be created from behind the same NAT. The tokens allow one to identify the sender of the packet thus making it possible to automatically switch over the endpoint. This protocol is intended as an alternative to the proto-41 protocol in use for tunneling IPv6 over IPv4 packets over the internet. Due to the authentication this protocol is especially useful for dynamic non-24/7 endnodes which are located behind NATs and want to use for instance a IPv6 Tunnel Broker. The protocol can carry any payload and thus is not limited to only IPv6 over IPv4 but can also be used for IPv4 over IPv6 and many other combinations of protocols. "QoS-NSLP QSpec Template", Jerry Ash, 20-Jul-04, This draft describes a QSpec template for the QoS NSIS Signaling Layer Protocol (QoS NSLP) for signaling QoS reservations in the Internet. A QSpec is transported in QoS-NSLP messages and is opaque to QoS NSLP. It contains the QoS Signaling Model (QSM) Control Information and QoS Description parameters. Control Information is, for example, the scope of a particular QSpec. QoS Description parameters are primary input and output parameters of the Resource Management Function. They include descriptions of the QoS desired and the QoS reserved. QoS Description parameters can also be used for collecting information about resource availability along the path and for signaling a range of acceptable QoS. The QSpec template defines generic parameters that are common to many QSMs. Particularly they are derived from the IntServ and DiffServ QoS Models. They should be used by all QSMs if applicable and must be understood by all QNEs. By identifying the generic parameters we aim to ensure interoperability between different QSMs. "Video Message Message Context", Tony Hansen, 25-Jun-04, The Message-Context header defined in RFC 3458 [1] describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". A receiving user agent (UA) may use this information as a hint to optimally present the message. "The DISCOVER opcode", , 28-May-04, The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may generate replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document documents experimental extends the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed during the TBDS project (1999- 2000), funded under DARPA grant F30602-99-1-0523. This draft was originally submitted for consideration in 2q2000. "A Distributed Web Search Protocol -- Dowser/0.1", Carlos Bueno, 28-May-04, Dowser is an application-level, peer-to-peer protocol for creating a searchable index and cache of documents. It is intended for both small-scale intranets and Worldwide Web-scale indexes. This document describes the messages that members, or "nodes", of the network pass to each other to distribute workload, request & respond to queries, and maintain the index. "Design Considerations for a Wireless OSPF Interface", Phil Spagnolo, 1-Jun-04, This document presents some analysis and simulation results intended to assist in the design of a wireless interface for the OSPF protocol. "Ultra Lightweight Encapsulation (ULE) Extension Header", Gorry Fairhurst, 1-Jun-04, This document proposes an extension format for the Ultra-Lightweight Encapsulation (ULE) protocol. The proposed method allows ULE to carry both optional (with an explicit extension length) and mandatory (with an implicit extension length) header information to assist in network/Receiver processing of a SNDU. These functions modify the behaviour of ULE, and introduce header processing operations that will simplify the addition of new headers. This Internet Draft is presented as a separate document to allow ipdvb working group discussion of the design trade-offs involved. If accepted, the techniques will be incorporated within a future revision of ULE. "DNS zone suffix option for DHCPv6", Renxiang Yan, 1-Jun-04, The DNS Zone Suffix option provides a mechanism for automated assignment of DNS zone suffix using DHCPv6. This mechanism is intended to assign a DNS zone suffix from DHCPv6 server to a client. The client then uses this suffix to configure its domain name. "GSS-APIv2 Extension for Storing Delegated Credentials", , 1-Jun-04, The details of Generic Security Service (GSS) credential store management vary by platform and even by GSS mechanism. Credential store management is an interesting concept that requires exploration. This document defines a small extension to the GSS-API for GSS-API credential store management. While exploration of the credential store management problem is the goal of this document, implementation of these interfaces is not discounted nor discouraged. "Updates to RFC 2418 Regarding the Role of IETF Working Group Chairs", Margaret Wasserman, 2-Jun-04, This document is an update to RFC 2418 that strengthens the recommended separation between the Working Group Chair and Document Editor roles. It states that a single person should not serve in both roles for a single document, except temporarily in exceptional situations. "DHCP Option for Home Agent Discovery in MIPv6", Alper Yegin, 2-Jun-04, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address and home subnet. A new DHCP option is defined to carry the information from a DHCP server to the DHCP client running on the mobile node. "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Sina Mirtorabi, Abhay Roy, 2-Jun-04, This document describes an extensible mechanism to support multiple topologies (MT) in OSPFv3. These topologies will be defined within each address family and can be used to compute different paths for different classes of service. The extension described in this document can further facilitate any future extensions of OSPFv3. "IPv4 Prefix Options for DHCPv6", Myung-Ki Shin, 3-Jun-04, This document describes new options for Dynamic Host Configuration Protocol (DHCP) version 6 that provide a mechanism for the delegation of IPv4 prefixes. Through these options, a delegating router can delegate IPv4 prefixes to authorized requesting devices. "TCP Corruption Notification Options", Michael Welzl, 3-Jun-04, This memo specifies options that enable TCP to detect corruption in the presence of link layers which hand over known-corrupt data to upper layers. The receiver notifies the sender of an erroneous segment that would otherwise be lost and assumed to be a sign of congestion. The sender uses this ACK to drive its RTO calculation, retransmit the segment and react to congestion earlier if ECE=1. In addition, this feedback could be used to realize a more appropriate rate change in response to such lost segments. "Dialstring parameter for the sip URI", Brian Rosen, 3-Jun-04, RFC2806bis explicitly disclaims that tel uris may not represent a dial string. That leaves no way specify a dialstring in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dialstring as a SIP URI. "IPv6 multicast address assignment with DHCPv6", Jerome Durand, 3-Jun-04, This document provides a simple solution to solve IPv6 multicast address assignment problem using the DHCPv6 protocol. "Identified Internet Mail", Jim Fenton, Michael Thomas, 3-Jun-04, This document describes extensions to the format of electronic mail messages and a public-key infrastructure to permit verification of the source of messages by either mail transport agents (MTAs) or mail user agents (MUAs). This may be used to implement a policy which, for example, favors the delivery of identified messages over messages lacking signatures or having incorrect signatures. Mechanisms by which signing of messages and verification of signatures can be performed by a trusted MTA, in order to minimize impact on the user, are also presented. "Certificate-based Binding Update Protocol (CBU)", F Bao, 9-Jun-04, This document proposes a comprehensive security solution for mobile IPv6 networks including secure binding update, secure fast handover, user authentication and session key management for data security. In our proposal, one of the home agent's functions is to act as security proxy for its mobile nodes. The authentication is based on the home agent??s certificate and the secret session keys are generated by strong cryptosystems. Our proposal avoids many security obstacles in the Return Routability protocol and provides a simple, integrated and efficient security solution for mobile communication. "Repurposing the STD Designation", John Klensin, 7-Jun-04, Over the years, it has been repeatedly observed that the STD nnnn and BCP nnnn designation for IETF Standards has not worked well, either as a stable reference for external specifications or as a combined reference for multiple documents that are linked together into a single specification. This document proposes two changes that have been discussed on and off for some time, but never written up or considered as specific proposals. The first of these would assign a STD (or BCP) number to a specification when it enters the first level of the Standards Track (or is first designated as a BCP). The second would turn STDs and BCPs into actual documents that describe what they identify and their publication and change history. "The SEED Cipher Algorithm and Its Use With IPSec", Jaeil Lee, 7-Jun-04, This document describes the use of the SEED block cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). "Reclassification of RFC 1863 to Historic", Pekka Savola, 7-Jun-04, This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also Obsoletes RFC 1863. "Simple Forward Error Correction (FEC) Schemes", Michael Luby, 8-Jun-04, This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452 [4] and RFC 3695 [5]. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of objects using a simpler FEC Payload ID, and in particular they can be used to deliver objects without using any explicit source block structure. Thus, they allow simpler delivery with less packet header overhead. "Reliable Server Pooling Policies", Michael Tuexen, Thomas Dreibholz, 8-Jun-04, This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at name servers and pool users. "Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery", Greg Daley, 9-Jun-04, The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. "A RTP Payload for Redundant Non-Audio Data", Satish Mundra, 9-Jun-04, This document specifies an RTP payload format for encoding redundant non-audio data for use with RFC 2198 redundancy scheme. The primary motivation for the payload format described herein is accurate loss detection and sequencing, and to make the redundancy mechanism independent of clock rate being used for non-audio data. It is hoped that use of this payload format will simplify the implementation of RFC 2198 redundancy mechanism for non-audio data and may improve efficiency of redundancy mechanism if RTCP extended reports (XR) were available to RTP senders. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for XML Documents Directory", Miguel Garcia-Martin, 9-Jun-04, The general assumption of XCAP is that a client selects a document in a XCAP server in order to manipulate data. This requires the XCAP client to know the path of the XCAP-manipulatable XML document stored in the XCAP server. This specification allows an XCAP client to retrieve its directory of XCAP-manipulatable XML documents from an XCAP server. "The sdp-anat Session Initiation Protocol (SIP) Option-Tag", Gonzalo Camarillo, Jonathan Rosenberg, 9-Jun-04, This document defines the sdp-anat SIP option-tag. The presence of this option-tag in a Supported header field indicates support for the SDP grouping framework and for the ANAT (Alternative Network Address Types) semantics. "Structural object class 'untypedObject' for LDAP/X.500", Hallvard Furuseth, 9-Jun-04, This document defines an 'untypedObject' structural object class for the Lightweight Directory Access Protocol (LDAP) and X.500. This is useful for entries with no 'natural' choice of structural object class, e.g. if an entry must exist even though its contents are uninteresting. "BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network", Defeng Li, 14-Jul-04, This document describes some methods which may be used by Service Providers to provide Virtual Private Networks for some scenarios where the Service Provider's network or Customer's network is comprised of part of IPv4 network and part of IPv6 network.These situations can't be avoided during the process of IPv4 transition to IPv6, e.g. IPv6 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4-IPv6 hybrid backbone network for IPv4-IPv6 hybrid VPN sites.This proposal continue to use the concepts described in the Internet draft 'BGP/MPLS VPN'[2547bis],such as RD,VRF,Route Target and some mechanisms. In BGP/MPLS VPN, MPLS is used to forward packets over the backbone, and "Multiprotocol BGP" is used for distributing VPN routes over the service provider backbone. "Mobile multi-gateway support for IPv6 mobile ad hoc networks", Kyungran Kang, 14-Jun-04, MANET (Mobile Ad-hoc NETwork) allows users to form a private wireless network, without existing centralized administrator that support multi-hop communication and low network establishment cost. Recently some interesting work has been published to allow manet node access to the Internet via internet gateway which is placed on the border of manet and the Internet. The Internet gateway has an important role to support global connectivity. This document introduces the management of internet gateway, routing policy and load balancing for the scenario where multiple mobile gateways exist for an ad hoc network. "MTU and Fragmentation Issues with In-the-Network Tunneling", Pekka Savola, 19-Jul-04, Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. "IP Traffic Engineering With Route Switched Paths (RSPs)", Naiming Shen, 21-Jul-04, This document describes a mechanism to establish traffic engineering IP tunnels. RSVP is used as a signaling protocol just as in MPLS TE technology but no MPLS forwarding capability is assumed on the switched path. IP routing is used to switch IP traffic trunks. A simple RSVP extension is needed to setup the IP route switched paths (RSPs). "Using IPsec to Secure IPv6-over-IPv4 Tunnels", Hannes Tschofenig, 22-Jul-04, This document gives guidance on securing IPv6-in-IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the revised IPsec framework. IKEv2 is extensively used as an authentication and key exchange protocol to cover address configuration procedures, and the usage of the Extensible Authentication Procotol and NAT traversal capabilities is also described. "Simple XOR, Reed-Solomon, and Parity Check Matrix-based FEC Schemes", Jani Peltotalo, 15-Jun-04, This document introduces several Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452 [5] and RFC 3695 [7]. More specifically it describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 2, reserved to simple XOR FEC scheme, and the Under-Specified FEC scheme corresponding to FEC Encoding ID 132, reserved to parity check matrix-based FEC scheme. This document also specifies the FEC Instance IDs 0 and 1, scoped by the FEC Encoding ID 129 and reserved to Reed-Solomon FEC codes. It also specifies the FEC Instance ID 0, scoped by the FEC Encoding ID 132 and reserved to LDGM-Staircase codes. Finally this document specifies two algorithms that MAY be used with all block FEC codes. "application/saml+xml Media Type Registration", Jeff Hodges, 21-Jun-04, This document describes a MIME media type -- application/saml+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions, or other SAML-defined objects. "Graceful Shutdown in MPLS Traffic Engineering Networks", Zafar Ali, 15-Jun-04, Graceful shutdown is a method for explicitly notifying a set of LSRs that either a Link or an entire node will remove itself from the network or the protocol is going to be disabled for a link or a node. Graceful shut down mechanisms are tailored towards addressing the planned outage in the network. This document provides protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", Ghyslain Pelletier, 15-Jun-04, RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. "Arrangement of Hop-by-Hop options", Suresh Krishnan, 16-Jun-04, The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes an arrangement of options to minimize such attacks. "The Codecs Parameter for "Bucket" Media Types", Randall Gellens, 16-Jun-04, Several MIME type/subtype combinations exist which can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered. "Extended MGCP Line Packages", Tania Sassenberg, 19-Jul-04, This document provides an extended set of Media Gateway Control Protocol (MGCP) packages. The Extended Analog Line, Business Set, Carrier, Intrusion, Display, Test, and Metering packages are newly defined in this document. "Session Key Transport in RADIUS", Glen Zorn, 8-Jul-04, This document describes an extension to the RADIUS protocol designed to support requests for, and delivery of, session key material between RADIUS clients and servers. The messages described in this document may be used for a wide variety of keying applications. "RADIUS Attributes for Key Delivery", Glen Zorn, 8-Jul-04, This document defines a pair of RADIUS Attributes designed to allow the secure transmission of encryption keys. "Recall Packet Approach to Data Source Authentication for Multicast Security", Atul Sharma, 17-Jun-04, Data source authentication is an important requirement to provide multicast security. Data source authentication assures that the member claiming to send the data is the actual sender. An imposter member should not be able to claim to be the sender of the data. This document proposes a scheme by which data source authentication can be acheived. The idea is to instead of digitally signing the data packets, a digitally signed recall packet on detection of an imposter transmission. The data packets are sent using symmetric MAC authentication. "Preempting IPv6 Neighbour Discovery", Greg Daley, 17-Jun-04, In certain circumstances, a host knows that it will be receiving data at an IP address for which its neighbours have no neighbour cache entry. Where the expected packets are required to be received promptly, or there is significant chance of packet loss in a neighbour discovery exchange from the peer to the host, it may be advantageous to install a neighbour cache entry on the peer before it is required. This document proposes a mechanism whereby hosts can choose to preemptively populate their peer's neighbour cache to forestall later neighbour discovery exchanges. "Email Configuration Options for DHCPv6", Cristian Cadar, 17-Jun-04, This document describes three options for Email related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option for Internet Message Access Protocol (IMAP) and Post Office Protocol (POP3) Server addresses for message retrieval from mailboxes on these servers and the option for the Simple Mail Transfer Protocol (SMTP) Server addresses to route SMTP messages throughout the Internet to a mail server. "IMAP Configuration Option for DHCP", Cristian Cadar, 17-Jun-04, This document describes a new option for Email related configuration information in Dynamic Host Configuration Protocol (DHCP), the option for Internet Message Access Protocol (IMAP) Server addresses for message retrieval from mailboxes on these servers. "Bootstrapping a Symmetric IPv6 Handover Key from SEND", James Kempf, 18-Jun-04, Multiple IPv6 handover optimization protocols (for example, Fast Mobile IPv6 and Context Transfer Protocol) require an Access Router to verify that signaling received to perform an IP handover operation originated from a Mobile Node having authorization to claim a particular address on the Access Router's wireless subnet. In this document, a method for securing such signaling is defined. The method utilizes a secret key sent from the Access Router to the Mobile Node prior to handover, encrypted with an RSA public key that the Mobile Node used to generate its Cryptographically Generated Address. The ability of the Mobile Node to decrypt the secret key verifies its possession of the private key corresponding to the public key used to generate the address. This allows the Mobile Node to use the secret key to sign and authorize signaling causing changes affecting traffic to and from that address. The use of symmetric cryptography avoids the time consuming public key operation associated with using the RSA key directly during performance-sensitive IP subnet handover. "Use of TCP timestamp option to defend against blind spoofing attack", Kacheong Poon, 18-Jun-04, The US-CERT alert (TA04-111A) shows that the well-known weakness in TCP's segment acceptance test is easier to exploit than previously thought. While there are already mechanisms, such as RFC 2385 for BGP and IPSEC, to defend against this kind of attack, we propose a light weight method making use of TCP timetstamp option as an alternative. "The Proxy Field in PIM Join Messages", IJsbrand Wijnands, 18-Jun-04, This document describes an extension to PIM which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. "Base Specification for Multicast in BGP/MPLS VPNs", Rahul Aggarwal, 22-Jun-04, This document describes the minimal set of procedures required to build multi-vendor inter-operable implementations of multicast for BGP/MPLS VPNs. It is based on prior specifications of multicast for BGP/MPLS VPN specifications that have been implemented and deployed. The procedures described herein require PIM-SM as the multicast routing protocol in the SP network. "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", Russell Housley, 19-Jul-04, This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect more than one content. If desired, attributes can be associated with the content. "Dry-Martini: Supporting PWE3 Over Sub-IP Networks", Ping Pan, 23-Jun-04, This memo proposes a method for transporting layer-2 frames over existing transport networks by establishing "pseudo-wires" between edge nodes. The key difference with the existing PWE3 design is that, in our proposal, pseudo-wires can be established directly on top of all types of "tunnels", including SONET cross-connects, optical wavelength and ATM circuits without introducing MPLS LSR functionality on all network intermediate nodes. The general mechanism for establishing and managing pseudo-wires is the same as what has been defined in draft-martini. At data forwarding level, we adapt the same encapsulation methods that have been defined in IETF PWE3 WG. This memo articulates some of the requirements for adapting such method. "Detecting Network Attachment in IPv6 - Best Current Practices", Sathya Narayanan, 23-Jun-04, Hosts experiencing rapid link-layer changes may require further configuration change detection procedures than more traditional fixed hosts. Detecting Network Attachment is a set of strategies for determining configuration validity in wireless or rapidly changing environments. This document details best current practice for Detecting Network Attachment in IPv6 hosts using Neighbor Discovery procedures. "Statistics in SIP", Susan Choudhary, 23-Jun-04, SIP has emerged as a popular protocol for session setup and management. But feedback is an important attribute of any session. The objective of this document is to provide a generic framework which could be used by user agents to provide feedback about the session when it terminates. "Context Transfer for PANA", Julien Bournelle, 23-Jun-04, The PANA protocol offers a way to authenticate clients in IP based access networks. It carries EAP over UDP which permits ISPs to use multiple authentication methods. However, in roaming environments IP clients might change of gateways and new EAP authentication from scratch may occur. This can considerably degrade performance. "Extensions to OSPF for Advertising Optional Route Attributes", Acee Lindem, 24-Jun-04, There are applications which require additional attributes to be advertised with an OSPF route. The existing OSPF LSA formats do not allow for backward compatible extension to advertise these attributes. This draft proposes an extension to OSPF for advertising additional attributes which will be associated with an OSPF route. "Path Computation Element Problem Statement", Jerry Ash, 24-Jun-04, This document provides a problem statement for the proposed Path Computation Element (PCE). The PCE is an approach to MPLS traffic engineering path computation that is particularly applicable in inter-domain environments. In this context, a domain may be an IGP area, an Autonomous System, or some other division of computational responsibility. An overview of solution alternatives and proposed PCE work group charter is also provided. "Message Submission", Randall Gellens, John Klensin, 25-Jun-04, Public comments should be sent to the IETF Submit mailing list, . To subscribe, send a message containing SUBSCRIBE to . This list will remain active after publication. Private comments may be sent to the authors. "Loop-Free Alternates for IP/LDP Local Protection", Alia Atlas, 28-Jun-04, This document defines an architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failure until the router has converged. When computing the primary next-hop for a prefix, a router S also determines an alternate next-hop which can be used if the primary next-hop fails. The alternate next-hop is said to be a loop-free alternate, which goes to a neighbor whose shortest path to the prefix does not go back through the router S. "DHCPv6 Options for Broadcast and Multicast Control Servers", Kuntal Chowdhury, 28-Jun-04, This document defines new options for Broadcast and Multicast Service controller discovery in an IP network. Broadcast and Multicast service over 3G wireless networks are being developed at the time of writing this document. Users of this service interact with a controller in the network to derive informations that are required to receive broadcast service. Dynamic Host Configuration Protocol can be used to configure the controller IPv6 addresses in the user's devices. This document defines the related options and option codes. "Internet Protocol (IP) Supplement for a Real Time Service", Dimitar Aleksandrov, 14-Jul-04, The Real Time Network Service (RTNS) is a process of data transfer (with real time characteristics) between two end systems. It is part of the OSI model of the Network layer. It is not a separate protocol, but rather an additional service, of which applications, exchanging data in real time, can take advantage. In the current document this service is defined as an option of the Internet Protocol. "Advertisement of the Group Best Paths in BGP", Enke Chen, 8-Jul-04, In this document we first identify and qualify the Group Best Paths for an address prefix as in general the necessary and sufficient subset of paths that need to be advertised by a BGP route reflector or a BGP confederation ASBR in order to eliminate the MED-type route oscillations and to achieve consistent routing in a network. We then propose a mechanism for BGP that would allow a route reflector or a confederation ASBR to advertise the Group Best Paths. The proposed mechanism is designed such that the vast majority of the BGP speakers in a network need only minor software changes in order to deploy the mechanism. "TCP's Reaction to Soft Errors", Fernando Gont, 28-Jun-04, This document discusses problems that may arise due to TCP's reaction to soft errors. In particular, it discusses the problem of long delays in connection establishment attempts that may arise when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The purpose of this document is to discuss this potential problem, and analyze the ways in which it could be worked around. It does not to try to specify whether IPv6 should be enabled by default or not. "Forwarding and Control Element Separation Protocol Layer", Alex Audu, 29-Jun-04, This document defines the Forces-PL protocol that is designed for communicating between Forwarding and Control Elements that make up a ForCEs-compliant network element. This protocol addresses all the requirements described in the Forces [FORCES-REQ] requirements document. This document also specifies architectural attributes necessary in an implementation of Forces-PL to ensure correct and secure protocol operation. "teste", , 29-Jun-04, test "Host Identity Indirection Infrastructure (Hi3)", Pekka Nikander, 29-Jun-04, The Secure Internet Indirection Infrastructure (Secure-i3) is a proposal for a flexible and secure overlay network that, if universally deployed, would effectively block a number of denial-of-service problems in the Internet. The Host Identity Protocol (HIP), on the other hand, is a proposal for deploying opportunistic, IPsec based end-to-end security, allowing any hosts to communicate in a secure way through the Internet. In this paper, we explore various possibilities for combining ideas from Secure-i3 and HIP, thereby producing an architecture that is more efficient and secure than Secure-i3 and more flexible and denial-of-service resistant than HIP. "ForCES Protocol Specification", Avri Doria, 14-Jul-04, This is the first draft of the ForCES protocol specification produced by the protocol design team. It is presented to the WG for consideration as a WG work item. "Analysis of Misconnection Scenarios in GMPLS Networks", Kohei Shiomoto, 29-Jun-04, The purpose of this memo is to describe and analyze the occurrence of misconnections in GMPLS networks. We present a problem statement, and describe some scenarios under which misconnections may happen. We then outline some common causes of misconnections and discuss some solutions to address them. Our goal is to facilitate further discussions of this issue and the associated solutions within the CCAMP Working Group. "Graceful Shutdown of BGP Sessions", Nicolas Dubois, 30-Jun-04, To ease the maintenance of BGP-4 sessions and limit the amount of traffic that is lost during planned maintenance on routers, a specific mechanism is proposed in order to gracefully shutdown a router or a session. It's proposed that a router first withdraw its route to its peer to initiate their convergence. After a timer the router can proceed with the closing of the BGP sessions and consequently remove its peers'routes from it's RIB (Routing Information Base). "IPSec Replay Attack Protection in Multisender Environment", Mohanlal Jangir, 30-Jun-04, The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, RFC2406] define certain mechanisms for protecting IP traffic. One of the mechanisms defined is replay attack protection. But this mechanism is not addressed in multisender environment where multiple senders are sending packets for same destination SA (This includes sharing of SA as well as multicast). This document reviews the issues in multisender environment and addresses solution for this by identifying the sending SA and having replay attack protection against each sending SA. The documents also summarizes the changes needed in AH, ESP, Key management protocols, which would enable IPSec to protect against replay attack protection in multisender environment for same destination SA. "Host/Edge Multihoming Problem Statement", Chan Ng, 30-Jun-04, This document analyzes multihoming from the perspective of the Internet edge: i.e. hosts and other edge networks. We built on top of the previous work that describes goals and benefits of multihoming, and identify problems for the provisioning of multihoming at the edge level. In this memo, we first look at the problem of multihoming for a generic IPv6 node, followed by narrowing the analysis down to mobile hosts and networks. "The SDP (Session Description Protocol) Label Attribute", Orit Levin, Gonzalo Camarillo, 1-Jul-04, This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to an application layer media stream identifier in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or media streams. The application receiving the SDP document can then associate the particular media stream with its application semantics or role. "DHCPv4 Options for Broadcast and Multicast Control Servers", Kuntal Chowdhury, 2-Jul-04, This document defines new options for Broadcast and Multicast Service controller discovery in an IP network. Broadcast service is being developed for 3G wireless networks. Users of the service interact with a controller in the network to derive informations that are required to receive broadcast service. Dynamic Host Configuration Protocol can be used to configure the controller IPv4 addresses or fully qualified domain names in the user's devices. This document defines the related options and option codes. "Alternate transport bindings for Real-time Application Quality of Service Monitoring (RAQMON) PDU", Anwar Siddiqui, 2-Jul-04, With the growth of the Internet and advancements in embedded technologies, smart IP devices such as IP phones, Cell Phones, Video desktop stations, Pagers, Instant Messaging Devices, PDAs, Networked Appliances, Wireless Hand-held devices and various other computing devices have become an integral part of our day-to-day operations. "The Group Security Association Key Management Protocol Application to the IP Security Architecture", George Gross, 2-Jul-04, The Group Security Association Key Management Protocol (GSAKMP)is a distributed secure multicast framework and key management protocol. This specification defines the GSAKMP profile for the IP security architecture version 2 and extends the base GSAKMP protocol with the Security Association Management (SAM) message. The GSAKMP IPsec policy token explicitly authorizes which group members may exercise the speaker privilege. When an authorized group speaker endpoint multicasts a SAM message to a GSAKMP group, the SAM message configures that group's Security Policy Databases and Security Association Databases in compliance to a template within the GSAKMP IPsec policy token. In addition, this specification profiles the three supporting components: RFC2401-bis compliant IP security subsystem, Negative-acknowledgement Oriented Reliable Multicast (NORM) protocol handler, and the X.509 Public Key Infrastructure. "Multiple Dialog Usages in the Session Initiation Protocol", Robert Sparks, 6-Jul-04, Several methods in the Session Initiation Protocol can create an association between endpoints known as a dialog. Some of these methods can also create a new association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. "Migration Issues for NFSv4", David Noveck, 6-Jul-04, RFC3530 described an fs_locations attribute which can be used to allow an fs to migrate between servers without disrupting client access and to refer a client to another server providing access to a specified file system. Initial implementation work for this feature has exposed a number of areas where RFC3530's handling of the issues leaves something to be desired. This document makes a number of suggestions to remedy these issues when the NFSv4 spec next undergoes a significant revision, most likely in connection with implementing a new minor revision, such as NFSv4.1. "IP Fast Reroute using Multiple Path Algorithm (MPA)", Venkata Naidu, 6-Jul-04, This document describes a practical mechanism to implement IP fast reroute using multiple viable loop-free next hops, which are not necessarily shortest path to a destination. Upon a link failure, all the destinations reachable via the primary nexthop will be forwarded to pre-computed alternative loop free nexthops, if any, without much delay. The mechanism does not impose any new protocol message/capability exchange. The mechanism does not use any tunneling techniques. It is shown that simple changes to existing IGP shortest path computation and routing table structures are sufficient to achieve the desired functionality. More over, routers which implement the proposed mechanism can co-exist and can be fully backward compatible with existing unmodified routers. "Implementation of IGMP and MLD Proxy-Reporting Switches", Girish Gupta, 6-Jul-04, This document suggests a way for implementing a IGMP/MLD proxy- reporting switch in which reports received from downstream hosts and queries received from upstream routers are used to build the Subscription Aggregation table. Subscription Aggregation table can be used for forwarding multicast data traffic, sending state change and current state reports to upstream router ports. "IPv6 Traffic Engineering in IS-IS", Jon Harrison, 6-Jul-04, This draft specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with 2 new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. "IP Fast Reroute using Stitched Shortest Paths Algorithm (SSPA)", Venkata Naidu, 6-Jul-04, This document describes a practical mechanism to implement IP fast reroute using dynamic SPF to compute local and remote loop free nexthops efficiently. Upon link failure, all the destinations reachable via the primary nexthop will be forwarded to alternative loop free nexthop, if any. If the alternative nexthop is remote, packet will be forwarded using any connectionless (for example, IP-in-IP) or connection-oriented (for example, MPLS) tunnels. This mechanism doesn't impose any new protocol message/capability exchange. It is shown that simple changes to existing IGP shortest path computation and routing table structures are sufficient to achieve the desired functionality. More over, routers which implement the proposed mechanism can co-exist and can be fully backward compatible with existing unmodified routers. "U-turn Alternates for IP/LDP Local Protection", Alia Atlas, 8-Jul-04, This document extends the architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failures until the router has converged. When computing the primary next-hop for a prefix, a router S also determines an alternate next-hop which can be used if the primary next-hop fails. The alternate can be either a loop-free alternate, as described elsewhere, or a U-turn alternate, which goes to a neighbor whose primary next-hop to the prefix is the router S, but that neighbor has a loop-free node-protecting alternate, which thus does not go through router S to reach the destination prefix. "Protection for inter-AS MPLS tunnels", Stefaan De Cnodder, Cristel Pelsser, 8-Jul-04, This document describes a solution for link protection, node protection, Shared Risk Link Group (SRLG) protection and fast recovery of inter-AS packet based LSPs. These problems are highlighted in [ASREQ]. The proposed solution is based on RSVP-TE [RFC3209] as recommended by [ASREQ]. Only the protection of links between 2 ASs, the protection of their SRLGs and of the nodes at the border of an AS are in the scope of this document. "A Combined User/Carrier ENUM", Penn Pfautz, 8-Jul-04, This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. "Extending the Space Available for TCP Options", Wesley Eddy, 8-Jul-04, This document describes a method for increasing the space available for TCP options. Two new negotiable TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options. "TLS Express", Mohamad Badra, 9-Jul-04, This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. "Multiple TEP Extension to DSTM", Jaehwoon Lee, 9-Jul-04, Dual stack transition mechanism (DSTM) provides connectivity between dual stack hosts (i.e., DSTM client) within an IPv6-only network and IPv4 nodes within an IPv4 internet or intranet. DSTM defined in [DSTM] considers only one TEP, that is, packets from an IPv4 node to a DSTM client need to be routed through the same DSTM border router as that used in transmitting packets from the DSTM client to the IPv4 node. In this draft, we propose a DSTM architecture of using multiple TEPs with only one IPv4 address pool for a DSTM domain. "Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies", Richard Rabbat, 9-Jul-04, Optical transport networks controlled by a GMPLS-based control plane enable today’s network operators to offer valuable new services. With the completion of a number of GMPLS signaling and routing standards and the availability of products implementing them, providers are now looking at ways to enable additional features such as shared-mesh restoration. This document presents the results of a serious attempt to systematically gather and collate carrier inputs on strategies for shared-mesh restoration and the associated issues. The survey results are presented in aggregate form to provide an overview of carrier thinking, while retaining specific carrier response confidentiality. The goal is to highlight areas of carrier concerns, and identify specific work items to focus on and facilitate further discussion. "PWE3 Control Word", Stewart Bryant, 9-Jul-04, This document describes the preferred designs of the PWE3 Control Word, and the PWE3 Payload Type Identifier. The design of these fields is chosen so that an MPLS LSR performing deep packet inspection will not confuse a PWE3 payload with an IP payload. "IPv6 Label Switching Architecture (6LSA)", Sham Chakravorty, 9-Jul-04, This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet switching technique that uses the IPv6 packet header Flow Label, header extensions, and unique routing algorithms, the latter two when needed, to establish IPv6-based label switched paths. The label switched paths, called 6LSPs, provide application and user specified routes for speedier transport of packets and as means for quality of service (QoS) solutions as in IPv4-based MPLS or ATM. Since MPLS-like protocol labeling will be redundant for IPv6 and since there are no widely-known QoS deployments of IPv6 over any of the layer 2 switching mechanisms such as ATM, the 6LSA framework fills the technology void without the link overhead from extraneous layer 2 labeling and signaling of MPLS, or packet fragmentation and added signaling as in ATM. Through the use of fast switching of 20-bit labels instead of 128-bit IPv6 address look-ups, the architecture presented here also provides processing savings through significantly reduced address fetches for the low-powered, handheld devices. "Matching Text Strings in PKIX Certificates", Paul Hoffman, Stephen Hanna, 9-Jul-04, Strings of text appear in many fields in PKIX certificates. Some applications need to compare the values in these fields to strings from other certificates, or to values obtained in other manners. For many string encodings, this can be done in an octet-by-octet fashion. Other encodings, however, require preparation before the strings can be compared. This document describes that preparation and when it needs to be applied. "Framework for Operational Security Requirements for IP Network Infrastructure", George Jones, 9-Jul-04, This document outlines work to be done and documents to be produced by the proposed Operational Security Requirements (OPSEC) Working Group. The goal of the working group is to codify knowledge about feature sets that are required to securely deploy and operate managed network elements providing transit services at OSI layers 2 and 3, i.e. switches and routers. The intent is to provide clear, concise documentation of requirements necessary for operating networks securely, to assist network operators in communicating their requirements to vendors, and to provide vendors with input that is useful for building more secure devices. The working group will produce requirements appropriate for large Internet Service Provider (ISP) and Enterprise Networks. This work is intended to refine RFCxxxx. "Requirements for Efficient and Automated Configuration Management", Mohammed Boucadair, 9-Jul-04, Given the ever-increasing importance of configuration tasks for the provisioning of a wide range of IP resources, networks, and services in today's Internet, this draft aims at listing the basic requirements that should drive the specification of a protocol to convey configuration information towards network devices. This memo doesn't aim at listing candidate protocols to convey such information, nor at choosing one of these. This draft basically describes a whole set of issues a service provider has to deal with, hence a list of requirements to better address such issues. "MP-BGP implementation Report", Susan Hares, 12-Jul-04, This document provides a survey of the BGP implementations supporting the multi-protocol extensions as specified in ietf-idr-rfc2858bis-06.txt implementations. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. "Avoiding Equal Cost Multipath Treatment in MPLS Networks", George Swallow, 12-Jul-04, This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks and makes best practice recommendations for anyone defining an application to run over an MPLS network and wishes to avoid such treatment. "Fragmentation Considered Very Harmful", Matt Mathis, 12-Jul-04, IPv4 fragmentation is not sufficiently robust for general use in today's Internet. The 16-bit IP identification field is not large enough to prevent frequent missassociated IP fragments and the TCP and UDP checksums are insufficient to prevent the resulting corrupted data from being delivered to higher protocol layers. In this note we describe some easily reproduced experiments demonstrating the problem and estimate the scale the data corruption in the presence of ever growing data rates. "RSVP Extension for Bandwidth Reduction of an Aggregate", James Polk, 12-Jul-04, This document proposes an extension to the Resource Reservation Protocol (RSVP) that allows an aggregated reservation to be partially preempted. Currently, when a higher priority reservation request arrives and sufficient bandwidth is unavailable to meet that request, a lower priority aggregated reservation may be preempted in whole, whether or not the entire bandwidth is required. This document describes a method where the lower priority aggregated reservation is preempted only to the extent to which its bandwidth is required for the higher priority request. This allows the aggregator to fail only a portion of the individual sessions that is aggregated and allow the rest of the sessions to continue unaffected. "Evaluating Scenarios for Session-specific Policies", Volker Hilt, 12-Jul-04, This draft describes detailed call flows for different use cases of session-specific policies. It compares the two approaches that are currently being discussed for session-specific policies, namely the piggyback model and the separate channel model. "Upper Layer-driven Link Layer Action", Youn-Hee Han, 12-Jul-04, This document describes scenarios where upper layer-driven link layer actions are necessary. A set of primitives is proposed for these interactions between the upper layers and the link layer. "A Session Initiation Protocol (SIP) Event Package for Device Information", Mahfuzur Rahman, 12-Jul-04, This document describes a Session Initiation Protocol (SIP) event package to carry device information including device status and device profile. Device status refers to a set of dynamic attributes that describe device's operating state, availability, and location information etc. Device profile on the other hand refers to a limited set of static attributes including device type, name, format type of status information, and model etc. of a particular device. "Defending TCP Against Spoofing Attacks", Joseph Touch, 12-Jul-04, Recent attacks on core Internet infrastructure indicate an increased vulnerability of TCP connections to spurious resets (RSTs). TCP has always been susceptible to such RST spoof attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. "Discussion on Service Providers' Policies with the Session Initiation Protocol (SIP)", Kumiko Ono, 12-Jul-04, Some service providers who operate SIP proxy servers and registrars need to be able to express various types of policies to their customers, such as media policies and security policies. Discussion needs to take place about the types of policies and how they will have an impact on SIP User Agents (UA)s. This document presents an overview of the types of policies that might be available, and how the operations of policies might be executed to aid in advancing the current discussions on session policies. "Resource Management In Diffserv: An NSIS QoS Signaling Model for Diffserv Networks", Attila Bader, 13-Jul-04, Resource Management in Diffserv (RMD) is a technique for adding admission control to Differentiated Services (Diffserv) networks. RMD complements the Diffserv architecture by pushing complex classification, conditioning and admission control functions to the edges of a Diffserv domain and simplifying the operation of internal nodes. It allows feedback to systems outside of the Diffserv domain on the availability of resources for individual flows within the domain while aggregating end-to-end resource reservations at the edge of the domain to reduce the burden on internal nodes. "Trust Models and Security in Multicast Listener Discovery", Greg Daley, Gopi Kurup, 12-Jul-04, The Multicast Listener Discovery (MLD) is used by IPv6 routers to discover the presence of multicast listeners (i.e. nodes that wish to receive multicast packets) on their directly attached links, and to discover which multicast addresses are of interest to those neighbouring nodes. The existing protocol specification (MLDv2) discusses the effects of on-link forgery of MLD packets but provides no protection from on-link attacks. By taking advantage of or abusing Multicast Listener Discovery, bogus devices may cause incorrect state and disruption to multicast or unicast packet delivery. This memo considers the trust models for the MLD protocols, and their interaction as well as their interaction with link-layer and multicast proxy devices. It provides a security and threat analysis for each model. "IANA Considerations for OSPF", Kireeti Kompella, 12-Jul-04, This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. "NSLP for Accounting Configuration Signaling", Falko Dressler, 12-Jul-04, Monitoring, metering and accounting of packets are increasingly important functionality that needs to be provided in the Internet. This document proposes the definition of a new NSIS NSLP which allows the dynamic configuration of accounting entities on the data path. A problem statement, scenarios for a QoS monitoring and a charging application, and requirements presented. Finally, the usage of NSIS for this purpose is motivated. "An In-Band Rollover Algorithm and a Out-Of-Band Priming Method for DNS Trust Anchors", Johan Ihren, 12-Jul-04, The DNS Security Extensions (DNSSEC) works by validating so called chains of authority. The start of these chains of authority are usually public keys that are anchored in the DNS clients, the so called trust anchors. "OCSP Extensions to IKEv2", Michael Myers, Hannes Tschofenig, 12-Jul-04, While IKEv2 supports public key based authentication (PKI), the corresponding use of in-band CRLs is problematic due to unbounded CRL size. The size of an OCSP response is however well-bounded and small. This document defines two extensions to IKEv2 which enable the use of OCSP for in-band signaling of certificate revocation status. Two new content encodings are defined for use in the CERTREQ and CERT payloads: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash CERTREQ payload triggers transmission of an OCSP Response CERT payload. "New IPv6CP Configuration Option for Mobile-IPv6", Youngjun Park, 12-Jul-04, This memo proposes an alternative to IPv6CP interface identifier negotiation in RFC 2472. Shorter PPP setup time is preferable to Mobile-IPv6 in order to prevent from the packet loss of ongoing data session. New IPv6CP Configuration Option and interface identifier negotiation process proposed here are designed to minimize latency in IPv6 address configuration when Mobile-IPv6 mobile node moves to new PDSN. "Securing Proxy Neighbour Discovery Problem Statement", Greg Daley, 12-Jul-04, Proxy Neighbour Discovery is used to provide an address presence on a link from hosts which are absent. It allows a host to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Proxy Neighbour Discovery is used in Mobile IPv6 and related protocols to provide reachability from hosts on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. "Consideration M and O Flags of IPv6 Router Advertisement", Soohong Park, 12-Jul-04, This document clarifies the processing and behavior of the IPv6 Router Advertisement M and O flags and proposes a solution for invoking the DHCPv6 based DHCPv6 administrator policy. "Service Mediation between Layer-2 and IP/MPLS Networks", Hamid Ould-Brahim, 12-Jul-04, Consider the scenario where the service provider establishes an end-to-end connection between edge devices that are attached to native layer-2 network and MPLS edge devices that are attached to MPLS core network. The end-to-end layer-2 connection is built from two segments: one segment is in its native layer-2 form established using native layer-2 signaling protocols and the other segment is a pseudowire established using L2VPN/PWE3 signaling protocols. We call such scenario "Service Mediation" and the end-to-end layer-2 connection a "mediated" service. This draft describes a flexible service mediation architecture that supports a number of capabilities such as address independence, address mobility, service and mediation gateway resiliency, support for multiple layer-2 addressing plans (E.164, X.121, NSAP addressing, etc), ability to not only initiate the mediated connection from the layer-2 network but as well from the MPLS network if desired. We highlight key components such as signaling, auto-discovery, endpoint identification, and resiliency. "IRIS - A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service", Andrew Newton, 12-Jul-04, This document describes a lightweight domain availability service using the IRIS framework and the data model of the IRIS Domain Registry service. "DNA solution framework", JinHyeock Choi, Erik Nordmark, 12-Jul-04, This draft captures the authors' personal opinions and is intended to serve as input to the discussion for the solution in the DNA WG. It presents a few assumptions for DNA solution. The draft proposes the solution to be based on 1) Link Identifier, 2) RA optimized for DNA and 3) Quick delivery of an RA and sketches what rough shape DNA solution will take. It also enumerate a few tasks to be worked on and issues to be resolved for efficient DNA solution. "The Session Initiation Protocol (SIP) and Spam", Jonathan Rosenberg, Cullen Jennings, 12-Jul-04, Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user to user communications. The Session Initiation Protocol (SIP) defines a system for user to user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. Discussions on this draft should be directed at sipping@ietf.org. "Token based Duplicate Network Detection for split mobile network (Token based DND)", Masayuki Kumazawa, 12-Jul-04, When multiple Mobile Routers share the same prefix, a Home Agent must be able to verify whether the mobile routers are in the same Mobile Network or not. Otherwise, the Home Agent may not be able to forward a data packet to the correct recipient since it may not be connected to the mobile router the home agent chooses to forward the packet. This document describes a Token based Duplicate Network Detection mechanism that enables a home agent to detect whether the mobile rotuers claiming the same prefix are in the same mobile network. "State Machines for Protocol for Carrying Authentication for Network Access (PANA)", Yoshihiro Ohba, 12-Jul-04, This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface to EAP state machines and can be implemented with supporting various features including separate NAP and ISP authentications, ISP selection and mobility optimization. The state machines and associated model are informative only. Implementations may achieve the same results using different methods. "DNA with unmodified routers: Prefix list based approach", JinHyeock Choi, 12-Jul-04, Upon establishing a new link-layer connection, a host determines whether a link change has occurred to examine the validity of its IP configuration. This draft presents a way to robustly check for link change without assuming changes to the routers. Each link can be uniquely identified by the set of prefixes assigned to it. We propose that, at each attached link, the host generates the complete prefix list, that is, the prefix list contains all the prefixes on the link, and when it receives a hint that indicates a possible link change, it detects the identity of the link by consulting the existing prefix list. This memo describes how to generate the complete prefix list and to robustly check for link change even in the presence of packet losses. "Group Cooperative Route Filtering Capability for BGP-4", Susan Hares, 12-Jul-04, Currently BGP-4 is capable of carrying multiple (Outbound Route Filters) ORFs entries sharing the AFI SAFI. Each ORF provides a filter that a route must pass through to be transmitted in the Route Refresh message. Efficient processing of filters for ORF may require ordering of ORFs filters in certain sequence. This group ORF provides an ORF type that specifies that ordering. "Mobility Protocol Options for IKEv2 (MOPO-IKE)", Pasi Eronen, 12-Jul-04, This document describes a mobility and multihoming extension to the IKEv2 protocol. The main purpose of this extension is to update the (outer) addresses associated with IKE and IPsec Security Associations. The extension also includes features that assist in selecting which addresses to use, and verify return routability during and after updates. It is also able to work together with NAT Traversal in some scenarios. "Dynamic Inter Home Agent Protocol", Benjamin Koh, Chan Ng, Jun Hirano, 12-Jul-04, This draft describes a proposed Dynamic Inter Home Agent solution to provide redundancy and load balancing of Home Agents. The proposed solution recommends additional communication between home agents that may be located far apart in terms of network topology but still belonging to or are trusted by the same administrative domains (service providers). While the mobile node is roaming away from its home network, intervening home agents in the path of the bidirectional tunnel between the mobile node and its registered home agent may detect its presence. The intervening home agents that are affiliated to the current home agent of the mobile node then proceed to update it of their availability to serve as home agent for the mobile node. "Carrying ATM reachability information in BGP", Chaitanya Kodeboyina, 12-Jul-04, This document defines multi-protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Asynchronous Transer Mode (ATM) network reachability information. This information exchange is one component in a solution to connect ATM network islands over an MPLS core. "Deterministic Fast Router Advertisement Configuration", Greg Daley, 13-Jul-04, Neighbour Discovery forces routers responding to Router Solicitations to delay a random interval of 0-500 ms in order to prevent contention and bandwidth utilization by multiple responding routers. Routers receiving solicitations may need to quickly send responding Router Advertisements faster than allowed in IPv6 Neighbour Discovery. "Mobile IPv6 - NSIS interaction for Firewalls", Hannes Tschofenig, 13-Jul-04, Most of the firewalls deployed today are Mobile IPv6 unaware. Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6 messages are allowed to pass through these firewalls. A signaling protocol is needed which can communicate with these firewalls and instruct them to bypass these Mobile IPv6 messages. The goal of this document is to describe the interaction between NSIS and Mobile IPv6 for successful deployment of Mobile IPv6. "Registration of MIME media type audio/sp-midi", Matti Hamalainen, Tom White, 13-Jul-04, MIDI Manufacturers Association (MMA) and Association of Music Electronics industry (AMEI) have recently produced the Scalable Polyphony MIDI (SP-MIDI) standard [1]. The SP-MIDI standard has been developed in particularly for mobile MIDI applications. SP-MIDI has been approved for 3GPP standardization and a dedicated SP-MIDI profile has been defined for 3GPP SP-MIDI devices [2]. Since MIDI information is a very compact media type 3GPP is initially focusing on the application of SP-MIDI for music downloading and messaging applications that require MIME registration. "Registration of MIME media type audio/mobile-xmf", Matti Hamalainen, Tom White, 13-Jul-04, MIDI Manufacturers Association (MMA) and Association of Music Electronics industry (AMEI) have recently produced the Mobile XMF standard [1]. The Mobile XMF standard has been developed in particularly for mobile MIDI [6] applications. Mobile XMF information is a very compact media type providing high quality synthetic audio content for music downloading and messaging applications that require MIME registration. "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 13-Jul-04, The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 13-Jul-04, The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a framework for consent-based communications in SIP. "Connection-Establishment Preconditions in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 13-Jul-04, This document defines the connection-establishment precondition type for the SIP preconditions framework. Connection-establishment preconditions are met when a transport connection (e.g., a TCP connection) is successfully established between two endpoints. "Fast Router Discovery with RA Caching", JinHyeock Choi, 13-Jul-04, This document presents RA Caching in AP for Fast Router Discovery. For seamless handoff, a mobile node MUST quickly discover its new access router. In our proposal an AP caches a Router Advertisement message and sends it to a new mobile node as soon as new L2 association is made. We present a way for an AP to cache a suitable RA. By putting 'RA Caching' and 'AP Notification' functionality on AP, we get the optimized result without IPv6 standard change. "TCP User TimeOut (UTO) Option", L Eggert, Fernando Gont, 13-Jul-04, The original TCP specification (RFC793) defines a "USER TIMEOUT" parameter that sets the policy as to when a user connection should be aborted. However, TCP provides no means of letting users suggest an abort policy to a remote peer dynamically. Even though a fixed policy may work well in many cases, there are a number of scenarios where a fixed USER TIMEOUT value may be inappropriate, and some means of setting the abort policy dynamically may be necessary for TCP to be used effectively in such scenarios. This document defines a new TCP option, which lets a TCP peer suggest a USER TIMEOUT value to a remote TCP during the connection-establishment phase, and modify it during the life of a connection, thus adapting TCP's connection-abort policy as necessary. "RTSP Announce Method", Thomas Zeng, 22-Jul-04, This memo describes an extension RTSP method, ANNOUNCE, which extends the core RTSP protocol [RTSP_NEW] to enable a RTSP protocol entity to push to the other side various types of information without the other side asking for it, as long as the other side has singalled the capability to support ANNOUNCE. "The Compact Media Format (CMF) Presentation (Syntax)", Roozbeh Atarius, 13-Jul-04, This document specifies a binary format container for multimedia elements with embedded time synchronization information. This syntax is called Compact Media Format (CMF) and can be employed to create a multimedia presentation with sound, music, picture, animation, etc. in messaging and other applications. CMF is optimized for small size and efficient use in 3G wireless networks and is currently deployed in cdma2000(r) networks. "Alternate Simultaneous Capabilities and Offers in the Session Description Protocol (SDP)", Medhavi Bhatia, 13-Jul-04, This document defines Session Description Protocol (SDP) attributes and semantics to express alternate capabilities and offers. The attribute "cgroup” is defined to express alternate simultaneous sets of capabilities. The “ALTS” semantics are defined to express specific alternate simultaneous offers. Existing methods like the MIME multipart/alternative subtype and the use of multiple session descriptions in SDP are also discussed. "GSSAPI Mechanisms without a Single Canonical Name", Sam Hartman, 13-Jul-04, The Generic Security Services API (GSSAPI) uses name-based authorization. GSSAPI authenticates two named parties to each other. Names can be stored on access control lists to make authorization decisions. Advances in security mechanisms require this model to be extended. Some mechanisms such as public-key mechanisms do not have a single name to be used. Other mechanisms such as Kerberos allow names to change as people move around organizations. This document proposes expanding the definition of GSSAPI names to deal with these situations. "Preserving BGP Next-Hops", Rahul Aggarwal, 13-Jul-04, A BGP speaker uses the NEXT_HOP attribute or the MP_REACH_NLRI attribute to advertise the IP address that should be used as the next hop to the destinations listed in the Network Layer Reachability Information (NLRI). This next hop may be rewritten by other BGP speakers when the NLRI is re-advertised. Some applications depend on the original BGP next hop. This document proposes a mechanism to preserve the original BGP next hop. "Setup and Maintenance of Pseudowires using RSVP-TE", Rahul Aggarwal, 13-Jul-04, This document describes procedures for using Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for signaling Pseudowires (PWs). One motivation is the signaling of PW QoS. The other is the setup of a multi-hop PW, for example, to span multiple domains. RSVP-TE provides mechanisms for QoS signaling and these can be leveraged for signaling PW QoS. It also provides the ability to signal bi-directional MPLS Label Switched Paths (LSP) with explicit routes. This can be used for signaling multi-hop PWs that require explicit routing. RSVP-TE also provides the ability to establish non- adjacent or targeted signaling sessions. "Lemonade Profile", Stéphane Maes, Alexey Melnikov, 13-Jul-04, This document describes the Lemonade profile to allow clients to submit new email messages incorporating content which resides on locations external to the client ("forward without download") and to optimize e-mail exchanges between clients and servers in a mobile environment. "Lemonade Command Extensions", Stéphane Maes, 13-Jul-04, The Lemonade Command Extensions defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. It proposes extensions for message delivery, and maintaining up-to-date personal information. Bindings to specific transport are explicitly defined. "Lemonade HTTP Binding", Stéphane Maes, 13-Jul-04, Lemonade (see [LEMONADEPROFILE]) describes extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. This draft describes bindings to HTTP. "VPLS OAM Requirements and Framework", Dinesh Mohan, 13-Jul-04, This draft provides framework and requirements for Virtual Private LAN Service (VPLS) Operation, Administration and Maintenance (OAM). "IPv6 Addressing in the IPv4 Internet", Fred Templin, 13-Jul-04, IPv6 includes a 128-bit address space designed as a solution for the 32-bit limitation of IPv4. But, IPv4 proliferation in the global Internet continues via private addressing domains behind Network Address Translators (NATs). Furthermore, a formerly popular viewpoint that IPv6 networking would soon replace IPv4 seems to be yielding to an emerging viewpoint of long-term coexistence. This document proposes a coexistence scenario with IPv6 for end-to-end addressing and IPv4 for inter/intra-network routing. "Payment for SIP Services", Cullen Jennings, 13-Jul-04, Communication systems require that a person receiving a call be able able to charge the caller when they are from different administrative domains. This is necessary for making fair exchanges of service between two different communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for doing this in SIP. The approach relies on a third party to act as a payment service provider and is optimized for very simple, low value transactions. It does not provide the full range of services that are desirable in typical online trading systems. "A Data Model for Presence", Jonathan Rosenberg, 13-Jul-04, Over the last year of work, the SIMPLE group has tried to answer the question of "what is a tuple". This document tries to answer that question by proposing an abstract data model for presence, and then mapping that data model onto the Presence Information Data Format (PIDF). It then discusses the operations of publication, composition, filtering as they relate to presence data processing. "NAT/Firewall Behavioral Requirements", Cullen Jennings, 13-Jul-04, This document defines basic terminology for describing different types of behavior for NATs and firewalls. It also defines a set of requirements for NATs and firewalls that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs and firewalls that meet this set of requirements will greatly increase the likelihood that applications will function properly. "External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3)", Kaushik Narayan, 13-Jul-04, SNMPv3 provides a framework for user identity based authentication, privacy and granular access control. SNMPv3 aids secure manageability and overcomes one of major drawbacks in previous versions of the SNMP standard. There has been a significant lack of uptake for deployment of SNMPv3, and a number of organizations are still using SNMPv1/SNMPv2c. This is because SNMPv3 does not integrate well with administrative security schemes defined for existing management interfaces like the device command line interfaces. We believe this is because the SNMPv3 standard does not address the issue of management and distribution of the keying material for SNMP. "SIP Computational Puzzles", Cullen Jennings, 13-Jul-04, SPAM has been a frustrating problem in communications and also in SIP. Forcing the client requesting the service to perform a calculation that limits the rate and increases the cost of requests is one of the techniques that may help manage this problem. This draft defines a way to allow a UAS to ask the UAC to compute a computationally expensive hash based function and present the result to the UAS. "Generic Route Optimization Model for NEMO Extended Support", Jongkeun Na, 13-Jul-04, In this memo, we introduce the generic Route Optimization (RO) model that can be used as a framework to evaluate the existing RO models. Then, we analyze typical RO problems by virtue of that. And, we discuss on the feasibility of achieving a unified RO in NEMO, and enumerate the issues that should be cleared for the purpose of that. "Secure Reverse Routing Header Solution in NEMO", Fan Zhao, 13-Jul-04, Abstract: In this draft, we begin with an extensive security analysis on a NEMO RO proposal, RRH, and then propose an effective security mechanism to resist those new threats introduced by the RRH header in the nested mobile network. "Supporting Multi-Sender SA in a Secure and Efficient Way", Fan Zhao, 13-Jul-04, Astract: In this draft, we propose two efficient and practical mechanisms to enable the anti-replay service in the multiple sender SA. As IPSec is still under its development, this draft is mainly based on the existing RFCs. The two solutions require only minor change to the current standards and are back compatible. The security of new proposals and the impacts of possible future standards will be analyzed and discussed. "Multicast in BGP/MPLS IP VPNs Management Information Base", Susheela Vaidya, Thomas Nadeau, 13-Jul-04, 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 to configure and/or monitor multicast in BGP/MPLS IP VPNs as per [MCAST-VPN]. "Multicast Ad hoc On-Demand Distance Vector Routing for IP version 6 (MAODV6)", Jae-Hoon Jeong, 13-Jul-04, This document describes multicasting based on shared multicast tree for IPv6 mobile ad hoc networks, which specifies an extension of MAODV including message formats. In addition, forwarding mechanism of multicast data packets is described to prevent duplicate data packets from being received by multicast group members. "An Extensible Markup Language (XML) Representation for Expressing Geographic Location Information Policy Capabilities", Christian Guenther, Hannes Tschofenig, 13-Jul-04, This specification defines a set of Extensible Markup Language (XML) elements for expressing geographic location information policy capabilities. "Prepaid Extensions to Radius for Event-based Charging", Christian Guenther, Hannes Tschofenig, 13-Jul-04, In event-based charging procedures, customers get charged for service usage per se. This type of charging can be independent of data volume transferred, time period of service availment, or user subscription status. This memo introduces Radius attributes appropriate for event-based charging with debiting of prepaid user accounts. "Diameter Quality of Service Application", Frank Alfano, 13-Jul-04, This document describes a Diameter Application that performs Authentication, Authorization, and Accounting for Quality-of-Service reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources used during the life of the application flow. This QoS AAA protocol may be used between any bearer-level network element that lies on the path of an application flow and an application server that lies anywhere in the network, allowing for a wide variety of flexible service deployment models. "Pros and Cons of allowing SIP Intermediaries to add MIME bodies", Rohan Mahy, 13-Jul-04, The SIPPING Working Group has developed requirements for session policy (including bandwidth and codec restrictions, logging, and middlebox traversal), request history, and identity. This document discusses the pros and cons of allowing intermediaries to add SIP message bodies to address these requirements. It is intended to provoke serious discussion rather than as a complete proposal. "Network Selection Implementation Results", Hannes Tschofenig, 13-Jul-04, This document aims to highlight implementation results on network discovery as well as some new ideas for its extension. The implementation is based on the draft on mediating network discovery, a mechanism that enables a mobile node to discover roaming partners of an access network via EAP. The concept allows automatic network selection of end hosts, based on additional parameters, hence reducing interacting with the user.This document should also open a discussion on the need on network capability mechanisms. "User Interface Requirement for the Internet X.509 Public Key Infrastructure", Tae Kyu Choi, 13-Jul-04, This document provides basic requirements of user interface at PKI client software that satisfy a full of PKI implementation with usability. To meet with the requirements, it defines root CA certificate trust mechanism, certificate sharing mechanism, and certificate representation method. "Decomposed Home Agent Architecture", Alan O'Neill, 13-Jul-04, RFC 3344 [1] describes the current version of Mobile IP version 4 signaling and forwarding. The signaling and forwarding is conducted between a Mobile Node and a Home Agent, via an optional intermediate Foreign Agent, for a Home Address of the Mobile Node. The Home Agent acts as the Mobile IP signaling endpoint, as well as the forwarding endpoint for packet tunneling between the Home Agent and the MN Care of Address. This document describes an alternative architecture in which the Home Agent is the signaling endpoint whilst a new Tunnel Agent acts as the forwarding endpoint. "Path-coupled NAT/Firewall Signaling Security Problems", Hannes Tschofenig, 13-Jul-04, This draft raises some of the open issues in dealing with path-coupled NAT/Firewall signaling and tries to raise awareness of the security issues beyond the NSIS working group. These issues need to be addressed in order to proceed with the security architecture for NAT/Firewall signaling. "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", Pekka Nikander, Julien Laganier, 13-Jul-04, This document specifies two new resource records for the Domain Name System, and how to use them with the Host Identity Protocol. These records allow a HIP node to store in the DNS its Host Identity (i.e., its public key), Host Identity Tag (i.e., a truncated hash of its public key), and Rendezvous Servers (RVS). " Multihoming Scenarios with Multiple Home Agents in Mobile IPv6", SeungSun Hong, 13-Jul-04, This document describes the multihoming issues in Mobile IP networks. It specifies the basic multihoming scenario, a mobile node is multihomed to multiple home agents within an AS, then describes the multihoming method for this basic scenario. The principle of the multihoming method in this document is that multiple home agents share security associations established between a mobile node and a home agent. By sharing security associations among home agents who serve the same home link, we can reduce the burden of MN to manage the HA list. This document points out technical issues related to sharing security associations among home agents and specifies possible solutions for them. Also, this document describes how to extend the basic multihoming method to more complicated multihoming cases such as multiple home agents in different AS. "Carrying Location Objects in RADIUS", Hannes Tschofenig, 13-Jul-04, This document describes RADIUS attributes for conveying the Access Network's operational ownership and location information based on a civil and geospatial location location format. The distribution of location information is privacy sensitive. "RTP Payload Format for Generic FEC-Encoded Time-Sensitive Media", Michael Luby, 13-Jul-04, This document describes a RTP payload format for streams that have been encoded using Forward Error Correction (FEC), for enhanced reliability. The FEC encoding scheme is assumed to be an instantiation of the "FEC Building Block" defined in RFC 3452, and packets and parameters defined for the encoding scheme are used directly as corresponding RTP payloads and parameters. "Clarifications on DHCPv6 Authentication", Tatsuya Jinmei, 13-Jul-04, This document describes issues about the DHCPv6 authentication mechanism identified from implementation experiences. It also tries to propose resolutions to some of the issues. "DNSSEC Non-Repudiation Resource Record", Roy Arends, 13-Jul-04, This document describes the DNSNR Resource Record (RR) for the Non-Repudiation (NR) of Existence service in the context of the DNS Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or "Authenticated Denial of Existence" Resource Records. A signed DNSNR RR protects security-aware DNS components against false denial of existence of RRsets by providing the RR types that exist for its ownername, which optionally includes a non-authoritative delegation point NS RR type. Labels in the ownername and the RDATA may be a hash-value as a defense against zone traversal. "Extended QoS Authorization for the QoS NSLP", Hannes Tschofenig, 13-Jul-04, Proper authorization is essential for a Quality of Service signaling protocol. Three authorization models have been identified: a two-party model, a token-based three-party model, and a generic three-party model This document discusses two possible solution for the generic three-party model: a challenge/response based and an EAP-based approach. "Datagram Congestion Control Protocol Mobility and Multihoming", Eddie Kohler, 13-Jul-04, This document lays out requirements and a preliminary design for transport-level mobility and multihoming support in the Datagram Congestion Control Protocol (DCCP) [DCCP]. "Advertising Interactive Connectivity Establishment (ICE) Services with Presence", Jon Peterson, 13-Jul-04, Many presence applications use availability information about a presentity to show a watcher their readiness to communicate. In the case of real-time multimedia communications, the readiness of the presentity to communicate does not entail that the network topography will permit communication to occur. Accordingly, this document specifies a means to integrate Interactive Connectivity Establishment (ICE) with presence. Presentities employing the Presence Information Data Format (PIDF) can use the extensions in this draft to advertise their ability to undergo a preliminary ICE check, and thus allow watchers to instigate ICE tests to ascertain whether or not the intervening network is friendly to real-time multimedia communication. In a presence application, the results of this test could be displayed to watchers as the relative "connectivity status" of the presentity. "Generic Security Requirements for Routing Protocols - Opened Questions", Jean-Jacques Puig, 13-Jul-04, This document introduces and presents problematics of the 'Generic Security Requirements for Routing Protocols' document. "Advanced IPv6 Internet Exchange model", Maria Morelli, 13-Jul-04, Internet Exchanges (IX) have played a key role in the development of Internet, organizing and coordinating the traffic interchange among Internet Service Providers (ISP). Traditionally, IXs have been based on layer 2 infrastructures, being the layer 3 services managed by the participant ISPs. "Inter domain MPLS Traffic Engineering - RSVP-TE extensions", Arthi Ayyangar, Jean Vasseur, 13-Jul-04, This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas and GMPLS overlay networks. "Loose Segment Optimization in Explicit Paths", Albert Tian, 13-Jul-04, RSVP-TE [RSVPTE] can signal explicit paths with loose or strict hops in a MPLS network. Using loose hops can shorten the ERO, but can not reduce the overhead associated with an RSVP signaled LSP since path states are still created on every hop along the path. In this paper, we propose a mechanism that can reduce the signaling and maintenance overhead associated with loose hops in an RSVP signaled LSP in an LDP enabled network. The mechanism can also be generalized to work with other tunneling technologies such as GRE or IP-in-IP. "Media Friendly Rate Control (MFRC)", Thomas Phelan, 13-Jul-04, Media Friendly Rate Control (MFRC) is a mechanism for rate control of unicast media streams that is intended to be a better fit for the requirements of streaming media applications than TCP-Friendly Rate Control (TFRC), while still maintaining fairness with competing TCP applications. "Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO Basic Support", Romain Kuntz, 13-Jul-04, This document describes the tests performed and results obtained with multihomed mobile networks managed by NEMO Basic Support. We have particularly analyzed mobile networks with multiple mobile routers and mobile networks with multiple NEMO-Prefixes. "IS-IS MPLS Traffic Engineering capabilities", , 13-Jul-04, This document specifies IS-IS traffic engineering capability sub-TLVs related to various router MPLS Traffic Engineering capabilities. These sub-TLVs are carried within the IS-IS CAPABILITY TLV. "IANA Registration for enumservice void", Richard Stastny, Lawrence Conroy, 13-Jul-04, This document registers the 'ENUMservice' 'void' using the URI scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range. "OSPF MPLS Traffic Engineering capabilities", , 13-Jul-04, This document specifies OSPF traffic engineering capability TLVs related to various MPLS Traffic Engineering capabilities. These OSPF TE capability TLVs are carried within the OSPF router information LSA (opaque type of 4, opaque ID of 0). "Analysis of IPv6 Multihoming Scenarios", Jordi Palet, 13-Jul-04, Multihoming seems to be one of the key pieces for the deployment of IPv6 in the enterprise scenario, but is becoming a frequent requirement in all kinds of networks. In addition, other factors including the deployment of broadband networks, the increase in the variety of access technologies, the increase in the demand for resilience/redundancy, etc., in non-enterprise environments, for example in SOHO/home, necessarily imply the increase of IPv6 multihoming demand for a number of scenarios, which are described in this memo. "SDP Descriptors for FLUTE", Harsh Mehta, 13-Jul-04, This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and end FLUTE sessions. "Routing extensions for discovery of TE router information", JP Vasseur, Jean-Louis Le Roux, 13-Jul-04, This document describes extensions to MPLS Traffic Engineering routing for the advertisement of Traffic Engineering Router Information and capabilities. This document specifies a functional description of these extensions whereas protocol specific formats and mechanisms are described in separate documents. "Using SAML for SIP", Hannes Tschofenig, 13-Jul-04, This document describes how to use the Security Assertion Markup Language (SAML) to offer trait-based authorization. As such, it provides an alternative to existing authorization mechanisms for SIP. "IS-IS Extended TLV For Code and Length Size Beyond One Octet", Naiming Shen, 13-Jul-04, This document describes an extension to IS-IS protocol that extends the code and length fields of IS-IS TLV to two octets each. The extension is backwards compatible to existing IS-IS implementation. A transition mechanism for the deployment of the new extension is also described. "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels", Francois Le Faucheur, 13-Jul-04, This document provides specification for aggregation of RSVP end-to- end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) Tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregated RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. "Diverse Inter-Region Path Setup/Establishment", A D’Achille, 13-Jul-04, This memo describes a mechanism to establish end-to-end diverse or disjoint label switched paths (LSPs) across multiple regions, as required for inter-area and inter-AS traffic engineering. The mechanism relies on the joint computation, in each region, of the LSP segments of the diversely routed LSPs, thereby achieving the simplicity of the per-domain approach with effectively no changes to the signaling protocols. This is achieved by the use of a new RSVP- TE object, called the Associated Route Object or ARO, which is defined in this document and used in the signaling messages in support of the scheme. "TCP Extensions for Immediate Retransmissions", L Eggert, 13-Jul-04, This document describes a modification to TCP's standard retransmission scheme that improves performance across intermittently connected paths. In addition to the regular retransmission attempts scheduled at exponentially increasing intervals, this extension causes additional, speculative retransmission attempts upon receiving external triggers. One example of such a trigger is "first hop router reachable." This document does not define the specifics of such triggers, although it describes some examples. Instead, it defines how a conforming TCP implementation operates when it receives a trigger. "Requirements for Path Computation Element in GMPLS and IP/MPLS Networks", Eiji Oki, 13-Jul-04, Path Computation Element (PCE) provides functions of traffic engineering in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net- works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal virtual network topology reconfiguration control, and jugdes on whether a new lower-region LSP should be established when a higher-region LSP is requested. PCE also handles interworking between GMPLS and IP/MPLS net- works, both of which will coexist at some point during the migration process. "Distributed SASL authentication in LDAP", Alexey Melnikov, Kurt Zeilenga, 13-Jul-04, This document was prompted by a desire to allow deployments of distributed SASL implementations, so that all authentication can be performed in a one central place. It tries to fulfill the following requirements: 1) The SASL framework is client/server authentication, but it doesn't preclude either the client or the server implementations from being distributed. 2) It might be also desirable to proxy an authentication exchange whether it was initiated over LDAP or another SASL-supporting protocol. This document defines a Distributed Authentication LDAP extended operation, that enables applications (including LDAP proxies and gateways) that authenticate using SASL, to use LDAP for performing authentication, by forwarding the SASL authentication requests to an LDAP server. "Bootstrapping Kerberos", Hannes Tschofenig, 13-Jul-04, This document proposes a mechanism to obtain a Kerberos Ticket Granting Ticket based on a successful EAP authentication and key agreement message exchange. The initial network access authentication procedure based on EAP is ideal for this purpose. This proposal allows Kerberos to be used within a local network without relying on a global Kerberos infrastructure. It should allow an incremental deployment of Kerberos and a wider distribution of Kerberos into roaming environments. "Fast Reroute using Alternative Shortest Paths", Albert Tian, 21-Jul-04, Repair path mechanism is an important element in IP/LDP fast reroute. In this document we propose a way to calculate local repair paths using alternative shortest paths. The solution can provide complete coverage for all destinations within an IGP area that can possibly be protected. In this document we also suggested an "Explicit Path with Loose Segment" model that can be used to characterize, classify, and analyse repair paths. We proved some of the common properties of loose segments, and showed that the model can be used to characterize all existing fast reroute solutions. "SIP Event Notification for Internet Media Guides", Yuji Nomura, Henning Schulzrinne, 13-Jul-04, This document specifies an update notification protocol for Internet Media Guides (IMGs) using SIP event notification. The mechanism achieves the timely delivery of IMGs and avoids that IMG receivers have to poll for updates. "IPv6 Campus Transition Scenario Description and Analysis", Tim Chown, 13-Jul-04, In this document we consider and analyse the specific scenario of IPv6 transition and deployment in a large department of a university campus network. The department is large enough to operate its own instances of all the conventional university services including (for example) web, DNS, email, filestore, interactive logins, and remote and wireless access. The scenario is a dual-stack one, i.e. transition to IPv6 means deploying IPv6 in the first instance alongside IPv4. This analysis will both identify the available (and still missing) components for IPv6 transition, and also test the applicability of the recently completed IPv6 Enterprise Network Scenarios document. "Reassign Port Number option for TCP", Timothy Shepard, 13-Jul-04, Most TCP connections are protected from spoofing attacks from off- path attackers by their obscurity. This memo suggests that the few TCP connections that aren't so protected today may be protected by making them obscure by using random values for both port numbers. The obvious difficulty with this approach is that the well-known port number is required on the initial SYN to connect to the desired service. A TCP option is proposed which can be used during the SYN and SYN-ACK exchange to request (and accomplish) reassignment of the well known port number to a random value. "Applicability of GMPLS protocols and architectures to Layer 1 Virtual Private Networks", Tomonori Takeda, 13-Jul-04, This document provides materials to show how existing Generalized Multiprotocol Label Switching (GMPLS) protocols and architectures, and current proposals for modifications to those protocols and architectures can be used to satisfy the requirements of Layer 1 Virtual Private Networks (L1VPNs). In addition, this document identifies any areas where additional protocol extensions or procedures are necessary so that GMPLS protocols can be used to satisfy the requirements of L1VPNs, and sets guidelines for possible solution work. "Some Possible Extensions of the Current LFB Model", Steven Blake, Zsolt Haraszti, 13-Jul-04, The ForCES Forwarding Element Model [Model] defines a model and schema for representing Logical Functional Block (LFB) classes and their operational and capability attributes. The operational attributes of LFB instances within a Forwarding Element (FE) are manipulated by the ForCES protocol [ForCES] to configure the operation of the FE. The model assumes that any particular LFB attribute is owned and accessed exclusively by a single LFB instance. While this is a simple and clean restriction, we observe that it imposes some complications when defining LFBs. This memo addresses these complications and proposes that the restriction be re-examined. "Workgroup Chair Document Shepherding", Henrik Levkowetz, David Meyer, 20-Jul-04, This document describes a pilot implementation of a protocol change within the IETF. The essence of the change is to have workgroup chairs more involved in the progress of the document after the workgroup and document editor have handed over the document for publication. The activities involved in this are: 1) providing a writeup for the document, to accompany the request for publication which is sent to the secretariat and the ADs (Area Directors); 2) following up on AD Evaluation comments on a draft to the authors and workgroup; and 3) following up on IESG comments (DISCUSS comments as well as other) on the draft. "SDP Attributes for T.120 Data Conferencing", Joerg Ott, 13-Jul-04, This memo specifies the use of the Session Description Protocol in combination with the SDP Offer/Answer exchange to setup and teardown data conferecing sessions based upon the ITU-T T.120 Series of Recommendations, thereby particularly enabling application sharing as defined in ITU-T T.128. "IP Flow Information Export (IPFIX) Over TCP", Simon Leinen, 13-Jul-04, This documents describes how the IP Flow Information Export (IPFIX) protocol should be mapped to the Transmission Control Protocol (TCP). "Inter-domain Traffic Engineering LSP path computation methods", JP Vasseur, 13-Jul-04, This document specifies two path computation methods for computing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) paths. In this document a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. The first path computation method is also called per-domain path computation whereby each entry boundary LSR is responsible for computing the path to the next exit boundary LSR (where for instance a boundary LSR is either an ARB or an ASBR) whereas in the second method a Path Computation Element (PCE)is used to compute an end to end partial or complete path across multiple domains. "An Extension to the XML Configuration Access Protocol (XCAP) for Manipulating Multiple Elements", Jonathan Rosenberg, 13-Jul-04, The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) provides a mechanism for getting and putting XML documents, elements and attributes to a server. XCAP only allows each operation to operate on a single document, element or attribute at a time. This specification defines an extension to XCAP that allows for manipulation of multiple XML elements within a single operation. "Simple Traversal of UDP Through Network Address Translators (NAT)(STUN)", Jonathan Rosenberg, 13-Jul-04, Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that provides the ability for applications to determine the public IP addresses allocated to them by the NAT. These addresses can be placed into protocol payloads where a client needs to provide a publically routable IP address. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. "NetConf Data Model", Sandeep Adwankar, 21-Jul-04, The NetConf protocol needs a way to represent the managed data on a device. This document provides a data model representation along with concrete realizations of system and interface managed objects. "Use of IPFIX for Export of Per-Packet Information", Guido Pohl, 13-Jul-04, This document describes the usage of the IP Flow Information Export (IPFIX) protocol for the case of exporting and processing per-packet information by means of IPFIX. The main idea is to export two types of records per flow: one type that consists of the usual flow information plus a unique flow identifier; and a second type of record that consists of the actual per-packet information plus a flow identifier that refers to the flow the specific packet belongs to -- that means the flow identifier is used to associate the packet data to its corresponding flow. "TE parameters to be exchanged between GMPLS-controlled ASes", Tomohiro Otani, 13-Jul-04, This draft investigates the difference between MPLS Inter-AS traffic engineering (TE) and GMPLS Inter-AS TE and describes requirements of TE parameters to be dynamically or statically exchanged between Generalized Multiprotocol Label Switching (GMPLS) inter-ASes. "Unified L2 Abstractions for L3-Driven Fast Handover", Koki Mitani, 13-Jul-04, This draft proposes unified L2 abstractions for L3-driven fast handover. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information such as L2 triggers. However, in current operating systems, each protocol layer is designed independently and information exchange between protocol layers is not allowed. To solve the problem, this draft defines 9 kinds of L2 abstractions in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". "ICMP Extensions for Policy-based Routing", Du Ke, 14-Jul-04, ping/traceroute and other network diagnostic tools are widely used in the IP networks to diagnose the network reachability, IP packet routing and routing failure location. However, the existing ping/traceroute tools are adaptable only to the pure networks where the routing is based on destination address. When an IP packet passes a certain equipment based on ACL policy routing, the ping/traceroute packet routing MAY be different from the real traffic flow routing. This will lead to an erroneous diagnostic result. "The SDP (Session Description Protocol) Label Attribute", Orit Levin, Gonzalo Camarillo, 14-Jul-04, This document defines a new Session Description Protocol (SDP) media-level attribute: 'label'. The 'label' attribute carries a pointer to an application layer media stream identifier in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the 'label' attribute to a particular media stream or media streams. The application receiving the SDP document can then associate the particular media stream with its application semantics or role. "EAP Password Authenticated Exchange", William Arbaugh, 14-Jul-04, This Internet Draft defines a provably secure Extensible Authentication Protocol method called EAP-PAX. This method is designed for bootstrapping a shared key-based authentication protocol with a weak preshared password or PIN. It includes key management features, is secure against dictionary attacks, includes optional support for identity protection, and avoids intellectual property rights associated with competing EAP methods. "MRTP: A Multi-Flow Real-time Transport Protocol", Sathya Narayanan, 14-Jul-04, Multimedia data transport over ad hoc networks is a challenging problem. The dynamic nature of the underlying routing and the highly varying quality of the wireless communication links present additional hurdles for the transport of real-time traffic between hosts. However, the mesh topology of ad hoc networks implies the existence of multiple paths between any two nodes. It has been shown in the literature that path diversity provides an effective means of combating transmission errors and topology changes that are typical in ad hoc networks. Moreover, data partitioning techniques, such as striping and thinning, have been demonstrated to improve the queuing performance of real-time data. Recognizing the advantages of these techniques, as well as the increasing need for video services in ad hoc networks, we propose a new transport protocol to support multipath transport of real-time data. The new protocol, called Multi-flow Real-time Transport Protocol (MRTP), provides a convenient vehicle for real-time multimedia applications to partition and to transmit data using multiple flows. Even though the basic idea of MRTP is presented in the context of ad hoc networks, the benefits demonstrated by the use of MRTP is equally applicable to other types of IP network providing multi-media streaming services including the Internet. "QoS renegotiation using RTCP inband signaling", Sejong Oh, 14-Jul-04, The control protocol, RTCP, provides for periodic reporting of reception quality, participant identification and other source description information, notification on changes in session membership, and the information needed to synchronize media streams. This document defines and extends these RTCP functionalities to provide with the end-to-end QoS renegotiation using fast in-band signaling during the active session states. The main purpose of this new function of RTCP is to support the handover between heterogeneous access networks with different QoS factors such as available bandwidth etc. "MIME Type Registrations for 3GPP2 Multimedia files", Harinath Garudadri, 14-Jul-04, This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. "Pseudo Wire Switching", Luca Martini, 14-Jul-04, This document describes how to switch pseudo wires (PW) between two distinct control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. "Transitional IMAP capabilities", Alexey Melnikov, 14-Jul-04, Software releases can't always wait for some document to become an RFC. As the result some software products are released when they implement a non-final version of an IMAP [IMAP4] extension. This may cause substantial interoperability problems between clients and servers that implement different revisions of the same document, as syntax and semantics of operations may change substantially between revisions of the same IMAP extension draft. "Optimized Route Cache Protocol (ORC)", Ryuji Wakikawa, 14-Jul-04, This draft proposes Optimized Route Cache Protocol (ORC) to provide route optimization for the NEMO Basic Support protocol. ORC provides a dynamic route optimization mechanism, similar to route optimization in Mobile IPv6. The ORC aims to manage binding information as if routing information of each mobile network are located at special routers called ``Correspondent Router''. "BFD Extensions for PW Exchange of Fault Notifications", Vasile Radoaca, 14-Jul-04, BFD mechanism [BFD] was original designed to detect failures in communication with a forwarding plane next hop. BFD operates on top of any data protocol being forwarded between two systems. This document describes how to use the BFD mechanism for exchanging OAM Notifications (e.g. AC and PWs Notifications) between OAM domains, for P2P PWs (Single Hop PW, or Multiple Hop PW). This proposal is presented as an alternative to the LDP Status Mechanism described in [PW-CNTL]. "ForCES Element Bindings and Topology Discovery Protocol", Furquan Ansari, 14-Jul-04, This document describes a protocol for dynamically determining CE/FE element bindings discovery and inter-FE topology discovery and maintenance. Such a mechanism is needed for all these elements in the set to behave as a single network element, as required by the ForCES architecture. The discovery protocol operates during both the pre-association and post-association phases of ForCES protocol. "Scope Modifiers in Intellectual Property Declarations", I Maturana, 14-Jul-04, The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers will abstract the intellectual property relationship of interoperable resources, available in the Internet. "Scalable VPWS Network", Chi Yudong, 14-Jul-04, In the pwe3 framework, PW is provided between the egree nodes. In this case, full-mesh PSN tunnel and signaling session connections must be established between pwe3 PEs, which leads to the issue of scalability, especially the difficulty of cross-AS PW services. This document provides a reflector-based VPWS network framework, and presents a solution that provides cross-AS pwe3. "XML Media Types", , 14-Jul-04, This document standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/ xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. "Host Identity Protocol (HIP) Rendezvous Extensions", L Eggert, 14-Jul-04, This document discusses rendezvous extensions for the Host Identity Protocol (HIP). Rendezvous mechanisms extend HIP for communication with HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. The first part of his document motivates the need for rendezvous mechanisms; the second part describes the protocol extensions in detail. "A Schema for Session Initiation Protocol User Agent Profile Data Sets", Dan Petrie, 14-Jul-04, This document defines the requirements and a format for SIP user agent profile data. An overall schema is specified for the definition of profile data sets. The schema also provides for expressing constraints for how multiple sources of profile data are to be combined. This document provides a guide to considerations, policies and syntax for defining data sets to be included in profile data. It also explores some specific data sets to test the requirements, assumptions and syntax "Concerns with URI-based call routing for emergency services", Ted Hardie, 14-Jul-04, This document discusses recent proposals that would introduce a common URI or set of URIs to identify and route calls intended to reach emergency services. "Framework for PCE-based MPLS-TE Fast Reroute Backup Path Computation", JP Vasseur, 14-Jul-04, This document proposes a framework for the use of Path Computation Elements (PCE) to compute bypass tunnels paths, in the context of the MPLS-TE Fast Reroute, while allowing bandwidth sharing between bypass tunnels protecting independent resources. Both a centralized and a distributed PCE scenarios are described. The corresponding required Routing and signalling extensions are beyond the scope of this framework and will be addressed in separate documents. "Tunnel Buffering for Mobile IPv6", Nick Moore, 14-Jul-04, Tunnel Buffering (TB) is an interoperable enhancement to Mobile IPv6 to reduce packet loss during movement, and to avoid retransmission when movement is complete. TB does this by 'pausing' the packets which are to be send over a MobileIPv6 or HMIPv6 tunnel until movement is complete. "RADIUS Extension for Management Authorization", David Nelson, 14-Jul-04, This document describes RADIUS Attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities. Specific provisions are made for remote management via framed management protocols, and for more granular levels of security and command privilege level beyond those included in RFC 2865 [RFC2865]. "Remote Call Control via Mbus and SIP", Rohan Mahy, 14-Jul-04, Mbus (Message Bus for Local Coordination) was designed with remote call control in mind as an Mbus profile. This document discusses changes necessary to the long abandoned call control profile to address recent requrirement, and conditions of use to make the core Mbus appropriate for use among SIP systems on the Internet. "SCTP NAT Transverse Considerations", Qiaobing Xie, 14-Jul-04, This document provides guidelines and solutions for dealing with SCTP association transversing NAT and similar middleboxes. "Setting up Mbus Control Sessions with SIP and SDP", Rohan Mahy, 14-Jul-04, Mbus (Message Bus for Local Coordination) was designed for use on individual hosts, subnets, or small multicast networks. This document describes how to setup an mbus control session using SIP and SDP. Using SIP to setup Mbus allows for authentication, negotiation of an Mbus secret key, and facilitates NAT and firewall traversal. "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Rahul Aggarwal, 14-Jul-04, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. "Fast End-to-End Restoration Mechanism with SRLG using Centralized Control", Jun Choi, 14-Jul-04, This draft describes the concept of the Shared Link Risk Group (SRLG) based logical ring configuration and recovery method using ring SRLG for the purpose of restoration in mesh networks. In this restoration architecture, backup paths can be easily established through the end-to-end path which follows from the logical ring configuration. It guarantees the establishment of backup path disjoint from the working path at all levels. To take advantage of bandwidth considerations and fast restoration mechanisms, a centralized Controller is used to provide dedicated protection to Optical Transport Networks using the SRLG concept. The Controller determines the logical rings over mesh optical networks and distributes information about primary and backup paths to the nodes in the optical transport layer. "Simple New Mail Notification", Randall Gellens, 14-Jul-04, This memo documents a long-standing technique supported by a large number of mail servers which allows users to be notified of new mail. In addition to server support, there are a number of clients which support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client. In brief, the technique is for the server to send the string 'nm_notifyuser' to the finger port on the IP address (either configured or last used) for the user who has received new mail. "Mobile IPv4 Home Address Leasetime", Alan O'Neill, 14-Jul-04, With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to the Mobile Nodes during the initial registration. Though the concept of NAI-based home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for achieving such a NAI-based home address assignment has not been outlined. More particularly, the lifetime of the assigned address is undefined and the address status when deregistering from the HA, such as when returning to the home network, is also undefined. This document first defines a default address lifetime for RFC3344 MIP entities to resolve this ambiguity. The document then specifies a dynamic home address leasetime, as well as two new MIP extensions and associated procedures to facilitate management of a dynamic home address leasetime between the MN and the HA. "Bridging IP at Layer-3", Aidan Williams, 21-Jul-04, Joining incompatible links together as an IP subnet by bridging IP packets at Layer-3 is an attractive goal. Several challenges that need to be addressed before IPbridging becomes a reality are listed in this document. "A Simple IPv4 Multicast Address Allocation Protocol (SMAAP)", Aidan Williams, 14-Jul-04, Specifies a peer-to-peer protocol for allocating dynamic IPv4 link local multicast addresses in an ad-hoc network. This protocol is intended for use in small networks without configured multicast address servers. "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", David Newman, 14-Jul-04, Test engineers take pains to declare all factors that affect a given measurement, including offered load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. "The case for more versatile BGP Route Reflectors", Olivier Bonaventure, 14-Jul-04, The Border Gateway Protocol (BGP) is the standard interdomain routing protocol in the Internet. Inside an Autonomous System (AS), the interdomain routes are often distributed by using BGP Route Reflectors (RR). Today, most RR are simple BGP routers. We show that by adding intelligence to the RR, it is possible to improve both the routing and the packet forwarding in ASes. We show how a versatile RR can help an AS to engineer the flow of its incoming or outgoing interdomain traffic. We also discuss how a versatile RR could help to reduce the BGP convergence time or reduce the size of the routing tables when providing BGP/MPLS VPN services. "IKE extensions for mobility through NAT", Mohan Parthasarathy, 15-Jul-04, This document discusses a simple NAT traversal method to support mobility for IKEv2 when the node moves behind a NAT. The method proposed here allows for the address change only after authenticating the new address. "Sever/Application State Protocol version 1 (SASPv1)", Alan Bivens, 15-Jul-04, Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The SASP protocol provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. "Reg Event Package Extension for GRUUs", Paul Kyzivat, 15-Jul-04, This draft defines an extension to RFC 3680 [1] for representing the GRUU associated with a Contact. "Guidelines for implementors using connection-oriented transports in the Session Initiation Protocol (SIP)", Vijay Gurbani, 15-Jul-04, This document provides guidelines for implementors using the transmission control protocol (TCP) in the Session Initiation Protocol (SIP). Although the discussions in this document pertain to TCP, the core ideas presented in the document should be applicable to any stream-oriented transport, including Transport Layer Security (TLS) over TCP and the Stream Control Transport Protocol (SCTP). "The 'application/ssml+xml' Media Type", , 15-Jul-04, This document defines the 'application/ssml+xml' media type for the Speech Synthesis based markup language. "SPF/FROM-HDR Determining sender policy for the From: header", Mark Lentczner, 16-Jul-04, This document is part of the Unified SPF series. It defines the SPF/FROM-HDR test, which uses the spf_test() function in conjunction with the From: header of the email. This document describes the mechanics, semantics and utility of the SPF/FROM-HDR test. It also recommends receiver policy actions. "IPFIX Implementation Notes", Luca Deri, 16-Jul-04, Providing an early implementation report is important in order to help validating a standard before its finalization. This document describes the lessons learnt while implementing both an IPFIX probe and collector. Its goals are manifold and include feedback to the IPFIX working group, in addition to suggestions for tackling open protocol issues that can be addressed in future IPFIX drafts. "Netconf Architecture Model", Rei Atarashi, 16-Jul-04, For the new network configuration concept discussed at NETCONF, we mention the importance of building new network architecture. We can not develop and discuss the concept using XML because it is only tools but the concept is confusable. The consensus of architecture is required to clarify the items and technologies that should be discussed and standardized at IETF. "DNS Publication Accreditation Data", Phillip Hallam-Baker, 16-Jul-04, This document describes a mechanism that may be used to publish accreditation data associated with email senders authenticated by means of SPF or CallerID. "Proof of Consent Mechanism", Phillip Hallam-Baker, 16-Jul-04, We propose a mechanism Proof of Consent that allows an email recipient to provide verifiable proof of ‘opt-in’ consent to receive email. Proof of Consent may be used to automatically whitelist email from mailing lists and email forwarded from another email server. Proof of Consent is designed to require minimal state maintenance by both the email sender and the recipient and to be deployable with minimal impact on existing email infrastructure. "Entity-to-Entity S/MIME", Phillip Hallam-Baker, 16-Jul-04, This document describes a set of related protocol extensions to S/MIME, SMTP and DNS that collectively simplify deployment of S/MIME. Particular attention is given to ensuring that S/MIME authenticated content is only received by end user clients capable of presenting the content in an acceptable manner. The proposal extends the ‘end-to-end’ security model of traditional S/MIME to support end-to-edge, edge-to-end and edge-to-edge use cases. "Sieve Extension: Bodypart Loops", Tony Hansen, 16-Jul-04, The current Sieve language has no looping mechanism, a way to look at individual parts, or any way to manipulate those individual parts. This document defines extensions for each of these needs. "RADIUS Attributes for Mobile IPv6 bootstrapping", Kuntal Chowdhury, Avi Lior, 16-Jul-04, This document defines new attributes to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. In an access network where the user attaches to get IPv6 access, there may be a Network Access Server (NAS) or an Access Gateway that will require authentication and authorization. In some cases, this type of access authentication takes place via RADIUS infrastructure. As part of the authentication setup the NAS may receive useful configuration information from the home RADIUS server of the user. In case of Mobile IPv6 access, the Home RADIUS server may assign various information relevant to the user's device for bootstrapping. "IP Pseudowire Encapsulation", Florin Balus, 16-Jul-04, This document specifies a PW encapsulation specific to IP packets, the IP Pseudowire, following the architectural principles defined in [PWE3 Architecture]. The IP Pseudowire is applicable mainly to the Ethernet to FR/ATM Interworking over MPLS (Routed mode) solution, described in [ARP Mediation], double-sided IWF. It enables the usage of PW OAM tools while offering support for preserving the characteristics of the end-to-end L2 service. The proposed solution addresses the case of an MPLS backbone running ECMP so that the IP and PW OAM packets follow the same path throughout the backbone. "Framework for Netconf Data Models", Sharon Chisholm, 16-Jul-04, This memo defines a framework for defining content for Netconf. "Security Best Practices Efforts and Documents", Chris Lonvick, 16-Jul-04, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Generalized MPLS Recovery Resource Sharing", , 16-Jul-04, Many protection and restoration (P&R) techniques are proposed to protect LSP in Generalized Multi-Protocol Label Switching (GMPLS) networks. Provisioning better P&R capability requires that much recovery resources be allocated on protection LSP, which may lead to resource waste in GMPLS networks. "Goals and Benefits of Multihoming", Thierry Ernst, 20-Jul-04, This document attempts to define the goals and benefits of multihoming for fixed and mobile hosts and routers. Those goals and benefits are illustrated with a set of real-life scenarios. "The DHCPv6 Client FQDN Option", Bernie Volz, 20-Jul-04, This document specifies a new DHCP for IPv6, DHCPv6, option which can be used to exchange information about a DHCPv6 client's fully-qualified domain name and about responsibility for updating DNS RRs related to the client's address assignments. "Framework of requirements for real-time text conversation using SIP", Arnold Van Wijk, 20-Jul-04, This document provides the framework of requirements for text conversation with real time character-by-character interactive flow over the IP network using the Session Initiation Protocol. The requirements for general real-time text-over-IP telephony, point-to point and conference calls, transcoding, relay services, user mobility, interworking between text-over-IP telephony and existing text-telephony, and some special features including instant messaging have been described. "Implicit Signaling over Stateless Networks", Vincenzo Mancuso, 21-Jul-04, This memo defines a mechanism for NSIS Signaling Layer Protocol (NSLP). The driving motivation is that some network domains, e.g. based on Differentiated Services data plane, might not explicit support a per-router and/or per-domain admission control rule. Hence, for such domains, explicit signaling is not a viable approach. To partially solve this issue, we suggest an admission control paradigm devised to provide ?Implicit Signaling? via data plane packet delivery operation. Implicit Signaling relies the decision to admit a new flow upon the successful and timely delivery, through the domain, of Probe packets independently generated by the NSIS initiator (NI). The key idea is to use failed receptions of Probes to discover, at the NI, that a congestion condition occurs in the network segment between NSIS initiator and NSIS Responder (NR), and to abort a reservation procedure. Since Implicit Signaling is not able to communicate per-flow traffic and QoS parameters, in principle it cannot exert a QoS control as tight as in the case of explicit mechanisms. However, it is important to notice that Implicit Signaling can indeed operate in a differentiated manner on the basis of traffic and QOS parameters, if i) Probes are marked according to the flow traffic and QoS requirements, ii) marked Probes experience a dropping behaviour according to their mark, and iii) Probe dropping is controlled according to measurements taken into the core routers. "ARP Mediation for IP Interworking of Layer 2 VPN", Himanshu Shah, 23-Jul-04, The VPWS service [L2VPN Framework] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a Pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both ethernet, both ATM), and the Pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the Pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". This document specifies the ARP Mediation function, and specifies draft-shah-l2vpn-arp-mediation-00.txt the encapsulation used to carry the IP datagrams on the Pseudowires when ARP mediation is used. Next Steps in Signaling (nsis) ------------------------------ "Next Steps in Signaling: Framework", Robert Hancock, 8-Jul-04, The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing and mobility. The different routing and mobility events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. "Security Threats for NSIS", Hannes Tschofenig, Dirk Kroeselberg, 24-Jun-04, This threats document provides a detailed analysis of the security threats relevant to the NSIS protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. "RSVP Security Properties", Hannes Tschofenig, 18-Feb-04, This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done with RSVP and to capture the knowledge about past activities. "Analysis of Existing Quality of Service Signaling Protocols", Jukka Manner, 3-May-04, This document reviews some of the existing QoS signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid the mistakes during the design and the implementation of any new protocol in this area. "NSLP for Quality-of-Service signaling", Sven Van den Bosch, Georgios Karagiannis, Andrew McDonald, 22-Jul-04, This draft describes an NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with the NTLP, it provides functionality similar to RSVP and extends it. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This version of the draft focuses on the basic protocol structure. It identifies the different message types and describes the basic operation of the protocol to create, refresh, modify and teardown a reservation or to obtain information on the characteristics of the associated data path. "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Martin Stiemerling, 22-Jul-04, This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators and Firewalls. This NSLP allows hosts to signal along a data path for Network Address Translators and Firewalls to be configured according to the data flow needs. The network scenarios, problems and solutions for path-coupled Network Address Translator and Firewall signaling are described. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. "GIMPS: General Internet Messaging Protocol for Signaling", Henning Schulzrinne, 20-Jul-04, This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The solution uses existing transport and security protocols under a common messaging layer, the Generic Internet Messaging Protocol for Signaling (GIMPS), which provides a universal service for diverse signaling applications. GIMPS does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIMPS and the lower layer protocols provides a solution for the base protocol component of the 'Next Steps in Signaling' framework. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer, 17-Mar-04, This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Open Pluggable Edge Services (opes) ----------------------------------- "An Architecture for Open Pluggable Edge Services (OPES)", Abbie Barbir, 12-Dec-02, This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. "Requirements for OPES Callout Protocols", Andre Beck, 12-Dec-02, This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluating possible protocol candidates as well as to guide the development of such protocols. "Policy, Authorization and Enforcement Requirements of OPES", Oskar Batuner, Andre Beck, Tat Chan, Hilarie Orman, Abbie Barbir, 6-Apr-04, This document describes policy, authorization and enforcement requirements for the selection of the services to be applied to a given OPES flow. "Security Threats and Risks for Open", Abbie Barbir, 10-Dec-03, The document investigates the security threats associated with OPES. The effects of security threats on the underlying architecture are discussed. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. "OPES Callout Protocol Core", Alex Rousskov, 5-May-04, This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: an OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). OCP Core defined in this document consists of application-agnostic mechanisms essential for efficient support of typical adaptations. "OPES entities and end points communication", Abbie Barbir, 6-May-04, This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). "OPES Treatment of IAB Considerations", Abbie Barbir, Alex Rousskov, 12-Apr-04, IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. "HTTP adaptation with OPES", Alex Rousskov, Martin Stecher, 15-Jan-04, Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document binds those mechanisms to a specific application protocol, HTTP. Together, application-agnostic OPES documents and this HTTP binding constitute a complete specification for HTTP adaptation with OPES. Operations & Management Open Area (opsarea) ------------------------------------------- "Guidelines for Authors and Reviewers of MIB Documents", C.M. Heard, 10-Jun-04, This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may used as a basis for reviews of other MIB documents. Open Shortest Path First IGP (ospf) ----------------------------------- "Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, 9-Apr-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol for IPv6. Please send comments to ospf@discuss.microsoft.com. "OSPF Refresh and Flooding Reduction in Stable Topologies", Padma Pillay-Esnault, 17-Jun-03, This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements in stable topologies. The OSPF current behavior requires that all LSAs other than DoNotAge LSAs to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs to reduce protocol traffic in stable topologies "OSPF Version 2 Management Information Base", Spencer Giacalone, Dan Joyal, Rob Coltun, Fred Baker, 6-Jan-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. This memo is intended to update and possibly obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1580 are explained in Appendix B. Please send comments to ospf@discuss.microsoft.com. "Detecting Inactive Neighbors over OSPF Demand Circuits", Sira Rao, Alex Zinin, Abhay Roy, 5-Feb-04, OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits is optimized in RFC1793 to minimize the amount of overhead traffic. A part of OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect a OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance", G Choudhury, 7-Jun-04, This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. "Authentication/Confidentiality for OSPFv3", Mukesh Gupta, Nagavenkata Melam, 11-Dec-03, This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. "Traffic Engineering Extensions to OSPF version 3", Kunihiro Ishiguro, Toshiaki Takada, 14-Jul-04, This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", Eric Rosen, 10-Mar-04, This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides 'BGP/MPLS IP VPN' service to a customer, and the customer uses OSPF to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPF from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of converting the routes from OSPF to BGP and back to OSPF, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE, and should be ignored by any other PEs that see it. "Extensions to OSPF for Advertising Optional Router Capabilities", Acee Lindem, Naiming Shen, Rahul Aggarwal, Scott Shaffer, JP Vasseur, 8-Jul-04, It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. "Graceful OSPF Restart Implementation Report", Acee Lindem, 28-Apr-04, Graceful OSPF Restart provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. "Support of address families in OSPFv3", Sina Mirtorabi, 6-Apr-04, This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. "OSPF Multi-Area Adjacency", Sina Mirtorabi, Peter Psenak, Acee Lindem, Anand Oswal, 20-Jul-04, This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. "Advertising a Router's Local Addresses in OSPF TE Extensions", Rahul Aggarwal, Kireeti Kompella, 21-Jul-04, This document describes procedures that enhance OSPF Traffic Engineering (TE) extensions for advertising a router's local addresses. This is needed to enable other routers in a network to compute traffic engineered MPLS LSPs to a given router's local addresses. Currently, the only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE enabled links and the local address corresponding to the Router ID. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Problem Statement and Usage Scenarios for PANA", Yoshihiro Ohba, 29-Apr-03, Network access authentication is a function that is typically required in most scenarios. This is accomplished in most networks via protocols such as PPP, PPPoE, IEEE 802.1X and others. The PANA (Protocol for carrying Authentication for Network Access) WG is considering the network access authentication function being performed at or above the IP layer. This document captures the various usage scenarios/applicability of a protocol that is used for network access authentication that is at layer-3 or above and additionally identifies the problem being addressed by the WG. "Protocol for Carrying Authentication for Network Access (PANA)Requirements", Alper Yegin, Yoshihiro Ohba, 15-Jun-04, It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. "Protocol for Carrying Authentication and Network Access Threat Analysis and Security Requirements", Mohan Parthasarathy, 17-Jun-04, The PANA (Protocol for carrying authentication for Network Access) working group is developing methods for authenticating clients to the access network using IP based protocols. This document discusses the threats to such protocols. The security requirements arising out of these threats will be used as additional input to the PANA WG for designing the IP based network access authentication protocol. "Protocol for Carrying Authentication for Network Access (PANA)", Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin, 19-Jul-04, Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method, and can be used on any link that can carry IP. PANA covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. "PANA enabling IPsec based Access Control", Mohan Parthasarathy, 6-May-04, The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. "SNMP usage for PAA-2-EP interface", Yacine Mghazli, Yoshihiro Ohba, Julien Bournelle, 22-Jul-04, The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client (PaC) successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group mandates the use of Simple Network Management Protocol (SNMP) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMP as the PAA-2-EP protocol. "PANA Framework", Prakash Jayaraman, 20-Jul-04, PANA design provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. This I-D defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: using PANA over DSL networks and WLAN networks. Protocol Independent Multicast (pim) ------------------------------------ "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Mark Handley, Isidor Kouvelas, Tony Speakman, Lorenzo Vicisano, 22-Jul-04, This document discusses Bi-directional PIM, a variant of PIM Sparse-Mode [9] that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides a default route to the RP thus eliminating the requirement for data-driven protocol events. "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, 20-Jul-04, This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. "Bootstrap Router (BSR) Mechanism for PIM", Bill Fenner, 19-Jul-04, This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast protocol) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Andy Adams, Jonathan Nicholas, William Siadak, 24-Jun-04, This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. "Anycast-RP using PIM", Dino Farinacci, 22-Jun-04, This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain, which runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem. Profiling Use of PKI in IPSEC (pki4ipsec) ----------------------------------------- "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Brian Korver, 22-Jul-04, IKE/IPsec and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE/IPsec and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Simple Certificate Validation Protocol (SCVP)", Ambarish Malpani, Russell Housley, Trevor Freeman, 20-Jul-04, SCVP allows a client to offload certificate handling to a server. The server can provide the client with a variety of valuable information about the certificate, such as whether the certificate is valid, a certification path to a trust anchor, and revocation status. SCVP has many purposes, including simplifying client implementations and allowing companies to centralize trust and policy management. "Internet X.509 Public Key Infrastructure Certificate Management Protocols", Carlisle Adams, Stephen Farrell, 14-Feb-04, This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides online interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. "Internet X.509 Public Key Infrastructure Permanent Identifier", Denis Pinkas, Thomas Gindin, 13-Jul-04, 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 -- Transport Protocols for CMP", Amit Kapoor, Ronald Tschalar, 11-Feb-04, This document describes how to layer Certificate Management Protocols over various transport protocols. "Internet X.509 Public Key Infrastructure Repository Locator Service", Sharon Boeyen, Phillip Hallam-Baker, 16-Sep-03, This document defines a PKI repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", Michael Myers, Carlisle Adams, Dave Solo, David Kemp, 15-Apr-03, This document describes the Certificate Request Message Format (CRMF). This syntax is used to convey a request for a certificate to a Certification Authority (CA) (possibly via a Registration Authority (RA)) for the purposes of X.509 certificate production. The request will typically include a public key and associated registration information. "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", Peter Gutmann, 21-May-04, The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. "Internet X.509 Public Key Infrastructure Warranty Certificate Extension", Duane Linsenbardt, Sue Pontius, Alice Sturgeon, 18-Nov-03, This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for a the certificate containing the extension. "Attribute Certificate Policies extension", Christopher Francis, Denis Pinkas, 4-Dec-03, This document describes one certificate extension to explicitly state the Attribute Certificate (AC) policies that apply to a given Attribute Certificate. The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e. to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific AC policies. "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", Jeong Park, 20-Jul-04, This document defines Privacy-Enhanced Protected Subject Identifier (PEPSI) format for including a privacy sensitive identifier in the subjectAltName extension of a certificate. "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Jim Schaad, Burton Kaliski, Russell Housley, 19-Mar-04, This document supplements RFC 3279. It describes the conventions for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm, and additional one-way hash functions with the PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. "Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs", David Chadwick, Mikhail Sahalayev, 29-Jun-04, This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry, or set of entries. Object classes are defined for these CRL entries. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. "Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates", David Chadwick, Mikhail Sahalayev, 19-Jul-04, This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. "Internet X.509 Public Key Infrastructure: Certification Path Building", Michael Cooper, Yuriy Dzambasow, 29-Jun-04, This document was written to provide guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate enabled application that can build valid certification paths across a wide range of PKI environments. "A 224-bit One-way Hash Function: SHA-224", Russell Housley, 31-Mar-04, This document specifies a 224-bit one-way hash function, called SHA-224. A SHA-224 is based on SHA-256, but it uses an different initial value and the result is truncated to 224 bits. "Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile.", Serguei Leontiev, 1-Apr-04, This document describes identifiers and appropriate parameters for the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, and also ASN.1 encoding scheme for digital signatures and public keys, used in Internet X.509 Public Key Infrastructure (PKI). This specification extends [RFC3279], 'Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' and, correspondingly, [RFC3280], 'Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile'. All implementations of this specification MUST also satisfy the requirements of [RFC3280]. Path MTU Discovery (pmtud) -------------------------- "Path MTU Discovery", Matt Mathis, 20-Jul-04, This document describes a robust new method for Path MTU Discovery that relies on TCP or other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP based Path MTU Discovery for IP versions 4 and 6, respectively. This document does not define a protocol, but rather a method to use features of existing protocols to discover the path MTU. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- "Class Extensions for PPP over ATM Adaptation Layer 2", B Thompson, bruce Buffam, Tmima Koren, 4-Feb-02, PPP over ATM Adaptation Layer 2 defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the AAL2 adaptation layer. This document defines a set of class extensions to PPP over AAL2 that implement equivalent functionality to Multi Class Multi Link PPP over a single ATM virtual circuit. Instead of using Multi Link PPP as the basis for fragmentation functionality, this document uses the functionality of the Segmentation and Reassembly Service Specific Convergence Sublayer that is already required as the basic encapsulation format of PPP over AAL2. "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Paul Funk, Simon Blake-Wilson, 20-Jul-04, EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Problem Statement (problem) --------------------------- "IETF Problem Resolution Process", Elwyn Davies, Jeanette Hofmann, 12-Jan-04, This document suggests processes to address some of the problems identified in the IETF Problem Statement. This document decomposes each of the problems described in the problem statement into a few areas for improvement, categorizes them either as problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF, and suggests ways to address the problems with the routine processes that can be implemented as soon as possible without disrupting other areas of the IETF processes. Packet Sampling (psamp) ----------------------- "A Framework for Passive Packet Measurement", Nick Duffield, 22-Jul-04, This document specifies a framework for the PSAMP (Packet Sampling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized reports, form ra stream of reports on the selected packets, and to export that stream to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and export are described, along with configuration of the PSAMP functions. Comments on this document should be addressed to the PSAMP Working Group mailing list: psamp@ops.ietf.org To subscribe: psamp-request@ops.ietf.org, in body: subscribe Archive: https://ops.ietf.org/lists/psamp/ "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, Maurizio Molina, Fredric Raspall, Nick Duffield, 16-Feb-04, This document describes sampling and filtering techniques for IP packet selection. In two information models (one for sampling, one for filtering) it defines what parameters are needed to describe the most common selection schemes and shows how techniques can be combined to build more elaborate packet selectors. The information models are used for configuring the selection technique in measurement processes and for reporting the technique in use to a collector. The document first suggests some terminology, then it describes in detail packet sampling and packet filtering techniques and their parameters. It also describes how these two techniques can be combined to build more elaborate packet selectors. Finally, it introduces information models for the most common sampling and filtering techniques. The document first suggests some terminology, then it describes in detail packet sampling and packet filtering techniques and their parameters. It also describes how these two techniques can be combined to build more elaborate packet selectors. Finally, it introduces information models for the most common sampling and filtering techniques. "Definitions of Managed Objects for Packet Sampling", Thomas Dietz, 22-Jul-04, This memo defines managed objects for packet sampling. These objects provide information about managed nodes supporting packet sampling, including packet sampling capabilities, configuration and statistics. They also allow to configure packet sampling concerning the IP interface at which packets are sampled, the packet selections methods used for sampling, and the collector to which packet samples are exported. "Packet Sampling (PSAMP) Protocol Specifications", Benoit Claise, 18-Feb-04, This document specifies the export of packet information from a PSAMP exporting process to a PSAMP colleting process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used. It is shown that The IPFIX protocol is well suited for this purpose, because the IPFIX architecture matches the PSAMP architecture very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. "Information Model for Packet Sampling Exports", Thomas Dietz, 22-Jul-04, This document defines an information and data model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the sampling process. The model is an extension to IPFIX information model. Pseudo Wire Emulation Edge to Edge (pwe3) ----------------------------------------- "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", X Xiao, 12-Jan-04, This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e. 'synchronous bit streams at rates defined by ITU G.702') are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. "Pseudo Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, Dave Danenberg, Sharon Mantin, 24-Jun-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire (PW) services on a general Packet Switched Net (PSN). "Pseudo Wire (PW) over MPLS PSN Management Information Base", David Zelig, Thomas Nadeau, Dave Danenberg, 24-Jun-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). "Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management", Thomas Nadeau, Dave Danenberg, David Zelig, Andrew Malis, 24-Jun-04, This memo defines an experimental portion of the Management information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the textual conventions to be used in the various Pseudo Wire (PW) MIB modules. "SONET/SDH Circuit Emulation over Packet (CEP)", Andrew Malis, 22-Jun-04, This draft provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over a packet-switched network (PSN). "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", Luca Martini, Eric Rosen, Nasser El-Aawar, Giles Heron, 19-Jul-04, An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. "Pseudowire Setup and Maintenance using LDP", Luca Martini, Eric Rosen, Toby Smith, 9-Jul-04, Layer 2 services (such as Frame Relay, ATM, ethernet) can be 'emulated' over an IP and/or MPLS backbone by encapsulating the layer 2 PDUs and then transmitting them over 'pseudowires'. It is also possible to use pseudowires to provide SONET circuit emulation over an IP and/or MPLS network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to LDP. Procedures for encapsulating layer 2 PDUs are specified in a set of companion documents. "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2", David Zelig, Andrew Malis, 7-Jun-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Native Service Processing of SONET/SDH circuits over a Packet Switch Network (PSN). "Ethernet Pseudo Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, 24-Jun-04, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet Pseudo Wire (PW) services. "PWE3 Architecture", Stewart Bryant, Prayson Pate, 25-Mar-04, This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, specifies the various protocol elements and their functions. "PWE3 Fragmentation and Reassembly", Andrew Malis, Mark Townsley, 10-Feb-04, This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. "Frame Relay over Pseudo-Wires", Claude Kawa, 3-Feb-04, This document defines frame relay pseudo-wire emulation edge-to-edge. A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over IP and MPLS packet switched network (PSN). Two mapping modes are defined: One-to-one mapping mode characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs is defined for MPLS PSN. The other mode is known as port mode or many-to-one mapping mode and is defined for MPLS PSN and IP PSN with L2TPv3. "Encapsulation Methods for Transport of ATM Over IP and MPLS Networks", Luca Martini, Matthew Bocci, Jeremy Brayley, Ghassem Koleyni, 19-Jul-04, A framework for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [3]. This draft provides encapsulation formats and guidelines for transporting a variety of ATM services over a PSN. "Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)", Maximilian Riegel, 29-Apr-04, This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits. "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", Luca Martini, Mark Townsley, 19-Jul-04, The Control and maintenance protocol for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [2]. This document pre-allocates the fixed Pseudo-wire identifier , and other fixed protocol values that are to be assigned by IANA using the 'IETF Consensus' policy defined in RFC2434 "Encapsulation Methods for Transport of PPP/HDLC Over IP and MPLS Networks", Luca Martini, Toby Smith, Eric Rosen, Giles Heron, Andrew Malis, Yeongil Seo, 21-Apr-04, A Pseudowire (PW) can be used to carry PPP, or HDLC Protocol Data Units over an IP or MPLS network without terminating the PPP/HDLC protocol. This enables service providers to offer 'emulated' HDLC, or PPP link services over existing IP or MPLS networks. This document specifies the encapsulation of PPP/HDLC PDUs within a pseudowire. "Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", Thomas Nadeau, Rahul Aggarwal, 30-Jun-04, This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with psuedowire connections. VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. VCCV makes use of IP based protocols such as Ping and MPLS-Ping to perform operations and maintenance functions. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. "Structure-Agnostic TDM over Packet (SAToP)", Sasha Vainshtein, Yakov Stein, 7-Jan-04, This document describes a pseudowire encapsulation for TDM (T1, E1, T3, E3) bit-streams that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing [G.704]. "PWE3 Frame Check Sequence Retention", Andrew Malis, 20-May-04, This document defines a mechanism for preserving frame FCS through Ethernet, Frame Relay, and HDLC pseudowires. "Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Sasha Vainshtein, 21-Jul-04, This document describes a method for encapsulating structured (NxDS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. "TDM over IP", Yakov Stein, 22-Jul-04, This document describes methods for structure-aware transport of TDM traffic over packet switched networks using pseudowires. "Managed Objects for Structure-Agnostic TDM over Packet Network", Orly Nicklass, 21-Jul-04, 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 pseudo wire encapsulation for TDM (T1, E1, T3, E3) bit-streams circuits over a Packet Switch Network (PSN). "Managed Objects for TDM over Packet Switched Network (PSN)", Orly Nicklass, 21-Jul-04, 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 pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). Remote Direct Data Placement (rddp) ----------------------------------- "DDP and RDMA Concerns", David Black, 3-Jun-04, This draft describes technical concerns that should be considered in the design of standardized RDMA and DDP protocols/mechanisms for use with Internet transport protocols. This draft was written to provide input to the proposed new Remote Direct Data Placement (rddp) WG, and is not intended for publication as an RFC. This is an updated and resubmitted version of draft-ietf-rddp-rdma- concerns-00.txt to make it available for current discussions of mandatory-to-implement security in the RDDP WG. Sections 4.1, 4.2, and 5 are of particular relevance to that discussion. "The Architecture of Direct Data Placement (DDP)And Remote Direct Memory Access (RDMA)On Internet Protocols", Stephen Bailey, Thomas Talpey, 13-Jul-04, This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g. RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. "Remote Direct Memory Access (RDMA) over IP Problem Statement", Allyn Romanow, Jeffrey Mogul, Thomas Talpey, Stephen Bailey, 13-Jul-04, This draft addresses an IP-based solution to the problem of high system overhead due to the movement of user data in the network I/O path. The overhead has limited the use of TCP/IP in interconnection networks, especially where high bandwidth, low latency and/or low overhead of end-system data movement are required by the hosted application. An architectural solution enabling "copy avoidance" is proposed to eliminate it. "Direct Data Placement over Reliable Transports", Himanshu Shah, 17-Feb-04, The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. "Marker PDU Aligned Framing for TCP Specification", Paul Culley, 20-Jul-04, A framing protocol is defined for TCP that is fully compliant with applicable TCP RFCs and fully interoperable with existing TCP implementations. The framing mechanism is designed to work as an 'adaptation layer' between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. "DDP/RDMAP Security", Jim Pinkerton, 19-Jul-04, This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. Finally, the document concludes with a summary of security services for RDDP, such as IPSec. Remote Network Monitoring (rmonmib) ----------------------------------- "Transport Performance Metrics MIB", Russell Dietz, Robert Cole, 15-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics are defined through reference to existing IETF, ITU and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. "Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms.", Carl Kalbfleisch, Robert Cole, Dan Romascanu, 15-Jun-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. Distribution of this memo is unlimited. "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Anwar Siddiqui, Dan Romascanu, 17-Jun-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB - RFC 2819. In particular, it describes managed objects used for real-time application QOS monitoring. Distribution of this memo is unlimited. "Real-time Application Quality of Service Monitoring (RAQMON) Framework", Anwar Siddiqui, 9-Jul-04, There is a need to monitor end devices such as IP Phones, Pagers, Instant Message Clients, Mobile Phones, and various other hand-held computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality of service (QoS) monitoring of various applications that run on these devices, and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time quality of service monitoring of applications. "Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU)", Anwar Siddiqui, 9-Jul-04, This memo defines a common protocol data unit (PDU) used between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC) to report application level QOS statistics required for extensions of the RMON Framework. This memo also outlines mechanisms to use the Real Time Transport Control Protocol (RTCP) and the Simple Network Management Protocol (SNMP) to transport these PDUs between the RAQMON Data Source (RDS) and the RAQMON Report Collector (RRC). "Remote Network Monitoring Management Information Base Version 2 Using SMIv2", Steven Waldbusser, 17-Feb-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing remote network monitoring devices. "Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)", Emile Stephan, Jordi Palet, 26-May-04, This memo defines additional (to those in RFC2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 (RFC2021) and the RMON Protocol Identifier Reference (RFC2895). Reliable Multicast Transport (rmt) ---------------------------------- "NACK-Oriented Reliable Multicast (NORM) Building Blocks", Brian Adamson, Carsten Bormann, Mark Handley, Joseph Macker, 15-Jul-04, This document discusses the creation the of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. "NACK-Oriented Reliable Multicast Protocol (NORM)", Brian Adamson, Carsten Bormann, Mark Handley, Joseph Macker, 15-Jul-04, This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. "PGMCC single rate multicast congestion control: Protocol Specification", Luigi Rizzo, Gianluca Iannaccone, Lorenzo Vicisano, Mark Handley, 14-Jul-04, This document describes PGMCC, a single rate multicast congestion control scheme which is TCP-friendly and achieves scalability, stability and fast response to variations in network conditions. PGMCC is suitable for both non-reliable and reliable data transfers. It is mainly designed for NAK- based multicast protocols, and uses a window-based, TCP-like control loop using positive ACKs between one representative of the receiver group (the ACKER) and the sender. The ACKER is selected dynamically and may change over time. PGMCC is made of two components: a window-based control loop, which closely mimics TCP behaviour, and a fast and low- overhead procedure to select (and track changes of) the ACKER. The scheme is robust to measurement errors, and supports fast response to changes in the receiver set and/or network conditions. "TCP-Friendly Multicast Congestion Control (TFMCC):Protocol Specification", Joerg Widmer, Mark Handley, 13-Jul-04, This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications such as streaming media where a relatively smooth sending rate is of importance. "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, 14-Jun-04, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. Robust Header Compression (rohc) -------------------------------- "Requirements for ROHC IP/TCP Header Compression", Lars-Erik Jonsson, 9-Jun-04, This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the ROHC WG. The document discusses the scope of TCP compression, performance considerations, assumptions on the surrounding environment, as well as IPR concerns. The structure of this document is inherited from the document defining RTP/UDP/IP requirements for ROHC. "RObust Header Compression (ROHC): Profile for TCP/IP (ROHC-TCP)", Ghyslain Pelletier, 20-Jul-04, This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. Existing TCP/IP header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common. In addition, existing schemes [RFC-1144, RFC-2507] have not addressed how to compress TCP options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-2883] and Timestamps [RFC-1323]. "ROHC Implementer's Guide", Lars-Erik Jonsson, Peter Kremer, 9-Jun-04, This document describes common misinterpretations and some ambiguous points of ROHC [RFC 3095], which defines the framework and four profiles of a robust and efficient header compression scheme. These points have been identified by the members of the ROHC working group during different interoperability test events. "Interoperability of RFC 3095", Lars-Erik Jonsson, 17-Jun-04, RFC 3095 defines a Proposed Standard protocol for RObust Header Compression (ROHC). In order to move the standard further to Draft Standard status, it is required to demonstrate interoperability for all functionality defined by the RFC. This document outlines those features to be tested, and also the test status for each feature, based on reports from interoperability tests or other proof of interoperability. "Formal Notation for Robust Header Compression (ROHC-FN)", Richard Price, 20-Jul-04, This document defines ROHC-FN: a formal notation for specifying how to compress and decompress fields from an arbitrary protocol stack. ROHC-FN is intended to simplify the creation of new compression profiles to fit within the ROHC [RFC-3095] framework. "RObust Header Compression (ROHC):Profiles for UDP-Lite", Ghyslain Pelletier, 9-Jun-04, This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP specified in RFC 3095. "Implementer's Guide for SigComp", Abigail Surtees, 22-Jul-04, This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. "RObust Header Compression (ROHC):Context Replication for ROHC Profiles", Ghyslain Pelletier, 15-Jul-04, This document defines context replication, a complement to the context initialization procedure found in ROHC (Robust Header Compression) [RFC-3095]. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure, and may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as for example short- lived TCP flows. "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", Zhigang Liu, Richard Price, 16-Feb-04, This document describes some specifics when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. "A Negative Acknowledgement Mechanism for Signaling Compression", Adam Roach, 22-Jun-04, This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "Generic Threats to Routing Protocols", Abbie Barbir, Sandra Murphy, Yibin Yang, 13-Apr-04, Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. This document provides a description and a summary of generic threats that affects routing protocols in general. The work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. "Security Requirements for Routing Protocols", Jean-Jacques Puig, Mohammed Achemlal, Emanuele Jones, Danny McPherson, 20-Apr-04, Routing protocols are subject to threats and attacks that can harm individual users or network operations as a whole. This document describes a generic set of security requirements for routing protocols and routing systems. "An Attack Tree for the Border Gateway Protocol", Sean Convery, 5-Apr-04, This I-D presents all known attack vectors into or using BGP. The data is presented in "Attack Tree" format as published by Schneier [ATTACKTREE] and detailed by the CERT in "Attack Modeling for Information Security and Survivability" [MODELING]. Future security improvements to BGP (whether best practices or enhancements to the protocol) should consider the attacks outlined here when determining the relative security improvements such changes provide. "OSPF Security Vulnerabilities Analysis", Emanuele Jones, Olivier Le Moigne, 6-May-04, Internet infrastructure protocols were designed at the very early stages of computer networks when "cyberspace" was still perceived as a benign environment. As a consequence, malicious attacks were not considered to be a major risk when these protocols were designed, leaving today's Internet vulnerable. This paper provides an analysis of OSPF vulnerabilities that could be exploited to modify the normal routing process across a single domain together with an assessment of when internal OSPF mechanisms can or cannot be leveraged to better secure a domain. "Generic Security Requirements for Routing Protocols", Danny McPherson, 9-Jul-04, Routing protocols are subject to threats and attacks that can harm individual users or network operations as a whole. This document describes a generic set of security requirements for routing protocols and routing systems. Reliable Server Pooling (rserpool) ---------------------------------- "Architecture for Reliable Server Pooling", Michael Tuexen, Q Xie, 13-Oct-03, This document describes an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. "Comparison of Protocols for Reliable Server Pooling", John Loughney, 20-Jul-04, This document compares protocols that may be applicable for the Reliable Server Pooling problem space. This document discusses the usage and applicability of these protocols for the Reliable Server Pooling architecture. "Aggregate Server Access Protocol (ASAP)", Randall Stewart, Q Xie, Maureen Stillman, Michael Tuexen, 10-Jun-04, Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Name Resolution Protocol (ENRP) [6] provides a high availability data transfer mechanism over IP networks. ASAP uses a name-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool Elements (PE) and Pool Users (PU) MUST have an accompanying transports mapping document. Note that ASAP messages passed between PE's and ENRP servers MUST use SCTP. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for name to address translation, load sharing management, and fault management while ENRP defines the high availability name translation service. "Enpoint Name Resolution Protocol (ENRP)", Q Xie, Randall Stewart, Maureen Stillman, 13-Jul-04, Endpoint Name Resolution Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture. Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. "Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution (ENRP) Parameters", Randall Stewart, Qiaobing Xie, Michael Tuexen, 10-Jun-04, This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution Protocol (ENRP) protocols defined within the Reliable Server Pooling (RSERPOOL) architecture. "Threats Introduced by Rserpool and Requirements for Security in response to Threats", Maureen Stillman, 9-Jul-04, Rserpool is an architecture and protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This Internet draft describes security threats to the Rserpool architecture and presents requirements for security to thwart these threats. "Reliable Server pool applicability Statement", Lode Coene, 19-Jul-04, This document describes the applicability of the reliable server pool architecture and protocols to applications which want to have High avialebility services. This is accomplished by using redundant servers and failover between servers of the same pool in case of server failure. Processing load in a pool may de distributed/shared between the members of the pool according to a certain policy. Also some guidance is given on the choice of underlying transport protocol (and corresponding transport protocol mapping) for transporting application data and Rserpool specific control data. "TCP Mapping for Reliable Server Pooling Failover Mode", Phill Conrad, Peter Lei, 14-Jun-04, This memo defines the shim protocol that maps the requirements of the ASAP protocol [5] to the capabilities of the TCP protocol [7]. In particular, this shim protocol adds the following capabiltiies that are required by ASAP, but not provided by TCP: (1) message orientation, (2) heartbeat messages, (3) multiple streams, and (4) undelivered message retrieval (if provided). "Services Provided By Reliable Server Pooling", Phill Conrad, 14-Jun-04, The Reliable Server Pooling architecture (abbreviated 'RSerPool', and defined in [1]), provides a set of services and protocols for building fault tolerant and highly available client/server applications. This memo describes the semantics of the services that RSerPool provides to upper layer protocols. Routing Area Working Group (rtgwg) ---------------------------------- "The Generalized TTL Security Mechanism (GTSM)", Vijay Gill, John Heasley, David Meyer, 30-Apr-04, The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. "Calculating IGP Routes Over Traffic Engineering Tunnels", Naiming Shen, Henk Smit, 24-May-04, This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create IGP shortcuts. In particular this document describes how Dijkstra's SPF algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. "IP Fast Reroute Framework", Mike Shand, 23-Jun-04, This document provides a framework for the development of IP fast re- route mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "The Anonymous SASL Mechanism", Kurt Zeilenga, 17-Feb-04, It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. "The Plain SASL Mechanism", Kurt Zeilenga, 17-Feb-04, This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. "Using Digest Authentication as a SASL Mechanism", Paul Leach, Chris Newman, Alexey Melnikov, 17-Feb-04, This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. "SASLprep: Stringprep profile for user names and passwords", Kurt Zeilenga, 22-Jul-04, This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. "Simple Authentication and Security Layer (SASL)", Alexey Melnikov, 29-Jun-04, The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL- compatible authentication mechanism can be used with any SASL- compatible protocol. This document describes how a SASL authentication mechanism is structured, describes how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the SASL EXTERNAL authentication mechanism. "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 12-Jul-04, This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) "SASL GSSAPI mechanisms", Alexey Melnikov, 28-Jun-04, The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document replaces section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism. Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting (seamoby) --------------------------------------------------------------------------------------- "Candidate Access Router Discovery", Marco Liebsch, 9-Jun-04, To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called 'candidate access router discovery' (CARD). At the time of IP-layer handover, that CAR, whose capabilities is a good match to the preferences of the MN, may be chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. "Context Transfer Protocol", John Loughney, 9-Jun-04, This document presents a context transfer protocol that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency, packet losses and avoiding re-initiation of signaling to and from the mobile node. "Instructions for Seamoby Experimental Protocol IANA Allocations", James Kempf, 9-Jun-04, Seamoby Candidate Access Router Discovery protocol and Context Transfer Protocol are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, SCTP Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about what allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. Secure Shell (secsh) -------------------- "SSH Transport Layer Protocol", Tatu Ylonen, Chris Lonvick, 3-Jun-04, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. "SSH Authentication Protocol", Tatu Ylonen, Chris Lonvick, 3-Jun-04, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. "SSH Connection Protocol", Tatu Ylonen, Tero Kivinen, Timo Rinne, Sami Lehtinen, 3-Jun-04, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. "SSH Protocol Architecture", Tatu Ylonen, Chris Lonvick, 3-Jun-04, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. Details of these protocols are described in separate documents. "Generic Message Exchange Authentication For SSH", Martin Forssen, Frank Cusack, 28-Apr-04, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). "SSH File Transfer Protocol", Joseph Galbraith, Tatu Ylonen, Sami Lehtinen, 12-Feb-04, The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", Jeffrey Hutzelman, Joseph Salowey, Joseph Galbraith, Von Welch, 20-Jul-04, The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [GSSAPI] provides security services to callers in a mechanism-independent fashion. "SSH Public Key File Format", Joseph Galbraith, Rodney Thayer, 6-Apr-04, This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol", Markus Friedl, Niels Provos, William Simpson, 24-Jul-03, This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. "Secure Shell Authentication Agent Protocol", Timo Rinne, Sami Lehtinen, 2-Feb-04, This document describes the Secure Shell authentication agent protocol (i.e., the protocol used between a client requesting authentication and the authentication agent). This protocol usually runs in a machine-spe- cific local channel or over a forwarded authentication channel. It is assumed that the channel is trusted, so no protection for the communica- tions channel is provided by this protocol. "SSH Protocol Assigned Numbers", Sami Lehtinen, Chris Lonvick, 3-Jun-04, This document defines the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for initialization of the IANA databases referenced in those documents. "Using DNS to Securely Publish SSH Key Fingerprints", Jacob Schlyter, Wesley Griffin, 5-Sep-03, This document describes a method to verify SSH host keys using DNSSEC. The document defines a new DNS resource record that contains a standard SSH key fingerprint. "SSH Transport Layer Encryption Modes", Mihir Bellare, 27-May-04, Researchers have recently discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy and integrity/authenticity attacks. "Session Channel Break Extension", Joseph Galbraith, Phillip Remaker, 21-Apr-04, The Session Channel Break Extension provides a means to send a BREAK signal [2] over an SSH terminal session [5]. "Secure Shell Public-Key Subsystem", Joseph Galbraith, 2-Apr-04, SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting aShell or a Command''. The subsystem name used with this protocol is ''publickey''. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Securing Neighbor Discovery (send) ---------------------------------- "Cryptographically Generated Addresses (CGA)", Tuomas Aura, 27-Apr-04, This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses where the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or other security infrastructure. "SEcure Neighbor Discovery (SEND)", Jari Arkko, James Kempf, Bill Sommerfeld, Brian Zill, Pekka Nikander, 19-Jul-04, IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine the link-layer addresses of other nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike to the original NDP specifications, these mechanisms do not make use of IPsec. Signaling Transport (sigtran) ----------------------------- "Stream Control Transmission Protocol Management Information Base", Javier Pastor, Maria-Carmen Belinchon, 6-Jun-03, The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport PSTN signaling messages over the connectionless packet network, but is capable of broader applications. This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. "Signalling Connection Control Part User Adaptation Layer (SUA)", John Loughney, Greg Sidebottom, 16-Dec-03, This Internet Draft defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transport Protocol. The protocol is designed to 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. "Telephony Signalling Transport over SCTP applicability statement", Lode Coene, Javier Pastor, 5-Aug-03, This document describes the applicability of the new protocols developed under the signaling transport framework[RFC2719]. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP)[RFC2960] and each adaptation layer for transport of telephony signalling information over IP infrastructure is explained. "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)", Tom George, 17-Jun-04, This Internet Draft defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. "DPNSS/DASS 2 extensions to the IUA protocol", Ranjith Mukundan, Ken Morneault, 8-Oct-03, This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in BTNR 188, is used to interconnect Private Branch Exchanges (PBX) in a private network and DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/ DASS 2 User Adaptation (DUA) implementation. "M3UA Implementor’s Guide", Javier Pastor, Ken Morneault, 16-Feb-04, This document contains a compilation of all defects found up until the publication date for M3UA [RFC3332]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M3UA to clarify errors in the original M3UA document. This document updates RFC3332 and text within this document supersedes the text found in RFC3332. "ISDN Q.921-User Adaptation Layer", Ken Morneault, 14-Jul-04, This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", Greg Sidebottom, Ken Morneault, Javier Pastor-Balbas, 22-Apr-04, This memo 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, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "A Presence Event Package for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 31-Jan-03, This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. "An Extensible Markup Language (XML) Based Format for Watcher Information", Jonathan Rosenberg, 31-Jan-03, Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an XML document format for such state. "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 31-Jan-03, This document defines the watcher information template-package for the SIP event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Adam Roach, Jonathan Rosenberg, Ben Campbell, 13-Jun-03, This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. "Requirements for Filtering of Watcher Information", Krisztian Kiss, 28-Jan-04, This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher infomation notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. "The Message Session Relay Protocol", Ben Campbell, 20-Jul-04, This document describes the Message Session Relay Protocol (MSRP), a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when setup via a rendezvous or session setup protocol such as the Session Initiation Protocol (SIP). "Requirements for Presence Specific Event Notification Filtering", Hisham Khartabil, Eva Leppanen, Tim Moran, 28-Jan-04, This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence infomation notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Jonathan Rosenberg, 20-Jul-04, This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. "An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, 20-Jul-04, This specification defines a document format that can be used to describe the differences between versions of resources managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). Documents of this format can be delivered to clients using a number of means, including the Session Initiation Protocol (SIP) event package for configuration data. By subscribing to this event package, clients can learn about document changes made by other clients. "Extensible Markup Language (XML) Formats for Representing Resource Lists", Jonathan Rosenberg, 19-Jul-04, In multimedia communications, presence and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services which are associated with a group of users. One example is a presence list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the presence list service, the server will obtain the presence of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists which are referenced from the first. Both documents can created and managed with the XML Configuration Access Protocol (XCAP). "RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)", Henning Schulzrinne, Vijay Gurbani, Paul Kyzivat, Jonathan Rosenberg, 22-Mar-04, The Rich Presence Information Data Format (RPID) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the presentity is doing (the activity element), a grouping identifier for a tuple (the class element), the type of tuple (the contact-type element), whether a contact is idle (the idle element), the typle of place a presentity is in (the placetype element), whether the presentity is in a public or private space (the privacy element), the relationship of a tuple to another presentity (the relationship element), and the overall role of the presentity (the sphere element). "Partial Notification of Presence Information", Mikko Lonnfors, Jose Costa-Requena, Eva Leppanen, Hisham Khartabil, 20-Apr-04, A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Limitations can also be caused by the interface between the terminal and the network, i.e. radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial notification. "Presence Information Data format (PIDF) Extension for Partial Presence", Mikko Lonnfors, Eva Leppanen, Hisham Khartabil, 20-Apr-04, The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. "Functional Description of Event Notification Filtering", Hisham Khartabil, 23-Jun-04, The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", Hisham Khartabil, 25-Jun-04, The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. "User agent capability presence status extension", Mikko Lonnfors, Krisztian Kiss, 10-May-04, Interoperation of Instant Messaging and Presence systems has been defined in the IMPP working group. The IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. However, these base formats might need standardized extensions in order to enable building rational applications using presence and instant messaging. This memo proposes an extension to represent 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)' capabilities in the Presence Information Document Format (PIDF) compliant presence documents. "CIPID: Contact Information in Presence Information Data Format", Henning Schulzrinne, 14-Jul-04, The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. "Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals", Henning Schulzrinne, 14-Jul-04, The timed presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time interval fully in the future or the past. "Indication of Message Composition for Instant Messaging", Henning Schulzrinne, 2-Jun-04, In instant messaging (IM) systems, it is useful to know during an IM conversation that the other party is composing a message, e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. "Presence Authorization Rules", Jonathan Rosenberg, 4-May-04, Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", Markus Isomaki, 24-Jun-04, This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is mainly intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs based on which it builds the overall presence state for the presentity. "Relay Extensions for Message Sessions Relay Protocol (MSRP)", Cullen Jennings, Rohan Mahy, 21-Jul-04, The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-mode messages stand alone, whereas Session-mode messages are setup as part of a session using the SIP protocol. MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time, peer-to-peer exchange of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. Session Initiation Protocol (sip) --------------------------------- "Session Timers in the Session Initiation Protocol (SIP)", Steve Donovan, Jonathan Rosenberg, 19-May-04, This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new header fields, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. "Caller Preferences for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, Henning Schulzrinne, Paul Kyzivat, 23-Oct-03, This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining four new request headers, Accept-Contact, Reject- Contact, Require-Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the capabilities and characteristics of a UA. "Management Information Base for Session Initiation Protocol (SIP)", Kevin Lingle, Joon Maeng, Jean-Francois Mule, Dave Walker, 20-Jul-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Jul-04, The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. "The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol", Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, 20-Nov-03, This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. "The Session Inititation Protocol (SIP) 'Replaces' Header", Billy Biggs, Rick Dean, Rohan Mahy, 18-Feb-04, This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Call Pickup'. Note that definition of these example features is non-normative. "The SIP Referred-By Mechanism", Robert Sparks, 23-Mar-04, The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. "Compressing the Session Initiation Protocol", Gonzalo Camarillo, 4-Nov-02, This document describes a mechanism to signal that compression is desired for one or more SIP messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", Sean Olson, 20-Jul-04, This document proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. "The Session Inititation Protocol (SIP) 'Join' Header", Rohan Mahy, Dan Petrie, 18-Feb-04, This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Barge-In', answering-machine-style 'Message Screening' and 'Call Center Monitoring'. Note that definition of these example features is non- normative. "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Jon Peterson, 17-May-04, The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests and responses, especially in an interdomain context. This document recommends practices and conventions for identifying end users in SIP messages, and proposes a way to distribute cryptographically secure authenticated identities. "SIP Authenticated Identity Body (AIB) Format", Jon Peterson, 6-May-04, RFC3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. "An Extension to the Session Initiation Protocol for Request History Information", Mary Barnes, 14-Jul-04, This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, Histinfo, to be included in the Supported header, is defined to allow UAs to indicate whether the History-Info should be returned in responses to a request which has captured the history information. A new priv-value, history, is added to the Privacy header to allow for privacy handling of the History-Info header. "Communications Resource Priority for the Session Initiation Protocol (SIP)", Henning Schulzrinne, James Polk, 22-Mar-04, This document defines two new SIP header fields for communications resource priority, namely 'Resource-Priority' and 'Accept-Resource- Priority'. The Resource-Priority header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 6-Jan-04, This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents. These capabilities are conveyed as parameters of the Contact header field. "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, 21-Jul-04, When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. "The Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 17-Jun-04, This document creates an IANA registry for SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 17-Jun-04, This document creates an IANA registry for SIP header field parameters. It also lists the already existing parameters to be used as initial values for that registry. "An Event State Publication Extension to the Session Initiation Protocol (SIP)", Aki Niemi, 28-May-04, This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. "Interactions of Preconditions with Session Mobility in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 19-Jul-04, This document updates the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 6-Jul-04, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server, and for communicating a GRUU to a peer within a dialog. "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 21-Jun-04, This document describes how to use the ANAT semantics of the SDP grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions using ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Session Initiation Protocol Service Examples", Alan Johnston, Robert Sparks, 21-Jul-04, This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join headers. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", Rohan Mahy, 15-Dec-03, This draft proposes a SIP event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, Henning Schulzrinne, 18-Feb-04, This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user, an receive notifications about the changes in state of INVITE initiated dialogs that the user is involved in. "A Session Initiation Protocol (SIP) Event Package for Conference State", Jonathan Rosenberg, Henning Schulzrinne, 21-Jul-04, This document defines a conference event package for the Session Initiation Protocol (SIP) Events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference URI. Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. "Session Initiation Protocol Torture Test Messages", Robert Sparks, 15-Jul-04, This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and 'torture' a parser. "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, 11-Oct-02, The 3rd Generation Partnership Project (3GPP) has selected SIP [2]as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of the Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements to establish a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document we express the requirements identified by 3GPP to support SIP for the Release 5 of the 3GPP IMS in cellular networks. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, Alan Johnston, 17-Feb-04, This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). This work is part of the SIP Multiparty Call Control Framework. "Interworking between SIP and QSIG", John Elwell, 19-Jan-04, This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. "A Framework for Session Initiation Protocol User Agent Profile Delivery", Dan Petrie, 21-Jul-04, This document defines the application of a set of protocols for providing profile data to SIP user agents. The objective is to define a means for automatically providing profile data a user agent needs to be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent profile data is defined here. As part of this framework a new SIP event package is defined here for the notification of profile changes. This framework is also intended to ease ongoing administration and upgrading of large scale deployments of SIP user agents. The contents and format of the profile data to be defined is outside the scope of this document. "Session Initiation Protocol Call Control - Conferencing for User Agents", Alan Johnston, Orit Levin, 20-Jul-04, This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. A SIP option tag for conference-aware UAs is defined. "A Framework for Conferencing with the Session Initiation Protocol", Jonathan Rosenberg, 30-Jun-04, The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. "Requirements for Session Policy for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Jul-04, The proxy server plays a central role as an intermediary in the establishment of sessions in the Session Initiation Protocol (SIP). In that role, they can define and impact policies on call routing, rendezvous, and other call features. However, there is no standard means by which proxies can have any influence on session policies, such as the codecs that are to be used. As such, ad-hoc and non-conformant techniques have been deployed to allow for such policy mechanisms. There is a need for a standards-based and complete mechanism for session policies. This document defines a set of requirements for such a mechanism. "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension", Jonathan Rosenberg, Paul Kyzivat, 20-Jul-04, This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It motivates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the matching algorithm. "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Eric Burger, 19-Jul-04, The Key Press Stimulus Event Package is a component of the Applications Interaction Framework for the Session Initiation Protocol (SIP). The event package defines a Key Press Markup Language (KPML) that describes filter specifications for reporting key presses entered at a presentation-free user interface SIP User Agent (UA). The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). This capability allows an Application Server service provider to monitor (filter) for a set of DTMF patterns at a SIP User Agent, either at an end user device or a gateway. The capability eliminates the need for hairpinning through a Media Server or duplicating all the DTMF events, when an Application Server needs to trigger mid-call service processing on DTMF digit patterns. "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Henning Schulzrinne, 2-Jun-04, This document describes how to manage early media in SIP using two models; the gateway model and the application server model. It also describes the inputs one needs to consider to define local policies for ringing tone generation. "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 22-Jul-04, This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. "Requirements for End-to-middle Security for the Session Initiation Protocol (SIP)", Kumiko Ono, Shinya Tachimoto, 6-Jul-04, A SIP User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/ or headers from intermediaries except those that provide services based on its content. This situation requires a mechanism called 'end-to-middle security' to secure information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 17-Jun-04, This document defines a new disposition type (early-session) for the Content-Disposition header field in SIP. The treatment of 'early-session' bodies is similar to the treatment of 'session' bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is 'early-session' are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. "Extending the Session Initiation Protocol Reason Header for Preemption Events", James Polk, 19-Jul-04, This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to include in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network using RSVP. This document does not attempt to address routers failing in the packet path; but a deliberate event of tearing down a flow between UAs, and informing the terminated UA(s) with an indication of what occurred. "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", Gonzalo Camarillo, 7-Jun-04, This document describes how to invoke transcoding services using SIP and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "Framework for Transcoding with the Session Initiation Protocol", Gonzalo Camarillo, 7-Feb-04, This document defines a framework for transcoding with SIP. This framework includes how to discover the need of transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed; the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "Emergency Services URI for the Session Initiation Protocol", Henning Schulzrinne, 10-Feb-04, As part of an overall architecture for supporting emergency calling for the Session Initiation Protocol (SIP), this document defines universal emergency SIP URIs, sip:sos@domain and sips:sos@domain, that allows SIP user agents to contact the local emergency call center. It also defines conventions that increase the high probability of reaching the appropriate emergency call center. The document does not define any SIP protocol extensions. "Requirements for Session Initiation Protocol Location Conveyance", James Polk, 19-Jul-04, This document presents the framework and requirements for usage of the Session Initiation Protocol (SIP) [RFC 3261] to convey user location information from a Session Initiation Protocol (SIP) user agent to another SIP entity. We consider cases where location information is conveyed from end to end, as well as cases where message routing by intermediaries is influenced by the location of the session initiator. We offer a set of solutions to the requirements, based on the scenario(s) being addressed. "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", Jon Peterson, 12-Feb-04, This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol. While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. "Profile Data for Session Initiation Protocol (SIP) Policies", Volker Hilt, 12-Jul-04, This draft specifies an XML schema for profile data for SIP session policies. This schema can be used within the user agent profile devliery framework to implement session-independent SIP session policies. "Requirements and Framework for Session Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List Services", Gonzalo Camarillo, 13-Jul-04, This document describes the need for SIP URI-List Services and provides requirements for their invocation. Additionaly, it defines a framework which includes all the SIP extensions needed to meet these requirements. "Message-Contained URI-Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Adam Roach, 13-Jul-04, This document describes how a user agent can provide another user agent with a list of URIs in a SIP message. The way the receiving user agent uses the URIs in the list is method or status code specific. "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Alan Johnston, 13-Jul-04, This document describes how to create a conference using SIP URI-list services. In particular, we describe a mechanism that allows a client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Gonzalo Camarillo, 13-Jul-04, This document specifies how to request a SIP URI-list service to send a copy of a MESSAGE to a set of destinations. The client sends a SIP MESSAGE request with a URI-list to the URI-list service, which sends a similar MESSAGE request to each of the URIs included in the list. "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Adam Roach, 13-Jul-04, This document describes how to create subscriptions to request-contained resource lists in SIP. This is done by having the SUBSCRIBE request that requests the creation of the subscription carry a URI list. "Refering to Multiple Resources in the Session Initiation Protocol (SIP)", , 13-Jul-04, This document defines extensions to the SIP REFER method so that this method can be used to refer servers to multiple resources. These extensions include the use of pointers to URI-lists in the Refer-To header field and the multiple-refer SIP option-tag. S/MIME Mail Security (smime) ---------------------------- "Examples of S/MIME Messages", Paul Hoffman, 19-Jul-04, This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. "CMS Symmetric Key Management and Distribution", Sean Turner, 14-Jan-03, This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). "Transporting S/MIME Objects in X.400", Paul Hoffman, Chistopher Bonatti, 8-Aug-03, This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. "Securing X.400 Content with S/MIME", Paul Hoffman, Chistopher Bonatti, Anders Eggen, 15-Aug-03, This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. "Use of the PSS Signature Algorithm in CMS", Jim Schaad, 19-Dec-03, This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS). "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS)", Serguei Leontiev, 1-Apr-04, This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption arbitrary message contents. "Use of the SEED Encryption Algorithm in CMS", Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee, 21-Apr-04, This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). Configuration Management with SNMP (snmpconf) --------------------------------------------- "Policy Based Management MIB", Steven Waldbusser, Jon Saperia, Thippanna Hongal, 21-May-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of SNMP infrastructures as well as a scripting language and a script execution environment. Speech Services Control (speechsc) ---------------------------------- "Requirements for Distributed Control of ASR, SI/SV and TTS Resources", David Oran, 29-Jan-04, This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to-speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. "Media Resource Control Protocol Version 2(MRCPv2)", Saravanan Shanmugham, 22-Jul-04, This document describes a proposal for a Media Resource Control Protocol Version 2 (MRCPv2) and aims to meet the requirements specified in the SPEECHSC working group requirements document. It is based on the Media Resource Control Protocol (MRCP), also called MRCPv1 developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks Inc. The MRCPv2 protocol will control media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers etc. over a network. This protocol depends on a session management protocol such as the Session Initiation Protocol (SIP) to establish a separate MRCPv2 control session between the client and the server. It also depends on SIP to establish the media pipe and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange can happen over the control session established above allowing the client to command and control the media processing resources that may exist on the media server. Service in the PSTN/IN Requesting InTernet Service (spirits) ------------------------------------------------------------ "The SPIRITS (Services in PSTN requesting Internet services) Protocol", Vijay Gurbani, Igor Faynberg, 26-Mar-04, This document describes SPIRITS protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting, Internet Caller-ID Delivery, are examples of SPIRITS services; as are location-based services on the cellular network. The protocol is to define the building blocks from which many other services can be built. Source-Specific Multicast (ssm) ------------------------------- "Source-Specific Multicast for IP", Hugh Holbrook, Bradley Cain, 19-Jul-04, IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. It defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. Secure Network Time Protocol (stime) ------------------------------------ "Public-Key Cryptography for the Network Time Protocol Version 2", David Mills, 5-Nov-02, This document describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. its design is based on the premiss that IPSEC schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, PKI schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping function and authentication function in ways not yet considered by the IETF. This Document includes the Autokey requirements analysis, design principles and protocol specification. A detailed description of the protocol states, events and transition functions is included. A prototype of the Autokey design based on this document has been implemented, tested and documented in the NTP Version 4 (NTPv4) software distribution for Unix, Windows and VMS at http://www.ntp.org. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "The syslog Protocol and Signed syslog Messages", John Kelsey, Jon Callas, 19-Mar-04, This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. "Syslog MIB", Glenn Keeni, Bruno Pape, 18-Feb-04, This memo provides a MIB module that can be used to monitor and manage syslog processes. It defines objects that allow the collection of information related to syslog processes, it also defines objects that can be used to monitor and/or control syslog processes. "The syslog Protocol", Rainer Gerhards, 15-Jul-04, This document describes the syslog protocol. The syslog protocol has been used throughout the years to convey event notifications. This documents describes a layered architecture for an easily extensible syslog protocol. It also describes the basic message format and structured elements used to provide meta-information about the message. "Transmission of syslog messages over UDP", Anton Okmianski, 12-May-04, This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. While several transport mappings are envisioned for the syslog protocol, syslog protocol implementors are required to support the transport mapping described in this document. This transport specification overcomes limitations of UDP/IP datagram size by introducing support for fragmentation of large messages. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Improving the robustness of TCP to Non-Congestion Events.", Sumitha Bhandarkar, A. L. Narasimha Reddy, 15-Jul-04, This document proposes TCP-DCR, a simple modification to the TCP congestion control algorithm to make it more robust to non-congestion events. In the absence of explicit notification from the network, the TCP congestion control algorithm treats the receipt of three duplicate acknowledgements as an indication of congestion in the network. This is not always correct, notably so in wireless networks with channel errors or networks prone to excessive packet reordering, resulting in degraded performance. TCP-DCR aims to remedy this by delaying the congestion response of TCP for a short interval of time tau, thereby creating room to handle any non-congestion events that may have occurred. If at the end of the delay tau, the event is not handled, then it is treated as a congestion loss. The modifications themselves do not handle the non-congestion event, but rather rely on some underlying mechanism to do this. This document discusses the implications of delaying congestion response on the fairness, TCP- compatibility and network dynamics, and the benefits to be gained by applying the TCP-DCR modifications to TCP. "Transmission Control Protocol security considerations", Randall Stewart, 10-Jun-04, TCP (RFC793 [1]) is widely deployed and one of the most often used reliable end to end protocols for data communication. Yet when it was defined over 20 years ago the internet, as we know it, was a different place lacking many of the threats that are now common. Recently several rather serious threats have been detailed that can pose new methods for both denial of service and possibly data injection by blind attackers. This document details those threats and also proposes some small changes to the way TCP handles inbound segments that either eliminate the threats or at least minimize them to a more acceptable level. "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Pasi Sarolahti, 14-Jul-04, Spurious retransmission timeouts cause suboptimal TCP performance, because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm at a TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious and to decide whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in case of a spurious timeout. The F-RTO algorithm can also be applied to SCTP. Internet Traffic Engineering (tewg) ----------------------------------- "A Traffic Engineering MIB", Kireeti Kompella, 6-Feb-04, 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 Traffic Engineered Tunnels, for example, Multi-Protocol Label Switched Paths. "Protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering", Francois Le Faucheur, 17-Mar-04, This document specifies the protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantic of a number of IGP extensions already defined for existing MPLS Traffic Engineering in RFC3630 and RFC-TBD as well as additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC3209 for existing MPLS Traffic Engineering. These extensions address the Requirements for DS-TE spelt out in RFC3564. "Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, 24-Mar-04, This document provides specification for one Bandwidth Constraints model for Diff-Serv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", Jerry Ash, 23-Jan-04, This document complements the DiffServ-aware MPLS TE (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. "MPLS Inter-AS Traffic Engineering requirements", Raymond Zhang, JP Vasseur, 17-Jun-04, This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). The main objective of this document is to present a set of requirements which would result in a set of general guidelines in the definition, selection and specification development for any technical solution(s) meeting these requirements. "Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", Francois Le Faucheur, Wai Lai, 24-Mar-04, This document provides specification for one Bandwidth Constraints model for Diff-Serv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. "Requirements for Inter-area MPLS Traffic Engineering", Jean-Louis Le Roux, 23-Jun-04, This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS-TE satisfy these requirements. Transport Layer Security (tls) ------------------------------ "ECC Cipher Suites For TLS", Vipul Gupta, 20-May-04, This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. "Addition of Camellia Ciphersuites to Transport Layer Security (TLS)", Shino Moriai, 18-Feb-04, This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. "Using SRP for TLS Authentication", Dave Taylor, 8-Jun-04, This memo presents a technique for using the SRP (Secure Remote Password) protocol ([SRP], [SRP-6]) as an authentication method for the TLS (Transport Layer Security) protocol [TLS]. "Using OpenPGP keys for TLS authentication", Nikos Mavroyanopoulos, 2-Apr-04, This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. "The TLS Protocol Version 1.1", Tim Dierks, Eric Rescorla, 19-Jul-04, This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", , 4-Jun-04, This document specifies new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties, and do not require any public key operations. Internet Open Trading Protocol (trade) -------------------------------------- "Payment API for v1.0 Internet Open Trading Protocol (IOTP)", Werner Hans, Hans Beykirch, Yoshiaki Kawatsura, Masaaki Hiroya, 25-Mar-04, The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. "XML Voucher: Generic Voucher Language", Ko Fujimura, Masayuki Terada, 16-Feb-04, This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide-range of electronic-values, including coupons, tickets, loyalty points, and gift certificates, which are often necessary to process in the course of payment and/or delivery transactions. "Electronic Commerce Modeling Language (ECML):Version 2 Specification", Donald Eastlake, 9-Jun-04, Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically organized payment related information field names in an XML syntax are defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meeting the requirements of RFC 3505. "Voucher Trading System Application Programming Interface (VTS-API)", Masayuki Terada, Ko Fujimura, 18-Feb-04, This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system to securely transfer vouchers, e.g., coupons, tickets, loyalty points, and gift certificates; this process is often necessary in the course of payment and/or delivery transactions. Transport Area Working Group (tsvwg) ------------------------------------ "Robust ECN Signaling with Nonces", David Wetherall, Neil Spring, David Ely, 4-Nov-02, This note describes the ECN-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECT codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Randall Stewart, 10-Jun-04, This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, 2-Apr-04, This document describes a mapping of the Stream Control Transmission Protocol SCTP RFC2960 [8] into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. "TCP Extended Statistics MIB", Matt Mathis, Jeremy Heffner, 19-Jul-04, This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. "The Eifel Response Algorithm for TCP", Reiner Ludwig, Andrei Gurtov, 18-Mar-04, Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts, and can avoid - depending on the detection algorithm - the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Pasi Sarolahti, 17-Feb-04, Spurious retransmission timeouts (RTOs) cause suboptimal TCP performance, because they often result in unnecessary retransmission of the last window of data. This document describes the 'Forward RTO Recovery' (F-RTO) algorithm for detecting spurious TCP RTOs. F-RTO is a TCP sender only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by an RTO, the F-RTO algorithm at a TCP sender monitors the incoming acknowledgements to determine whether the timeout was spurious and to decide whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in case of a spurious timeout. The F-RTO algorithm can also be applied with the SCTP protocol. Usenet Article Standard Update (usefor) --------------------------------------- "News Article Format and Transmission", Charles Lindsey, 17-May-04, This Draft is intended as a standards track document, obsoleting RFC 1036, which itself dates from 1987. This Standard defines the format of Netnews articles and specifies the requirements to be met by software which originates, distributes, stores and displays them. Since the 1980s, Usenet has grown explosively, and many Internet and non-Internet sites now participate. In addition, the Netnews technology is now in widespread use for other purposes. Backward compatibility has been a major goal of this endeavour, but where this standard and earlier documents or practices conflict, this standard should be followed. In most such cases, current practice is already compatible with these changes. "Usenet Best Practice", Charles Lindsey, 3-Jun-04, This Draft is intended to become a "Best Current Practice" RFC. Its purpose is to set out how software should behave and conventions which users should observe, in order that Netnews in general, and Usenet in particular, should provide the most effective service to its users. "News Article Format", Charles Lindsey, 12-Jul-04, This document defines the format of network news articles. Network news articles resemble mail messages but are broadcast to potentially large audiences, using a flooding algorithm that propagates one copy to each interested host (or group thereof), typically stores only one copy per host, and does not require any central administration or systematic registration of interested users. Network news originated as the medium of communication for Usenet, circa 1980. Since then Usenet has grown explosively, and many Internet sites participate in it. In addition, the news technology is now in widespread use for other purposes, on the Internet and elsewhere. IPv6 Operations (v6ops) ----------------------- "Analysis on IPv6 Transition in 3GPP Networks", Juha Wiljakka, 25-May-04, This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. "Basic Transition Mechanisms for IPv6 Hosts and Routers", Erik Nordmark, Robert Gilligan, 22-Jul-04, This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. "Evaluation of Transition Mechanisms for Unmanaged Networks", Christian Huitema, 3-Jun-04, In a companion paper we defined the "unmanaged networks", which typically correspond to home networks or small office networks, and the requirements for transition mechanisms in various scenarios of transition to IPv6. We start from this analysis and evaluate here the suitability of mechanisms that have already been specified, proposed or deployed. "Security Considerations for 6to4", Pekka Savola, 20-Jul-04, The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routers and Relay Routers, which accept and decapsulate IPv4 protocol-41 ('IPv6-in-IPv4') traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. "IPv6 Enterprise Network Scenarios", Jim Bound, 19-Jul-04, This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. "Issues with Dual Stack IPv6 on by Default", Sebastien Roy, Alain Durand, James Paugh, 20-Jul-04, This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network insecurity. The purpose of this memo is to raise awareness of these problems so that they can be fixed or worked around, not to try to specify whether IPv6 should be enabled by default or not. "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Sebastien Roy, Alain Durand, James Paugh, 11-May-04, This document describes a change to the IPv6 Neighbor Discovery conceptual host sending algorithm. According to the algorithm, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. "Scenarios and Analysis for Introducing IPv6 into ISP Networks", Mikael Lind, Vladimir Ksinant, Soohong Park, Alain Baudot, Pekka Savola, 18-Jun-04, This document first describes different scenarios for the introduction of IPv6 into an existing IPv4 ISP network without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the suitability of the already defined transition mechanisms in this context. Known challenges are also identified. "Application Aspects of IPv6 Transition", Myung-Ki Shin, 24-Jun-04, As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and what is the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. "Procedures for Renumbering an IPv6 Network without a Flag Day", Fred Baker, Eliot Lear, Ralph Droms, 9-Jul-04, This document describes the steps in a procedure that can be used to transition from the use of an existing prefix to a new prefix in a network. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a make-before-break transition, as well as addressing naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. "Requirements for assisted tunneling", , 28-Jun-04, This document defines requirements for a tunnel set-up protocol that could be used by an ISP to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity without having to upgrade its access network. Voice Profile for Internet Mail (vpim) -------------------------------------- "Internet Voice Messaging", Stuart McRae, Glenn Parsons, 17-Jun-04, This document provides for the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure. The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2, but rather an alternative specification for a different application. "Voice Message Routing Service", Gregory Vaudreuil, 13-Jul-04, Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list "Voice Messaging Directory Service", Gregory Vaudreuil, 13-Jul-04, This document provides details of the VPIM directory service. The service provides the email address of the recipient given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient. Please send comments on this document to the VPIM working group mailing list Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Virtual Router Redundancy Protocol for IPv6", Robert Hinden, 16-Feb-04, This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address associated with a virtual router is called the Master, and forwards packets sent to this IP address. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discovery [ND] mechanisms. "Definitions of Managed Objects for the VRRPv2 and VRRpv3", Kalyan Tata, 17-Jun-04, This specification defines a Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol for both IPv4 and IPv6 as defined in RFC 3768 and RFC xxxx ( RFC-editor, this is currently draft-ietf-vrrp-ipv6-spec-06.txt ). This memo obsoletes RFC 2787. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources", Jim Whitehead, 5-Apr-04, This specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/ 1.1 302 (Found) status code, redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org [1], which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org [2]. Discussions of the WEBDAV working group are archived at URL: http:// lists.w3.org/Archives/Public/w3c-dist-auth/. "HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis", Lisa Dusseault, John Crawford, 19-Jul-04, WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience. "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, John Crawford, 2-Jul-04, This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. "Quota and Size Properties for DAV Collections", Brian Korver, Lisa Dusseault, Claudia Warner, 19-Jul-04, WebDAV servers are frequently deployed with quota (size) limitations. This Internet-Draft discusses the properties and minor behaviors needed for clients to interoperate with quota implementations on WebDAV repositories. Centralized Conferencing (xcon) ------------------------------- "Requirements for Conference Policy Control Protocol", Petri Koskelainen, Hisham Khartabil, 26-Apr-04, The conference policy server allows clients to manipulate and interact with the conference policy. One mechanism to manipulate the policy is to use conference policy control protocol (CPCP). This document gives the requirements for CPCP. "Conferencing Scenarios", Roni Even, 19-Jul-04, This document describes multimedia conferencing scenarios. It describes both basic and advance conferencing scenarios involving voice, video, text and interactive text sessions. These conferencing scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. "Requirements for Floor Control Protocol", Henning Schulzrinne, 21-Jul-04, Floor control is a means to manage joint or exclusive access to shared resource in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. "The Conference Policy Control Protocol (CPCP)", Hisham Khartabil, Petri Koskelainen, 20-Jul-04, This document describes the Conference Policy Control Protocol (CPCP). It specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy data elements that enable a user to define a conference policy. It also defines an XML Configuration Access Protocol (XCAP) application usage that is needed to store and manipulate a conference policy. "The Binary Floor Control Protocol (BFCP)", , 13-Jul-04, This document specicies the Binary Floor Control Protocol (BFCP). BFCP is used between conference participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", Peter Saint-Andre, 13-Apr-04, This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. "Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, 10-May-04, This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. "End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 14-Jul-04, This document defines a method for end-to-end object signing and encryption in the Extensible Messaging and Presence Protocol (XMPP). "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", Peter Saint-Andre, 4-May-04, This document describes a mapping of the Extensible Messaging and Presence Protocol (XMPP) to the Common Presence and Instant Messaging (CPIM) specifications. Zero Configuration Networking (zeroconf) ---------------------------------------- "Dynamic Configuration of Link-Local IPv4 Addresses", Bernard Aboba, 13-Jul-04, To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a DHCP server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.