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) -------------------------------------------------- "Diameter Mobile IPv4 Application", Pat Calhoun, Tony Johansson, Charles Perkins, Tom Hiller, 10-Aug-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, 26-Jul-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, 13-Aug-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, 13-Aug-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, 22-Oct-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. "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, 18-Oct-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, Rajesh Abbi, 15-Oct-04, This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (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 document obsoletes RFC 3276. AToM MIB (atommib) ------------------ "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, 21-Oct-04, This document specifies Atom, an XML-based Web content and metadata syndication format. "The Atom Publishing Protocol", Joe Gregorio, 8-Oct-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-02.txt). "Atom Feed Autodiscovery", Mark Pilgrim, 18-Aug-04, This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the element. Audio/Video Transport (avt) --------------------------- "Tunneling Multiplexed Compressed RTP ('TCRTP')", B Thompson, Tmima Koren, Dan Wing, 13-Sep-04, 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. "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. "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams", Guenther Liebl, 26-Oct-04, This document specifies an efficient way to ensure erasure- resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon (RS) codes together with interleaving. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Furthermore, protection of non-progressive multimedia streams is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By applying interleaving and RS codes a payload format is defined, which can be easily integrated into the existing framework for RTP. "Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)", Joerg Ott, Stephan Wenger, 11-Aug-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, 27-Oct-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, 27-Oct-04, This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, JPEG 2000. JPEG 2000 features are considered and there are provisions in this payload format for scalability, prioritization of different parts of the codestream, and error recovery. JPEG 2000 is a truly scalable compression technology allowing applications to encode one way and decode many different ways. Extending from one image to a series of JPEG 2000 images, one has a JPEG 2000 video stream. "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", Henning Schulzrinne, Scott Petrack, 22-Oct-04, This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. This memo preserves the content standardized by RFC 2833, but clarifies its use through reorganization of the text, addition of tutorial content, and addition of normative text describing the detailed application of the content. "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, 6-Oct-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. (This document updates RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices.) "RTP payload Format for H.264 Video", Stephan Wenger, 19-Aug-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, 7-Oct-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, 8-Oct-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. "RTP Payload for Text Conversation", Gunnar Hellstrom, 30-Aug-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. "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, 20-Sep-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, 20-Sep-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, 8-Oct-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, 25-Aug-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 Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec", Sassan Ahmadi, 18-Oct-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. A MIME type registration is included for VMR-WB RTP payload 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, 1-Oct-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, 26-Oct-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 an equation based congestion control scheme for unicast flows operating in a best effort Internet environment. This profile provides RTP flows with the mechanism to use congestion control in best effort IP networks. "RTP Payload Format for BroadVoice Speech Codecs", Juin-Hwey Chen, 26-Aug-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. "RTP Payload Format for ATRAC Family", Matthew Romaine, 21-Oct-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. "RTP Payload for Text Conversation interleaved in an audio stream", Gunnar Hellstrom, 30-Aug-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. "RTP Payload Format for H.263 using RFC2190 to Historic status", Roni Even, 15-Sep-04, The first RFC that describes RTP payload format for H.263 is RFC2190. This specification discusses why to move this RFC to historic status. "Proposed RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base", Alan Clark, 12-Oct-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). "Storage File Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec", Sassan Ahmadi, 18-Oct-04, This document specifies a file format for the storage of variable-rate multimode wideband (VMR-WB) speech codec. A MIME type registration is included for VMR-WB files. 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 retrieval of VMR-WB stored data (generated in the interoperable mode) by AMR-WB decoder. "RTP Timestamp Frequency for Variable Rate Audio Codecs", Stephan Wenger, Colin Perkins, 19-Oct-04, This memo discusses the problems of audio codecs with variable external sampling rates. Historically, for audio codecs, the RTP timestamp frequency was chosen to match the sampling rate of the audio codec. However, this choice is nowadays more difficult to justify, because of the advent of audio codecs (and, even more important, practical use cases) that support multiple sample rates and the switch between the sample rates during the lifetime of an RTP session. This Internet draft addresses the problem by suggesting that RTP Payload RFCs for such codecs to utilize a single, high, unified RTP timestamp frequency. "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", Johan Sjoberg, 19-Oct-04, This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Simple Traversal of UDP Through Network Address Translators (NAT) (STUN)", Jonathan Rosenberg, 18-Oct-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. "NAT Behavioral Requirements for Unicast UDP", Francois Audet, Cullen Jennings, 18-Oct-04, This document defines basic terminology for describing different types of behavior for NATs when handling unicast UDP. It also defines a set of requirements for NATs that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that applications will function properly. 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. Benchmarking Methodology (bmwg) ------------------------------- "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. "Methodology for Forwarding Information Base (FIB) based Router Performance", Guy Trotter, 4-Nov-04, The forwarding performance of an IP router is highly dependent on the information in its forwarding information base. This document describes the methodology to be used to determine the IP packet forwarding performance of an IP router as a function of the routers ability to properly form and optimize its forwarding information base. "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 OSPF 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, 25-Oct-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, 25-Oct-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]. "Considerations for Benchmarking IGP Data Plane Route Convergence", Scott Poretsky, 25-Oct-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, 26-Oct-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, 26-Oct-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", David Newman, Timmons Player, 22-Oct-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, 27-Oct-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 The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", Ernest Bell, Vivian Ngai, 21-Sep-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]. 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, 8-Sep-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, 27-Aug-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. Common Control and Measurement Plane (ccamp) -------------------------------------------- "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, 9-Sep-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, 1-Oct-04, GMPLS consists of a suite of protocol extensions to MPLS to make these protocols more generally applicable, to include - for example - control of non-packet based switching, and particularly, optical switching. One area of prime consideration is to use Generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are directed towards controlling SDH/SONET networks. SDH/SONET 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 GMPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to GMPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. "Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", Dimitri Papadimitriou, 27-Sep-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, 8-Oct-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, 8-Oct-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 Switching Router (LSR) Management Information Base", Thomas Nadeau, 8-Oct-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 Generalized Multi-Protocol Label Switching (GMPLS)", Eric Mannie, Dimitri Papadimitriou, 4-Oct-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. "Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", George Swallow, John Drake, Hirokazu Ishimatsu, Yakov Rekhter, 15-Oct-04, Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching 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, 4-Oct-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, 13-Oct-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 Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", Jonathan Lang, Bala Rajagopalan, 4-Oct-04, This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (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)", Deborah Brungard, 13-Oct-04, The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (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, 8-Oct-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, 31-Aug-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 is a clarification to the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. "GMPLS - Communication of Alarm Information", Lou Berger, 21-Sep-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, 27-Oct-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, 25-Aug-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 including tunnels that support the traced path. "Node ID based RSVP Hello: A Clarification Statement", Zafar Ali, 26-Oct-04, performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. "GMPLS Based Segment Recovery", Lou Berger, 26-Oct-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. This document also updates the handling of Notify_Request objects specified in [RFC3473]. "A Framework for Inter-Domain MPLS Traffic Engineering", Adrian Farrel, 20-Aug-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. "Reoptimization of MPLS Traffic Engineering loosely routed LSP", , 1-Sep-04, This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS 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). "A Transport Network View of LMP", Don Fedyk, 17-Sep-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. "Extensions to GMPLS RSVP Graceful Restart", Arun Satyanarayana, Reshad Rahman, 11-Oct-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. 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, 22-Oct-04, This document describes an IRIS registry schema for IP address and Autonomous System Number 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. "A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS)", Andrew Newton, 8-Oct-04, This document describes a lightweight domain availability service using the IRIS framework and the data model of the IRIS Domain Registry service. "A Lightweight UDP Transport for the the Internet Registry Information Service", Andrew Newton, 8-Oct-04, This document describes a lightweight UDP transport for the Internet Registry Information Service (IRIS). Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control", Sally Floyd, Eddie Kohler, 28-Oct-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, 28-Oct-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, 28-Oct-04, The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data, but can benefit from control over the tradeoff between timeliness and reliability. "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, 12-Oct-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. "DHCP VPN Information option", Richard Johnson, Kenneth Kinnear, Mark Stapp, Jay Kumarasamy, 4-Oct-04, This memo defines a new DHCP option for passing VPN information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in situations where VPN information needs to be passed to the DHCP server for proper address allocation to take place. "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option", Ralph Droms, John Schnizlein, 8-Sep-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. "The IPv4 DHCP Options for the Internet Storage Name Service", Charles Monia, Josh Tseng, Kevin Gibbons, 9-Nov-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, 11-Aug-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 Subscriber ID Suboption for the DHCP Relay Agent Option", Richard Johnson, Theyn Palaniappan, Mark Stapp, 7-Sep-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. "DHCP Server-ID Override Suboption", Richard Johnson, 4-Oct-04, This memo defines a new suboption of the DHCP relay information option [6] which allows the DHCP relay to specify a new value for the Server-ID option, which is inserted by the DHCP Server. In some cases it is convenient for the DHCP relay to act as the actual DHCP server such that DHCP RENEWAL requests will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on RENEWAL messages. This new relay agent suboption allows the relay to tell the DHCP server what value to use in the Server-ID option [3]. If this suboption is not present, the server should build the Server-ID option in the normal fashion. "Subnet Allocation using DHCP", Richard Johnson, 27-Sep-04, This document defines a new DHCP option which is passed between the DHCP Client to the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. "Detection of Network Attachment (DNA) in IPv4", Bernard Aboba, 18-Oct-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). "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, 26-Oct-04, This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (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. "DHCP Option for Proxy Server Configuration", Senthil Balasubramanian, 21-Oct-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). "DHCP: IPv4 and IPv6 Dual-Stack Issues", Tim Chown, 28-Oct-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, 9-Sep-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, 28-Oct-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. "Vendor-Specific Information Suboption for the DHCP Relay Agent Option", Mark Stapp, 10-Sep-04, This memo defines a new Vendor-Specific Information 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. "The DHCPv6 Client FQDN Option", Bernie Volz, 24-Sep-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. "Clarifications on DHCPv6 Authentication", Tatsuya Jinmei, 18-Oct-04, This document describes issues about the authentication mechanism of the Dynamic Host Configuration Protocol for IP version 6 that were identified from implementation experiences. It also tries to propose resolutions to some of the issues. Distributed Management (disman) ------------------------------- "Event MIB", Ramanathan Kavasseri, Bob Stewart, 23-Sep-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 that can be used to manage and monitor MIB objects and take action through events. "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", Juergen Quittek, Kenneth White, 21-Oct-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, 13-Oct-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. During link identity detection, 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 Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure and of limited signaling. "Link-layer Event Notifications for Detecting Network Attachments", Alper Yegin, 24-Sep-04, Certain network access technologies are capable of providing various link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This draft provides a non-exhaustive catalogue of information available from well-known access technologies. 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, 21-Oct-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. "DSA Keying and Signature Information in the DNS", Donald Eastlake, 12-Aug-04, The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. "Storage of Diffie-Hellman Keying Information in the DNS", Donald Eastlake, 11-Aug-04, The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. "DNS Security Introduction and Requirements", Roy Arends, Rob Austein, Dan Massey, Matt Larson, Scott Rose, 11-Oct-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. "Elliptic Curve KEYs in the DNS", R Schroeppel, Donald Eastlake, 13-Aug-04, A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described. "TKEY Secret Key Renewal Mode", Y Kamite, Masaya Nakayama, 15-Oct-04, This document defines a new mode in TKEY and proposes an atomic method for changing secret keys used for TSIG 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. "Resource Records for the DNS Security Extensions", Roy Arends, 11-Oct-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, 11-Oct-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. "Clarifying the Role of Wild Card Domains in the Domain Name System", Edward Lewis, 11-Oct-04, The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, 27-Oct-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. "HMAC SHA TSIG Algorithm Identifiers", Donald Eastlake 3rd, 19-Aug-04, Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers for additional HMAC SHA TSIG algorithms and standardizes how to specify the truncation of HMAC values. "RFC 3267 Interoperability Report", Jacob Schlyter, 25-Aug-04, This memo documents the result from the RFC 3267 (Handling of Unknown DNS Resource Record Types) interoperability testing. "Requirements related to DNSSEC Signed Proof of Non-Existence", Ben Laurie, 22-Oct-04, DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. "An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors.", Johan Ihren, 19-Oct-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. These keys are known as the so called trust anchors. This memo describes a method how these client trust anchors can be replaced using the DNS validation and querying mechanisms (in-band) when the key pairs used for signing by zone owner are rolled. This memo also describes a method to establish the validity of trust anchors for initial configuration, or priming, using out of band mechanisms. "Automated Updates of DNSSEC Trust Anchors", Michael StJohns, 27-Oct-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. Domain Name System Operations (dnsop) ------------------------------------- "Observed DNS Resolution Misbehavior", Matt Larson, Piet Barber, 27-Oct-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, 26-Oct-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. "DNSSEC Operational Practices", Olaf Kolkman, 11-Oct-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-Aug-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, 25-Oct-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, 29-Sep-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, 27-Sep-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, 27-Oct-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", Dale Moberg, Rik Drummond, 6-Oct-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. Entity MIB (entmib) ------------------- "Entity MIB (Version 3)", Keith McCloghrie, Andy Bierman, 27-Oct-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-Sep-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 physical entities. Telephone Number Mapping (enum) ------------------------------- "E.164 Number Mapping for the Extensible Provisioning Protocol", Scott Hollenbeck, 27-Oct-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, 21-Oct-04, This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. "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, 25-Oct-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. "IANA Registration for Enumservice VOID", Richard Stastny, Lawrence Conroy, 12-Oct-04, This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". 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, 10-Aug-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, 10-Aug-04, 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, 23-Aug-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. "ForCES Protocol Specification", Avri Doria, 26-Oct-04, This specification documents the Forwarding and Control Element Seperation protocol. This protocol is desgined to be used between a Control Element and a Forwarding Element in a Routing Network Element. 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 Configuration Information", Henning Schulzrinne, 6-Oct-04, This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option for the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces and cities, as well as street addresses and building information. "A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, 28-Oct-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, 10-Sep-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 Objects", Jon Peterson, 9-Sep-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, 28-Oct-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. "Carrying Location Objects in RADIUS", Hannes Tschofenig, 26-Oct-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. Global Routing Operations (grow) -------------------------------- "BGP Communities for Data Collection", David Meyer, 21-Sep-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, 27-Oct-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. "BGP Wedgies", Tim Griffin, Geoff Huston, 6-Oct-04, It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol", Robert Moskowitz, 27-Oct-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. "Host Identity Protocol Architecture", Robert Moskowitz, 18-Oct-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. "End-Host Mobility and Multi-Homing with Host Identity Protocol", Pekka Nikander, 19-Oct-04, This document specifies basic end-host mobility and multi-homing mechanisms for the Host Identity Protocol. "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", Pekka Nikander, Julien Laganier, 19-Oct-04, This document specifies two new resource records for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These records allow a HIP node to store in the DNS its Host Identity (its public key), Host Identity Tag (a truncated hash of its public key), and Rendezvous Servers (RVS). "Host Identity Protocol (HIP) Rendezvous Extensions", Julien Laganier, L Eggert, 19-Oct-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. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Managed Objects of EPON", Lior Khermosh, 29-Sep-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 IEEE Draft 802.3ah-2004 Draft 3.3. 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-2004 Draft 3.3 Annex 30A and mainly partitioned accordingly. "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", Edward Beili, 27-Oct-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 Std 802.3ah-2004. "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) --------------------------------- "Writing Protocol Models", Eric Rescorla, 16-Sep-04, The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not for reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. "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. "OMA-IETF Standardization Collaboration", Geoff Huston, Ileana Leuca, 10-Aug-04, This document describes the standardization collaboration between the Open Mobile Alliance and the Internet Engineering Task Force. "Architectural Implications of Link Layer Indications", Bernard Aboba, 15-Oct-04, As a performance optimization, proposals have been made for utilizing link layer indications (also known as "triggers" or "hints") to influence the behavior of the Internet, Transport or Application layers. This document briefly summarizes current proposals and describes architectural issues relating to link layer indications. "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, 22-Oct-04, This note discusses how to extend the DNS with new data for a new application. DNS extension discussion too often circulate around reuse of the TXT record. This document lists different mechanisms to accomplish the extension to DNS, and comes to the conclusion use of a new RR Type is the best solution. "IAB and IESG Recommendation for IETF Administrative Restructuring", Scott Hollenbeck, 22-Oct-04, This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. This recommendation will be discussed on the IETF list (ietf@ietf.org), and the IETF leadership will attempt to determine if there is IETF consensus in going forward with this plan through a Last Call process. 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, 22-Oct-04, The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", Jeffrey Haas, Susan Hares, 31-Aug-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 the Border Gateway Protocol Version 4 or lower. "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 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. "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 18-Aug-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. "AS-wide Unique BGP Identifier for BGP-4", Enke Chen, Jenny Yuan, 21-Sep-04, To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the 'uniqueness' requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. "BGP-4 Protocol Analysis", David Meyer, Keyur Patel, 30-Aug-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, 18-Oct-04, Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to the BGP protocol to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination. This internet draft does not discuss security issues with forwarding of packets. "Experience with the BGP-4 Protocol", Danny McPherson, Keyur Patel, 15-Sep-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, David Hares, 12-Nov-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, Alvaro Retana, 12-Nov-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. "Address Prefix Based Outbound Route Filter for BGP-4", Enke Chen, 30-Aug-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. 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. "Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain", Ken Carlberg, 22-Sep-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 [rfc3689] 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 Emergency Telecommunications Services (ETS) Within a Single Administrative Domain", Ken Carlberg, 22-Sep-04, This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (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, 22-Sep-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. 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, 25-Oct-04, The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "metadata" for messages stored in an IMAP mailbox. "IMAP4 LIST Command Extensions", Barry Leiba, Alexey Melnikov, 4-Oct-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, 11-Oct-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. "IMAP4 ACL extension - updated list of rights", Alexey Melnikov, 13-Sep-04, The ACL (Access Control List) extension [RFC2086] of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. This document updates the list of rights defined in RFC 2086. It also clarifies which rights are required for different IMAP commands. Internet and Management Support for Storage (imss) -------------------------------------------------- "Fibre Channel Name Server MIB", Claudio DeSanti, 21-Oct-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. "Fibre Channel Fabric Address Manager MIB", Claudio DeSanti, 21-Oct-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 Fabric Address Manager. At present, this memo is a work item of T11.5 (http://www.t11.org). The plan is that it will later be a work item of the IETF's IMSS working group. Extended Incident Handling (inch) --------------------------------- "Incident Handling: Real-Time Inter-Network Defense", Kathleen Moriarty, 25-Oct-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, 24-Sep-04, 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, 12-Oct-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. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. "Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus", Stan Green, 9-Sep-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, 11-Aug-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. "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, 26-Oct-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, 27-Oct-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. IP over DVB (ipdvb) ------------------- "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks", Gorry Fairhurst, Bernhard Collini-Nocker, 7-Oct-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. ULE supports an extension format that allows it 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. "A Framework for transmission of IP datagrams over MPEG-2 Networks", Marie-Jose Montpetit, 30-Sep-04, This document describes an 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. 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. IP Flow Information Export (ipfix) ---------------------------------- "Architecture Model for IP Flow Information Export", K Norseth, Ganesh Sadasivan, Nevil Brownlee, 12-Oct-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. "Information Model for IP Flow Information Export", Paul Calato, 27-Oct-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, 22-Oct-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, 28-Oct-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, 27-Oct-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, 25-Oct-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). "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, 13-Aug-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. "Definitions of Managed Objects for Infiniband Channel Adapters (CA)", Sean Harnedy, 21-Oct-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, 21-Oct-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, 26-Oct-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). 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, 27-Oct-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, 10-Aug-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) ---------------------------------- "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 Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers using Service Location Protocol version 2 (SLPv2)", Mark Bakke, John Hufferd, Kaladhar Voruganti, Marjorie Krueger, Todd Sperry, 26-Aug-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, 27-Oct-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 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. "T11 Network Address Authority (NAA) naming format for iSCSI Node Names", Robert Elliott, Marjorie Krueger, Mallikarjun Chadalapaka, 10-Aug-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. "Datamover Architecture for iSCSI (DA)", Mallikarjun Chadalapaka, 10-Sep-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. "iSCSI Extensions for RDMA Specification", Mike Ko, 14-Sep-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. IP Security Protocol (ipsec) ---------------------------- "IP Encapsulating Security Payload (ESP)", Stephen Kent, 4-Oct-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, 4-Oct-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 (SAs). "IP Authentication Header", Stephen Kent, 27-Oct-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). "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, 26-Oct-04, This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document is based upon RFC 2401 (November 1998). "Cryptographic Algorithm Implementation Requirements For ESP And AH", Donald Eastlake 3rd, 23-Aug-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. 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, 21-Oct-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, 21-Oct-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, 21-Oct-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) -------------------- "A Telephony Gateway REgistration Protocol (TGREP)", Manjunath Bangalore, 21-Oct-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, 25-Oct-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. IP Version 6 Working Group (ipv6) --------------------------------- "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", Alex Conta, Steve Deering, 22-Oct-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, 14-Oct-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. "IPv6 Host to Router Load Sharing", Robert Hinden, 21-Oct-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, Myung-Ki Shin, Hyoung-Jun Kim, 15-Oct-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, 23-Aug-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, 20-Oct-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, 20-Aug-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. "Unique Local IPv6 Unicast Addresses", Robert Hinden, Brian Haberman, 25-Oct-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, 20-Oct-04, This memo defines a Management Information Base (MIB) module 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 MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. "IPv6 Stateless Address Autoconfiguration", Susan Thomson, 3-Sep-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 are specified in RFC 3315; an alternative way of using the stateful protocol to deliver 'other information' only is specified in RFC 3736. "Optimistic Duplicate Address Detection for IPv6", Nick Moore, 9-Sep-04, Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case and to remain interoperable with unmodified hosts and routers. "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)", Thomas Narten, 29-Oct-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. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Thomas Narten, 25-Oct-04, Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. 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. "Routing IPv6 with IS-IS", Chris Hopps, 28-Sep-04, This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. "IS-IS Extensions in Support of Generalized MPLS", Kireeti Kompella, Yakov Rekhter, 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 (krb-wg) -------------------- "Public Key Cryptography for Initial Authentication in Kerberos", Brian Tung, Clifford Neuman, Matt Hur, Ari Medvinsky, Sasha Medvinsky, John Wray, Jonathan Trostle, 26-Oct-04, This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification [1]. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by passing digital 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", Larry Zhu, 27-Oct-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, 7-Sep-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, 25-Oct-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. "OCSP Support for PKINIT", Larry Zhu, 16-Aug-04, This document defines a mechanism to enable in-band transmission of OCSP responses. These responses are used to verify the validity of the certificates used in PKINIT - the Kerberos Version 5 extension that provides for the use of public key cryptography. "Unkeyed SHA-1 Checksum Specification for Kerberos 5", Kenneth Raeburn, 21-Oct-04, The Kerberos cryptosystem specification requires a profile detailing several operations for a new checksum type for ensuring the integrity of data in Kerberos and related protocol exchanges. This document specifies the use of a simple unkeyed checksum type based on SHA-1. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP)", Gilles Bourdon, 11-Oct-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-Oct-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'", Vipin Jain, 13-Sep-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, 26-Oct-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. "L2VPN Extensions for L2TP", Wei Luo, 27-Oct-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. "ATM Pseudo-Wire Extensions for L2TP", Mark Townsley, Sanjeev Singh, 25-Oct-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. 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, 18-Oct-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, 22-Sep-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, 30-Sep-04, There are a number of different kinds of "Provider Provisioned Layer 2 VPNs" (L2VPNs). The 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". When the discovery process is complete, a signaling protocol is automatically invoked. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any PW signaling protocol needs to have a method which allows each PW endpoint to identify the other; thus a PW signaling protocol will have the notion of an endpoint identifier. 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 L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each provisioning model. It discusses the way in which the endpoint identifiers are distributed by the discovery process, especially when the discovery process is based upon the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). "IP-Only LAN Service (IPLS)", Himanshu Shah, 4-Oct-04, A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear to those systems as if they are interconnected on a private LAN. The systems which are interconnected in this way may themselves be LAN switches. If, however, the interconnected systems are NOT LAN switches, but rather are IP hosts or IP routers, certain simplifications are possible. We call this simplified type of virtual private LAN service an ?Ip-only LAN Service? (IPLS). In IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their MAC Destination Addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the ?MAC Address Learning? procedures of IEEE 802.1D. Further, Address Resolution Protocol (ARP) messages are proxied, rather than being carried transparently. This draft specifies the protocols and procedures for support of the IPLS service. "VPLS OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, 21-Oct-04, This draft provides framework and requirements for Virtual Private LAN Service (VPLS) Operation, Administration and Maintenance (OAM). "ARP Mediation for IP Interworking of Layer 2 VPN", Himanshu Shah, 4-Oct-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 draft-ietf-l2vpn-arp-mediation-00.txt connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". This document specifies the ARP Mediation function, and specifies the encapsulation used to carry the IP datagrams on the Pseudowires when ARP mediation is used. "VPLS Applicability", Marc Lasserre, 18-Oct-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 across metropolitan area networks as well as wide area networks. [VPLS-LDP] defines a method for signaling MPLS connections between member PEs of a VPN and a method for forwarding Ethernet frames over such connections. This document describes the applicability of such procedures to provide VPLS services. This document also compares the characteristics of this solution against the requirements specified in [L2VPN-REQ]. In summary, there are no architectural limitations to prevent the requirements from being met. But meeting certain requirements (e.g. QoS) is beyond the specification of [VPLS-LDP], and requires careful planning and precise implementation of the Service Provider (SP) networks. This document attempts to capture such issues, presents the potential solutions to these issues, and discusses the pros and cons of each alternative. This document does not cover the applicability of [VPLS-BGP]. 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, 25-Aug-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, 5-Oct-04, This document describes a method by which a Service Provider may use an IP backbone to provide IP 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"); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. This document obsoletes RFC 2547. "Use of PE-PE IPsec in RFC2547 VPNs", Eric Rosen, Jeremy De Clercq, Chandru Sargor, 30-Sep-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 Provider/Customer Edge Protocol for BGP/MPLS IP VPNs", Eric Rosen, 21-Oct-04, Many Service Providers offer Virtual Private Network ("VPN") services to their customers, using a technique in which customer edge routers ("CE routers") are routing peers of provider edge routers ("PE routers"). The Border Gateway Protocol ("BGP") is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching ("MPLS") is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First ("OSPF") protocol. "Use of PE-PE GRE or IP in BGP/MPLS IP VPNs", Yakov Rekhter, Eric Rosen, 11-Oct-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, 28-Sep-04, This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). "Applicability Statement for BGP/MPLS IP VPNs", Eric Rosen, 5-Oct-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 L3VPN Operations and Management", Yacine Mghazli, 17-Sep-04, This document provides a framework for operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. 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]. "Provider Provissioned VPN terminology", Loa Andersson, 10-Sep-04, The wide spread interest in provider-provisioned VPN solutions lead to memos proposing different and overlapping solutions. The IETF working groups, first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs, have been discussed these proposals and documented specifications. 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. This document seeks to fill the need to make the terminology in the area clearer and more intuitive. "Constrained VPN route distribution", Pedro Marques, 14-Sep-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, 26-Oct-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, 21-Oct-04, This document describes the protocol elements, along with their semantics and encodings, of 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, 25-Oct-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, 26-Oct-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, 25-Oct-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, 8-Oct-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, 26-Oct-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, 26-Oct-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, 26-Oct-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. 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, 11-Oct-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, 4-Oct-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", Mark Crispin, 18-Oct-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". "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. "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, 25-Oct-04, Mobile IMAP clients are notoriously slow to connect to IMAP mail servers because of the large volume of data exchanged in order to ensure that the client is synchronized with the server. This problem is amplified when the mobile terminal is moving which exasperates the connection problems they tend to have: low bandwidth allocations, out-of-range disconnects, and poor connection quality to the cell/WLAN network. "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", Randall Gellens, 12-Nov-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. "Server To Server Notification Protocol Requirements", Gev Decktor, 9-Aug-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. "Message Submission BURL Extension", , 18-Oct-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. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-Term Archive Service Requirements", Carl Wallace, 25-Oct-04, There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. "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. "Requirements for Certification Services", Tobias Gondrom, 25-Oct-04, This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. It establishes the need for components to be used in addition to long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. Multicast & Anycast Group Membership (magma) -------------------------------------------- "Using IGMPv3 and MLDv2 For Source-Specific Multicast", Hugh Holbrook, Bradley Cain, Brian Haberman, 4-Oct-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. This document updates the IGMPv3 and MLDv2 specifications. "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 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, 21-Oct-04, The concept of Internet Group Membership Protocol (IGMP) and Multicast Listener Discovery (MLD) 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, 16-Aug-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. "Sender ID: Authenticating E-Mail", Jim Lyon, 18-Aug-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 Sender-ID Protocol", Meng Weng Wong, 16-Sep-04, This document defines a protocol for the authorization of Internet hosts to use domain names in the sender mailbox of mail that those hosts send. Authorization records are published in DNS for domain names that may be used as part of sender mailboxes. Mail receivers then perform a check against those records to see if a client host submitting a piece of mail is actually authorized. Since there are several different concepts of sender mailbox, this protocol is generic and can be applied to one or more of such "scopes". "Purported Responsible Address in E-Mail Messages", Jim Lyon, 18-Aug-04, The document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the "Purported Responsible Address" (PRA). "Authorizing Use of Domains in MAIL FROM", Mark Lentczner, Meng Weng Wong, 16-Sep-04, Mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction in what a sending host can use as the reverse-path of a message. This document describes a protocol whereby a domain can explicitly authorize the hosts that are allowed to use its domain name in a reverse-path, and a way for receiving hosts to check such authorization. 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, 25-Oct-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, 28-Oct-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. "PIM-SM Multicast Routing Security Issues and Enhancements", Pekka Savola, Rami Lehtonen, David Meyer, 13-Oct-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. "IPv6 Multicast Deployment Issues", Pekka Savola, 2-Sep-04, This memo describes known issues with IPv6 multicast, and provides historical reference of how some earlier problems have been resolved. 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. 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, 28-Oct-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, 6-Oct-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, 14-Sep-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, 1-Oct-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", Charles Perkins, 25-Oct-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. "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", Sami Vaarala, 4-Oct-04, This document outlines the proposed solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec are not required. "Foreign Agent Error Extension for Mobile IPv4", Charles Perkins, 19-Oct-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. Mobility for IPv6 (mip6) ------------------------ "Mobile IPv6 Management Information Base", Glenn Keeni, Ken-ichi Nagami, Kazuhide Koide, Sri Gundavelli, 25-Oct-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, 2-Sep-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-Oct-04, A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. "Mobile IP version 6 Route Optimization Security Design Background", Pekka Nikander, 18-Oct-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, 14-Oct-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. "Mobile IPv6 and Firewalls Problem statement", Franck Le, 27-Aug-04, Firewalls are an integral aspect of a majority of IP networks today given the state of security in the Internet, threats and vulnerabilities to data networks. IP networks today are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development. "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", Vijay Devarapalli, 19-Oct-04, This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. MIPv6 Signaling and Handoff Optimization (mipshop) -------------------------------------------------- "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, 26-Oct-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, 22-Oct-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, 26-Oct-04, This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. 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, 27-Oct-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, 29-Sep-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 connection attribute, which handles connection reestablishment. "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, 27-Oct-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). "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, 19-Aug-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, 27-Oct-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 (ANAT) for theSession Description Protocol (SDP) Grouping Framework", Gonzalo Camarillo, 27-Oct-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. "The SDP (Session Description Protocol) Label Attribute", Orit Levin, Gonzalo Camarillo, 29-Sep-04, This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream 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 streams. The application can then use the provided pointer to refer to each particular media stream in its context. "Connection-Establishment Preconditions in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 1-Oct-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. "RTSP Announce Method", Thomas Zeng, 20-Oct-04, This memo describes an extension RTSP request, ANNOUNCE, which extends the core RTSP protocol [RTSP_NEW] to allow one end to push to the other end various types of information by RTSP means. 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. "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, 7-Sep-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, 26-Oct-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, 14-Oct-04, This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label switching controlled Frame-Relay and ATM interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. "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, 27-Sep-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. "OAM Requirements for MPLS Networks", Thomas Nadeau, 2-Sep-04, As transport of diverse traffic types such as voice, frame relay, and ATM over MPLS become more common, the ability to detect, handle and diagnose control and data plane defects becomes critical. Detection and specification of how to handle those defects is not only important because such defects may not only affect the fundamental operation of an Multi-Protocol Label Switching network, but also because they MAY impact service level specification commitments for customers of that network. "MPLS Traffic Engineering Soft preemption", Matthew Meyer, 1-Oct-04, This document details MPLS Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/eliminating traffic disruption of preempted Traffic Engineered Label Switched Paths. Initially MPLS RSVP-TE was defined supporting only immediate Label Switched Path displacement upon preemption. The utilization of a preemption pending flag helps more gracefully mitigate the re-route process of preempted Label Switched Paths. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the Label Switched Path can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering 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, 25-Oct-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. "LDP Specification", Loa Andersson, 12-Oct-04, The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. "Avoiding Equal Cost Multipath Treatment in MPLS Networks", George Swallow, 19-Oct-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. 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. "TESLA: Multicast Source Authentication Transform Introduction", Adrian Perrig, Ran Canetti, Dawn Song, Doug Tygar, Bob Briscoe, 16-Aug-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, 28-Oct-04, This document describes a light-weight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. "The Use of RSA Signatures within ESP and AH", Brian Weis, 8-Oct-04, This memo describes the use of the RSA Digital Signature algorithm [RSA] as an authentication algorithm within the revised IP Encapsulating Security Payload [ESP] and the revised IP Authentication Header [AH]. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) is not sufficient. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. Further information on the other components necessary for ESP and AH implementations is provided by [ROADMAP]. "The Use of TESLA in SRTP", Mark Baugher, 27-Oct-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. "GKDP: Group Key Distribution Protocol", Lacshminath Dondeti, 26-Oct-04, This document specifies a group key distribution protocol (GKDP) based on IKEv2 [2]; the new protocol is similar to IKEv2 in message and payload formats, and message semantics to a large extent. The protocol in conformance with MSEC key management architecture contains two components: member registration and group rekeying, and downloads a group security association from the GCKS to a member. This protocol is independent of IKEv2 except in its likeness. Site Multihoming in IPv6 (multi6) --------------------------------- "IPv4 Multihoming Motivation, Practices and Limitations", Joe Abley, Benjamin Black, Vijay Gill, 19-Oct-04, Multihoming is an essential component of service for sites 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" working group of the IETF, who are working to a longer term 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, 23-Sep-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", Geoff Huston, 25-Oct-04, This memo provides an analysis of the architectural 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, 26-Oct-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, 26-Oct-04, This document defines a terminology for discussing network mobility issues and solution requirements. "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, 7-Oct-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 [8]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. "Analysis of Multihoming in Network Mobility Support", Thierry Ernst, 27-Oct-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. "NEMO Management Information Base", Sri Gundavelli, Glenn Keeni, Kazuhide Koide, 19-Oct-04, This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB , for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile IPv6 node with NEMO Basic Support functionality. Network Configuration (netconf) ------------------------------- "NETCONF Configuration Protocol", Rob Enns, 28-Oct-04, The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an XML-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple RPC layer. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)", Eliot Lear, 19-Oct-04, This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). "Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)", Ted Goddard, 8-Sep-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, 18-Oct-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. "Internet Standards Documentation (ISDs)", John Klensin, John Loughney, 24-Sep-04, It has been observed that the current IETF standard designations, STD nnnn and BCP nnnn designation, have not worked well. Problems have been found when one of them is used either as a stable reference for external specifications or as a combined reference for multiple documents linked together into a single document. This document proposes two changes to these designations. The first of these changes would create a new document series and assign a new number and acronym to a specification when it enters the first level of the Standards Track (or is first designated as a BCP). The second would migrate the concept of STDs and BCPs numbering of RFCs into actual documents that detail what they identify, their publication information and their change history. "Getting rid of the cruft: A procedure to deprecate old standards", Harald Alvestrand, Eliot Lear, 4-Oct-04, This document describes a procedure for performing the downgrading of old standards described in RFC 2026, as well as BCPs, without placing an unreasonable load on groups charged with performing other tasks in the IETF. "Sample ISD for the IETF Standards Process", Scott Bradner, 20-Oct-04, This is a sample Internet Standards Documentation (ISD) for the IETF Standards Process. This document follows the model proposed in draft-ietf-newtrk-isd-repurposing-isd-00. "Internet Standards Documentation (ISDs) - Examples", John Klensin, 29-Oct-04, The proposal to define what is actually an IETF standard and to create ways of explaining and qualifying its applicability and relationship to other documents has been described in an Internet-Draft, "Internet Standards Documentation (ISDs)" (draft-ietf-newtrk-repurposing-isd-00). This document provides some examples of what such documents might look like. It includes a very complicated example (SMTP) and a fairly simple one (the IMAP/POP authorization specification of RFC 2195, which has not progressed beyond Proposed Standard). 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, 20-Sep-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, 20-Sep-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, 27-Oct-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, 8-Sep-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, 6-Oct-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, 14-Oct-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, 5-Oct-04, This document defines an extension the Network News Transport Protocol [NNTP] which allows a 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 the remainder of an NNTP session. Individual Submissions (none) ----------------------------- "Securing FTP with TLS", Paul Ford-Hutchinson, Martin Carpenter, Tim Hudson, Eric Murray, Volker Wiegand, 13-Aug-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. "Sieve: Vacation Extension", Tim Showalter, 27-Oct-04, This document describes an extension to the Sieve mail filtering language for an autoresponder similar to that of the Unix 'vacation' command for replying to messages with certain safety features to prevent problems. "The application/smil and application/smil+xml Media Types", Philipp Hoschka, 4-Aug-04, 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. "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. "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, 25-Oct-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. "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. "Sieve Email Filtering -- Regular Expression Extension", Ken Murchison, 27-Oct-04, In some cases, it is desirable to have a string matching mechanism which is more powerful than a simple exact match, a substring match or a glob-style wildcard match. The regular expression matching mechanism defined in this draft should allow users to isolate just about any string or address in a message header or envelope. "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, 20-Oct-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, 26-Oct-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. "Diversion Indication in SIP", Stuart Levy, Bryan Byerly, John Yang, 26-Aug-04, This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. "UMAC: Message Authentication Code using Universal Hashing", Ted Krovetz, 12-Oct-04, This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis and its only internal "cryptographic" use is a block cipher, AES, to generate the pseudorandom pads and internal key material. "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. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", Luca Martini, 24-Sep-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. "A Configuration Schema for LDAP Based Directory User Agents", M Ansari, Luke Howard, Bob Joslin, 18-Aug-04, This document describes a mechanism for global configuration of similar directory user agents. This document defines a schema for configuration of these DUAs that may be discovered using the Light- weight Directory Access Protocol in RFC 2251[17]. A set of attri- bute types and an objectclass are proposed, along with specific guidelines for interpreting them. A significant feature of the global configuration policy for DUAs is a mechanism that allows DUAs to re-configure their schema to that of the end user's environment. This configuration is achieved through attribute and objectclass mapping. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. "Domain Name System Uniform Resource Identifiers", Simon Josefsson, 2-Sep-04, 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]. "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, 28-Oct-04, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM 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, result indications, and a fast re-authentication procedure. "Analysis of the Security of BGP/MPLS IP VPNs", Michael Behringer, 21-Oct-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. "Additional XML Security URIs", Donald Eastlake, 1-Oct-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. "LDAP: Additional Schema Elements", Kurt Zeilenga, 26-Oct-04, This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol from COSINE and Internet X.500 pilot projects. "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", Jari Arkko, Henry Haverinen, 28-Oct-04, This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Authentication and Key Agreement (AKA) mechanism used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and cdma2000. AKA is based on symmetric keys, and runs typically in a Subscriber Identity Module (UMTS Subscriber Identity Module USIM, or (Removable) User Identity Module (R)UIM), a smart card like device. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. "Simple Explicit Multicast (SEM)", Ali Boudani, Bernard Cousin, 11-Oct-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, 8-Oct-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, 25-Aug-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, 25-Aug-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, 20-Oct-04, This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that there is no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. "CastGate: an auto-tunneling architecture for IP Multicast", Pieter Liefooghe, 22-Oct-04, The architecture described in this document aims at giving as many unicast-only end-users access to IP multicast content, this without the need for their ISPs to upgrade their network infrastructure to IP multicast. It further does not require any change to the unicast only infrastructure nor to the end-user operating systems. The access that is provided, is from a user's perspective as good as a real IP multicast connection. It can be used to send and receive ASM content and allows the receptions of SSM content. It further allows applying Authentication, Authorization and Accounting (AAA) to IP Multicast. "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. "Dynamic Service Negotiation Protocol (DSNP)", Jyh-Cheng Chen, 9-Nov-04, This memo presents the specification of Dynamic Service Negotiation Protocol (DSNP). DSNP is a protocol to negotiate the SLS (Service Level Specification) in IP layer. It can be used for service negotiation from host to network, network to host, and network to network. The automated negotiation makes service negotiation efficient in terms of time, cost, and correctness, etc. The dynamic negotiation not only allows users to adapt their needs dynamically, but also let providers better utilize the network. The DSNP messages and packet formats are detailed. DSNP can be used in both wireline and wireless networks. It is, however, particularly useful in mobile environment. To demonstrate the usefulness of DSNP, a reference wireless QoS architecture is presented. Exemplary applications are illustrated. "Basic Network Media Services with SIP", Eric Burger, 28-Oct-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, 21-Oct-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, 27-Sep-04, This specification extends the Web Distributed Authoring Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. "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]. "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. "The Dublin Core Metadata Element Set", John Kunze, 13-Aug-04, Defines fifteen metadata elements for resource description in a cross-disciplinary information environment: title, creator, subject, description, publisher, contributor, date, type, format, identifier, source, language, relation, coverage, and rights. This document, containing essentially the same text as ANSI/NISO Z39.85, supersedes Internet RFC 2413, which was the first published version of the Dublin Core. "FTP/TLS Friendly Firewalls", Paul Ford-Hutchinson, 13-Aug-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, 21-Oct-04, Several protocols borrow the authentication mechanisms from the Hypertext Transfer Protocol, HTTP. This document specifies an extension to RADIUS that allows a RADIUS client in an HTTP-style server, upon reception of a request, retrieve and compute Digest authentication information from a RADIUS server. Additionally, a scenario describing the authentication of a user emitting an HTTP-style request is provided. "An Effective Solution for Multicast Scalability:The MPLS Multicast Tree (MMT)", Ali Boudani, 11-Oct-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. "Old X.500/LDAP RFCs to Historic", Kurt Zeilenga, 26-Oct-04, This document recommends the retirement of various early X.500 and LDAP RFCs documents which are no longer relevant to the Internet community, except for historical purposes. "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) "Tight membership support in SDP", Eunkyung Kim, 21-Oct-04, This document defines a set of Session Description Protocol (SDP)attributes that allow SDP to provides tightly controlled membership information. Some multimedia conferencing applications may require strict membership control policies. A group session creator describes basic membership information in SDP, and it can be negotiated by the Offer / Answer model. "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, 26-Oct-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, 27-Oct-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 and firewalls, but to "turn" them into port-restricted NATs. "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. "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). "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, 27-Sep-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, 25-Oct-04, The IPv6 addressing architecture 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 and has the same properties than identifiers based on IEEE standards. "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 26-Oct-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, 26-Oct-04, The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes belonging to an object class. "LDAP Absolute True and False Filters", Kurt Zeilenga, 26-Oct-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. "Mobile SCTP", Maximilian Riegel, Michael Tuexen, 18-Oct-04, Transport layer mobility management is presented in addition to Mobile IP for providing seamless mobility in the Internet. By use of SCTP (Stream Control Transmission Protocol) and some of its currently proposed extensions a seamless handover can be fully accomplished in the mobile client without any provisions in the network, only assisted by functions embedded in Mobile SCTP enabled servers. Client mobility management based on Mobile SCTP seems not to require any new protocol development. It is a particular application of SCTP eventually solving the requirements of transport layer mobility in the Internet. "IMAP ANNOTATEMORE Extension", Cyrus Daboo, 25-Oct-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. "LDAP Schema for UDDIv3", Bruce Bergeson, Kent Boogert, Vijay Nanjundaswamy, 26-Aug-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, 1-Sep-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, 1-Sep-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, 1-Sep-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, 1-Oct-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. "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, 27-Sep-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. "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, 21-Sep-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. "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, 1-Sep-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. "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. "HTTP Header Field Registrations", Mark Nottingham, 21-Sep-04, This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. "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, 25-Oct-04, This document attempts to address some of the issues involved in building a disconnected IMAP4 [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. "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. "A Protocol for Anycast Address Resolving", Shingo Ata, Hiroshi Kitamura, Masayuki Murata, 27-Oct-04, Since the route of packets to the same anycast adddress may change according to the network/node condition, it is not suitable to use anycast addresses directry for stateful communications (such as TCP). The more preferable use of the anycast addresses is to discover (the unicast address of) service node. The approach intended to describe in this document is to resolve (i.e., obtain) the corresponding unicast address for the anycast address prior to establishing the communication. We call this process as Anycast Address Resolving (AARP). The objevtive of the AARP is to enable the use of anycast addresses to all existing applications without any modifications. "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. "Quick-Start for TCP and IP", Amit Jain, Sally Floyd, 27-Sep-04, This draft specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and at times in the middle of a data transfer. While Quick-Start is designed to be used by a range of transport protocols, in this document we describe its use with TCP. By using Quick-Start, a TCP host, say, host A, would indicate its desired sending rate in bytes per second, using a Quick Start Request option in the IP header of a TCP packet. A Quick-Start request for a higher sending rate would be sent in a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start request is not approved. If the Quick-Start request is not approved, then the sender would use the default congestion control mechanisms. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick- Start Request option, or have not agreed to the Quick-Start rate request. TCP host B communicates the final rate request to TCP host A in a transport-level Quick-Start Response in an answering TCP packet. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and all of the routers along the path support the Quick-Start Request. "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. "An Architecture for IP Packet Tracing", Gargi Keeni, Yoshitaka Kuwata, 28-Oct-04, This document presents an architecture for use in tracing packets across the Internet. It envisages a two-tier model wherein at the top level a Packet Tracer Application (PTA) queries relevant Autonomous System (AS) packet tracers (ASPT) with details of the packet to be traced. The PTA constructs the complete path from the responses of the queried ASPTs. At the lower level an ASPT receives queries from a PTA, traces the path of a packet within the AS and sends back the result to the PTA. "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. "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. "Secure Ad hoc On-Demand Distance Vector (SAODV) Routing", Manel Zapata, 11-Aug-04, The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension of the AODV routing protocol that can be used to protect the route discovery mechanism providing security features like integrity, authentication and non-repudiation. "Taxonomy of Route Optimization models in the Nemo Context", Pascal Thubert, Marco Molteni, Chan Ng, 27-Oct-04, With current Network Mobility (NEMO) Basic Support, all communications to and from mobile network nodes must go through the MR-HA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay. To overcome these limitations, one might have to turn to route optimization (RO) for NEMO. This memo documents various types of route optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO route optimization. "National and Local Characters for DNS Top Level Domain (TLD) Names", John Klensin, 12-Nov-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 in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific 'multilingual' TLDs in the language(s) and script(s) of that country. "EAP-Support in Smartcard", Pascal Urien, 19-Aug-04, This document describes the interface to the EAP protocol in smartcards, which may store multiple identities associated to EAP methods and appropriate credentials. "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. "DCLOR: De-correlated Loss Recovery using SACK option for spurious timeouts", Yogesh Swami, Khiem Le, 3-Sep-04, A spurious timeout in TCP forces the sender to unnecessarily retransmit one complete congestion window of data into the network. In addition, the congestion state of the network could change substantially after a spurious timeout. In this draft we propose a conservative congestion response algorithm afert spurious timeout that takes network state into account. "LDAP Content Synchronization Operation", Kurt Zeilenga, Jin Choi, 29-Sep-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, 28-Oct-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, 27-Sep-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, 8-Oct-04, Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing functions. MSCML presents an application-level model for conference control, as opposed to device-level conference control models. One use of 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. "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. "Policy Core Extension Lightweight Directory Access Protocol Schema", Angelica Reyes, 1-Oct-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. "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). "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]. "Address Management for IKE version 2", Francis Dupont, 25-Oct-04, The current IKEv2 proposal 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 IETF working group goals 1, 2, 3, 4, and 6. "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, 12-Nov-04, This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. 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. "Requirements for Session Initiation Protocol (SIP)-based Emergency Calls", Henning Schulzrinne, 25-Oct-04, This document enumerates requirements for emergency calls in VoIP and general Internet multimedia systems. We divide the requirements into 'trunk replacement' and 'end-to-end'. Trunking solutions only exchange the emergency call center's circuit-switched access by an IP-based system. The requirements for end-to-end IP-based emergency calling address functional and security issues for determining the correct emergency address, for identifying the appropriate emergency call center and for identifying the caller and its location. While we focus on systems that employ the Session Initiation Protocol (SIP), many of the requirements may also apply to other environments, such as those using H.248/Megaco, MGCP or H.323. "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, 7-Oct-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. "vCard Extensions for IM", Cullen Jennings, 25-Oct-04, This document 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.st. "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. "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, 16-Aug-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. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", Ned Freed, John Klensin, 18-Aug-04, This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. "The LDAP No-Op Control", Kurt Zeilenga, 26-Oct-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. "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. "SIP/SIMPLE Based Presence and IM Architecture", Avshalom Houri, 25-Oct-04, This 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, 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. SPECIFCATIONS SECTION TO BE UPDATED SHORTLY "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. "Considerations in Benchmarking Routing Protocol Network Convergence", Russ White, Vishwas Manral, Robert Adams, 8-Oct-04, This document attempts to discuss some of the definitions required to undertake the specifications of such benchmarks, and also to discuss some of the possible ways to benchmark a routing protocol performance within a network, and some of the implications of those benchmarks. The definition of convergence is discussed first, then polling network devices. Several tests which are commonly used to measure network convergence are examined. This draft does not attempt to define what techniques should be used to benchmark network convergence, but only to provide considerations that testers shoudl consider when attempting to measure netowrk convergence using various methods. "IPv6 Anycast Functionality/Terminology Definition", Satoshi Doi, 27-Oct-04, Anycast is very useful, and many researches about it are made. This document defines anycast related terms to use a term in common on the researches about anycast. In this document, we focus on network- layer anycast, which is defined in IPv6 specification [ADDR-ARCH]. "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, 25-Oct-04, This draft presents an extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to support charging for prepaid services. The charging models supported are namely: volume-based charging, duration-based charging and one-time-based charging. "Sieve -- Variables Extension", Kjetil Homme, 15-Sep-04, In advanced filtering rule sets, it is useful to keep state or con­ figuration details across rules. This extension adds an action to store data in variables, an action to retrieve the current time, changes the interpolation of strings, and supplies a new test so that the value of a string can be examined. "Bundle Protocol Specification", Keith Scott, Scott Burleigh, 7-Sep-04, This document describes the end-to-end protocol, header formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). "Delay-Tolerant 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, 27-Aug-04, TCP congestion control is based on the assumption that the end-to-end path of a connection changes only insignificantly after connection establishment. Network layer mobility protocols that change a connection's point of attachment transparently to the transport layer may violate this assumption and cause TCP to make congestion control decisions based on invalid information. This document describes a TCP option that allows a connection endpoint to inform a peer when it changes location. This document also outlines the proper congestion control behavior that should take place in the face of such network layer mobility. "EPP Internationalized Domain Name (IDN) Object Mapping", Edmon Chung, Henry Tong, 27-Oct-04, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internationalized Internet domain names (that includes English alphanumeric domain names) stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. More specifically, EPP-IDN intends to provide a mechanism for explicitly managing and provisioning Reserved Variants and Zone Variants created for a Primary Domain Name. "IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration", Eiji Oki, 28-Oct-04, This document addresses the migration from Multiprotocol Label Switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to expand the capacity of existing MPLS-based controlled infrastructure, networks consisting of L2SC, TDM, LSC, and FSC devices will be deployed, and these will be controlled by the GMPLS protocols. GMPLS protocols are, however, subtly different from MPLS protocols. This document describes possible migration scenarios, the mechanisms to compensate for the differences between MPLS and GMPLS protocols, and how the mechanisms are applied to migrate from a MPLS to a 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]. "RSERPOOL Redundancy-model Policy", Qiaobing Xie, 9-Nov-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. "Guidelines for Mandating Automated Key Management", Steven Bellovin, 4-Nov-04, The question often arises of whether or not a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo proposes guidelines for making such decisions. The presumption is that when symmetric cryptographic mechanisms are used in a protocol, then automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. "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. "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. "Mentioning Intellectual Property Rights Considerations in Last Calls", Pekka Savola, 27-Oct-04, This memo describes an additional policy with last calls regarding Intellectual Property Rights (IPR) disclosures or other knowledge of IPR. The existence and the pointer to the IPR disclosures or an indication of non-existence of knowledge of such disclosures must be mentioned in all IETF last calls and should be mentioned in working group last calls. Additionally, all documents under the IETF change control for which a last call prior to the approval was not required and IPR disclosures are known, must now be either last-called or rejected. This memo updates RFC 2026 and RFC 2418. "EAP IKEv2 Method (EAP-IKEv2)", Hannes Tschofenig, Dirk Kroeselberg, 28-Oct-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. "Routing Policy Specification Language next generation (RPSLng)", Larry Blunk, Joao Luis Damas, Florent Parent, Andrei Robachevski, 9-Aug-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 Collation Registry", Chris Newman, 28-Oct-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, 26-Oct-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, 27-Oct-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. "Advertising Equal Cost MultiPath routes in BGP", Manav Bhatia, 7-Sep-04, This document describes an extensible mechanism that will allow a BGP [BGP4] speaker to advertise equal cost multiple BGP routes for a destination to its peers. A new BGP capability [BGP-CAP], termed "Equal Cost Multipath Capability", is defined, which would allow a local BGP speaker to express its ability to support advertisement of such multiple paths to its peers. "Layer Two Tunneling Protocol (Version 3) Graceful Restart", Sharon Galtzur, Gonen Zilber, 28-Oct-04, This document describes a mechanism that helps to minimize the negative effects on L2TP traffic caused by L2TP Control Connection Endpoint (LCCE) control plane restart, specifically by the restart of its control protocol component, on LCCEs that are capable of preserving the L2TP forwarding component ( a.k.a. the L2TP data plane) across the restart. The mechanism described in this document is applicable to all LCCEs, both those with the ability to preserve Forwarding State during the control plane (CP) restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). "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, 27-Oct-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. "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. "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". "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, 26-Oct-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. "The Flat Multicast Key Exchange protocol", Laurence Duquerroy, Sebastien Josset, 15-Sep-04, This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange), derived from the Group Domain of Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is to Manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols such as the IPSEC ESP protocol. The FMKE protocol is destined to provide an optimized solution for very large groups with direct connections such as in satellite systems, or wireless systems such as WIFI. It can be considered as a GDOI use case adapted for satellite networks. "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. "Dissemination of flow specification rules", Pedro Marques, 12-Oct-04, This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding special treatment that is desired for sub-components of a particular IP prefix. Additionally it defines an application of that encoding format to traffic filtering of inter-domain flows such as what is necessary in order to mitigate (distributed) denial of service attacks. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. "IPv6 Transition/Co-existence Security Considerations", Pekka Savola, 27-Oct-04, The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: Issues due to the IPv6 protocol itself, due to transition mechanisms, and due to the way in which IPv6 is being deployed. "Configuration Guidelines for DiffServ Service Classes", Fred Baker, 25-Oct-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. "A Performance Report Event Package For SIP", Alan Johnston, 18-Oct-04, This document discusses the motivation and requirements for the delivery of performance reports and other summary reports from VoIP applications in endpoints to non-participants in the session. A publication mechanism using a new SIP events package is proposed as a solution. An event package "perfrpt" and an application/perfrtp MIME type is defined in this document along with some example call flows. "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. "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, 26-Oct-04, This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. "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, 11-Oct-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. "An ENUM Registry Type for the Internet Registry Information Service", A Newton, 28-Sep-04, This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. "Media Objects Markup Language (MOML)", Tim Melanchuk, Garland Sharratt, 18-Aug-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, 18-Aug-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. "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. "Address Resolution for IP datagrams over MPEG-2 networks", Gorry Fairhurst, Marie-Jose Montpetit, 21-Oct-04, This document describes the current mechanisms to bind IPv4/IPv6 addresses and flows to MPEG-2 Transport Streams (TS). For MPEG-2 systems to become true subnetworks of the general Internet, methods 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. In MPEG-2 networks, address resolution is a three level process: the IP address is resolved to a NPA/MAC address, then associated with a Packet ID (PID) and finally to a 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 their compliance to AR requirements established. "End-to-middle security in the Session Initiation Protocol(SIP)", Kinji Ono, Shinya Tachimoto, 25-Oct-04, Some services provided by intermediaries depend on the ability to inspect the message bodies in the Session Initiation Protocol (SIP). When sensitive information is included in these bodies, a SIP User Agent (UA) needs to protect it from all intermediaries except for certain selected ones. This document proposes a mechanism for securing information passed between an end user and a selected intermediary using S/MIME. It also proposes mechanisms for notifying the UA that an intermediary needs to inspect an S/MIME-secured message body, and that the message body needs to be transmitted securely. "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. "Requirements for transport of video control commands", Andrea Basso, Orit Levin, Nermeen Ismail, 26-Oct-04, A variety of video communication services such as video conferencing and video messaging rely on the capability of video encoders and decoders to respond to 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. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Thomas Schmidt, Matthias Waehlisch, 27-Sep-04, This document extends the Hierarchical Mobile IPv6 Internet Draft to include the reception and transmission of multicast traffic at the Mobile Node. It introduces handover mechanisms for IPv6 mobile 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 proxy infrastructure. Handover latencies in the proposed scheme remain bound to link switching delays with respect to these local proxy points. Multicast listeners in addition encounter the option to optimize multicast routing by turning to a direct data reception. "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. "Mobility management for Dual stack mobile nodes A Problem Statement", George Tsirtsis, Hesham Soliman, 27-Oct-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 Configuration based on Router Advertisement", Jae-Hoon Jeong, 25-Oct-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. "Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS", Eric Rosen, 30-Sep-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. "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, 12-Aug-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, 25-Oct-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 a unique 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. "Dual Stack Mobile IPv6", Hesham Soliman, George Tsirtsis, 27-Oct-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. "Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)", David Black, Keith McCloghrie, Juergen Schoenwaelder, 21-Oct-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. URIs 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. "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. "A Uniform Resource Identifier (URI) Scheme for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 12-Oct-04, This document defines a Uniform Resource Identifier (URI) scheme for use in identifying 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. "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. "The TV-Anytime Content Reference Identifier (CRID) Uniform Resource Locator", Nigel Earnshaw, 27-Sep-04, 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 and 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. "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. "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. "A Session-Based Security Model (SBSM) for version 3 of the Simple Network Management Protocol (SNMPv3)", David Perkins, Wesley Hardaker, 18-Oct-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, 15-Sep-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, 27-Oct-04, The use of multiple interface is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile hosts which are more subject to failure or sudden lacks of connectivity. However, Mobile IPv6 currently lack support for such multihomed nodes. Individual solutions have been proposed to extend Mobile IPv6 but all issues have not been addressed in a single document. The purpose of the present document is thus to fill this gap and to contribute to raise the discussion in order to make sure that forthcoming solutions will address all the issues. In this document, we propose a taxonomy to classify the situations where a mobile node could be multihomed. This taxonomy is then used to highlight the issues preventing mobile nodes operating Mobile IPv6 to be multihomed. "On-Demand Access Authorization for SIP Event Subscriptions", Dirk Trossen, Henning Schulzrinne, 25-Aug-04, A target or presentity may want to temporarily allow limited access to its location or presence information to a third party. We will describe in this document use cases and solutions (focusing on the delivery of geospatial information and presence). We will further outline the relation to ongoing SIMPLE and GEOPRIV work. "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. "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. "PWE3 Congestion Control Framework", Eric Rosen, Stewart Bryant, Bruce Davie, 30-Sep-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. "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. "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, 25-Oct-04, SIP systems are often used to initiate connections to voicemail or unified messaging systems. This document describes a convention for forming SIP Request URIs that request particular services from unified messaging systems. "The Standard Hexdump Format", Joachim Strombergson, 12-Nov-04, This document specifies the Standard Hexdump Format (SHF), a new XML-based open format for describing binary data in hexadecimal notation. 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. "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", Mark Townsley, 27-Oct-04, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label or label stack and its payload over L2TPv3. This enables an application which traditionally requires an MPLS-enabled core network to utilize an L2TPv3 encapsulation over an IP network instead. "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, 27-Oct-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). "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. "A Framework for Session-Specific Intermediary Session Policies in SIP", Volker Hilt, 26-Oct-04, This specification defines a framework for session-specific policies in Session Initiation Protocol (SIP) sessions. It enables intermediaries to request the use of policies in a SIP session and defines the transport mechanisms needed for creating and delivering policies on a per-session basis. "The Extended LDAP Data Interchange Format (ELDIF)", Andrew Sciberras, 21-Oct-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. "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]. "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, 27-Oct-04, Most efforts on Generalized MPLS (GMPLS) have been focused on 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, Asynchronous Transfer Mode (ATM) LSPs and Frame Relay (FR) 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 Layer- 2 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, 27-Oct-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. "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. "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. "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. "Partial Document Changes (PATCH Method) for HTTP", Lisa Dusseault, 15-Oct-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, 21-Oct-04, This document specifies a dynamic load balance mechanism among multiple home agents by taking into account acceptable number of mobile nodes for each home agent up to now, with the goal of reducing and preventing traffic bottlenecks at the home agent. This mechanism can be used when a home agent is overloaded, wants to achieve better load-balancing with peer home agents, or is going offline for service. "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. "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. "Multicast Reconfiguration Protocol for Stateless DHCPv6", a Vijayabhaskar, 6-Oct-04, Stateless DHCPv6 [DHCPv6Light] is a light-weight DHCPv6 [DHCPv6] protocol in which the server manages only the service parameters like DNS server addresses, NTP server addresses etc., and hence there is no need to maintain the state of the clients, perhaps, it doesn't need to store any information about the clients at all. So, a renumbering event or change in some of the configuration parameters cannot be notified to the clients by the stateless DHCPv6 server. This specification provides a solution for this. "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. "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, 11-Oct-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, 6-Oct-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'. "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. "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. "Calendar Server Extensions for WebDAV (CalDAV)", Lisa Dusseault, 28-Oct-04, This document specifies a set of methods, headers and resource types that define the calendaring and scheduling extension to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring an intereropable standard that supports single-user calendar access, calendar sharing, and calendar publishing. "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. "Tags for Identifying Languages", Addison Phillips, Mark Davis, 12-Nov-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). "UDT: A Transport Protocol for Data Intensive Applications", Yunhong Gu, Robert Grossman, 16-Sep-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. "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. "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. "The SEED Encryption Algorithm", Jongwook Park, 30-Aug-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). "BGP/MPLS IP VPNs over Layer 2 Tunneling Protocol ver 3", Mark Townsley, 27-Oct-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: A Method for Traffic Separation on an Ethernet Access Network", Torben Melsen, Steven Blake, 15-Sep-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. "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. "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. "6to4 Reverse DNS Delegation", Geoff Huston, 6-Oct-04, This memo describes a potential mechanism for entering a description of DNS servers which provide "reverse lookup" of 6to4 addresses into the 6to4 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 IPv6 /48 address prefix corresponds to the requested delegation point. "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. "Applicability Statement of NSIS Protocols in Mobile Environments", Roland Bless, Sung-Hyuck Lee, 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. "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 EAP Method", Florent Bersani, 9-Nov-04, This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). In case mutual authentication is successful, EAP-PSK provides a protected channel for both parties to communicate over. In this document, this protected channel is used to exchange protected result indications. In the future, it may be used to implement extensions for EAP-PSK. "Considerations in Validating the Path in Routing Protocols", Russ White, Bora Akyol, Nick Feamster, 5-Oct-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. "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. "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 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"). "Sockets Direct Protocol (SDP) for iWARP over TCP", James Pinkerton, 30-Aug-04, SDP is a byte-stream transport protocol that closely mimics TCP's stream semantics. SDP utilizes iWARP's advanced protocol offload, kernel bypass, and zero copy capabilities. Because of this, SDP can have lower CPU and memory bandwidth utilization when compared to conventional implementations of sockets over TCP, while preserving the familiar byte-stream oriented semantics upon which most current network applications depend. "LDP graceful restart for planned outages", Ina Minei, 22-Oct-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). "EAP Method Requirements for Wireless LANs", Dorothy Stanley, Jesse Walker, Bernard Aboba, 10-Aug-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. "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. "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, 6-Oct-04, This document provides a mechanism by which the DHCPv4 servers can provide information about the IPv6-over-IPv4 tunnel endpoint. The IPv4/IPv6 dual stack nodes can use this information to set up a tunnel to the tunnel endpoint to obtain IPv6 connectivity without requiring manual intervention at any of the tunnel endpoints at tunnel establishment time. "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, 28-Oct-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, 10-Aug-04, This specification designs an architecture that aims at load balancing flows along multiple routes according to a measure of their average traffic loads. This architecture supports such a service due to the operation in a closed loop of an enhanced routing control plane with an enhanced forwarding plane. Basically, this routing paradigm allows a second dynamic metric called load to be taken into account when calculating new routes and when forwarding the flows along the routes. "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. "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, 9-Sep-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, 27-Oct-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, 17-Sep-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. "Definitions of Entity Manufacturing and URN Managed Objects", Kaj Tesink, 18-Aug-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]. "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. "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. "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. "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. "Connectivity Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, 27-Oct-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. "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. "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, 15-Sep-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, 27-Oct-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. "RTP No-Op Payload Format", Flemming Andreasen, 26-Oct-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. "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. "Transporting Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 13-Oct-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). "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, 6-Oct-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. "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. "Marking Mail Transfer Agents in reverse DNS with TXT RRs", Markus Stumpf, 21-Oct-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. "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 Message Header Field", Martin Duerst, 26-Oct-04, This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message "VPLS Applicability", Marc Lasserre, X Xiao, Cesar Garrido, Yetik Serbest, 30-Aug-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, 26-Oct-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. "U-turn Alternates for IP/LDP Fast-Reroute", Alia Atlas, 27-Oct-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 U-turn alternates for IP Fast-Reroute, this document defines three bits in the proposed link capabilities extension. "ISIS Extensions for Signaling Local Protection Capabilities", Alia Atlas, 26-Oct-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. "Emergency Services for Internet Telephony Systems", Henning Schulzrinne, Brian Rosen, 25-Oct-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 (MSRP)", Aki Niemi, Miguel Garcia-Martin, 28-Oct-04, The Message Session Relay Protocol (MSRP) defines a mechanism for sending session-based instant messages. The session is negotiated 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 multi-party conference, etc. "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. "How to Gain Prominence and Influence in Standards Organizations", Donald Eastlake 3rd, 26-Oct-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]. "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", Joseph Salowey, 26-Oct-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. "Extension for EAP Authentication in IKEv2", Pasi Eronen, 19-Oct-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, 27-Oct-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. "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. "MIPv6 Authorization and Configuration based on EAP", Gerardo Giaretta, 12-Oct-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. "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. "LDAP Turn Operation", Kurt Zeilenga, 26-Oct-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, or to enable each peer to act as both client and server with respect to the other. "Route tags in OSPFv3", Sina Mirtorabi, 7-Sep-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, 29-Sep-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. "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, 26-Oct-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. Eventually P-IMAP aims at being neutral to the network transport neutrality. "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Xiaobao Chen, Mark Watson, Martin Harris, 5-Oct-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, 13-Aug-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. "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. "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. "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. "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, Reshad Rahman, 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. "BGP-based Auto-Discovery for L2VPNs", Susan Hares, Wei Luo, Paul Unbehagen, Vasile Radoaca, 1-Nov-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. "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. "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. "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. "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. "Problem Statement: HIP operation over Network Address Translators", Martin Stiemerling, 22-Oct-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, 28-Oct-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, 15-Oct-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. "Possible Deployment Scenarios for IPv6 Anycasting", Shingo Ata, 27-Oct-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. "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 "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. "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. "Address Management for Mobile SCTP Handover", Moon Jeong Chang, Meejeong Lee, Seok Koh, 12-Oct-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. "Multi-homing for small scale fixed network Using Mobile IP and NEMO", Kenichi Nagami, 28-Oct-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. "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. "Cost optimization based on Enterprise-ENUM", Andrzej Bartosiewicz, 3-Sep-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, 12-Oct-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. "IMAP4 POSTADDRESS extension", Alexey Melnikov, 15-Oct-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. "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, 25-Oct-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, 18-Aug-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 describes a similar mechanism for ISIS. This draft also describes an optional extension of Multi-topologies whereby some links might be excluded from the default topology. "Prototype of a Generic AAA Server", Cees de Laat, 4-Oct-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. "Email Submission Between Independent Networks", Carl Hutzler, Dave Crocker, Pete Resnick, Robert Sanderson, Eric Allman, 16-Sep-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. "Authenticated Service Identities for the Extensible Authentication Protocol (EAP)", Jari Arkko, Pasi Eronen, 27-Oct-04, EAP is usually used in an arrangement where the actual service (such as a wireless LAN access point) is separated from the authentication server. However, EAP itself does not have a concept of a service identity or its parameters, and thus the client usually does not authenticate any information about the service itself, even when a mutually authenticating EAP method is used. This document specifies a backward compatible extension to popular EAP methods for authenticating service related information, such as the identity and type of the offered service. A common parameter name space is created in order to ensure that the same kinds of identifiers can be authenticated independent of the choice of the EAP authentication method. "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. "Requirements for Assured Service Capabilities in Voice over IP", Michael Pierce, 21-Oct-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, 21-Oct-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, 21-Oct-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. "Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB)", Steve Silverman, Michael Pierce, Don Choi, 6-Oct-04, Some networks require certain packet flows to be transported with preferential treatment over others of the same type (e.g., voice or video). This document defines a new PHB (Per Hop Behavior), the Multi-Level Expedited Forwarding (MLEF) PHB, which is a minor extension to EF defined in RFC 3246. RFC 3246 defines the Expedited Forwarding PHB for applications requiring low latency, but with a single DSCP and treatment per queue. Although EF suggests that packet discard should be used to achieve this behavior, it does not define an algorithm for packet discard. This document extends that concept and defines a PHB with multiple discard 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. "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. "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. "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. "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Jordi Palet, Miguel Diaz, 26-Oct-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, 28-Oct-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]]]. "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. "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, 26-Oct-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, 26-Oct-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. "Mediating Network Discovery in the Extensible Authentication Protocol (EAP)", Farid Adrangi, 25-Oct-04, This document defines a mechanism that allows an access network to provide identity selection hints to an EAP client. The purpose is to help the client in selecting the most appropriate identity and NAI decoration to use. This solution is especially useful in roaming scenarios where the access network does not have a direct relationship with the client's home network, but instead a mediating network, such as a roaming consortium or broker, is used. "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. "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. "Generalized Traffic Engineering Protocol", Eiji Oki, 29-Oct-04, This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between a Path Computation Element (PCE) 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. PCE provides a function of traffic engineer-ing, which calculates LSP routes and judges whether a new lower-layer LSP should be established and whether an existing lower-layer LSP should be released. "Stream Control Transmission Protocol (SCTP) Security Threats", Randall Stewart, 16-Sep-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, 11-Oct-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.] "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. "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, 11-Oct-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. "SIP Reason header extension for indicating redirection reasons", John Elwell, 21-Oct-04, This examines the need for signalling additional information concerning the reason for redirection in SIP and proposes an extension to the Reason header. "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, 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, 23-Aug-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, 18-Aug-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 "TLS Session Resumption without Server-Side State", Joseph Salowey, 23-Aug-04, This document describes a mechanism which enables the TLS server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This mechanism makes use of TLS extensions. "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, 25-Oct-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. "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-Sep-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, 26-Oct-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. "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, 15-Oct-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, 15-Oct-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, 11-Aug-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, 21-Oct-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, 2-Nov-04, This document describes a mechanism to establish traffic engineering IP tunnels. Resource ReSerVation Protocol (RSVP) is used as a signaling protocol described in Generalized Multi-Protocol Lable Swithing (GMPLS) RSVP Traffic Engineering technology, but no MPLS forwarding capability is assumed on the switched path. IP routing is used to switch IP traffic trunks. A simple GMPLS RSVP Traffic Engineering extension is needed to setup the IP Route Switched Paths (RSPs). "Using IPsec to Secure IPv6-over-IPv4 Tunnels", Hannes Tschofenig, 26-Oct-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, 22-Oct-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, 26-Oct-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 timestamp (RFC 1323) 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, 11-Aug-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, 14-Oct-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. "Use of Context Transfer Protocol (CTP) for PANA", Julien Bournelle, 22-Oct-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, 19-Aug-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, 29-Sep-04, In this document we first identify the (neighbor-AS based) Group Best Paths for an address prefix as the sufficient subset that can be advertised by a BGP route reflector or a BGP confederation ASBR to eliminate the MED-type route oscillations in a network. We then propose a BGP extension to support the advertisement of the Group Best Paths by a route reflector or a confederation ASBR. The extension also allows the advertisement of all the paths in a group that survive the MED comparison, thus achieving the same routing consistency as the full IBGP mesh. The proposed mechanisms are designed such that the vast majority of the BGP speakers in a network need only minor software changes in order to deploy the mechanisms. "TCP's Reaction to Soft Errors", Fernando Gont, 25-Oct-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, 19-Aug-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, 9-Nov-04, This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two 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, 26-Oct-04, This document defines and describes the use of u-turn alternates to provide local protection for IP unicast and/or LDP traffic in the event of a single link or node failure. When a topology change occurs, a router S pre-computes for each prefix an alternate next-hop that can be used if the primary next-hop fails. An acceptable alternate can be either a loop-free alternate or a U-turn alternate. A U-turn alternate uses a neighbor, whose primary next-hop to the prefix is router S itself and which has itself 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, 3-Sep-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, 25-Oct-04, Optical transport networks operated using a GMPLS-based control plane enable todays 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. These can be key to efficient network operation while providing strict performance guarantees. In that context, several areas of work still need to be addressed within the CCAMP WG of the IETF to develop interoperable, standards-based solutions that carriers can embrace. Towards that end, 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 on them. This is to enable the CCAMP WG to pursue ongoing and further work in this area that is focused towards addressing the identified carrier requirements. "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, 21-Oct-04, This document outlines work to be done and documents to be produced by the Operational Security Capabilities (OPSEC) Working Group. The goal of the working group is to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. The intent is to provide clear, concise documentation of capabilities 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 a list of capabilities appropriate for large Internet Service Provider (ISP) and Enterprise Networks. This work is intended to refine [RFC3871]. "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, 27-Oct-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. "RMD-QSP: An NSIS QoS Signaling Policy model for Networks Using Resource Management in Diffserv (RMD)", Attila Bader, 21-Oct-04, This document describes an NSIS QoS Signaling Policy model for networks that use the Resource Management in Diffserv (RMD) concept. 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. "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, 27-Oct-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, 25-Oct-04, This document clarifies the processing and behaviour of a host for the M and O flags of IPv6 Router Advertisement and proposes a solution for invoking the DHCPv6 service based on administrator policy in conjunction with new host variables for the M and O flags. "Service Mediation between Layer-2 and PWE3/L2VPN Networks", Hamid Ould-Brahim, 26-Oct-04, [SWALLOW-IW] describes an approach for interworking a native ATM SPVC segment with an ATM/FR-based pseudowire. The approach requires that an ATM edge device to encode the remote MPLS provider edge IP address within the NSAP destination address per call-basis, and covers mostly ATM and FRF.8 specifications. This draft covers other scenarios where a) the native layer-2 edge doesn’t have a priori knowledge of the remote PE IP addresses, b) the Layer-2 Provider Edge and the layer-2 network can be native Frame Relay (FR) using native layer-2 signaling protocols, c) the native layer-2 network can use not only NSAP addressing but as well E.164, X.121, or any preferred native addressing scheme, and d) the interface between the MPLS/IP network and native layer-2 network can be FRF.10/X.76 interface. We refer to the above problem space as "Service Mediation" to indicate that the native layer-2 signaling is terminated at the MPLS/IP device attached to the layer-2 network and the "mediated" service is an end-to-end connection built from two segments: one segment is in its native layer-2 form which we denote as Native Wire (NW) established using native layer-2 signaling protocols and the other segment is a pseudowire (PW) established using PWE3/L2VPN signaling protocols. "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, 28-Oct-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, 13-Oct-04, When multiple Mobile Routers share the same prefix, a Home Agent must be able to verify whether the Mobile Routers share the same Mobile Network or not. Otherwise, the Home Agent may not be able to forward a data packet to a correct recipient since the recipient 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 multiple 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, 25-Oct-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 currently attached link by consulting the existing prefix list. This memo describes how to generate the complete prefix list and to robustly detect the link identity 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, 27-Oct-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, 26-Oct-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, 26-Oct-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, Jonathan Rosenberg, Gonzalo Camarillo, 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, 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, 22-Oct-04, The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is aborted. TCP implementations typically use a single, system-wide user timeout value. The TCP User Timeout Option allows conforming TCP implementations to exchange requests for individual, per-connection user timeouts. Lengthening the system-wide default user timeout allows established TCP connections to survive extended periods of disconnection. On the other hand, shortening the default user timeout allows busy servers to explicitly notify their clients they will maintain the connection state information only accross short periods of disconnection. "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, 25-Oct-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 Original BGP Next Hops", Rahul Aggarwal, 16-Aug-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 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, Ali Sajassi, 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, 16-Aug-04, The IPv6 128-bit address space was designed as a solution for the 32-bit limitation of IPv4, but the proliferation of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs). For these reasons, deployment of IPv6 at the end nodes with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. This document proposes a coexistence scenario with IPv6 for end to end addressing and IPv4 for network traversal. "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. "RADIUS Extensions for IEEE 802", Paul Congdon, 11-Aug-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). "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. "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. "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, 26-Oct-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, 26-Oct-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. Clients that implement the Diameter QoS Application contact an authorizing entity/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, 27-Oct-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. "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. "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, 26-Oct-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, 9-Nov-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, 28-Oct-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, 14-Oct-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, 28-Oct-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-Sep-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 connectivity indicators. One example of such a connectivity indicator is "first hop router reachable." This document does not define the specifics of such connectivity indicators, although it describes some examples. Instead, it defines how a conforming TCP implementation operates when it receives a connectivity indicator. "Requirements for Path Computation Element in GMPLS and IP/MPLS Networks", Eiji Oki, 29-Oct-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, 27-Oct-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, 27-Oct-04, This document provides an applicability analysis on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to satisfy the requirements of Layer 1 Virtual Private Networks (L1VPNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy the requirements of L1VPNs, and provides guidelines for potential extensions. "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, 27-Oct-04, This document describes how the IP Flow Information Export (IPFIX) protocol should be mapped to the Transmission Control Protocol (TCP), including how Transport Layer Security (TLS) can be used with this mapping. "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. "GMPLS Inter-domain Traffic Engineering Requirements", Tomohiro Otani, 22-Oct-04, This draft provides requirements for the support of generalized multi-protocol label switching (GMPLS) inter-domain traffic engineering (TE). Its main objective is to present the differences between MPLS inter-domain TE and GMPLS inter-domain TE. This draft covers not only GMPLS Inter-domain architecture but also functional requirements in terms of GMPLS signaling and routing in order to specify these in a GMPLS Inter-domain environment. "Unified L2 Abstractions for L3-Driven Fast Handover", Koki Mitani, 27-Oct-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, 29-Sep-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, 25-Oct-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''. "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 "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 Intra-NE Topology Discovery", Furquan Ansari, 29-Oct-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, I Robredo, 12-Nov-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 abstract the ownership behavior of resources available in interoperable environnments, such as 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, Julien Laganier, 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, 28-Oct-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, 29-Oct-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 PCE-based backup path computation. 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. "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. "Server/Application State Protocol v1", Alan Bivens, 20-Oct-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-Oct-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, 27-Oct-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, 12-Nov-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, 27-Oct-04, This document proposes a PW encapsulation specific to IP packets, the IP Pseudowire, following the architectural principles defined in [PWE3 Architecture]. This proposal introduces an optional CW for IP encapsulation. Note that when the inclusion of a control word is not negotiated, the IP PW uses the encapsulation described in [RFC3032]. "Framework for Netconf Data Models", Sharon Chisholm, 27-Oct-04, This memo defines a framework for defining content for Netconf. "Security Best Practices Efforts and Documents", Chris Lonvick, 21-Sep-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. "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. "ICMP attacks against TCP", Fernando Gont, 9-Sep-04, This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes a work-around to eliminate or minimize the impact of this type of attack. "Increasing the payload of ICMP error messages", Fernando Gont, 3-Aug-04, The original ICMP specification states that when a packet elicits an ICMP error message, the IP header plus the next 64 bits of the original datagram must be returned in the payload of the ICMP error message. This imposes a constraint on the design of transport-layer protocols, which are forced to include all the relevant information needed to identify an instance of communication in the first 64 bits of their protocol header. It also limits the amount of data from the original packet available to the transport-layer when acting on the ICMP error message. Including only the first 64 bits of the original datagram's payload may also not be enough to demultiplex ICMP error messages if IP is being used to tunnel some other network-layer protocol. This document proposes to increase the amount of data of the original datagram to be included in the payload of ICMP error messages. "VPLS Node Auto Auto-Discovery Using IGP", Oded Bergman, 3-Aug-04, This Internet Draft describes a method for automatic discovery of Virtual Private LAN Service (VPLS) PE nodes and services, in order to establish VPLS networks. "UDDI URI Scheme Registration with IANA", Andrew Hately, Karl Best, 3-Aug-04, This IETF document reproduces the UDDI keying scheme definition found in the OASIS UDDI Version 3 Specification [2] and is published as an RFC for ease of access and IANA registration. Change control is retained within OASIS "The Real Time Streaming Protocol (RTSP) and Session Description Protocol(SDP) Static Dictionary for Signaling Compression (SigComp)", Susan Choudhary, Jasdip Singh, 3-Aug-04, The Real Time Streaming Protocol (RTSP) is a text-based protocol for controlling the delivery of real-time data. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the RTSP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. The document provides a new static dictionary for RTSP and SDP. The dictionary is to be used in conjunction with RTSP, SDP and SigComp. "Per VPN Routing for Layer 3 PPVPNs", Girish Bhat, 3-Aug-04, This document describes a method to do Per VPN routing for L3 PPVPNs. The solution uses BGP for auto-discovery of VPN membership, but uses Per VPN RIP instances and dynamic MPLS tunnel interfaces to exchange customer routes. The document proposes modifications to the RIP protocol to the make the solution scalable. The framework presented also supports deployment of multicast routing and forwarding for L3 PPVPNs without enabling multicast in the core. "Simple Path Control Protocol Specification", David Lillethun, 3-Aug-04, The Simple Path Control Protocol (SPC) defined in this document is a new protocol defined to enable processes external to networks to establish, delete and monitor paths, including lightpaths. The architecture of this protocol establishes a method of providing messages, and procedures that allow such external processes to use those messages to directly request network resources related to path provisioning. "Guidelines for Writing an IANA Considerations Section in RFCs", Thomas Narten, Harald Alvestrand, 17-Sep-04, Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication trans- form for IPsec). To ensure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF pro- tocols, that role is provided by the Internet Assigned Numbers Authority (IANA). "E-DHCP: Extended Dynamic Host Configuration Protocol", Jacques Demerjian, 9-Aug-04, This document proposes an extension to DHCP protocol called E-DHCP (Extended-Dynamic Host Configuration Protocol) in order to allow a strict control on the equipments through a strong authentication process. "A Proposed Media Delivery Index", James Welch, James Clark, 9-Aug-04, This memo defines a Media Delivery Index (MDI) measurement which can be used as a diagnostic tool or a quality indicator for monitoring a network intended to transport streaming media such as MPEG video or other arrival time and packet loss sensitive information. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and data loss at-a-glance. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying constant bit rate streaming media. Included is a set of managed objects for SNMP-based management of IP media streams for which an MDI measurement is obtained. "A generalization of Delegation Signer Resource Record (DS RR) use", Gilles Guette, 18-Aug-04, This document defines a generalization of the DS RR use in order to reduce the number of secure entry points in a resolver and in order to create a secure link between islands of security. This allows to simulate a secure spanning tree among all secure zones and reduce the number of non secure name resolutions. "Interoperability Test Spec for SUA (SIGTRAN)", Vivek Bansal, 10-Aug-04, These test specification are to test the interoperability between different SUA implementations is based on SCCP User Adaptation Layer protocol (SUA), as described in IETF draft "S/MIME Capabilities in X.509 certificates", Stefan Santesson, 10-Aug-04, This document defines a certificate extension for inclusion of S/MIME capabilities in public key certificates as defined by RFC 3280. S/MIME Capabilities provides a method of broadcasting the cryptographic S/MIME capabilities of the certified subject as a complement to use of S/MIME Capabilities signed attributes as defined in RFC 3851. "Subordinate Subtree Search Scope for LDAP", Jim Sermersheim, 26-Oct-04, The Lightweight Directory Application Protocol (LDAP) specification supports three scope values for the search operation -- namely: baseObject, singleLevel, and wholeSubtree. This document introduces a subordinateSubtree scope which constrains the search scope to all subordinates of the named base object. "Dynamic Multi-Source Discovery for SSM using MSDP", Rami Lehtonen, 20-Oct-04, This draft specifies dynamic multi-source discovery for source-specific multicast (SSM). The source discovery is handled by the end-hosts and multicast routing has to be only SSM aware. The source discovery is achieved by sending MSDP Source Active messages through the original SSM channel. The support can be implemented on the application level. "Server Index Query (SIQ) Protocol", Anthony Howe, 11-Aug-04, The Server Index Query (SIQ) protocol is intended to provide a standard means by which a mail exchange (MX) server can query one or more external services for scoring based on facts or reputation of an IP/domain pair. This document specifies the communication protocol used to transmit the IP/domain query and return the query response. The implementation, correctness of results, and/or management of SIQ servers is beyond the scope of this document. "SIMCO Protocol Implementation Interoperability Report", Martin Stiemerling, 11-Aug-04, This memo summarizes the results of the first interoperability event for the Simple Middlebox Control (SIMCO) protocol. SIMCO is an implementation of MIDCOM for controlling middleboxes, such as firewalls and NATs. The test scenarios are described and the results of each scenario for each implementation is given. Finally, enhancements to be made to the SIMCO protocol specification are listed. "Handoff and Resource Management for Multi-homed Networks", Mazen TLAIS, 12-Aug-04, Multi-homed networks based on IPv6 form an important architecture within the NEMO (NEtwork MObility) configurations. Mainly in these networks the Mobile Router (MR) can appear in the neighbourhood of several Access Routers (ARs). In this case, MR has several egress interfaces and can detect several ARs simultaneously. This draft introduces a protocol that achieves handoff and resource management in a NEMO network in the case of multi-homed MR. We called this protocol an HRMMN protocol (Handoff and Resource Management for Multi-homed Networks). We introduce into the NEMO architecture an intelligent control entity called Access Router Controller (ARC). Based on traffic information transmitted through several ARs under the control of specific ARC, this latter is responsible of taking decisions about handoff, resource management and maintain of multiple bidirectional tunnels. "HTMLX: Simple Well-Formed Format For Legacy HTML Documents", Ted Shaneyfelt, 16-Aug-04, Changing some legacy Htpertext Markup Language (HTML) documents to XHTML format would require certain tags to be dropped. Not changing them to some sort of Extensible Markup Language (XML) would prevent their use by new tools. "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 12-Aug-04, This document clarifies and generalizes the GSS-API "channel bindings" facility. This document also specifies the format of the various types of channel bindings. "Pre-Shared-Key key Exchange methods for TLS", Mohamad Badra, 12-Aug-04, This document specifies new key exchange methods for Transport Layer Security protocol to support authentication based on pre installed key and to allow anonymous exchanges, identity protection And Perfect Forward Secrecy. "IPsec transport mode in Mobike environments", Francis Dupont, 25-Oct-04, This document specifies how to use IPsec transport mode security associations in a Mobike environment, i.e., in an environment with sequential (mobility) or parallel (multi-homing) addresses. "An Architecture for Transport Layer Mobility", Wesley Eddy, 16-Aug-04, This document describes a generalized architecture for implementing mobility in the transport layer rather than the network layer. In addition, the document discusses the advantages of this approach, the basic mechanisms and interactions required to support transport layer mobility, and examples of how to enable mobility in various transport protocols, using this architecture. "Thoughts About Layer 3.5 Redirection Security", Iljitsch van Beijnum, 16-Aug-04, The new multi6 design team as of august 2004 is chartered to explore multihoming by means of a "layer 3.5 wedge" that allows unmodified applications and transport protocols to become address agile. In order to do this, the two hosts involved must communicate certain parameters. The exact nature of this communication isn't specified at this time. However, this document discusses certain security issues pertaining to such communication. "RFC 1888 is obsolete", Brian Carpenter, 16-Sep-04, This document recommends that RFC 1888, on OSI NSAPs and IPv6, be reclassified Historic as most of it has no further value, apart from one section which is faulty. "RADIUS Shared Secret Security Amplification", Paul Funk, 27-Aug-04, This draft describes how a mechanism defined in [PKCS-5] can be used to amplify the security of a RADIUS shared secret; namely, that a precursor secret is hashed many times to produce an amplified shared secret for use in RADIUS. "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman Asadullah, 22-Oct-04, This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistance with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies using tunneling mechanisms and native IPv6. "Mail Policy Records (MPR)", Douglas Otis, 18-Aug-04, For domains sending or receiving mail, there is often a desire to publish policies indicating types of mail sent or accepted, and to specify the collateral Mail Channel to assist in these policies. The challenge is to allow the recipient a deterministic means for obtaining this information, while not creating additional burdens for normal mail use. "Media Type Specifications and Registration Procedures", Ned Freed, John Klensin, 18-Aug-04, This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. "IPvLX: IPv6 Addressing in the IPv4 Internet", Fred Templin, 30-Aug-04, The IPv6 128-bit address space was designed as a solution for the 32-bit limitation of IPv4, but deployment of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs). For these reasons, use of IPv6 at the end nodes with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. This document proposes IP Virtual Link Extension (IPvLX): a new encapsulation method for IPv6 addressing in IPv4 networks. "The file URI Scheme", Paul Hoffman, 20-Sep-04, This document specifies the file: Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "The ftp URI Scheme", Paul Hoffman, 21-Oct-04, This document specifies the ftp: Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "The gopher URI Scheme", Paul Hoffman, 20-Sep-04, This document specifies the gopher: Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "The news and nntp URI Schemes", Paul Hoffman, 21-Oct-04, This document specifies the news and nntp Uniform Resource Identifier (URI) schemes that were originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "The prospero URI Scheme", Paul Hoffman, 20-Sep-04, This document specifies the prospero: Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "The telnet URI Scheme", Paul Hoffman, 27-Oct-04, This document specifies the telnet: Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "Goals for Zero-Configuration Tunneling", Maria Morelli, 2-Sep-04, This document describes the set of goals to be fulfilled by a Zero- configuration tunneling protocol. Zero-configuration tunneling here denotes a minimalistic IPv6-in-IPv4 automatic tunneling mechanism that could be used by a Service Provider to offer IPv6 connectivity to its customers in early phases of IPv4 to IPv6 transition. "Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 2-Sep-04, This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish-subscribe functionality. "Internet Security Glossary, Version 2", Rob Shirey, 23-Aug-04, This Glossary has 1,500 entries that give definitions, abbreviations, and explanations for terminology concerning information system security. It makes recommendations to improve the clarity of Internet Standards documents (ISDs) and the ease with which international readers can understand ISDs. Its follow the principles that ISDs should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that are proprietary, favor a particular vendor, or create a bias toward a particular technology or mechanism versus other, competing techniques that already exist or might be developed. "Distributed Procedures for LDAP Operations", Jim Sermersheim, 26-Oct-04, This document provides the data types and procedures used while servicing Lightweight Directory Application Protocol (LDAP) user operations in order to participate in a distributed directory. In particular, it describes the way in which an LDAP user operation in a distributed directory environment finds its way to the proper DSA(s) for servicing. "The wais URI Scheme", Paul Hoffman, 20-Sep-04, This document specifies the wais: Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. "NoReply Header Fields for Internet Mail", Keith Moore, 25-Aug-04, This memo introduces new header fields for use in Internet email, to allow the author of a message to specify primary (To) and secondary (Cc) recipients who, in the author's opinion, should not be recipients of a reply to the message. These new fields are designed to be highly compatible with pre-existing mail handling programs, and to facilitate a graceful transition. If this document is favorably received, it is the author's intent to submit this document (as an individual submission) for consideration for Proposed Standard status. Unless IESG directs otherwise, public discussion of this document should be on the ietf-822@imc.org mailing list. Comments may also be sent to the author. "Guidelines for an Arabic Domain Name System", Mansour Farah, 25-Aug-04, There have been several attempts aimed at developing an Arabic Domain Name System using Arabic characters in an Arabic-language coherent fashion. To satisfy this demand, an entire environment needs to be developed in order to take into account technology standardization, policy and administrative arrangements, as well as new applications. In the beginning of the second quarter of 2003, an Arabic Domain Name Task Force (ADNTF) was formed under the auspices of United Nations Economic and Social Commission for Western Asia (ESCWA), and the guidance of Multilingual Internet Names Consortium (MINC); one of its main objectives was to help define standards for ADNS through a Request For Comments (RFC) document. This document resolves many technical and linguistic issues, including the adoption of the client-side DNS-based approach to name resolution; syntax of the proposed Arabic Domain Names together with the character set and many Arabic language-specific issues were clearly resolved. This Internet-Draft proposes guidelines that are compatible with the Internet Consortium for Assigned Names and Numbers (ICANN) and the Internet Engineering Task Force (IETF) as far as Domain Names System (DNS) and Internationalized Domain Names (IDN) standards are concerned. Technical, management, operational, and language-specific issues are discussed and recommendations are made. "Getting rid of the cruft: A procedure to deprecate old standards", Harald Alvestrand, Eliot Lear, 13-Sep-04, This document describes a procedure for performing the downgrading of old standards described in RFC 2026, as well as BCPs, without placing an unreasonable load on groups charged with performing other tasks in the IETF. "Multicast in BGP/MPLS VPNs and VPLS", Rahul Aggarwal, 28-Oct-04, This document describes a solution framework for overcoming the limitations of existing Multicast VPN (MVPN) and VPLS multicast solutions. It describes procedures for enhancing the scalability of multicast for BGP/MPLS VPNs. It also describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. The procedures described here reduce the overhead of PIM neighbor relationships that a PE router needs to maintain for BGP/MPLS VPNs. They also reduce the state (and the overhead of maintaining the state) in the SP network by removing the need to maintain in the SP network at least one dedicated multicast tree per each VPN. "Mobile Transmission Control Protocol (MTCP) for Mobility Management over IP networks", Yujun Kuang, 25-Aug-04, This document defines two types of IP addresses to support mobile TCP - one for routing and location management, the other for host identification. Therefore, the dependency of TCP/UDP socket identification upon the network layer is eliminated, and transmission sessions will be no longer dependent of network layer IP address, that is, location changes of a mobile host result only new network IP address, which has no impact on transmission communications and its continuity. "RIPv2 Cryptographic Authentication", Randall Atkinson, 26-Aug-04, This note describes a rough draft of a proposed revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC-2082. This document includes specific details of how HMAC SHA-1 is used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and also adds significant text to the Security Considerations section. "IETF Administrative Support Functions", Carl Malamud, 13-Sep-04, This Internet-Draft discusses the restructuring of administrative support functions for the IETF. The draft begins with a discussion of prior steps in the process that led up to this report and discusses the process going forward. The draft then examines the current functioning of administrative support functions, analyzes options for restructuring operational functions, and analyzes options available to provide an institutional framework for such support. "SMTP Service Extension for Reliable Submission", Eric Burger, 27-Aug-04, There is an issue with SMTP that RFC1047 raised in 1988. The time between a SMTP client submitting a mail object and the SMTP server responding to the request can be arbitrarily long. SMTP addresses this issue by a hack, hoping that the SMTP server responds fast enough and the SMTP client waits long enough to find out if the submission was successful. "SMTP Service Extension for Detached Operation", Eric Burger, 27-Aug-04, The normal operation for the Simple Mail Transfer Protocol (SMTP) is for the submitting device to wait for all processing to complete and for the server to return a positive acknowledgement to the client. However, some devices have very intermittent connectivity, such as wireless mobile terminals. For such devices, a means to have processing continue in the case of a dropped connection is desirable. To this end, this SMTP service extension enables a client to submit a message and reliably detach from the session, indicating to the server to continue in the absence of a connection to the client. "Accounting Issue in Well Managed IP Multicasting Services", Tsunemasa Hayashi, 29-Oct-04, This I-D describes problems on accounting issues in multicasting. General requirements for accounting capabilities including QoS related issues are listed. This I-D assumes that these capabilities can be realized by appropriate functions implemented at edges of a network based on IGMP or MLD. Such functions would log in a dedicated database information obtained from edge routers. Finally, a case for CDN services is described as an application example which could benefit from multicasting with accounting capabilities. It is proposed that this I-D be used as a starting point for further discussion on these issues. "Improvement of Return Routability Protocol", Ying Qiu, 30-Aug-04, This document proposes an improved security solution for Return Routability (RR) protocol without changing the architecture. With the improvement, three types of redirect attacks can be prevented. "BinaryTime: An alternate format for representing date and time in ASN.1", Russell Housley, 24-Sep-04, This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. "Instructions to Request for Comments (RFC) Authors", Paul Hoffman, 13-Sep-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. "Interoperability between all NFS versions and local filesystem", Aditya Pandit, 1-Sep-04, NFS (Network File System) version 4 is a major rewrite of NFS. NFS version 4 has lot of new features added into the protocol and the behavior is changed a lot from the predecessors. This Draft considers the interoperability problems of all versions of NFS and local filesystem. Yet, access to any one file system through the NFS v2 or NFS v3 or NFS v4 protocol requires that a single server be accessed. This draft tries to suggest the behavior that could be expected when NFS version 4 is used in multi-protocol environment with NFS version 2 and version 3. "Marketing Buzzword "SIPPING 16" Considered Harmful", , 1-Sep-04, The Session Initiation Protocol (SIP) has become very popular, and with this popularity, the harmful misconceptions that there is a specific limit to the number of features that can be implemented using SIP primitives, and that informational documents produced by the SIPPING Working Group that show example call flows place restrictions on what can be implemented. One especially catchy buzzword--The "SIPPING 16"--supposedly refers to the sixteen basic features of SIP. This document describes why the mythical SIPPING 16 does not exist, and where to find out more information about SIP features. "Using Universal Content Identifier as Uniform Resource Names", Sang-ug Kang, 2-Sep-04, This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as musics, videos, texts, images, e-books and other types of digital resources produced or managed by NCA. "The NetIQ Common Agent Protocol", Roger Huebner, 2-Sep-04, This document outlines the protocol used by the NetIQ Common Agent as part of its NetIQ Common Agent Protocol (NCAP). This binary protocol is used over standard TCP sockets and provides both real-time event delivery and common RPC services to the NetIQ Common Agent Framework. These messages may be encrypted via SSL based on the handshake received during intial negotiation. Messages consist primarily of a standardized header and a variable-length body. Both message header and content are stored in sender-native form, pursuant to a reader-makes-right data flow. "Command Additions for Dynamic Authorization Extensions to Remote Authentication Dial-In User Services (RADIUS)", Murtaza Chiba, 2-Sep-04, This draft proposes to expand RFC3576 by adding commands that allow for, amongst other things, a query interface and ways to characterize the Change of Authorization messages. "MIME Sub-type Registrations for FITS", Steven Allen, 2-Sep-04, This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of FITS files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged using FITS. "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", Susan Harris, Paul Hoffman, 21-Oct-04, This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. "Addition of SEED Ciphersuites to Transport Layer Security (TLS)", Hyangjin Lee, 3-Sep-04, This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. "A string encoding of Presentation Address", Steve Kille, Alexey Melnikov, 21-Oct-04, There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This is a revision of RFC 1278. This document also defines a string representation for IPv6 network addresses as defined in RFC 1888 and draft-melnikov-nsap-ipv6-XX.txt. "STODER: A Reliable TCP Spurious Timeout Detection Algorithm using Repacketization", Qian Zhang, 7-Sep-04, Spurious timeouts are not rare events in wireless wide-area network, e.g. GPRS or EDGE. It has been reported that spurious timeouts greatly decrease TCP's performance in many aspects. It is not only because of the unnecessary retransmission of the last window of data, but also the congestion control is falsely triggered. Existing proposals of detecting spurious timeouts either require additional information on each data packet, e.g., the timestamps option, or heuristically deduce spurious timeouts. These approaches need heuristic feedbacks from the receiver, and hence are vulnerable to misbehaving receivers. In this document, a novel algorithm that reliably detects spurious TCP retransmission timeouts, called STODER, is presented. STODER is a TCP sender algorithm and does not require any information attached on data packets. STODER exploits TCP repacketization to detect false retransmission and is well protected against malicious receivers. Therefore, a more aggressive response algorithm can be safely applied along with the STODER algorithm. "Network Address to support OSI over IPv6", Alexey Melnikov, 7-Sep-04, This document defines a format for OSI NSAP Addresses for use where TCP or UDP is used to provide the OSI Network Service over IPv6, as in RFC 2126 (ISO Transport Service on top of TCP (ITOT)). This requires encoding of an IPv6 address and a port number in the NSAP. RFC 1277 defines an NSAP format for use with IPv4 addresses, and this document updates RFC 1277 to allow for IPv6 addresses. "Bounce Address Tag Validation (BATV)", John Levine, 7-Sep-04, The envelope of Internet mail contains an RFC2821.MailFrom command, which may supply an address to be used as the recipient of transmission and delivery notices about the original message. Existing Internet mail permits unauthorized use of addresses in the MailFrom command, causing notices to be sent to unwitting and unwilling recipients. Bounce Address Tag Validation (BATV) defines an extensible mechanism for validating the MailFrom address. It also defines an initial use of that mechanism which requires no administrative overhead and no global implementation. "IPv6 Tunnel End-point Automatic Discovery Mechanism", Jordi Palet, 26-Oct-04, Tunneling is commonly used by several IPv6 transition mechanisms. To be able to automate setting up tunnels, one critical component is a solution to automatically discover the tunnel end-point (TEP) for the transition mechanism. This memo proposes a solution for discovering the IPv6 TEP in a simple an efficient way. "Multiparty Communication Parameters and Metrics", Lei Liang, 9-Sep-04, The purpose of this memo is to highlight the new QoS requirements of the multiparty communication services in terms of measurement parameters. It tries to derive a set of parameter metrics from the existing one-way metrics in IP Performance metrics IPPM [2] [3] [4] for the multiparty communications to present these new requirements. These parameter metrics are supposed to provide methods and rules for engineers to measure and judge the QoS of the multiparty communications. "BGP Wedgies", Geoff Huston, Tim Griffin, 9-Sep-04, It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non- deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". "Time Zones in XML", Doug Royer, 10-Sep-04, The iCalendar data format is being updated and included in those discussions is the desire to update the time zone information. This is a proposal for time zone updates to iCalendar. The time zone information will be available in XML format. To comment on this document send email to ietf-calendar@imc.org . This document also specifies an IANA registration process for time zones. No attempt is made to specify any specific time zones as that is political information that is out of scope for this document. "AAA Mobile IPv6 Application Framework", Alper Yegin, 10-Sep-04, This document describes a framework for using AAA backend protocols (e.g., RADIUS, Diameter) between home agents and AAA servers for centralizing Mobile IPv6 service management. Implementation of this framework requires definition of a new AAA application on the aforementioned protocols. "Chargeable User Identity", Farid Adrangi, 26-Oct-04, This document describes a new RADIUS attribute used by a home RADIUS to indicate Chargeable User Identity to all parties involved in the roaming transaction outside the home network. "Service Provider requirements for PWs", Peter Willis, 10-Sep-04, This internet draft provides some requirements to help steer future PWE3 work from the perspective of a Service Provider. "Calendar Access Protocol (CAP)", Doug Royer, 4-Oct-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). "Requirements for IETF Draft Submission Toolset", Alex Rousskov, 26-Oct-04, This document specifies requirements for an IETF toolset facilitating Internet-Draft submission, validation, and posting. "Message Header for Indicating Sender Authentication Status", Murray Kucherawy, 10-Sep-04, This memo defines a new message header for use with [MAIL] messages to indicate the results of sender authentication efforts to mail user agents (MUAs) in order to equip them to relay that information in a convenient way to users. "Generic Security Service API Version 2 : Java & C# Bindings", Cameron Morris, 13-Sep-04, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document proposes an update to RFC 2853, Generic Security Service API Version 2 : Java Bindings, to include C# bindings. "A Modification to Make PAWS Robust to Segment Reordering", Noritoshi Demizu, 26-Oct-04, The purpose of PAWS (Protect Against Wrapped Sequence numbers), defined in RFC1323, is to protect a TCP connection against old duplicate segments from the same connection. There is a possibility, however, that PAWS may discard valid reordered segments. This memo proposes a modification to PAWS to solve this problem. "An Extended AAA Authorization Framework with Delegation", Yoshihiro Ohba, 13-Sep-04, This document extends the AAA authorization framework described in RFC 2904 in that some or all of the authorization task is delegated from the AAA server to a local network entity. The extension considers new AAA services such as PANA network access service and dynamic host configuration service that have different characteristics from legacy AAA services such as PPP service and IEEE 802.1X network access service. "MEGACO package for Push To Talk over Cellular (PoC) Networks", R Ezhirpavai, 14-Sep-04, Push To Talk over cellular (PoC) networks is supported through centralised Push To Talk Servers which handles both SIP signalling and the media (RTP) relay part. This document defines a distributed architecture for PoC Server implementation with PoC signalling server handling the SIP signalling and group management, whereas Media Server handles the RTP relay part and the communication between these two servers is over MEGACO protocol using the package defined in this document. "Why Authentication Data suboption is needed for MIP6", Basavaraj Patil, 14-Sep-04, The security for signaling messages between the mobile node and home agent in Mobile IPv6 is based on the existence of an IPsec SA between the two entities. I-D: draft-ietf-mip6-auth-protocol-00.txt specifies a mechanism to secure the binding update and binding acknowledgement messages using an authentication option carried within these mes- sages. This document captures the reasons why the authentication option mechanism needs to be standardized by the Mobile IPv6 working group. "Proposed RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base", Alan Clark, 14-Sep-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). "Overview of the Internet Multicast Addressing Architecture", Pekka Savola, 16-Sep-04, The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use "QoS Signaling in a Nested Virtual Private Network", Fred Baker, 24-Sep-04, Some networks require communication between an interior and exterior portion of a VPN, but have sensitivities about what information is communicated across the boundary. This note seeks to outline the issues and the nature of the proposed solutions. "Extended Option Space for TCP", Eddie Kohler, 20-Sep-04, This memo describes a reinterpretation of the TCP Data Offset field, affecting the previously illegal code points 0-4, that allows endpoints to fit more than 40 bytes of option into TCP segments. "Reasons to Deprecate NAT-PT", Cedric Aoun, 21-Sep-04, This document discusses reasons why use of the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766 should be deprecated and RFC2766 moved to historic status. Description of an alternative protocol translation mechanism is out of scope for this document. "Internationalized Domain Names Registration and Administration Guidelines for Arabic Characters Group of Languages (Arabic, Persian, Urdu,...)", Rifaah Ekrema, 21-Sep-04, Achieving internationalized access to domain names raises many complex issues. These issues are not only associated with basic protocol design (i.e., how the names are represented on the network, compared, and converted to appropriate forms) but also issues and options for deployment, transition, registration and administration. "A Framework for MPLS Operations", David Allan, Thomas Nadeau, 23-Sep-04, This document is a framework for how data plane OAM functions can be applied to operations and maintenance procedures. The document is structured to outline how OAM functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. "Symmetric RTP and RTCP Considered Helpful", Dan Wing, 8-Oct-04, This document defines symmetric RTP and symmetric RTCP and recommends their use. "Goals for AAA-HA interface", Gerardo Giaretta, 23-Sep-04, In commercial deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitely authorized and traced. A convenient approach to do that is to define an interface between the Home Agent (HA) and the AAA infrastructure of the MSP, which stores user's credentials and service profiles. The availability of this interface can be useful also to enable dynamic Mobile IPv6 bootstrapping on both the mobile node and the designated HA. This document describes various scenarios where an interface between the HA and the AAA infrastructure of the MSP is required. Furthermore, a list of design goals for this interface is provided. "Path Computation Element (PCE) Architecture", Adrian Farrel, 24-Sep-04, Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layers networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. "EAP Smart Card Protocol (EAP-SC)", Pascal Urien, 28-Sep-04, Smart Cards are hardware security devices that are widely used in data and voice networks to authenticate users and devices, and to enforce security policies on the client platform. "Request for the URN namespace "tib" for scientific primary data", Jan Brase, 28-Sep-04, The German research agency (DFG) has started a project in 2004 to improve the access to primary data especially for interdisciplinary data use. Publications of primary data should be citable as publications so that the data set may be cited together with the author when being used further. By this, scientific primary data should not be exclusively understood as part of a scientific publication, but may have its own identity. The data records remain at their research institutes, but the metadata records will be stored at the German national library of Science and Technology (TIB) as a central registration agency, the data records are identified with a DOI as a persistent identifier. In cooperation with the German Library the data record shall also be registered with an urn. "Transporting WebDAV-Related Event Notifications over the Extensible Messaging and Presence Protocol (XMPP)", Joe Hildebrand, Peter Saint-Andre, 29-Sep-04, This memo describes a method for notifying interested parties about WebDAV-related events (such as PUTs and DELETEs), where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish-subscribe functionality. "Algorithms for Internet Key Exchange version 1 (IKEv1)", Paul Hoffman, 20-Oct-04, The required and suggested algorithms in the original IKEv1 specification does not reflect the current reality of IPsec market. It requires allowing weak security and suggests algorithms that are thinly implemented. This document updates the original specification and is intended for all IKEv1 implementations deployed today. "ENUM Validation Information Mapping for the Extensible Provisioning Protocol", Bernie Hoeneisen, 30-Sep-04, This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers. "IETF: Proposed Organizational Changes", Patrice Lyons, 19-Oct-04, This memo outlines the nature of the Internet Engineering Task Force (IETF) as an unincorporated association, reviews some history of the IETF Secretariat relevant to the current structure of the organization, and proposes steps that might be taken to move forward in the interest of the Internet community more generally. Since the IETF serves as a focal point in the technical evolution of the Internet infrastructure, it is important that any organizational changes take into account the wider public interest. Considerations of who provides support to the IETF hinge on the legal status of the IETF itself. Steps should be taken to clarify this matter as a first priority. "An Extension to the Session Initiation Protocol (SIP) for Media Loopback", Kaynam Hedayat, 20-Oct-04, The wide deployment of VoIP and Video over IP services has introduced new challenges in managing and maintaining voice/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP or Video over IP service. Today in networks that deliver real-time media, short of running ' ping' and ' traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP and Video Over IP performance metrics. "Path Computation Model for Recovery LSPs Using External PCE", Nagao Ogino, 1-Oct-04, This document proposes a PC model, where the recovery LSP route in a domain is computed using an external PCE. Recovery LSP computation that promotes bandwidth sharing between other recovery LSPs requires unreserved bandwidth information that corresponds to each failure position or SRLG. However, the present IGP-TE can only advertise unreserved bandwidth information corresponding to eight priority classes to each LSR involved in an IGP area. An external PCE in a domain can compute efficient recovery LSP routes by exclusively preserving such unreserved bandwidth information without any extension of the present IGP-TE. "Distributing Keys for DNSSEC", Ben Laurie, 1-Oct-04, Until DNSSEC is fully deployed, so-called "islands of trust" will exist. This will lead to a large number of keys with no method within DNSSEC to manage the keys. This proposal seeks to address that issue using existing mechanisms to allow cross-signing of root (i.e. roots of islands) keys. This cross-signing of keys creates a non-hierarchical web of trust which permits the efficient gathering and validation of trust anchors. "Simple Partition Transfer Protocol (SPTP)", Nestor Soriano, 4-Oct-04, This document presents a protocol intended to transfer the whole contents of a disk partition (or the whole directory tree placed under a given directory on the disk) to a backup server. The protocol lies on top of TCP or other stream-oriented transport protocol, and is based on the exchange of messages between the client (the host sending data) and the server (the host storing the received data). "Far End Camera Control Payload Type", Roni Even, 4-Oct-04, This document defines the syntax and the semantics of SDP parameters needed to support far end camera control protocol. In conversional video applications far end camera control protocol is used by participants to control the remote camera. The common used protocol is ITU H.281 over H.224. "IMAP statistics for Lemonade", Arnaud Meylan, 7-Oct-04, This memo presents statistics on IMAP's network utilization for some common use cases. In addition we evaluate the performance of dictionary based command compression as well as transport layer compression for IMAP traffic. "Responsible Submitter of an E-mail Message", William Leibzon, 7-Oct-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. "New parameter for the "tel" URI to support ENUM", Richard Stastny, 7-Oct-04, This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in SIP proxies, H.323 gatekeepers and other VoIP network elements. The presence of the "enumdi" parameter indicates to the VoIP network element receiving an URI containing an E.164 number that an ENUM query as defined in RFC3761 has already been performed on the E.164 number indicated by the previous VoIP network element. "ENUM Validation Architecture and Token Format Definition", Alexander Mayrhofer, 8-Oct-04, ENUM domains track the right-to-use of the underlying E.164 number. The process of asserting this is called "validation". This document describes a generalized role model and a XML data format -- the validation token -- to convey validation related information. "Global HA to HA protocol", Pascal Thubert, 8-Oct-04, This paper extends Mobile IPv6 [9] and the NEMO Basic Support [11] to remove the Layer 2 dependencies on the Home Link and allow the global (L3) distribution of the HAs that serve a same Home Network. "Port Randomisation", Michael Larsen, 8-Oct-04, The Internet protocols TCP and UDP are both vulnerable to data injection attacks. The consequences of injected data range from nuisance through broken connections and corrupted local data. "Analysis and Minimization of Microloops in Link-state Routing Protocols", Alex Zinin, 8-Oct-04, Link-state routing protocols (e.g. OSPF or IS-IS) are known to converge to a loop-free state within a finite period of time after a failure. It is normal, however, to observe short-term loops during the period of failure propagation, route recalculation, and forwarding table update, due to the asynchronous nature of link-state protocol operation. This document provides an analysis of formation of such microloops and suggests simple mechanisms to minimize them. "Goals for Zero-Configuration Tunneling in 3GPP", karen Nielsen, 11-Oct-04, Various types of IPv6-IPv4 tunneling are envisaged to be required in the transition period from IPv4 networking to IPv6 networking, or more precisely, in the transition period from IPv4 only networking to dual or mixed IPv6 and IPv4 networking. "cryptographically signed web-content", Jon Bendtsen, 11-Oct-04, This document describes a backwards compatible method to transfer the both indication of cryptographically signed web-content and an URL to the actual signature. The method supports more than one type of signature system, certificate system, or root Certificate Authority. "IPvLX Errata", Fred Templin, 12-Nov-04, This document provides errata for 'IPvLX: IPv6 Addressing in the IPv4 Internet'. It is intended as a companion document to be applied as a 'patch' to the base document. "Transmission of IPv4 and ARP Packets over Fibre Channel", Claudio DeSanti, 11-Oct-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. "Quality of Service for Ad hoc Optimized Link State Routing Protocol (QOLSR)", Hakim Badis, 11-Oct-04, The Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. It reduces the message overhead as compared to a classical flooding mechanism and offers distributed partial link state information in the network using MPRs. "Recommendations to achieve efficient Router Reachability Detection in IPv6 networks", Sathya Narayanan, 11-Oct-04, Detecting Network Attachment (DNA) requires the rapid detection of link identity and validation of the current IP configuration [3]. Even though acquiring the configuration for a new link is outside the scope of DNA, mechanisms that can accomplish both DNA and collect possible configuration information about the current link will prove to be very useful in rapidly changing network environments. RFC 2461 defines a Router Discovery (RD) procedure [1] to learn about the available access routers on an L3 link. RFC 2461 [1] also defines Neighbor Discovery (ND) procedure to discover neighbors in the same link. This draft recommends a few simple modifications to the Router Discovery (RD) procedure defined by RFC 2461 [1] that can lead to efficient Router Reachability Detection (RRD), while enabling the quick learning of other available routers if the current router is not available. "Namespace Considerations and Registries for GSS-API Extensions", Nicolas Williams, 11-Oct-04, This document describes the ways in which the GSS-API may be extended and directs the creation of IANA registries for GSS-API namespaces that may be affected by any extensions. "Requirements for Manageability Sections in Routing Area Drafts", Adrian Farrel, 12-Oct-04, It has often been the case that manageability considerations have been retrofitted to protocols. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the requirement for all new Routing Area Internet-Drafts to include an "Manageability Considerations" section, and gives guidance on what that section should contain. "Application Master Session Key (AMSK) for Mobile IPv6", Gerardo Giaretta, 12-Oct-04, The Extensible Authentication Protocol (EAP) defines an extensible framework for performing network access authentication. Most EAP authentication algorithms, also known as "methods", export keying material that can be used with lower layer ciphersuites. It is also possible for EAP peers to exploit the EAP keying framework to derive Application Master Session Keys (AMSKs) for specific applications. This document defines how to generate an Application Master Session Key (AMSK) specific to Mobile IPv6. This AMSK can be used by Mobile Node and Home Agent as the shared secret needed to bootstrap Mobile IPv6 protocol operation. "Error and Congestion Control Algorithm for mSCTP handover", Moon Jeong Chang, 12-Oct-04, This document describes a novel error and congestion control algorithm for mobile Stream Control Transmission Protocol (mSCTP). This algorithm is simple but very effective means to minimize the lost packet recovery time as well as the handover latency by capitalizing on the transport layer awareness of the mobility. "IPv6 Network Architecture Protection", Gunter Van de Velde, 12-Oct-04, Although there are many perceived benefits to Network Address Translation (NAT), the primary benefit of "amplifying" available address space is not needed in IPv6. In addition to its many serious disadvantages there is a perception that other benefits exist, such as a variety of management and security reasons that could be useful for an Internet Protocol. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the benefits without the need for NAT. "Sharing and Remote Access to Applications", Henning Schulzrinne, 13-Oct-04, We describe requirements for accessing general graphical user interface (GUI) applications remotely, either by a single remote user or embedded into a multiparty conference. "Benchmarking Methodology for Wireless LAN Devices", Scott Bradner, 13-Oct-04, This document provides a framework and methodology for performing stress testing and benchmarking of wireless LAN (WLAN) devices, including clients (i.e., host interfaces) and Access Points. The document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such devices, and also supplies the methods used to calculate the results of these tests. This document also describes specific formats for reporting the results of the tests. It extends the methodology defined for benchmarking network interconnecting devices in RFC 2544 and LAN switches in RFC 2889 to WLAN devices. "Inter-AS PCE Communication protocol", Mohammed Boucadair, 13-Oct-04, This draft describes a new protocol allowing communication between two Path Computation Elements (PCEs) located in different domains in order to compute inter-domain paths satisfying a set of QoS constraints. This protocol could also be used for intra-domain purposes. "Sender Policy Framework: Authorizing Use of Domains in MAIL FROM", Mark Lentczner, Meng Weng Wong, 13-Oct-04, Mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction in what a sending host can use as the reverse-path of a message. This document describes a protocol whereby a domain can explicitly authorize the hosts that are allowed to use its domain name in a reverse-path, and a way for receiving hosts to check such authorization. "Service Location Protocol Extensions for Mobile IPv6", Joel Hartman, 13-Oct-04, This document specifies extensions to the Service Location Protocol verson 2 (SLPv2) which allow applications residing in Mobile IPv6 nodes to interact with SLPv2 agents in fixed networks. Each mobile node contains a Visiting Agent which communicates with Access Agents residing in fixed networks. In networks already deployed with SLPv2-based service infrastructure, this allows applications in visiting mobile nodes to use SLPv2 and provide site-local services without needing prior knowledge or static configuration of the networks they visit. By monitoring changes in Access Agent Advertisements, Visiting Agents can decide if the mobile node has moved to a new network, and if it is necessary to rediscover and reregister site-local services. This document extends SLPv2 and the SLP API with new message types, error codes and function calls. "Mobile IPv6 Application API", Mark Borst, 13-Oct-04, By design, Mobile IPv6 does not provide movement information to higher layers or applications. However, new breeds of location-sensitive applications and technologies would benefit from having access to such information. This document outlines how the knowledge of mobility can be usefully harnessed by applications which reside in a mobile node as well as a correspondent node. It then defines an application-level API to fulfill those needs. "BGP Security Requirements", Blaine Christian, 25-Oct-04, The security of BGP is critical to the continued health and well being of internetworking. While securing a link between two BGP peers is a relatively easy technical matter, the manner in which to do so is not standard. Additionally, a secure link does not provide security or authentication of the routes updates themselves. In this document, we describe a set of requirements for securing BGP is described, both in the areas of peering relationships and prefix authentication. "DNS Response clarification.", Roy Arends, 14-Oct-04, This document clarifies DNS response message interpretation to avoid denial of service attacks using DNS responses. In a recent DNS software assessment it has come to light that some implementations respond to DNS response messages. A loop occurs if the receiver of this response responds with a response. It was never explicitly stated that response messages must not be answered. This draft makes the statement explicit. "Route Optimization with Nested Correspondent Nodes", Thierry Ernst, 14-Oct-04, This document aims at assisting the problem statement of route optimization in nested mobile networks. We describe the paths packets would take using existing Mobile IPv6 and NEMO Basic Support mechanisms when one or both end nodes of a communication flow are located in a nested NEMO. One of both of the end nodes may themselves be either mobile nodes performing Mobile IPv6, or standard IPv6 nodes performing no mobility function at all. The path can become extremely suboptimal if no optimization is provided. "A Solution for providing inter-AS MPLS-based QoS tunnels", Mohammed Boucadair, 15-Oct-04, This draft describes a solution for providing inter-AS MPLS-based Quality of Service (QoS) tunnels. This solution makes use of Path Computation Elements (PCE) as a means to compute inter-domain constraint-based paths. Service considerations and agreements between two Service Providers implementing this solution are also described. "Source Address Selection Policy option for DHCPv6", Hirotaka Matsuoka, Tomohiro Fujisaki, Jun-ya Kato, Arifumi Matsumoto, 15-Oct-04, The Source Address Selection Policy option of DHCPv6 provides a mechanism for notifying end nodes of information about source address selection policies. This makes it possible for an end node to set up a connection without concern for transfer failures due to ingress filtering by ISPs, for ISP operators to manage user behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. "Lemonade Requirements for Server to Client Notifications", Stéphane Maes, 15-Oct-04, This document describes Lemonade requirements for server to client notifications. These server to client notifications provide information on crucial changes to a client. This document does not assume how notifications are provided to the clients: the client to server notifications may be actively pushed to a client through different mechanisms rather than requiring the client to initiate contact to ask for state changes; or they may be polled by the client, still avoiding that the client performs full state comparisons. "Limitations induced by BGP on the computation of interdomain LSPs", Cristel Pelsser, 15-Oct-04, Path Computation Elements have been proposed to aid the establishment of interdomain Label Switched Paths. We propose to colocate the PCE with a route reflector and show that the performance of such a PCE depends on the quality of the interdomain routes that it collects. "Storing Certificates in the Domain Name System (DNS)", Simon Josefsson, 15-Oct-04, Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). More information on this document, including rfcdiff output, may be found at . "Requirements for multicast in Provider Provisioned IP VPNs", Thomas Morin, Renaud Moignard, Jean-Louis Le Roux, 15-Oct-04, This document presents a set of functional requirements for network solutions that allow the support of IP multicast within IP provider provided virtual private networks (PP VPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions, that specify the support of IP multicast within VPNs, use these requirements as a guideline. It is not the intent of this document to propose technical solutions, nor to detail solution specific issues. "The IMG Envelope", Rod Walsh, Juha-Pekka Luoma, Jani Peltotalo, Sami Peltotalo, 21-Oct-04, This document defines the metadata transfer envelope for Internet Media Guides (IMGs). IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. IMG metadata is encapsulated into, or associated with, an IMG envelope before actual transport. The IMG envelope is a structure providing independence between IMG transport protocols and different metadata formats. This specification provides the IMG envelope instantiation using structured Extensible Markup Language (XML) syntax, both as a wrapper in which to embed an IMG metadata fragment object and as a distinct object to associate with a distinct IMG metadata object. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 15-Oct-04, This is the initial draft of the HIP-RG experiment report. "The Font Primary Content Type for Multipurpose Internet Mail Extensions", David Singer, 15-Oct-04, This document serves to register and document the top-level MIME type for fonts, under which the representation formats for fonts may be registered. It also registers some specific font types under that top-level type. "IP MIB for IP Fast-Reroute", Alia Atlas, Bill Anderson, Don Fedyk, 18-Oct-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 relevant for IP routes using IP Fast-Reroute [IPFRR]. "DNS Endpoint Discovery (DNS-EPD)", James Snell, Andrew Donoho, 18-Oct-04, This memo introduces two new DNS Resource Record types for the DNS-based discovery of Web service endpoints. "The "ws:" URI Scheme for DNS Endpoint Discovery", James Snell, Andrew Donoho, 18-Oct-04, This memo introduces the "ws:" URI scheme for use in conjunction with DNS-Based Web Services Discovery. The URI is used to identify Web services that have been advertised in DNS. "The Local Mobility Management Protocol (LMMP)", Jukka Manner, 18-Oct-04, Mobile IP (MIP) is the well-known protocol to handle the mobility of IP-based mobile nodes (MN). However, MIP has some drawbacks, including high latency in updates during a handover, and the need for infrastructure in the home networks of MNs. To enhance the mobility of nodes within a single domain, an access network (AN), several local mobility (also called micro mobility) management protocols have been suggested. All these protocols have their strengths and drawbacks. The deployment of these protocols is a chicken and egg problem, since both the AN and the MNs must support the same protocol. This draft presents a new protocol that can be used to replace the communication between the AN and the MNs in the existing local mobility management schemes. The protocol hides from MNs the AN-internal mobility management mechanisms and, therefore, allows MNs to log in to and roam within any AN regardless of the local mobility scheme used. "Guidelines and Registration Procedures for new URI Schemes", Tony Hansen, Ted Hardie, Larry Masinter, 18-Oct-04, This document provides guidelines and recommendations for the definition of new URI schemes, and a mechanism to register those URI schemes. This is a first draft attempt to capture the sense of direction for updates to RFC 2717 and RFC 2718. These changes were discussed at the August 26, 2004 URIREV4 BOF: see http://lists.w3.org/Archives/Public/uri/2004Aug/0007.html for the minutes. Please send comments to uri@w3.org. "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", Wassim Haddad, 18-Oct-04, This memo describes the privacy in mobility and multi-homing problem statement. "An User-to-User Authenticated Key Exchange Mechanism Based on the UMTS Authentication and Key Agreement (AKA)", John Floroiu, 18-Oct-04, The present draft describes an user-to-user (u2u) authenticated key exchange mechanism based on the UMTS AKA mechanism [1]. The proposed scheme is based on the generation of security tokens (in fact encrypted public Diffie-Hellman keys) by the peer's operator. Such a security token along with credential information contained within the peer's AKA Authentication Vector (AV) enables two communicating peers to securely derive a shared key. "Media Policy Templates for XCON", Chris Boulton, Umesh Chandra, 18-Oct-04, Media Policy control is the mechanism by which participants of a conference manipulates the media in the conference. The controls provided to conference participants to mainpulate media enhances participants experience in the conference. This document provides a minimum set of media policy templates that can be instantiated during conference creation and manipulated during the life cycle of a conference instance. The templates define a conference properties like what streams are supported, what controls are available etc. This work is being discussed on the xcon@ietf.org mailing list. "pNFS Operations Summary", Brent Welch, 18-Oct-04, This Internet-Draft provides a description of the pNFS extension for NFSv4. The key feature of the protocol extension is the ability for clients to perform read and write operations that go directly from the client to individual storage system elements without funneling all such accesses through a single file server. Of course, the file server must coordinate the client I/O so that the file system retains its integrity. The extension adds operations that query and manage layout information that allows parallel I/O between clients and storage system elements. The layouts are managed in a similar way as delegations in that they have leases and can be recalled by the server, but layout information is independent of delegations. "Network Access Control Protocol (NACP)", Susan Thomson, 18-Oct-04, The Network Access Control Protocol (NACP) is a protocol used to encapsulate EAP (Extensible Authentication Protocol) messages in a UDP (User Datagram Protocol) transport between an authenticator and peer. "TLS Inner Application Extension (TLS/IA)", Paul Funk, 18-Oct-04, This document defines a new TLS extension called "Inner Application". When TLS is used with the Inner Application extension (TLS/IA), additional messages are exchanged during the TLS handshake, each of which is an encrypted sequence of Attribute- Value-Pairs (AVPs) from the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and Diameter have the same meaning in TLS/AI; that is, each attribute code point refers to the same logical attribute in any of these protocols. Arbitrary "applications" may be implemented using the AVP exchange. Possible applications include EAP or other forms of user authentication, client integrity checking, provisioning of additional tunnels, and the like. Use of the RADIUS/Diameter namespace provides natural compatibility between TLS/IA applications and widely deployed AAA infrastructures. "Configuring Source Address Selection Policy by Neighbor Discovery Protocol for IPv6", Tomohiro Fujisaki, 21-Oct-04, This document describes a Neighbor Discovery IPv6 Source Address Selection(SAS) Policy option for distributing of source address selection policies to end nodes. This option is particularly effective when a consumer site has multiple address blocks. Every end node is guided by such a policy in selecting an appropriate source address for each destination address. This makes it possible for an end node to set up a connection without concern for transfer failures due to ingress filtering by ISPs, for ISP operators to manage user behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. "Hierarchical Proxy Mobile Ressource Reservation Protocol", Charles Abondo, Samuel Pierre, 18-Oct-04, This document defines a resource reservation protocol Hierarchical Proxy Mobile Resource Reservation Protocol (HPMRSVP). This protocol is based on the hierarchical architecture HMIPv6 and used a modified version of FHMIPv6 to handle the handover. During a session, the resource reservation between two mobile nodes is limited to the access network. Furthermore, when a handover occurs, resources are uniquely reserved to the target access point before the handover is completed. The proposed protocol allows to reduce delays and packet loss. In addition, management of refresh messages is moved to the access router, which holds the refresh reservation state for the duration of the session on behalf of the mobile unit. The access network thereby becomes responsible for upholding the session, which optimizes the utilization of the radio link. "DHCP Relay Agent Option to Support Mobile IPv6 bootstrapping", Kuntal Chowdhury, Jayshree Bharatia, 18-Oct-04, This document defines a new DHCPv6 option and number of sub-options for DHCP Relay Agent to facilitate Mobile IPv6 bootstrapping along with a AAA infrastructure. "Hash Based Addresses (HBA)", Marcelo Bagnulo, 18-Oct-04, This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. The main idea is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by appending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound. "Ingress filtering compatibility for IPv6 multihomed sites", Christian Huitema, 18-Oct-04, The note presents a set of mechanisms to provide ingress filtering compatibility for legacy hosts in IPv6 multihomed sites. The described mechanisms are not a complete multihoming solution but just a component, and additional mechanisms will be needed to fulfill all the requirements of multihoming. "Address selection in multihomed environments", Christian Huitema, 18-Oct-04, This note presents mechanisms for address selection in hosts within a multihomed site. The goal of the presented mechanisms is to allow hosts within the multihomed site to establish new communications after an outage. The presented mechanisms are not by themselves a complete multihoming solution but rather a component of such solution. "GSS-API Domain-Based Service Names and Name Type", Nicolas Williams, 18-Oct-04, This document describes domainname-based service principal names and the corresponding name type for the GSS-API. Domain-based service names are similar to host-based service names, but using a domain name (not necessarily and Internat domain name) instead of or in addition to a hostname. The primary purpose of domain-based service names is to provide a way to name clustered services after the domain which they service, thereby allowing their clients to authorize the service's servers based on authentication of their names. "Path Computation Service discovery via Border Gateway Protocol", Mohammed Boucadair, 18-Oct-04, This drafts aims at describing a simple mechanism that will ease discovery of Autonomous Systems supporting inter-domain MPLS-based constrained tunnels service (this service is also denoted by Path Computation Service (PCSv)) managed by distinct Internet Network Providers (INP). Particularly, this draft describes how Border Gateway Protocol (BGP) is used to announce Path Computation Service unique identifiers across the Internet in order for other PCEs to be able to discover a path towards every AS supporting this Path Computation Service. "GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", Nicolas Williams, 18-Oct-04, This document describes the mapping of GSS-API domainname-based service principal names onto Kerberos V principal names. "A PRF API extension for the GSS-API", Nicolas Williams, 18-Oct-04, This document defines a Pseudo-Random Function (PRF) extension to the GSS-API for keying application protocols given an established GSS-API security context. "Functional decomposition of the M6 protocol", Marcelo Bagnulo, Jari Arkko, 18-Oct-04, In this note we will present a functional decomposition of the M6 protocol i.e. the protocol for preserving established communications in multihomed environments. We will do so by describing a protocol walkthrough, presenting which functions have to be performed at each stage and the messages required to accomplish them. The functional decomposition presented in this draft is based on the general functional analysis of multihoming approaches presented in [3]. "A PRF for the Kerberos V GSS-API Mechanism", Nicolas Williams, 18-Oct-04, This document defines the Pseudo-Random Function (PRF) for the Kerberos V GSS-API mechanism, based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. "IMAP extension for referencing the last SEARCH result", Alexey Melnikov, 18-Oct-04, Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example fetching the found messages, deleting them or copying them to another mailbox. This can be achieved using standard IMAP operations described in RFC 2501, however this would be suboptimal: the server will send the list of found messages to the client, after that the client will have to parse the list, reformat it and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command. This document proposes an IMAP extension that allows a client to tell a server to use the result of the latest SEARCH (or UID SEARCH) command as an input to any subsequent command. "Multi6 Application Referral Issues", Erik Nordmark, 18-Oct-04, In order to fully solve the scalable multihoming problem there is a need to separate the current IP address functionality into identifiers (which are used to identify e.g., TCP connections) and locators which are used to forward packets in the routing system. Such a separation has an impact on the current use of IP address in the application layer. This document presents these issues for the purposes of stimulating discussions. "LDP IGP Synchronization", Markus Jork, 18-Oct-04, In networks depending on edge-to-edge establishment of MPLS forwarding paths via LDP, blackholing of traffic can occur in situations where the IGP is operational on a link and thus the link is used for IP forwarding but LDP is not operational on that link for whatever reason. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. "Multihoming L3 Shim Approach", Erik Nordmark, 18-Oct-04, This document outlines an approach to solving IPv6 multihoming in order to stimulate discussion. The approach is based on using a multi6 shim placed between the IP endpoint sublayer and the IP routing sublayer, and, at least initially, using routable IP locators as the identifiers visible above the shim layer. The approach 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. This document does not specify the mechanism for authenticating and authorizing the "rehoming" - this is specified in the HBA document. Nor does it specify the messages used to establish multihoming state. The document does not even specify the packet format used for the data packets. Instead it discusses the issue of receive side demultiplexing and the different tradeoffs. The resolution of this issue will effect the packet format for the data packets. "Revised Registration Procedures for URL Scheme Names", Paul Hoffman, 18-Oct-04, This document revises the registration procedures given in RFC 2717 based on five years of experience. It simplifies the requirements for getting a scheme listed by IANA by removing the technical review and allowing multiple registrants to share a scheme name. "Extending Return Routability Procedure for Network Prefix (RRNP)", Chan Ng, 18-Oct-04, This memo highlights the inadequacy of existing return routability procedure when one takes network prefix into consideration under the context of route optimization with Network Mobility (NEMO). An extended return routability procedure, called Return Routability with Network Prefix (RRNP), is thus proposed to address this problem. With RRNP, a correspondent node can verify the collocation of care-of address, home address, and network prefix(es) specified in a binding update message. "Diameter Mobile IPv6 Bootstrapping Application using PANA", Junghoon Jee, 18-Oct-04, This document specifies a new Diameter Application to support the Mobile IPv6's bootstrapping mechanism during the AAA authentication and authorization phase based on PANA. PANA is used as a protocol for network authentication between mobile nodes and access networks. During the PANA authentication phase, the mobile node's initial configuration information like its home address, home agent address and IKE pre-shared keying material is piggybacked to the PANA messages cryptographically protected by the PANA SA. The Diameter and PANA message formats to support the Mobile IPv6 bootstrapping are defined. "Extensible Mail Protocol (ExMP)", Steven Taylor, 18-Oct-04, This document describes the Extensible Mail Protocol (ExMP); a protocol designed to deliver XML formatted mail messages between post office nodes using Simple Object Access Protocol (SOAP) via HTTPS. The purpose of this ExMP is to become a total end-to-end mail delivery and retrieval system that is both scalable and secure. "IGMP Proxy Behavior", Dan Wing, 18-Oct-04, This document describes the behavior of an IGMP Proxy, as implemented in NAT devices, and places requirements on such devices. "VPLS Interoperability with CE Bridges", Ali Sajassi, Yetik Serbest, Frank Brockners, 18-Oct-04, One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer bridges. If only connectivity among customer IP routers/hosts was desired, then IPLS solution [IPLS] could have been used. The strength of the VPLS solution is that it can provide connectivity to both bridge and non-bridge types of CE devices. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks today or the same level of service that they receive from their Ethernet Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or its predecessor ? QinQ-based network). When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. Majority of these issues have currently been addressed in IEEE 802.1ad standard for provider bridges and they need to be addressed for VPLS networks. This draft discusses these issues and wherever possible, the recommended solutions to these issues. "Protection Against Spoofing Attacks by Using the TCP Timestamps Option", Noritoshi Demizu, 19-Oct-04, This memo describes a method of protecting TCP connections against off-path, third party spoofing attacks, by making use of the TCP Timestamps option specified in RFC1323. The original basis of the idea was proposed by Kacheong Poon. This memo discusses its issues to add complementary ideas to his original approach. Viable ideas in this memo will be incorporated into his upcoming draft. "Link Buffering for MANETs", Thomas Clausen, Kenichi Mase, 19-Oct-04, A number of MANET routing protocols employ the ability to temporarily buffer undeliverable IP datagrams until a route to a destination becomes available. This is indeed the case for reactive protocols, which largely are based on the ability to store an undeliverable IP datagram while a route discovery operation is carried out. Current specifications of proactive routing-protocols do, however, also indiate that they may benefit from such a mechanism: while a local link breakage may imply that a selected route to a given destination breaks, buffering an undeliverable IP datagram may allow a local topology discovery mechanism to select an alternative route. This document describes a generic mechanism for buffering IP datagrams in MANETs. The mechanism is based on the idea that while a local link may make a route to a destination fail, it does not imply that an alternative route to that destination is not available. Hence, IP datagrams for transmission along that route are buffered to allow the routing protocol time to construct an alternative route. The IP datagram is discarded only if the routing protocol hasnâ"À"Ùt been able to provide an alternative route within a determined small delay. We note, that this specification does not mandate a required behavior for MANET routing protocols. Rather, since the mechanisms currently employed in the four existing MANET routing protocol specification are similar in what they try to accomplish, it is the goal of this specification to generalize and expand on these mechanisms, thereby provide a framework for (i) discussing and refining the mechanism in isolation and (ii) providing a common element, which may be usefull for multiple MANET routing protocols. "LDAP Modify-Increment Extension", Kurt Zeilenga, 19-Oct-04, This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension. "LDAP X.509 Certificate Schema", Kurt Zeilenga, 19-Oct-04, This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP). The LDAP definitions for these X.509 and X.521 schema elements replaces those provided in RFC 2252 and RFC 2256. "Requirements for GMPLS-based multi-region and multi-layer networks", Kohei Shiomoto, 19-Oct-04, Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability, that is, one data plane switching layer. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. GMPLS can provide a comprehensive framework for the control of a network consisting of network elements based on different switching technologies, which we call a 'multi-region' network (MRN). GMPLS can also facilitate the control of layered networks where connections in a higher layer network are facilitated by a lower layer network. This draft defines a framework for GMPLS-based multi-region and multi- layer networks, and lists a set of functional requirements. "Common Intrusion Detection Signatures Standard", Adam Wierzbicki, 19-Oct-04, The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided. "Service Discovery using NAPTR records in DNS", Alain Durand, Shu Yamamoto, 19-Oct-04, This document describes a method to store and retrieve local configuration information from the DNS using NAPTR records in the reverse path DNS tree. It works for both IPv4 in-addr.arpa and IPv6 ip6.arpa. "SIP Conventions for Connection Usage", Cullen Jennings, Alan Hawrylyshen, 19-Oct-04, SIP has many situations where a request can only be routed over an existing connection. This can arise in cases with firewall or network address translation (NAT) devices in the network path, over both UDP and TCP. TLS is also affected when the user agent (UA) does not have a certificate suitable for mutual TLS authentication. This draft addresses how user agents and proxies need to behave to work in these environments, and addresses keep-alive and DNS configuration issues required for high reliability connections in situations where the UA can form connections to the proxy but the reverse is not generally true. This work is being discussed on the sipping@ietf.org mailing list. "Service Discovery using NAPTR records in DNS", Alain Durand, 19-Oct-04, This document describes a method to store and retrieve local configuration information from the DNS using NAPTR records in the reverse path DNS tree. It works for both IPv4 in-addr.arpa and IPv6 ip6.arpa. "Adapting Mobile IPv6 Fast Handovers for IPv4", Rajeev Koodli, Charles Perkins, 19-Oct-04, The Mobile IPv6 fast handover document [2] specifies a protocol to improve latency and packet loss resulting from Mobile IPv6 handover operations. This document adapts the protocol for IPv4 networks to improve performance over Mobile IPv4 operations, including processing of Agent Advertisements, new Care of Address acquisition and Registration Request and Reply. However, Foreign Agent operation at a router is not necessary. Also, the protocol may be used transparently on hosts which do not support Mobile IP, but with limited movement across subnets. Using the concepts outlined in [2], this document also addresses movement detection, IP address configuration and location update latencies. For reducing the IP address configuration, the draft provides two alternatives. First, the new CoA is always made to be the new access router's IP address. Second, a hash algorithm is used to produce a new CoA, and any conflicts are resolved so as not to cause traffic misdirection. "Lemonade and Mobile e-mail", Stephane Maes, 25-Oct-04, This document describes the challenges with mobile e-mail in order to identify the challenges that are within the mobile profile of Lemonade. "IMAP Extension for CHECKPOINT Synchronization", Michael Wener, 19-Oct-04, This document describes an IMAP extension that aids in allowing a client to maintain mailbox synchronization without performing a deep sync after each connection. The goal is to minimize, but not eliminate, the need for deep synchronizations. The extension defines a way for a client to receive and acknowledge state change responses from the server. "IMAP Extension for MSGFILTER", Michael Wener, 19-Oct-04, In a mobile environment it is often desirable to allow a user to restrict or constrain the set of messages that will be sent to the mobile device. There may be several reasons. The user may not want to pay for the bandwidth consumed, they may not want to to consume memory on the phone or they may just want to restrict what they get "bothered" by while in a mobile environment. This draft defines a way to allow the user to restrict message sets per folder. "IMAP4 Multi-Accessed Mailbox Practice", Mike Gahrns, Alexey Melnikov, 19-Oct-04, IMAP4[IMAP4] is rich client/server protocol that allows a client to access and manipulate electronic mail messages on a server. Within the protocol framework, it is possible to have differing results for particular client/server interactions. If a protocol does not allow for this, it is often unduly restrictive. "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", Seisho Yasukawa, Adrian Farrel, Zafar Ali, 19-Oct-04, Recent proposals have extended the scope of Multi-Protocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to encompass point-to-multipoint (P2MP) TE LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping" [LSP-PING]. This documents does not replace any of the mechanism of LSP Ping, but clarifies their applicability to P2MP MPLS TE LSPs, and extends the techniques and mechanisms of LSP Ping to the P2MP TE environment. "Next Steps for ENROLL", Hannes Tschofenig, Dirk Kroeselberg, 19-Oct-04, This document describes framework specific aspects relevant for the Credential and Provisioning (ENROLL) working group. State-of-the-art work with possible relevance for ENROLL is given with a special focus on the 3GPP Generic Authentication Architecture (GAA), which has a relationship to the Trusted Transitive Introduction (TTI) model. The main goal of this document is to initiate some discussions about the focus of the working group and possible next steps. "Testing Hierarchical Virtual Private LAN Services", Olen Stokes, Vach Kompella, Giles Heron, Yetik Serbest, 19-Oct-04, This document describes a methodology for testing the operation, administration and maintenance (OA&M) of a general VPN service, that is applied here to Hierarchical Virtual Private LAN Services (HVPLS) as described in [VPLS]. As part of this methodology, the MPLS ping concepts described in [LSP-PING] are extended to enable HVPLS spoke- to-spoke connectivity testing. The approaches to identifying OAM packets has also been made compatible with [LSP-PING] and [PWE3-VCCV]. These are the goals of this draft: - checking connectivity between 'service-aware' nodes of a network, - verifying data plane and control plane integrity, - verifying service membership There are two specific requirements to which we call attention because of their seemingly contradictory nature: - the checking of connectivity MUST involve the ability to use packets that look like customer packets - the OAM packets MUST not propagate beyond the boundary of the provider network "Robust Header Compression (ROHC) over 802 networks", Carsten Bormann, 19-Oct-04, Various proposals have been submitted to the ROHC working group for enabling the use of ROHC [RFC 3095] header compression over Ethernet, 802.11 and other 802-based links. Previous proposals generally suffered from a lack of systems perspective on 802 networks. The present document attempts to supply some systems perspective and provides a rough outline for a solution. "What's In a Name: RFC", Jonathan Rosenberg, Allison Mankin, 19-Oct-04, Currently, the Request for Comments (RFC) moniker applies to all documents that are published by the RFC editor. This includes documents produced by IETF processes, such as IAB documents or working group standards, on an equal footing with individual contributions to the RFC editor. As a result, the term RFC does not mean that a document has been produced by the IETF (though some non-IETF RFCs strongly resemble IETF RFCs). This is at odds with the understanding of the commons, which has come to view RFCs as the output document series of the IETF. This document discusses the importance of aligning fact with this common understanding, and proposes that the name RFC be associated only with IETF documents. "RTP-ROHC in ROHC Formal Notation", Carsten Bormann, 19-Oct-04, RFC 3095 [2] defines four ROHC profiles for the header compression of IP, UDP, RTP, ESP, and related protocol headers. RFC 3095 is defined in English language and taditional RFC box notation. The present document gives a definition of RFC 3095's packet formats in the ROHC Formal Notation that was defined to facilitate the development of the TCP header compression ROHC profile. "BGP/MPLS IP Multicast VPNs", Seisho Yasukawa, Shankar Karuna, Adrian Farrel, 19-Oct-04, This document describes a solution framework for IP Multicast VPNs. It describes procedures for establishing optimal virtual private IP multicast networks over a provider network. The simple multicast tunnel operation mechanism within a core network provides easy and flexible IP multicast VPN service operation for the service provider. And because the solution can minimize PIM neighbor maintenance over remote PEs, the solution enhances the scalability performance of the multicast VPN service network. This document also describes a P2MP TE LSP based multicast tunnel mechanism which could enhance TE capability and reliability of IP multicast VPNs. "Bootstrapping TESLA", Steffen Fries, Hannes Tschofenig, 19-Oct-04, With the Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA) a protocol for providing source authentication in multicast scenarios was introduced. A mapping for TESLA to the Secure Real-time Transport Protocol (SRTP) has been published which assumes that some TESLA parameters are made available by out-of-band mechanisms. This document describes payloads for bootstrapping these parameters with the help of the Multimedia Internet KEYing (MIKEY) protocol. "NSLP for Metering Configuration Signaling", Falko Dressler, 19-Oct-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, named Metering NSLP, which allows the dynamic configuration of Metering Entities on the data path. A problem statement, scenarios for charging, QoS monitoring, and monitoring for network security issues such as intrusion detection, and requirements are presented. Finally, the usage of NSIS for this purpose is motivated. "Guide to the GSS-APIv3", Nicolas Williams, 19-Oct-04, Extensions to the GSS-APIv2 are needed for a number of reasons. This documents describes the extensions being proposed, the resons, possible future directions, and portability, IANA and security considerations. This document does not define any protocol or interface and is purely informational. "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", S Govindan, 19-Oct-04, This document presents objectives for the Control and Provisioning of Wireless Access Points (CAPWAP) framework. Primarily it presents a fundamental objective for interoperability among wireless local area network (WLAN) devices of different designs. The document also describes additional objectives for shared WLAN infrastructure and QoS. "HIP Resolution and Rendezvous Problem Description", L Eggert, Julien Laganier, 19-Oct-04, This document investigates the design space for resolution and rendezvous mechanisms for the Host Identity Protocol (HIP.) It identifies and describes specific issues that HIP resolution and rendezvous mechanisms should address. These issues include dependencies on the DNS, lack of support for direct communication based on host identities, lack of a reverse lookup mechanism for host identities, and DNS and node rendezvous. This document does not propose specific resolution and rendezvous mechanisms. Different alternative solutions will be described and discussed in companion documents. These documents should analyze if and to what degree the specific proposals they present address the issues identified here. "Network-Layer Signaling: Transport Layer", Melinda Shore, 19-Oct-04, The RSVP model for communicating requests to network devices along a datapath has proven useful for a variety of applications beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to signaling uses other than IntServ. We are developing a modernized version that, among other things, is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol. "Zero-Configuration Tunneling Requirements", Radhakrishnan Suryanarayanan, 19-Oct-04, This document describes the set of goals to be fulfilled by a Zero-Configuration Tunneling protocol. Zero-Configuration Tunneling here denotes an automatic tunneling mechanism that could be used by a Service Provider to offer IPv6 connectivity to its customers in early phases of IPv4 to IPv6 transition. "Security Issues in PIM-SM Link-local Messages", John Atwood, 19-Oct-04, This document proposes some modifications to the Internet-Draft for Protocol Independent Multicast - Sparse Mode (PIM-SM) Protocol regarding security issues of its link-local messages. To protect these link-local messages, in the Internet-Draft for PIM-SM a security mechanism has been proposed that uses the IPsec Authentication Header (AH) protocol. While using IPsec AH protocol, the anti-replay mechanism has been disabled. This compromise makes PIM-SM vulnerable to Denial of Service (DoS) attack. In this document, a new proposal is presented to protect PIM link-local messages while activating the anti-replay mechanism as well. This proposal builds on the new Security Association lookup method that has been specified in the Internet-Draft that revises the AH protocol. "Centralized Conference Control Protocol (CCCP)", Orit Levin, Gur Kimchi, 19-Oct-04, This document defines a new client-server Centralized Conferencing Control Protocol (CCCP) for manipulating a conference behavior by either a conference participant or otherwise authorized entity that implements a CCCP client. By implementing a CCCP server, a conference focus provides a means for its clients to control the conference policy and the state of the focus and other participants in the conference. "A Session Initiation Protocol (SIP) Event Package and Data Format for Incoming Session Barring and Answer Mode in support for the Push-to-talk Over Cellular (PoC) service", Miguel Garcia-Martin, 19-Oct-04, The Open Mobile Alliance (OMA) is defining the Push-to-talk Over Cellular (PoC) service where SIP is the protocol used to establish half duplex media sessions across different participants, send instant messages, etc. This document defines a SIP event package to support publication, subscription and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. "Sample ISD for the IETF Standards Process", Scott Bradner, 19-Oct-04, This is a sample Internet Standards Documentation (ISD) for the IETF Standards Process. This document follows the model proposed in draft-ietf-newtrk-isd-repurposing-isd-00. "Motivation for a Multi-Flow Real-time Transport Protocol", Sathya Narayanan, 19-Oct-04, We proposed a new multi-flow real time protocol (MRTP) in our earlier internet-draft [1] for carrying real-time data through multiple paths between the source and the destination. There are a various advantages in multipath data transport as demonstrated by [2][3] [5][8]. MRTP would provide an end-to-end transport services over multiple flows and paths to real time data. In this draft we discuss the motivation for needing such a standardized protocol to encourage further discussion on the requirement for a multi-path transport protocol. "Service Identification", Bernhard Boehmer, Hannes Tschofenig, 19-Oct-04, This document discusses the aspect of service identification in presence documents. A solution is proposed which extends RPID by utilizing the tModel service description provided by the Universal Description, Discovery and Integration (UDDI) framework. "A Framework for Loop-free Convergence", Stewart Bryant, Mike Shand, 19-Oct-04, This draft describes mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair or management action. "HOTP: An HMAC-based One Time Password Algorithm", David M'Raihi, 21-Oct-04, This document describes an algorithm to generate one-time password values, based on HMAC [BCK1]. A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote VPN access, Wi-Fi network logon to transaction-oriented Web applications. "A Resource Reservation Extension for the Reduction of Bandwidth of a Reservation Flow", James Polk, 19-Oct-04, This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to a reservation. This mechanism can be used to affect individual reservations, aggregate reservations or other forms of RSVP tunnels. "Loose End Message Routing Method for NATFW NSLP", Martin Stiemerling, 19-Oct-04, This memo describes the use cases and solution for a new NTLP message routing method (MRM) that is used by the NATFW NSLP protocol to located Network Address Translators on the upstream data path. This message routing method is used by NSIS nodes behind a NAT to allocate a public reachable IP address and/or port number. The current way to do so has been name as "signaling the wrong way" and should be replaced by the proposed message routing method. The scope of this memo is currently limited to Network Address Translator usage only. "DHCPv6 Relay Agent Information Option", Ralph Droms, 19-Oct-04, This document introduces the capabilities of the DHCPv4 Relay Agent Information Option in RFC 3046 and the corresponding RADIUS- Attributes Sub-option to DHCPv6. In particular, the document describes a new DHCPv6 option called the Relay Agent Information option which extends the set of DHCPv6 options as defined in RFC 3315 and 3376. Following its DHCPv4 counterpart as defined in RFC 3046, the new option is inserted by the DHCPv6 relay agent when forwarding client-originated DHCPv6 packets to a DHCPv6 server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The Relay Agent Information option is organized as a single DHCPv6 option that contains one or more "sub-options" that convey information known by the relay agent. A RADIUS Attributes Sub-option, following its DHCPv4 counterpart, is also defined. "NAT and Firewall Traversal for HIP", Hannes Tschofenig, 19-Oct-04, The Host Identity Protocol is a signaling protocol which adds another layer to the Internet model and establishes IPsec ESP SAs to protect subsequent data traffic. HIP also aims to interwork with middleboxes (such as NATs and Firewalls). This document investigates this aspect in more detail. "NEMO Route Optimisation Problem Statement", Thomas Clausen, Emmanuel Baccelli, Ryuji Wakikawa, 19-Oct-04, The NEMO working group has developed a protocol suite, extending the notion of edge-mobility on the Internet to include that of network mobility. This implies that a set of nodes, along with their mobile router, change their point of attachment and that traffic to these nodes is tunneled to be delivered through their new point of attachment. This mechanism is transparent to applications in that existing traffic to a node is being encapsulated and tunneled, regardless of where the network containing the destination node is attached. The NEMO specification is not limited to a single level of mobile networks, attaching to the stationary Internet. Rather, arbitrary levels of nested mobile networks are supported, employing for each level of nesting the same encapsulation and tunneling mechanisms. With arbitrarily deep nested mobile networks, the overhead incurred through tunneling and encapsulation of data traffic can, however, become large. As a consequence, a number of different proposals exist, which aim at performing "route optimization" for nested mobile networks. This document aims at describing the different scenarios in which route-optimization is desired, as well as the different proposed solutions for achieving route-optimization in nested mobile networks. "Specification for the Explicit Control Protocol (XCP)", Aaron Falk, 19-Oct-04, This document contains an initial specification for the Explicit Control Protocol (XCP), an experimental congestion control protocol. XCP is designed to deliver the highest possible end-to-end throughput over a broad range of network infrastructure, including links with very large bandwidth-delay products, which are not well served by the current control algorithms. XCP is potentially applicable to any transport protocol, although initial testing has applied it to TCP in particular. XCP routers are required to perform a small calculation on congestion state carried in each data packet. XCP routers also periodically recalculate the local parameters required to provide fairness. On the other hand, there is no per-flow congestion state in XCP routers. "RTP Payloads for Anti-shadow Redundancy", Qiaobing Xie, 19-Oct-04, This document defines a special form of RTP redundant packatization format for multimedia broadcast and multicast services to combat service interruptions caused by losses of large numbers of consecutive media frames. Along with the payload format, this document also defines the procedures the RTP sender and receiver will need to use to conceal the large frames losses. "DNS authoritative server misconfiguration and a countermeasure in resolver", Kazunori Fujiwara, 27-Oct-04, This memo describes DNS authoritative name server misconfiguration and that results in a significant query cost in DNS resolver server. In some cases we recommend re-checking DNS authoritative servers with a viewpoint of current RFC and propose corresponding changes in DNS resolver server implementations to protect it. And more, we point open issues. The recommendations made in this document are based on analysis of abnormal DNS resolver server load at large ISP cache server which has many customers. "Mobile IPv6 Bootstrapping Architecture Using DHCP", Yoshihiro Ohba, 19-Oct-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 describes a bootstrapping architecture in which there is some dependency between AAA for network access and AAA for mobility service and DHCP in the visited network is used for carrying Mobile IPv6 bootstrap information to the mobile node. The architecture is based on an assumption that the mobile node uses network access credentials as the seed information without a need to pre-configure any Mobile IPv6 service parameters. "Parallel NFS Requirements and Design Considerations", Garth Gibson, 19-Oct-04, This draft specifies the requirements that should be satisfied in the definition of a parallel NFS protocol and the considerations recommended for its designs. It responds to the scalable bandwidth problem described in the pNFS Problem Statement, draft-gibson-pnfs-problem-statement-01.txt. In the interest of a timely adoption of scalable bandwidth file service, parallel NFS is proposed to be a NFSv4 minor extension for communicating file layout available through existing and future storage subsystem protocols such as other NFSv4 file servers (NFS), block-based SCSI subsystems (SBC), and object-based SCSI (OSD) subsystems. "Exchanging Host Identities in SIP", Hannes Tschofenig, 19-Oct-04, This document proposes to exchange Host Identities (or Host Identity Tags) in SIP/SDP for later usage in the Host Identity Protocol Protocol (HIP) between the SIP user agents. As such, it is a first step in investigating the interaction between SIP and HIP and mainly a discussion document. "Path Computation Element Metric Protocol (PCEMP)", Jun Choi, 19-Oct-04, In this draft, we propose an analysis of a Path Computation Element Metric Protocol (PCEMP) that acts as a generic computation model for path based metrics in large multi-domain or multi-layer networks. The mechanism that is described in this draft is generic and can serve as an application path computation framework for any Path Computation Element (PCE) This draft proposes to elucidate protocol independent metrics defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques through the PCEMP and is in line with the PCE WG Charter. "Framework of PCEMP based Layer 1 Virtual Private Network", Jun Choi, 19-Oct-04, When path computation is done in the management systems for Layer 1 Virtual Private Networks (L1 VPNs), it would be important that resource information is synchronized between the management systems and the Provider Edge /Provider (PE/P). This draft looks at such a scenario from the viewpoint of the Path Computation Element Metric Protocol (PCEMP) that acts a generic computation model for path based metrics in large multi-domain or multi-layer networks. This draft proposes to show how a L1 VPN framework may be included within the scope of Path Computation Element architectures and is derived primarily from the motivation of per VPN peer service solutions using PCE techniques. PCEMP metrics defining path quality measurement criteria, algorithm complexity and scalability criteria for L1 VPNs is in line with the functional specifications of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s) of the PCE WG Charter. "Fast IPv6 PCE peer Advertisement using PCEMP", Jun Choi, Dipnarayan Guha, 19-Oct-04, In this draft, we propose a guideline for an improved version of router handling procedures in RFC 2461 that allow for improved default router acquisition performance when an active IP host moves from one subnet to the other using the Path Computation Element Metric Protocol (PCEMP). Router handling procedures can be improved by a soft configuration of PCEMP support in the context of real-time data driven strategy on individual PCE nodes. This draft is an informational draft that shows a guideline to specifications of modifying existing protocols to facilitate communication between LSRs and PCEs, and between a PCE and other PCEs. This can also be a guideline for mobile PCE nodes changing respective PCEDAs and thus needing fast advertisements to the corresponding LSRs and other PCE peers using IPv6 schemes. "Autoconfiguration in a MANET: connectivity scenarios and technical issues", Simone Ruffino, Patrick Stupar, Thomas Clausen, 19-Oct-04, MANET interconnection with external networks enables a number of usage scenarios, but generates also a number of technical issues, mainly related with node autoconfiguration and global connectivity. This Internet Draft aims at characterizing global connectivity scenarios and listing technical issues related to IP address autoconfiguration which are implied by such scenarios and should be addressed by a generic solution. "Bootstrapping Mobile IPv6 using PANA", Hannes Tschofenig, Srinath Thiruvengadam, 19-Oct-04, Recently the MIP6 working group has expressed a fair amount of interest in developing another Mobile Node <--> Home Agent Binding Update security solution. The currently proposed solution heavily focuses on one specific authentication and key exchange protocol. Obviously, this approach suffers from some limitations. This document investigates the usage of an EAP based bootstrapping approach using PANA. "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Gonzalo Camarillo, 19-Oct-04, This document specifies how to describe BFCP streams in a SDP session description. User agents using the offer/answer model to establish BFCP streams use this format in their offers and their answers. "The Simple and Protected GSS-API Negotiation Mechanism", Larry Zhu, 19-Oct-04, This document specifies a security negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. This mechanism allows negotiating and choosing one security mechanism from a common set of security mechanisms shared by GSS-API peers. Once the common security mechanism is identified, the security mechanism MAY also negotiate mechanism-specific options during its context establishment, but that will be inside the mechanism tokens, and invisible to this protocol. "Things to think about when Renumbering an IPv6 network", Tim Chown, 19-Oct-04, This memo presents a summary of scenarios, issues for consideration and IPv6-specific tools for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. The document is not intended to be complete at the -00 phase, and will be enhanced as further operational experience is gathered. "Considerations for DNA Schemes with Multiple Interfaces and Layer 2 Technologies", Yong-Geun Hong, 19-Oct-04, In this document we consider and analyze various environments for applying Detecting Network Attachment (DNA) schemes. Although DNA schemes are typically run for each interface and a host separately checks for link changes on each interface when the host has multiple interfaces, DNA schemes in the host must be considered to check the multiple interfaces at the same time for a seamless service. In addition, DNA schemes in the host must be capable of managing together each DNA scheme on each interface. Current DNA schemes only rely on 'Break before Make' L2 technology such as 802.11. But now and in future, there will be other 'Make before break' L2 technologies such as CDMA. In these L2 technologies, DNA schemes must be operated differently in order to make use of their characteristics. "Comparative Analysis of Multi6 Proposals using a Locator/Identifier Split", Ananth Nagarajan, Hannes Tschofenig, 19-Oct-04, An IP address serves as a locator and an identifier in the classical Internet environment. This dual role of the IP address makes mobility and multihoming a challenging task. There have been various proposals to overcome this limitation, particularly from the Multi6 working group. This memo makes a comparative analysis of these proposals that support a locator/identifier split for multihoming in IPv6 from the security point of view. The purpose is also to provide a common framework under which future proposals can be compared and chosen for various security requirements. "Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks", Tony Larsson, 19-Oct-04, The introduction of IPv6 in the Internet will most likely be through stepwise deployment, resulting in a heterogeneous network environment with interconnected IPv4 (public/private) and IPv6 networks. This document identifies the scenarios relevant for mobility management in such a heterogeneous network environment, lists related work compliant to Mobile IP, and evaluates possible solutions. "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", Jari Arkko, Christian Vogt, 19-Oct-04, The Mobile IPv6 mobility-management protocol enables minimum routing paths between a mobile node and a correspondent node, which may itself be mobile. This feature is called route optimization. Route optimization requires authorization of initially unacquainted and untrusted parties. A so-called return-routability procedure was integrated into the Mobile IPv6 in order to do this securely. The return-routability procedure equips the mobile node with cryptographic tokens that authenticate the mobile node and prove the mobile node's presence at a claimed new location after movement. Recently, a number of improvements or optional alternatives have been suggested to the standard procedure. The primary driver between these improvements is oftentimes further reduction of signaling messages and latency, but other improvements such as better security have also been suggested. This document discusses the potential goals for future enhancements of route optimization, the security threats that such enhancements must consider, and the various enhancement proposals and their key ideas. An evaluation of some recent proposals is included, as well as a discussion of how significant the Mobile IPv6 related optimizations are related to other ongoing optimization efforts. Finally, needs for future research are outlined. "Aggregation of DiffServ Service Classes", Kwok Ho Chan, Jozef Babiarz, 19-Oct-04, Applications with similar traffic characteristics and performance requirements are mapped into different diffserv service classes based on end-to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment satisfy the traffic characteristics and performance requirements of two or more service classes. For such cases, it may be desirable to aggregate two or more service classes into a forwarding treatment. This draft provides guidelines for aggregation of service classes into forwarding treatments. "Failure Detection and Locator Selection in Multi6", Jari Arkko, 19-Oct-04, This draft discusses locator pair selection and failure detection mechanisms for the IPv6 multihoming feature being developed in the Multi6 working group. Elements of this document may also be useful for developing the details of the MOBIKE or HIP multihoming mechanisms. The draft also discusses the roles of a multihoming protocol versus network attachment functions at IP and link layers. "A Framework for Centralized Conferencing", Mary Barnes, Chris Boulton, 19-Oct-04, This document describes a framework for Centralized Conferencing (XCON). This XCON framework document provides an enhanced framework for conferencing that is protocol agnostic. This document expands upon the interfaces between the functional elements introduced in the SIP conferencing framework by describing the characteristics of connecting protocols and providing a related data model. However, this framework is applicable for a variety of signaling protocols besides SIP including H.323, XMPP, and even PSTN signaling protocols. "TCP/IP based TML (Transport Mapping Layer) for ForCES protocol", Hormuzd Khosravi, 19-Oct-04, This document defines the TCP/IP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the transport protocols and also describes how this TML addresses all the requirements described in the Forces [3] requirements and ForCES protocol [7] document. "Partial Mesh in VPLS", Cheng-Yin Lee, 19-Oct-04, Some standard network devices may not be able to communicate with each other as if they were connected to a common LAN segment in the event of partial mesh connectivity in a VPLS. Unless this problem is addressed, the deployment of VPLS may eventually be limited to sites not using link state routing or bridges. "RFC2547bis networks using internal BGP as PE-CE protocol.", Pedro Marques, 20-Oct-04, This document defines protocol extensions and procedures for BGP PE- CE router iteration in RFC2547bis networks. These have the objective of making the usage of the RFC2547bis VPN transparent to the customer network, as far as routing information is concerned. "Security Considerations for Impersonation and Identity in Messaging Systems", Jon Peterson, 20-Oct-04, This document provides an overview of the concept of identity in Internet messaging systems as a means of preventing impersonation. It describes the architectural roles necessary to provide identity, and details some approaches to the generation of identity assertions and the transmission of such assertions within messages. The trade-offs of various design decisions are explained. "A Session Initiation Protocol (SIP) Event Package for Conference Floor State", Eunsook Kim, 20-Oct-04, This document defines a conference floor event package for Session Initiation Protocol (SIP) conferences that require floor control. The conference floor event package allows users to subscribe to a conference floor server URIs. Notifications are sent about changes in the floor state of the conference and optionally about changes in the state of additional floor components of the conference. Subscriptions and notifications of conference floor are supported by an event package within the general SIP event notification framework. "Source Address Selection Policy Distribution for Multihoming", Arifumi Matsumoto, 20-Oct-04, This document describes a method for the distribution of source address selection policy from ISPs to gateway routers for consumers and from the gateways to end nodes. This method is particularly effective when a consumer site has multiple address blocks. Every end node is guided by the policy in selecting an appropriate source address for each destination address and every gateway is guided by the policy in forwarding packets to appropriate next-hop ISPs. This makes it possible for an end node to set a connection up without being concerned about failures of transfer due to ingress filtering by the ISPs, for ISP operators to manage consumers' behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. "Inter Home Agents Protocol Specification", Ryuji Wakikawa, 20-Oct-04, This document provides protocol base specification of the inter Home Agent protocol for both Mobile IPv6 and the NEMO Basic Support protocol. This document specifies Home Agent configuration, message format and its handling operation. "The Trusted Email Open Standard (TEOS)", John Levine, 20-Oct-04, The Trusted Email Open Standard (TEOS) is a multi-level identity system for SMTP e-mail. It uses signatures to authenticate the identity of the sender of a message, and further permits the secure transmission of assertions about each message including the type of message, third-party certifications, and graphical trust marks. "Anycast Address Assignment using DHCPv6", Syam Madanapalli, 20-Oct-04, This document introduces a new option in DHCPv6 for Anycast/Shared Unicast Address assignment for a particular type of service that DHCPv6 Client provides. This address assignment is much similar to other address types assignments, except that Anycast Address assignment requires the specification of Service Type of the Anycast or Shared Unicast Address. "Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3)", David Harrington, Juergen Schoenwaelder, 21-Oct-04, This document describes the Transport Layer Security Model (TLSM) for the Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. At this stage, this document does not provide a complete solution - it rather identifies and discusses some key aspects that need discussion and future work. "Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap", Hui Deng, 21-Oct-04, This document specifies a mechanism for Mobile IPv6 bootstrap procedure. By making a extension of MIP6 specification and using IKE to guarantee its security, this mechanism bring into a new component BCF(Bootstrap Control Function) to handle MN¡¯s bootstrap procedure between MN and multiple HAs. Two new bootstrap messages Init and Ack has been defined to support bootstrap procedure. "Raptor Forward Error Correction (FEC) Schemes for Objects", Michael Luby, M. Amin Shokrollahi, 21-Oct-04, This document describes the Raptor code and its application to reliable delivery of objects. Two Fully-Specified Forward Error Correction (FEC) schemes are introduced, one for a non-systematic version of Raptor and one for a systematic version of Raptor, that supplements the FEC schemes described in RFC 3452. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols. "Path type support for NSIS signaling", Takako Sanda, 26-Oct-04, NSIS state management needs to track data path changes and update the states along the affected data paths. However, in certain scenarios, it also needs to be aware of the path type to achieve appropriate operations. For example, a triangular path and a route-optimized path for a MN at the same location may involve in a communication session when Mobile IP is employed. Therefore, certain functionality for data path distinction is necessary in the NSIS signaling. This draft discusses the problems and issues involved in the NSIS state management relevant to the data path differentiation. Specific scenarios for Mobile IP route optimization procedure are used for illustration of the problems. Potential solution and its impacts on current NSIS protocol design are discussed as well. "Proposed Transition Plan for IETF Administrative Restructuring", Margaret Wasserman, Leslie Daigle, 26-Oct-04, This document proposes a transition plan and schedule for the administrative restructuring effort currently underway in the IETF. "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN)", Dimitri Papadimitriou, 21-Oct-04, Most of the initial efforts on Generalized Multi-Protocol Label Switching (GMPLS) have been related to environments hosting single switching capability devices e.g. one data plane switching layer, as such, the complexity raised by the control of such data planes is similar to the one expected in classical IP/MPLS networks. The present document analyses the various GMPLS signaling and routing aspects when considering network environments consisting of multiple switching data layers. "IPsec support for NAT-PT in IPv6", Inseok Choi, 21-Oct-04, The NAT-PT, one of the IPv6 transition mechanisms, supports IPv6 node in a NAT-PT domain to communicate with IPv4-only nodes outside. However, due to the IP datagram conversion at the NAT-PT server, NAT-PT node has a problem in establishing the end-to-end security using the IPsec IKE and AH mode. This memo describes the reason why the problem is caused and proposes a solution for assuring the end-to-end security using IPsec in the NAT-PT environment. "Structure of the IETF Administrative Support Activity (IASA)", Margaret Wasserman, Leslie Daigle, 27-Oct-04, This document describes the structure of the IETF Administrative Support Activity (IASA) as an IETF-controlled activity housed within the Internet Society (ISOC) legal umbrella. It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD) and the ISOC Board of Trustees in the fiscal and administrative support of the IETF standards process. It also defines how the IAOC will be comprised and selected. "The Key ID Information Type for the General Extension Payload in MIKEY", Elisabetta Carrara, 21-Oct-04, This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing Protocol. This is used in the Multimedia Broadcast/Multicast Service specified in the 3rd Generation Partnership Project. "NFSv4 Cross-Domain Considerations", Rick Mesta, 21-Oct-04, The purpose of this document is to elicit discussion on configuration schemes for determining the domain name to be used by NFSv4 implementations that do not natively support users and groups from multiple domains. This document also describes a method by which NFSv4 clients and servers can discover a domain name value appropriate for qualifying NFSv4 user and group names, by leveraging DNS TXT resource records. "NEMO Route Optimization Problem Statement, Requirements and Evaluation Considerations", Fan Zhao, 21-Oct-04, This document describes and analyzes the routing optimization problem in NEMO, defines the requirements that must be met by NEMO route optimization solutions and then describes the metrics to evaluate the performance of NEMO route optimization solutions. "Operation of Anycast Services", Kurt Lindqvist, Joe Abley, 22-Oct-04, As the Internet has grown, many services with high availability requirements have emerged. The requirements of these services have increased the demands on the reliability of the infrastructure on which those services rely. Many techniques have been employed to increase the availability of services deployed on the Internet. This document presents operational experience of wide-scale service distribution using anycast, and proposes a series of recommendations for others using this approach. "Forwarding and Control Element Separation IP Transport Mapping Layer", Alex Audu, 22-Oct-04, This document defines the Forces-IPTML protocol that is designed to complement ForCES-PL (ForCES Protocol Layer) for communicating between Forwarding and Control Elements that make up a ForCEs-compliant network element, using IP transport technology (e.g. TCP/IP, SCTP/IP, UDP/IP). This protocol addresses all the requirements described in the Forces [0] requirements document. This document also specifies architectural attributes necessary in an implementation of Forces-IPTML to ensure correct and secure protocol operation. "Supporting IP Multicast over VPLS", Yetik Serbest, 27-Oct-04, In Virtual Private LAN Service (VPLS), the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS instance appear to be connected by a single LAN. A VPLS solution performs replication for multicast traffic at the ingress PE devices. When replicated at the ingress PE, multicast traffic wastes bandwidth when 1. Multicast traffic is sent to sites with no members, and 2. Pseudo wires to different sites go through a shared path. This document is addressing the former by IGMP and PIM snooping. "IMAP Extension for CLEARIDLE", Michael Wener, 28-Oct-04, The IMAPRev4 specification supports unsolicited responses being sent to a client at any time. The IDLE specification defines a way for a client to sit in an idle connection waiting to receive these responses. This document clarifies and extends the set of responses that a client may receive while in the idle state. The desire is to allow a client to predict exactly what set of unsolicited responses it can rely on receiving when listening on an idle connection. "Internet Routing Dynamics and NSIS Related Considerations", Charles Shen, 4-Nov-04, This document presents the main results from a recent Internet routing dynamics measurement and discusses their impact on NSIS protocol design. It also provides an evaluation of the simple, low cost packet TTL monitoring route change detection mechanism in the context of different NSIS deployment models. "Reliable Server Pooling Sockets API Extensions", Qiaobing Xie, 9-Nov-04, This document describes a sockets-like API for the Reliable Server Pooling (RSerPool) protocol suite. This API provides applications within an RSerPool enabled system with a reliable communications layer via a highly-available socket interface (rsp_socket). "Intelligent Transcoding Gateway Model for Transcoding with the Session Initiation Protocol", Taegyu Kang, 9-Nov-04, This document introduces a new model, Intelligent Transcoding Gateway, in Framework[6] for transcoding with the Session Initiation Protocol. The model might be applied for more general-purpose services satisfying the requirements of multimedia applications without an additional INVITE, meanwhile the existing two models, The third party call control model and The conference bridge model, are applied for the specific application requirements in support of deaf, hard of hearing and speech-impaired individuals[2]. "Purported Responsible Address in E-Mail Messages", Jim Lyon, 9-Nov-04, This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the "Purported Responsible Address" (PRA). "SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message", Eric Allman, 9-Nov-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. "Sender ID: Authenticating E-Mail", Jim Lyon, 9-Nov-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 a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. "GIMPS State Machine", Xiaoming Fu, 11-Nov-04, This document describes the state machines for the General Internet Messaging Protocol for Signaling (GIMPS). The states of GIMPS nodes for a given flow and their transitions are presented in order to illustrate how GIMPS may be implemented. "Multipoint Connectivity With L2TP", P Rajinikanthan, 11-Nov-04, This memo talks about the problem that exist in the current L2TP network and the solution to that problem. In L2TP, internet link at LNS gets congested when two or more remote user starts communicating between them. This memo suggest multipoint capabality for L2TP, where LACs communicates between them and need not require LNS for every data packet. This draft also deals with the applications of multipoint L2TP in broadband networks. "resource reservation for NEMO networks", Mazen TLAIS, Nadia Boukhatem, 12-Nov-04, Degradation or forced service termination may occur because of frequent handoffs that may occur within NEMO networks. This paper presents a resource reservation scheme aiming at supporting quality of service guaranty. We focus on a reservation protocol adapted to NEMO specifications. For doing so, we use a generic signaling protocol that may exploit advantages of both reservation protocols; IntServ and DiffServ. "Minimally Covering NSEC Records and DNSSEC On-line Signing", Samuel Weiler, Johan Ihren, 12-Nov-04, This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by [-records]. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. "Extending the Session Initiation Protocol Reason Header for Indicating Locations", Jun Koshiko, 12-Nov-04, This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to indicate the location of the SIP element which issued a certain SIP message. This capability enables many enhanced services by providing the information as to how and why a SIP message arrives at a specific application, user, or proxy server. This draft defines new reason-params for the protocol field of the Reason header field in RFC3326 [1]. "QoS NSLP State Machine", Xiaoming Fu, 12-Nov-04, This document describes the state machines for the NSIS Signaling Layer Protocol for Quality-of-Service signaling (QoS NSLP). A set of state machines for QoS NSLP entities at different locations of a flow path are presented in order to illustrate how QoS NSLP may be implemented. "Abbreviations for Brazilian Time Zones", Pedro Zorzenon, 12-Nov-04, There are lots of diferent abbreviations used in computer world for Brazilian timezones. This document intend to standardize them. "Security Issues in Dynamic Home Agent Address Discovery", Qian Sun, 12-Nov-04, This document describes potential security issues relevant to the Dynamic Home Agent Address Discovery (DHAAD) procedure in Mobile IPv6. In particular, we illustrate a Denial of Service (DoS) attack scenario and propose three possible solutions to improve the security of DHAAD in MIPv6. "Derivation of DNS Name Predecessor and Successor", Geoffrey Sisson, Ben Laurie, 12-Nov-04, This document describes a method for deriving the canonically-ordered predecessor and successor of a DNS name. This is expected to be useful for real-time NSEC resource record synthesis, which may be used in alterative implementations of DNSSEC-enabled DNS servers. 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, 26-Oct-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, 14-Sep-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, 27-Oct-04, This draft describes an NSIS Signalling Layer Protocol (NSLP) for signalling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Martin Stiemerling, 27-Oct-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, 27-Oct-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. "QoS-NSLP QSpec Template", Jerry Ash, 21-Oct-04, The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model such as IntServ or DiffServ. Rather, all information specific to QoS models is encapsulated in a separate object, the QSpec. This draft defines a template for the QSpec, which contains both the QoS description and control information specific to a given QoS model. The QSpec format is defined as are a number of generic and optional parameters. Generic parameters provide a common language to be re-used in several QoS models, which are derived initially from the IntServ and DiffServ QoS models. Optional parameters aim to ensure the extensibility of QoS NSLP to other QoS models. "Applicability Statement of NSIS Protocols in Mobile Environments", Sung-Hyuck Lee, 19-Oct-04, The 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. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer, 22-Oct-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) ----------------------------------- "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. "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. "Textual Conventions for Virtual Local Area Network Identifiers (VLAN-ID)", Bert Wijnen, 1-Oct-04, This memo defines textual conventions to represent the commonly used Virtual Local Area Network Identifier (VLAN-ID). The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. Open Shortest Path First IGP (ospf) ----------------------------------- "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. "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, 22-Oct-04, 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, 1-Nov-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, 22-Oct-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. "MT-OSPF: Multi Topology (MT) Routing in OSPF", Peter Psenak, 5-Oct-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 describes a similar mechanism for ISIS. This draft also describes an optional extension of Multi-topologies whereby some links might be excluded from the default topology. "OSPFv3 Graceful Restart", Acee Lindem, 6-Oct-04, This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State advertisements (LSA) and other considerations. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Protocol for Carrying Authentication for Network Access (PANA)Requirements", Alper Yegin, Yoshihiro Ohba, 31-Aug-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, 9-Aug-04, This document discusses the threats to protocols that are used to carry authentication for network access. 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, 21-Oct-04, Extensible Authentication Protocol (EAP) defines a number of authentication schemes. Network access authentication requires a host to authenticate itself before being authorized for sending and receiving packets. The Protocol for Carrying Authentication for Network Access (PANA) is defined in this document. PANA is a link-layer agnostic carrier for EAP. PANA specifies the client-to-network access authentication within the scope of an overall secure network access framework. "PANA enabling IPsec based Access Control", Mohan Parthasarathy, 15-Sep-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-Oct-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, 16-Sep-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, 27-Oct-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 (pki4ipse) ---------------------------------------- "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Brian Korver, 1-Oct-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. "Requirements for an IPsec Certificate Management Profile", Chistopher Bonatti, 1-Nov-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. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Simple Certificate Validation Protocol (SCVP)", Ambarish Malpani, Russell Housley, Trevor Freeman, 26-Oct-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, 8-Oct-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 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, 23-Aug-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-Oct-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, 28-Oct-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. "Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX", Daniel R. L. Brown, 16-Aug-04, This document gives additional algorithms and associated ASN.1 identifiers for elliptic curve cryptography (ECC) used with the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (PKIX). The algorithms and identifiers here are consistent with both ANSI X9.62-1998 and X9.63-2001, and shall be consistent with the forthcoming revisions of these documents. Consistency shall also be maintained with SEC1 and SEC2, and any revisions or successors of such documents. "Internet X.509 Public Key Infrastructure Lightweight Directory Access Protocol Schema for X.509 Certificates", Peter Gietz, Norbert Klasen, 27-Oct-04, This document describes a Lightweight Directory Access Protocol schema which can be used to implement a certificate store for X.509 certificates. Specifically, two structural object classes for X.509 user and CA certificates are defined. Key fields of a certificate are stored in LDAP attributes so that applications can easily retrieve the certificates needed by using basic LDAP search filters. Multiple certificates for a single entity can be stored and retrieved. "Lightweight OCSP Profile for High Volume Environments", Alex Deacon, 27-Oct-04, This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or PKI environments that require a lightweight solution to minimize bandwidth and client side processing. Path MTU Discovery (pmtud) -------------------------- "Path MTU Discovery", Matt Mathis, 25-Oct-04, This document describes a robust method for Path MTU Discovery that relies on TCP or some 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. 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. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Nick Duffield, 22-Oct-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 a 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. "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, Maurizio Molina, Fredric Raspall, Nick Duffield, 19-Oct-04, This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in measurement processes and for reporting the technique in use to a Collector. "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. "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) ----------------------------------------- "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, 7-Sep-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, 29-Sep-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, 25-Oct-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 low-rate TDM and 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, 30-Aug-04, This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. "Frame Relay over Pseudo-Wires", Claude Kawa, 30-Aug-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. The first, one-to-one mapping mode, is characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs, and is defined for MPLS PSN only. The second mode is known as port mode or many-to-one mapping mode and is defined for both MPLS PSNs and IP PSNs with L2TPv3. "Encapsulation Methods for Transport of ATM Over MPLS Networks", Luca Martini, Matthew Bocci, Jeremy Brayley, Ghassem Koleyni, 28-Sep-04, An ATM Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing IP or MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide a ATM "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, 7-Oct-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 "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, 30-Aug-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). "PWE3 ATM Transparent Cell Transport Service", Andrew Malis, 23-Aug-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]. "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, 27-Oct-04, This document enumerates the OAM defect state mapping from pseudo wire emulated edge-to-edge services over MPLS and IP transport networks to their native attached services. "PWE3 Control Word for use over an MPLS PSN", Stewart Bryant, 19-Oct-04, This document describes the preferred designs of the PWE3 Control Word, and the PW Associated Channel Header. 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. RADIUS EXTensions (radext) -------------------------- "The Network Access Identifier", Bernard Aboba, 21-Oct-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 network 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. Resource Allocation Protocol (rap) ---------------------------------- "COPS Over TLS", Jesse Walker, Amol Kulkarni, 27-Sep-04, This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet. This document also updates RFC 2748 by modifying the contents of the Client-Accept message. 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, 26-Oct-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, 26-Oct-04, Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks and the Internet itself - especially where high bandwidth, low latency and/or low overhead are required by the hosted application. This draft examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). "An RDMA Protocol Specification", Renato Recio, 9-Sep-04, This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into ULP Buffers without intermediate data copies. It also enables a kernel bypass implementation. "Direct Data Placement over Reliable Transports", Himanshu Shah, 31-Aug-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. "Applicability of Remote Direct Memory Access Protocol (RDMA)and Direct Data Placement (DDP)", Caitlin Bestler, Lode Coene, 10-Sep-04, This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It contrasts the different transport options over IP that DDP can use, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. "Stream Control Transmission Protocol (SCTP) Remote Direct Memory Access (RDMA) Direct Data Placement (DDP) Adaptation", Randall Stewart, 27-Sep-04, This document describes a method to adapt Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) to Stream Control Transmission Protocol (SCTP) RFC2960 [2] using a generic description found in [RDMA-Draft] [4] and [DDP-Draft] [3]. "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, 27-Aug-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, 18-Oct-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, 18-Oct-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. "Transport Mappings for Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU)", Anwar Siddiqui, 18-Oct-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, ireless hand-held devices and various other computing devices have become an integral part of our day-to-day operations. Enterprises as well as service providers have requirements to monitor these end devices for application level session quality. [RAQMON- FRAMEWORK] defines an architecture and specifications to monitor such end devices for Quality of Service in real time. The same document specifies and information model for the performance monitoring data that is being used for this purpose. This memo specifies two transport mappings of the RAQMON information model using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). Distribution of this memo is unlimited. "Remote Network Monitoring Management Information Base Version 2", Steven Waldbusser, 20-Oct-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. 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, 14-Oct-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. Robust Header Compression (rohc) -------------------------------- "Requirements for ROHC IP/TCP Header Compression", Lars-Erik Jonsson, 14-Sep-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, 27-Oct-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. "ROHC Implementer's Guide", Lars-Erik Jonsson, Peter Kremer, 26-Oct-04, This document describes common misinterpretations and some ambiguous points of ROHC [1], which defines the framework and four profiles of a robust and efficient header compression scheme. The members of the ROHC working group have identified these issues during implementation and at the various interoperability test events. "TCP/IP Field Behavior", Mark West, Steven McCanne, 27-Oct-04, Header compression is possible thanks to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095 [36]. "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, 28-Oct-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, 6-Oct-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. "A Negative Acknowledgement Mechanism for Signaling Compression", Adam Roach, 21-Oct-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. "ROHC LLA Implementer's Guide", Kristofer Sandlund, 27-Sep-04, This document describes common misinterpretations and some ambiguous points of ROHC LLA [3], which defines the Link-Layer Assisted profile for IP/UDP/RTP. These points have been identified by the members of the ROHC working group during implementation of the profile. "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", Ghyslain Pelletier, 12-Nov-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. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "Generic Threats to Routing Protocols", Abbie Barbir, Sandra Murphy, Yibin Yang, 27-Oct-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. "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, 25-Oct-04, 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, 15-Oct-04, Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Name Resolution Protocol (ENRP) [7] 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. "Enpoint Name Resolution Protocol (ENRP)", Q Xie, Randall Stewart, Maureen Stillman, 15-Oct-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, 15-Oct-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. "Reliable Server Pooling Policies", Michael Tuexen, Thomas Dreibholz, 20-Oct-04, This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at name servers and pool users. Routing Area Working Group (rtgwg) ---------------------------------- "The Generalized TTL Security Mechanism (GTSM)", Vijay Gill, John Heasley, David Meyer, 30-Sep-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. This document obsoletes RFC 3682. "IP Fast Reroute Framework", Mike Shand, 28-Oct-04, This document provides a framework for the development of IP fast-reroute 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. "Basic Specification for IP Fast-Reroute: Loop-free Alternates", Alia Atlas, 4-Oct-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. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "The Anonymous SASL Mechanism", Kurt Zeilenga, 26-Oct-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, 26-Oct-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, 8-Sep-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, 27-Oct-04, The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 27-Oct-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, 14-Sep-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, 12-Aug-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", Chris Lonvick, 27-Oct-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, 27-Oct-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", Chris Lonvick, 27-Oct-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", Chris Lonvick, 27-Oct-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, 27-Oct-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. "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. "SSH Protocol Assigned Numbers", Chris Lonvick, 27-Oct-04, This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the 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. 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) ----------------------------- "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. "SS7 MTP3-User Adaptation Layer (M3UA)Management Information Base using SMIv2", Antonio Roque, 11-Aug-04, The MTP3-User Adaptation Layer is a protocol for the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database. It is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. "DPNSS/DASS 2 extensions to the IUA protocol", Ranjith Mukundan, Ken Morneault, 27-Sep-04, 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. "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)", Ken Morneault, Javier Pastor-Balbas, 14-Oct-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 Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Adam Roach, Jonathan Rosenberg, Ben Campbell, 25-Oct-04, 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. "The Message Session Relay Protocol", Ben Campbell, 26-Oct-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). "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Jonathan Rosenberg, 22-Oct-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, 25-Oct-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 resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state 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 be 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, 27-Oct-04, The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. The Rich Presence Information Data Format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions 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. "Partial Notification of Presence Information", Mikko Lonnfors, Jose Costa-Requena, Eva Leppanen, Hisham Khartabil, 27-Oct-04, By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even a just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of a new document type that contains the data that has actually changed. "Presence Information Data format (PIDF) Extension for Partial Presence", Mikko Lonnfors, Eva Leppanen, Hisham Khartabil, 28-Oct-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, 4-Oct-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, 4-Oct-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. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying the rules for when that information should be delivered. 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 Extension to Presence Information Data Format(PIDF)", Mikko Lonnfors, Krisztian Kiss, 26-Oct-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 defines an extension to represent RFC3840 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, 11-Aug-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, 28-Oct-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, 22-Oct-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, 26-Oct-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. "A Data Model for Presence", Jonathan Rosenberg, 27-Oct-04, This document defines the underlying data model and data processing operations used by Session Initiation Protocol (SIP) for Instant Messaging Leveraging Presence Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. The data processing operations described here include composition, privacy filtering, and watcher filtering. "Partial Publication of Presence Information", Mikko Lonnfors, 28-Oct-04, Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bear a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. Session Initiation Protocol (sip) --------------------------------- "Session Timers in the Session Initiation Protocol (SIP)", Steve Donovan, Jonathan Rosenberg, 11-Aug-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. "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. "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", Eric Burger, 27-Oct-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. "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Jon Peterson, 29-Sep-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. "An Extension to the Session Initiation Protocol for Request History Information", Mary Barnes, 25-Oct-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, 26-Oct-04, This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and Session Initiation Protocol (SIP) proxies. It does not directly influence the forwarding behavior of IP routers. "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, 25-Oct-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. "Update to the Session Initiation Protocol (SIP) Preconditions Framework", Gonzalo Camarillo, 29-Sep-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. "Best Current Practices for NAT Traversal for SIP", Chris Boulton, Jonathan Rosenberg, 27-Oct-04, Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NAT) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding call flows. "A Session Initiation Protocol (SIP) Event Package for Conference State", Jonathan Rosenberg, Henning Schulzrinne, 25-Oct-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, 22-Oct-04, This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. 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, 2-Nov-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, 22-Oct-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. "High Level Requirements for Tightly Coupled SIP Conferencing", Orit Levin, Roni Even, 7-Oct-04, This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. "A Framework for Conferencing with the Session Initiation Protocol", Jonathan Rosenberg, 19-Oct-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, 25-Oct-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, 27-Oct-04, This document describes a SIP Event Package "kpml" that enables monitoring of DTMF signals and uses XML documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML scripts that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML scripts to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). "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, 25-Oct-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, 8-Oct-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, 25-Aug-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, 17-Sep-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. "Requirements for Session Initiation Protocol Location Conveyance", James Polk, 26-Oct-04, This document presents the framework and requirements for usage of the Session Initiation Protocol (SIP) to convey user location information from one Session Initiation Protocol (SIP) entity 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. "Session-Independent Session Initiation Protocol (SIP) Policies - Mechanism and Policy Schema", Volker Hilt, 26-Oct-04, This draft specifies an XML schema for profile data for SIP session-policies. It defines a delivery mechanism for SIP session-policies that are independent of a specific SIP session. "Requirements and Framework for Session Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List Services", Gonzalo Camarillo, 18-Oct-04, This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionaly, it defines a framework for SIP URI-List services which includes security considerations applicable to these services. "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, 18-Oct-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, 18-Oct-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, 18-Oct-04, This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE. Instead of having a subscriber send a SUBSCRIBE for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. "Refering to Multiple Resources in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 18-Oct-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. "Certificate Management Service for SIP", Cullen Jennings, Jon Peterson, 19-Oct-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. "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 19-Oct-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, 19-Oct-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. "Framework of requirements for real-time text conversation using SIP.", Arnold Van Wijk, 20-Oct-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. S/MIME Mail Security (smime) ---------------------------- "Examples of S/MIME Messages", Paul Hoffman, 25-Aug-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). "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). "Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)", Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee, 30-Aug-04, This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). "Certificate extension for S/MIME Capabilities", Stefan Santesson, 12-Nov-04, This document defines a certificate extension for inclusion of S/MIME capabilities in public key certificates defined by RFC 3280. S/MIME Capabilities provides an optional method to communicate cryptographic capabilities of the certified subject as a complement to use of the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. 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, 20-Oct-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. Source-Specific Multicast (ssm) ------------------------------- "Source-Specific Multicast for IP", Hugh Holbrook, Bradley Cain, 8-Sep-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. This document 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. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "The syslog Protocol", Rainer Gerhards, 22-Oct-04, This document describes the syslog protocol which is used to convey event notification messages. It 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-Nov-04, This document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. Syslog protocol layered architecture provided for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementors are required to support this transport protocol. 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. "A Roadmap for TCP Specification Documents", Martin Duke, 11-Oct-04, This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a rough guide and quick reference for both TCP implementers and other parties that need help consuming the vast cornucopia of TCP-related RFCs. 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, 13-Sep-04, This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. "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, 21-Oct-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, 25-Aug-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]. "The TLS Protocol Version 1.1", Tim Dierks, Eric Rescorla, 11-Aug-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)", Pasi Eronen, 6-Oct-04, This document specifies three sets of 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. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. 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, 25-Oct-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, 27-Sep-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. "Stream Control Transmission Protocol (SCTP) Implementer's Guide", Randall Stewart, 18-Oct-04, This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document. This document updates RFC2960 [6] and text within this document supersedes the text found in RFC2960 [6]. "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, 15-Sep-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. 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, 15-Sep-04, This document specifies the syntax of network news articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document supersedes RFC 1036, updating it to reflect current practice and incorporating incremental changes specified in other documents. "News Article Architecture and Protocols", Charles Lindsey, 21-Sep-04, This Draft, together with its companion draft [USEFOR], are intended as standards track documents, together obsoleting RFC 1036, which itself dates from 1987. IPv6 Operations (v6ops) ----------------------- "Analysis on IPv6 Transition in 3GPP Networks", Juha Wiljakka, 27-Oct-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, 1-Sep-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. "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. "Goals for Registered Assisted Tunneling", Florent Parent, 22-Oct-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 through tunneling. "IPv6 Enterprise Network Analysis", Jim Bound, 16-Sep-04, This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition units and requirements expanded from a previous Enterprise Scenarios document, and will depict a set of components and transition methods required for the enterprise to transition to IPv6 within each scenario and then common to all scenarios. 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, 28-Oct-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, 28-Oct-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, 1-Oct-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, 21-Oct-04, This specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), 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. "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, 29-Sep-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, 26-Oct-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, 12-Aug-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, 25-Oct-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. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usages for Conference Policy Manipulation and Conference Policy Privelges Manipulation", Hisham Khartabil, 12-Oct-04, The Conference Policy is defined as the complete set of rules for a particular conference manipulated by the conference policy server. The Conferece Policy Control Protocol (CPCP) is the protocol used by client to manipulate the conference policy. This document defines an XML Configuration Access Protocol (XCAP) application usage that may be used to store and manipulate a conference policy. "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, 28-Oct-04, Floor control is a means to manage joint or exclusive access to shared resources 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 specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. "Privileges for Manipulating a Conference Policy", Hisham Khartabil, Aki Niemi, 12-Oct-04, The Conference Policy is defined as the complete set of rules for a particular conference manipulated by the conference policy server. The Conferece Policy Control Protocol (CPCP) is the protocol used by client to manipulate the conference policy. This document specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy meta data that enable a user to assign privileges to users that enables them to read and/or manipulate parts of or the entire conference policy. "The Conference Policy Control Protocol (CPCP)", Hisham Khartabil, 12-Oct-04, The Conference Policy is defined as the complete set of rules for a particular conference manipulated by the conference policy server. The Conferece Policy Control Protocol (CPCP) is the protocol used by clients to manipulate the conference policy. 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. 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.