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, 18-Nov-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, 2-Feb-05, 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. "Client SMTP Authorization (CSA)", Douglas Otis, 22-Feb-05, 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)", John Leslie, 22-Feb-05, 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. 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, 17-Jan-05, 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, 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, 17-Jan-05, 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, 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 Publishing Format and Protocol (atompub) --------------------------------------------- "The Atom Syndication Format", Mark Nottingham, 27-Jan-05, 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 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, 29-Dec-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, 16-Feb-05, This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It is intended that other codes will be documented separately. "RTP Payload Format for AC-3 Streams", Jason Flaks, 1-Feb-05, This document describes an RTP payload format for transporting AC-3 encoded audio data. AC-3 is a high quality, multichannel audio coding system used in US HDTV, DVD, cable and satellite television and other media. The RTP payload format as presented in this document includes support for data fragmentation. "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 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. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 8-Dec-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-Dec-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, 10-Jan-05, 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). The memo also defines how session descriptions may specify RTP streams that use the framing method. "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, 16-Feb-05, 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, 30-Dec-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, 22-Feb-05, 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 synchronized with audio/video contents and used in application such as captioning, titling and multimedia presentations. 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, 3-Feb-05, 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 media type registration is included for VMR-WB RTP payload format. "RTP Payload Format for Extended AMR Wideband (AMR-WB+) Audio Codec", Johan Sjoberg, 15-Feb-05, This document specifies a real-time transport protocol (RTP) payload format for Extended AMR Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high quality music and speech. A media type registration for AMR-WB+ is included in this specification. "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 and Storage Format for BroadVoice Speech Codecs", Juin-Hwey Chen, 21-Feb-05, This document describes the RTP payload format and the storage 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, 18-Feb-05, 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, 31-Jan-05, 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, Amy Pendleton, 22-Feb-05, 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, 26-Jan-05, 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. "MIME type registration for RTP Payload format for H.224", Roni Even, 13-Dec-04, In conversional video applications far end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 MIME type. It defines the syntax and the semantics of the SDP parameters needed to support far end camera control protocol using H.281. "Definition of Events For Modem, FAX, and Text Telephony Signals", Henning Schulzrinne, 18-Feb-05, This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-08) to add event codes for modem, FAX, and text telephony signals when carried in the telephony event RTP payload. "Definition of Events For Channel-Oriented Telephony Signalling", Henning Schulzrinne, 7-Feb-05, This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-07) to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. "Enhanced Processing For Priority and Header in: RTP Payload Format for JPEG 2000 Video Streams", Andrew Leung, 15-Feb-05, This memo describes extended uses for payload header in RFCXXXY, An RTP Payload Format for JPEG 2000 Video, for better support of JPEG 2000 features such as scalability and includes a main header recovery method. This memo MUST be accompanied with an implementation of RFCXXXY for a complete implementation. RFCXXXY itself is a complete description of the payload header and signaling, this document only describes additional processing of values for the payload header. There is also another MIME and SDP marker signaling for implementations of this document. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Simple Traversal of UDP Through Network Address Translators (NAT) (STUN)", Jonathan Rosenberg, 24-Feb-05, 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. "NAT Behavioral Requirements for Unicast UDP", Francois Audet, Cullen Jennings, 13-Jan-05, This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP, and defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD For MPLS LSPs", Rahul Aggarwal, 21-Feb-05, 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, 22-Feb-05, 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, 22-Feb-05, 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, 22-Feb-05, 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 Network-layer Traffic Control Mechanisms", Jerry Perser, David Newman, 21-Feb-05, This document describes terminology for the benchmarking of devices that implement traffic control based on IP precedence or diff-serv code point criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control meachanisms. "Benchmarking Terminology for Routers Supporting Resource Reservation", Krisztian Nemeth, Istvan Cselenyi, Andras Korn, 20-Jan-05, The purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. "Terminology for Benchmarking BGP Device Convergence in the Control Plane", Howard Berkowitz, 21-Jul-04, This draft establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. "Methodology for Forwarding Information Base (FIB) based Router Performance", Jeffery Dunn, Cynthia Martin, 15-Feb-05, 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, 21-Feb-05, This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Benchmarking Methodology for IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, 21-Feb-05, 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, 21-Feb-05, 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, 21-Feb-05, 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, 21-Feb-05, 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, 23-Feb-05, 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 [4]. "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", David Newman, Timmons Player, 16-Feb-05, 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, 16-Feb-05, 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]. "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", Vivian Ngai, Ernest Bell, 16-Nov-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001. The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-1998, P802.1u and P802.1v. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB]. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", Lily Yang, Petros Zerfos, Emek Sadot, 18-Nov-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. "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", S Govindan, 10-Dec-04, This document presents a set of objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). It presents objectives in three categories: architecture, operations and security. The primary purpose of the document is to present focused requirements which when realized, will ensure interoperability among wireless local area network (WLAN) devices of alternative designs. These objectives will form the basis for the development and evaluation of a CAPWAP protocol. 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, 23-Feb-05, Generalized MPLS (GMPLS) is a suite of protocol extensions to MPLS (Multi-Protocol Label Switching) to make it generally applicable, to include - for example - control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document high-lights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required 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, 17-Jan-05, 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, 11-Feb-05, 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 Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", Thomas Nadeau, 21-Feb-05, 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, 18-Feb-05, 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, 21-Feb-05, 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 and GMPLS Signaling", Adrian Farrel, 21-Feb-05, 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) and Generalized MPLS (GMPLS) Traffic Engineered (TE) 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, and GMPLS signaling as defined in 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description', RFC3473. These extensions mean 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 - Communication of Alarm Information", Lou Berger, 16-Nov-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, 21-Feb-05, 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", JP Vasseur, 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, 21-Feb-05, The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and 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-T), 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, 21-Feb-05, 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. "Inter domain GMPLS Traffic Engineering - RSVP-TE extensions", Arthi Ayyangar, JP Vasseur, 9-Feb-05, 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. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "IRIS - An Address Registry (areg) Type for the Internet Registry Information Service", A Newton, 21-Feb-05, 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, 28-Jan-05, 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, 25-Jan-05, This document describes a lightweight UDP transport for the Internet Registry Information Service (IRIS). "IRIS - URI Resolution for AREG Type for the Internet Registry Information Service", Engin Gunduz, 21-Feb-05, This document describes a URI Resolution method for the IRIS registry schema for IP address and Autonomous System Number information. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control", Sally Floyd, Eddie Kohler, 18-Nov-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, 21-Dec-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)", Eddie Kohler, 15-Nov-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. "TCP Friendly Rate Control (TFRC) for Voice: VoIP Variant and Faster Restart", Sally Floyd, Eddie Kohler, 22-Feb-05, TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC 3448]. This document adds a VoIP variant to TFRC. TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. The VoIP variant of TFRC is designed for applications that send small packets, where the design goal is to achieve the same bandwidth in bps as a TCP flow using 1500-byte data packets. The VoIP variant of TFRC enforces a Min Interval of 10 ms between data packets, to prevent a single flow from sending small packets arbitrarily frequently. This document also introduces faster restart, a mechanism for safely improving the behavior of interactive flows that use TFRC. 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, 15-Feb-05, 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, 17-Feb-05, 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. " Virtual Subnet Selection Sub-Option for the Relay Agent Information Option", Kenneth Kinnear, Mark Stapp, Richard Johnson, Jay Kumarasamy, 16-Feb-05, In some environments, a relay agent resides in a network element which also has access to one or more virtual private networks (VPNs). If one DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know information about the VPN on which each client resides. The virtual-subnet-selection sub- option of the relay-agent-information option is used by the relay agent to tell the DHCP server important information about the VPN (called the Virtual Subnet Selection information, or VSS) for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. "Virtual Subnet Selection Option", Richard Johnson, Kenneth Kinnear, Mark Stapp, Jay Kumarasamy, 10-Feb-05, This memo defines a new DHCP option for passing Virtual Subnet Selection (VSS) information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address allocation to take place. The option number currently in use is 221. This memo documents the current usage of the option in agreement with RFC-3942[7] , which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "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 Option", Richard Johnson, 10-Feb-05, 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. The option number currently in use is 220. This memo documents the current usage of the option in agreement with RFC-3942[7] , which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "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). "DHCP Preboot eXecution Environment (PXE) Suboptions", Michael Johnston, 27-Jan-05, Define DHCP suboptions being used by PXE and EFI clients. "Node-Specific Client Identifiers for DHCPv4", Ted Lemon, 3-Feb-05, 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. "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. "Information Refresh Time Option for DHCPv6", Stig Venaas, Tim Chown, 11-Jan-05, This document describes a DHCPv6 option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh 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, 15-Feb-05, This document specifies a new Dynamic Host Configuration Protocol 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. "DHCPv4 Options for Broadcast and Multicast Control Servers", Kuntal Chowdhury, 29-Dec-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. "DHCPv6 Options for Broadcast and Multicast Control Servers", Kuntal Chowdhury, 29-Dec-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. "Service-Oriented Address Assignment using DHCPv6", Syam Madanapalli, 20-Jan-05, This document introduces a new option in DHCPv6 for Service-Oriented Address assignment for a particular type of service that DHCPv6 Clients provide. The Service-Oriented Address can be either Anycast/Shared Unicast or a Well-known Unicast Address. This address assignment is much similar to other address type assignments, except that Service-Oriented Address assignment requires the specification of Service Type of the node that is requesting the address. "DHCPv6 Relay agent RADIUS Attribute Option", Wing Lau, 14-Feb-05, 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 RADIUS Attributes Option (RRAO) which extends the set of DHCPv6 options as defined in RFC 3315 and 3376. Following its DHCPv4 counterpart, the new option is inserted by the DHCPv6 relay agent when forwarding client-originated DHCPv6 packets to a DHCPv6 server. Servers recognizing the RRAO 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. 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, 14-Dec-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, 27-Dec-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, 11-Feb-05, 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, 9-Feb-05, 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-Feb-05, 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. "DNSSEC Opt-in", Roy Arends, Mark Kosters, David Blacka, 3-Feb-05, In RFC 2535, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an 'Opt-In' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. "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, 29-Dec-04, The standard method for storing elliptic curve cryptographic keys and signatures in the Domain Name System is specified. "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, 31-Jan-05, 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 updates RFCs 1034 and 1035. "Clarifying the Role of Wild Card Domains in the Domain Name System", Edward Lewis, 11-Feb-05, This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, 23-Feb-05, 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, 21-Feb-05, 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. "DNSSEC Hash Authenticated Denial of Existence", Ben Laurie, 22-Feb-05, The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be used to provide authenticated denial of existence of DNS ownernames and types; however, it permits any user to traverse a zone and obtain a listing of all ownernames. "Storing Certificates in the Domain Name System (DNS)", Simon Josefsson, 3-Feb-05, 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). "DNSSEC Experiments", David Blacka, 4-Feb-05, In the long history of the development of the DNS security [1] extensions (DNSSEC), a number of alternate methodologies and modifications have been proposed and rejected for practical, rather than strictly technical, reasons. There is a desire to be able to experiment with these alternate methods in the public DNS. This document describes a methodology for deploying alternate, non-backwards-compatible, DNSSEC methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. Domain Name System Operations (dnsop) ------------------------------------- "Encouraging the use of DNS IN-ADDR Mapping", Daniel Senie, 22-Feb-05, Mapping of addresses to names has been a feature of DNS. Many sites, implement it, many others don't. Some applications attempt to use it as a part of a security strategy. The goal of this document is to encourage proper deployment of address to name mappings, and provide guidance for their use. "Observed DNS Resolution Misbehavior", Matt Larson, Piet Barber, 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. "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. "DNSSEC Operational Practices", Olaf Kolkman, 28-Dec-04, This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues as key generation, key storage, signature generation, key rollover and related policies. "Requirements for Automated Key Rollover in DNSsec", Gilles Guette, 19-Jan-05, 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 during an automated rollover process. This document is essentially about in-band key rollover. "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, 21-Feb-05, 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 for IPv6 DNS configuration to select the 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, 29-Dec-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, 21-Feb-05, 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'. It also specifies the EAP key hierarchy. "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 Using HTTP, Applicability Statement 2 (AS2)", Dale Moberg, Rik Drummond, 19-Jan-05, This document provides a applicability statement (RFC 2026, 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML, Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format, or in the UN Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) format, or in other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1," RFC 3335. "Compressed Data for EDIINT", Terry Harding, 31-Jan-05, The intent of this document is to be placed on the RFC track as an Informational RFC. The EDIINT AS1 and AS2 message formats don't currently contain any transport neutral provisions for compressing data when utilizing S/MIME as the secure packaging standard. Compressing data before transmission provides a number of advantages including 1. reducing data redundancy, and so reducing opportunities for attacks exploiting redundancy, and 2. reducing the amount of data and so speeding up cryptographic processing such as signing, encryption, archiving, and 3. reducing the overall transmitted message size, reducing both time and bandwidth needed for transport. Entity MIB (entmib) ------------------- "Entity MIB (Version 3)", Keith McCloghrie, Andy Bierman, 20-Jan-05, 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, 24-Jan-05, 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, 2-Dec-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, 14-Feb-05, 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. "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". "An ENUM Registry Type for the Internet Registry Information Service", Andrew Newton, 1-Feb-05, This document describes an IRIS registry schema for registered ENUM 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 ENUM registries. Internet Fax (fax) ------------------ "Full-mode Fax Profile for Internet Mail: FFPIM", David Crocker, Graham Klyne, 23-Dec-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 Requirements", K Mimura, K Yokoyama, T Satoh, C Kanaide, 23-Feb-05, To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail based Internet Fax service (i-fax) an "Internet FAX Gateway" is required. This document provides recommendations for the functionality of Internet FAX Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; viceversa an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. "Guideline of optional services for Internet FAX Gateway", K Mimura, 2-Feb-05, To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail based Internet Fax service (i-fax) an "Internet FAX Gateway" is required. This document provides guidelines for the optional functionality of Internet FAX Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; viceversa an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. "SMTP and MIME Extensions For Content Conversion", Kiyoshi Toyoda, Dave Crocker, 21-Jan-05, 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. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Forwarding Element Model", Lily Yang, 23-Feb-05, 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, 22-Feb-05, 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, 21-Feb-05, 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, 30-Nov-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, 22-Feb-05, 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, 22-Feb-05, 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. "Location Types Registry", Henning Schulzrinne, Hannes Tschofenig, 30-Nov-04, This document creates a registry for location types. 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. "Embedding Globally Routable Internet Addresses Considered Harmful", Dave Plonka, 23-Nov-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". "Operation of Anycast Services", Joe Abley, Kurt Lindqvist, 16-Feb-05, As the Internet has grown, and as systems and networked services within enterprises have been more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. General Switch Management Protocol (gsmp) ----------------------------------------- "GSMPv3 Base Specification", Avri Doria, 15-Nov-04, This document describes the base General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol", Robert Moskowitz, 22-Feb-05, 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, 11-Jan-05, 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, their 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. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. "End-Host Mobility and Multi-Homing with Host Identity Protocol", Pekka Nikander, 22-Feb-05, This document defines a "locator" parameter for the Host Identity Protocol and specifies an end-host mobility mechanism. "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", Pekka Nikander, Julien Laganier, 22-Feb-05, This document specifies two new resource records (RRs) for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Name or IP addresses of its Rendezvous Servers (RVS). "Host Identity Protocol (HIP) Rendezvous Extensions", Julien Laganier, L Eggert, 22-Feb-05, This document discusses a Rendezvous extension for the Host Identity Protocol (HIP). The Rendezvous extension extend HIP and the HIP registration extension for initiating communication between HIP nodes via HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. 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, 30-Nov-04, This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet likeEthernet 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, 9-Feb-05, 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, 10-Dec-04, This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. "A Survey of Internet Identities", Patrik Faltstrom, Geoff Huston, 14-Dec-04, This memo provides an overview of the various realms of identification used within the Internet protocol suite, with a view to noting the interdependencies of the different identifiers and consequent implications for updating their specifications or changing their infrastructures' operations. "Architectural Implications of Link Indications", Bernard Aboba, 11-Jan-05, This document provides an overview of the role of link indications within the Internet Architecture. While the judicious use of link indications can provide performance benefits, experience has also shown that that inapropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues and provides examples of appropriate and inappropriate uses of 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. "What's in a Name: False Assumptions about DNS Names", Jonathan Rosenberg, 23-Feb-05, The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, URIs, and other application layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. A danger of this trend is that the humans and automata which consume and use these identifiers will make assumptions about the services that are or should be provided by the hosts associated with these identifiers. This document discusses this problem in more detail and makes recommendations on how it can be avoided. "Process for the IAB selection of an IAOC member", Geoff Huston, 24-Jan-05, This memo outlines the process by which the IAB makes a selection of a member of the IETF Administrative Oversight Committee. "IAB Thoughts on the Role of the Internet Research Task Force (IRTF)", Sally Floyd, Vern Paxson, 28-Jan-05, As part of the process of appointing a new chair of the Internet Research Task Force (IRTF) (due to the resignation of the current chair, Vern Paxson), the IAB is considering the future role of the IRTF both on its own, and in relationship to the IETF. The IAB decided to expand this discussion into an IAB report on the role of the IRTF, and to circulate this document for wider community review. "Process for the IAB and IESG selection of IAOC members", Geoff Huston, Bert Wijnen, 4-Feb-05, This memo outlines the process by which the IAB and the IESG makes selections of members of the IETF Administrative Oversight Committee. "Considerations for Selection of Techniques for NAT Traversal", Jonathan Rosenberg, 14-Feb-05, There are many protocols designed and deployed on the Internet today which do not naturally traverse Network Address Translators (NAT). In order to allow these protocols to work in the presence of NAT, additional logic needs to be added to the network. This logic modifies the behavior of the protocol in some way. There are choices where this logic can be placed in the network. It can reside in the NATs themselves, transparently altering the protocol; when this occurs, it is called an Application Layer Gateway (ALG). It can reside in server components, hiding the changes from NATs and clients alike, it can reside in the clients, or it can reside in a combination thereof. The choice of the placement of this logic typically has implications on many aspects of the protocol, including security, deployability, manageability and availability. This document provides a set of considerations that should be taken into account by protocol and network designers when making this choice. 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. "Cooperative Route Filtering Capability for BGP-4", Enke Chen, Yakov Rekhter, 21-Dec-04, This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "Graceful Restart Mechanism for BGP", Srihari Sangli, Yakov Rekhter, Rex Fernando, John Scudder, Enke Chen, 9-Jun-04, This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). "BGP support for four-octet AS number space", Quaizar Vohra, Enke Chen, 21-Dec-04, Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. "BGP Extended Communities Attribute", Srihari Sangli, Dan Tappan, Yakov Rekhter, 1-Feb-05, This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. "Aspath Based Outbound Route Filter for BGP-4", Keyur Patel, Susan Hares, 2-Feb-05, This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "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, 3-Dec-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 [RFC1264]. In order to fulfill the requirement, this report augments [RFC1774] and summarizes the key features of BGP-4 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. "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. "Avoid BGP Best Path Transitions from One External to Another", Enke Chen, Srihari Sangli, 20-Dec-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. "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. "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", Hervé Debar, 3-Feb-05, 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. "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, 2-Dec-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, 7-Feb-05, 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, 7-Feb-05, 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) ------------------------------------------ "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. "IMAP ANNOTATE Extension", Randall Gellens, Cyrus Daboo, 3-Feb-05, 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, 10-Feb-05, 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", Alexey Melnikov, 18-Feb-05, The ACL (Access Control List) extension (RFC 2086) of the Internet Message Access Protocol (IMAP4rev1) permits mailbox access control lists to be manipulated through the IMAP protocol. This document is a revision of the RFC 2086. It defines several new access control rights and 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, 17-Feb-05, 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. "Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel", Claudio DeSanti, 7-Feb-05, This document specifies the way of encapsulating IPv6, IPv4 and ARP packets over Fibre Channel. This document specifies also the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. Extended Incident Handling (inch) --------------------------------- "The Incident Object Description Exchange Format Data Model and XML Implementation Document Type Definition", Jan Meijer, 15-Nov-04, The purpose of the Incident Object Description Exchange Format (IODEF) is to define a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. The IODEF satisfies the requirements specified in RFCXXX [1] This Internet-Draft describes a data model for representing incident information exported from incident handling systems managed by CSIRTs. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "Requirements for Format for INcident Report Exchange (FINE)", Yuri Demchenko, 9-Feb-05, The purpose of the Format for Incident report Exchange (FINE) is to facilitate the exchange of incident information and statistics among responsible Computer Security Incident Response Teams (CSIRTs) and involved parties. FINE can be used for reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. A common and well-defined format will help in the exchange of Incident related information across organizations, regions and countries. This document describes the requirements for an Incident Report Exchange Format. "The Incident Object Description Exchange Format (IODEF) Implementation Guide", Roman Danyliw, 15-Nov-04, The purpose of this Internet-Draft is to provide implementation guidelines for Computer Security Incident Response Teams (CSIRT) adopting the Incident Object Description Exchange Format (IODEF). "Incident Handling: Real-Time Inter-Network Defense", Kathleen Moriarty, 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, 8-Feb-05, 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, 22-Nov-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 DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) 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. "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", Richard Woundy, 21-Feb-05, This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. "Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", Azlina Ahmad, 28-Jan-05, 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-Feb-05, 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, 22-Feb-05, 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, 25-Jan-05, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. "Management Event MIB for PacketCable/IPCablecom MTAs", Wim De Ketelaere, 22-Feb-05, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for events generated by PacketCable and 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. IP over DVB (ipdvb) ------------------- "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", Gorry Fairhurst, Bernhard Collini-Nocker, 16-Feb-05, The MPEG-2 Transport Stream (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 the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. "A Framework for transmission of IP datagrams over MPEG-2 Networks", Marie-Jose Montpetit, 18-Jan-05, 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, 21-Feb-05, This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP 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", Juergen Quittek, 21-Feb-05, This memo defines and information 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 Observation Point, the traffic Metering Process and the Exporting Process. Although developed for the IPFIX protocol, 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-Feb-05, 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 is required. This document describes how the IPFIX flow record data, options record data and templates are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process. "IPFIX Applicability", Tanja Zseby, 18-Feb-05, 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). "Definition of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management", Sean Harnedy, 30-Nov-04, This memo defines a Management Information Base (MIB) module that contains Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. The intent is that these TEXTUAL CONVENTIONs (TCs) will be imported and used in IPOVERIB related MIB modules. "IP over InfiniBand(IPoIB) Architecture", Vivek Kashyap, 4-May-04, InfiniBand is a high speed, channel based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. "Transmission of IP over InfiniBand", H.K. Jerry Chu, Vivek Kashyap, 13-Jan-05, This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link layer address to be used when resolving the IP addresses in 'IP over InfiniBand (IPoIB)' subnets. The document also describes the mapping from IP multicast addresse to InfiniBand multicast addresses. Additionally this document defines the setup and configuration of IPoIB links. "DHCP over InfiniBand", Vivek Kashyap, 14-Feb-05, An InfiniBand network uses a link-layer addressing scheme that is 20-octets long. This is larger than the 16-octets reserved for the hardware address in DHCP/BOOTP message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IP over InfiniBand(IPoIB) network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. "Definitions of Managed Objects for Infiniband Channel Adapters (CA)", Sean Harnedy, 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). "IP over InfiniBand: Connected Mode", Vivek Kashyap, 23-Feb-05, This document specifies a method for transmitting IPv4/IPv6 packets and address resolution over the connectd modes of InfiniBand. 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, 20-Dec-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, 30-Nov-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 and for encouraging all IP performance metrics to be registered here. IANA has been assigned to administer this new registry. IANA has been assigned to administer this new registry. "Packet Reordering Metric for IPPM", Al Morton, 18-Feb-05, 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. "Overview of Implementation reports for RFC 2678 - 2681", Henk Uijterwaal, 8-Feb-05, This document contains a summary of the implementation reports submitted for RFC's 2678 to 2681 during the second half of 2004. Intellectual Property Rights (ipr) ---------------------------------- "Indication of Trademarks in IETF Documents", Scott Bradner, 3-Feb-05, People writing IETF documents sometimes must use trademarked terms. This document clarifies how document authors can indicate that a term is trademarked. This document updates RFC 3667 and 3668. 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, 22-Feb-05, 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, 9-Dec-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, which are used to interconnect FC fabrics with IP networks. "Definitions of Managed Objects For iFCP", Kevin Gibbons, 1-Feb-05, 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-Dec-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, 27-Jan-05, 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 module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. "Datamover Architecture for iSCSI (DA)", Mallikarjun Chadalapaka, 9-Feb-05, 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, 8-Feb-05, 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). "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, 8-Dec-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, 8-Dec-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 obsoletes RFC 2401 (November 1998). Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor: Please remove this line prior to publication as an RFC.] "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. "The Use of Galois/Counter Mode (GCM) in IPsec ESP", David McGrew, 27-Apr-04, This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. IPSEC KEYing information resource record (ipseckey) --------------------------------------------------- "A method for storing IPsec keying material in DNS", Michael Richardson, 20-Jan-05, 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, 22-Feb-05, 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 described in this document is of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards based defined packet filters and actions. "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, 22-Feb-05, 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 Uniform Resource Identifiers (URIs)", Vijay Gurbani, 15-Feb-05, This document describes a standardized mechanism to convey trunk group- related information in sip and tel Uniform Resource Identifiers (URIs). An extension to the "tel" URI is defined for this purpose. "New Parameters for the 'tel' URI to Support Number Portability", James Yu, 18-Feb-05, Number Portability (NP) for the geographical telephone numbers and freephone numbers impacts signaling and routing in the Global Switched Telephone Network (GSTN) and Internet Protocol (IP) domain. At present, there is no mechanism for a network node in the IP domain to pass the NP-related information to the next-hop network node after it has performed an NP database dip. This document defines several new parameters in the "tel" Uniform Resource Identifier (URI) to carry the NP-related information that can be used by the network nodes in the IP domain to correctly set up the calls or sessions. "The ENUM Dip Indicator parameter for the "tel" URI", Richard Stastny, Lawrence Conroy, 3-Feb-05, This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) as defined in RFC3966 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. IP Version 6 Working Group (ipv6) --------------------------------- "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", Alex Conta, 22-Nov-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, 19-Jan-05, 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, 7-Dec-04, This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate their unique multicast addresses automatically without conflicts. Basically, this document proposes an alternative method for creating link-local multicast addresses over a known method like unicast-prefix-based IPv6 multicast addresses. It is preferred to use this method for link-local scope rather than unicast- prefix-based IPv6 multicast addresses. This memo update RFC3306. "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, 24-Jan-05, 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 Version 6 Addressing Architecture", Robert Hinden, Steve Deering, 18-Feb-05, This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-3513 "IP Version 6 Addressing Architecture". "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, 28-Dec-04, This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. "Optimistic Duplicate Address Detection for IPv6", Nick Moore, 14-Feb-05, 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. "Centrally Assigned Unique Local IPv6 Unicast Addresses", Robert Hinden, Brian Haberman, 21-Feb-05, 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, 22-Feb-05, 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, 28-Dec-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. "Considerations on M and O Flags of IPv6 Router Advertisement", Soohong Park, 1-Dec-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. "Bridge-like Neighbor Discovery Proxies (ND Proxy)", Dave Thaler, 22-Feb-05, 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. IS-IS for IP Internets (isis) ----------------------------- "Management Information Base for IS-IS", Jeff Parker, 18-Feb-05, 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. "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, 11-Feb-05, 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, 18-Jan-05, 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. "Definition of an IS-IS Link Attribute sub-TLV", JP Vasseur, Stefano Previdi, 14-Jan-05, This document defines a sub-TLV called “Link-attributes” carried within the TLV 22 and used to flood some link characteristics. "IPv6 Traffic Engineering in IS-IS", Jon Harrison, 17-Jan-05, 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. "IS-IS extensions for advertising router information", JP Vasseur, 26-Jan-05, This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. Integrated Security Model for SNMP (isms) ----------------------------------------- "Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol)", Uri Blumenthal, 14-Feb-05, Although the Simple Network Management Protocol (SNMPv3) is secure, operators and administrators have found that deploying it can be problematic in large distributions, due to a lack of integration between its User-Based Security Model (USM) and other authentication and user management infrastructure. This memo contains an evaluation of three proposals for an integrated security model for SNMP, and, based on these proposals, suggests how the ISMS (Integrated Security Model for SNMP) working group might move forward. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- "The Simple and Protected GSS-API Negotiation Mechanism", Larry Zhu, 24-Jan-05, This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. "Desired Enhancements to GSSAPI Naming", Sam Hartman, 22-Feb-05, The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms such as public-key mechanisms do not have a single name to be used across all environments. Other mechanisms such as Kerberos include may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. "GSS-API Domain-Based Service Names and Name Type", Nicolas Williams, 3-Dec-04, This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (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. "A PRF API extension for the GSS-API", Nicolas Williams, 14-Feb-05, This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Applicatoin Programming Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that don't or cannot use GSS-API per-message MIC (message integrity check) and wrap tokens for session protection. "GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", Nicolas Williams, 3-Dec-04, This document describes the mapping of GSS-API domainname-based service principal names onto Kerberos V principal names. "A PRF for the Kerberos V GSS-API Mechanism", Nicolas Williams, 15-Feb-05, 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. "GSS-API V2: Java & C# Bindings", James Luciani, 27-Dec-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 Generic Security Service API Version 2: Java Bindings [RFC2853], to include C# bindings. The proposed updates are documented as additions to be merged into section 4 of RFC 2853. "Corrections and Updates of GSS-API Java Bindings", Seema Malkani, 2-Feb-05, This document corrects and updates the specification of the Java programming language bindings of the Generic Security Services Application Programming Interface (GSS-API). Specifically, the error code values used for GSS exceptions were incorrect in the original; additionally, missing numeric values of the credential usage constants are specified. "Guide to the GSS-APIv3", Nicolas Williams, 14-Feb-05, 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. "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 15-Feb-05, This document clarifies and generalizes the GSS-API "channel bindings" facility. This document also specifies the format of the various types of channel bindings. "GSS-API Extension for Storing Delegated Credentials", Nicolas Williams, 15-Feb-05, 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. "Namespace Considerations and Registries for GSS-API Extensions", Nicolas Williams, 15-Feb-05, This document describes the ways in which the GSS-API may be extended and directs the creation of IANA registries for various GSS-API namespaces. Kerberos WG (krb-wg) -------------------- "Public Key Cryptography for Initial Authentication in Kerberos", Brian Tung, Larry Zhu, 21-Feb-05, This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by passing digital certificates and associated authenticators in pre-authentication data fields. "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. "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. "Kerberos Set/Change Password: Version 2", Nicolas Williams, 22-Feb-05, 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, 1-Feb-05, 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. "The Kerberos Network Authentication Service (Version 5)", Tom Yu, 25-Jan-05, This document describes version 5 of the Kerberos network authentication protocol. It describes a framework to allow for extensions to be made to the protocol without creating interoperability problems. 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, 2-Dec-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 nodes. Additional documents detail the specifics for each data 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. "Transport of Ethernet Frames over L2TPv3", Rahul Aggarwal, 7-Dec-04, This document describes transport of Ethernet frames over Layer 2 Tunneling Protocol (L2TPv3). This includes the transport of Ethernet port to port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudo Wires to transport Ethernet frames over an IP network. "L2VPN Extensions for L2TP", Wei Luo, 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 Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur, 2-Feb-05, 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. 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, 22-Feb-05, 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, Yakov Rekhter, 21-Feb-05, 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 offers a Layer 2 Virtual Private Network (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, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. "Virtual Private LAN Services over MPLS", Marc Lasserre, Vach Kompella, 22-Feb-05, This document describes a virtual private LAN service (VPLS) solution using pseudo-wires, a service previously implemented over other tunneling technologies and 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. Multiple VPLS services can be supported from a single PE node. "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", Eric Rosen, Vasile Radoaca, 21-Feb-05, 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. "Using RADIUS for PE-Based VPN Discovery", Juha Heinanen, 21-Feb-05, This document describes a strategy by which Provider Equipment (PE) can be dynamically provisioned for inclusion in PE-based Layer 2 Virtual Private Networks (L2VPNs). This layered strategy utilizes the Remote Authentication Dial In User Service (RADIUS) protocol as a centralized control mechanism and can be used in conjunction with other proposed mechanisms. The mechanisms described in this document enhance those established by RFC 2868 and conform to those described by the L2VPN Framework. "VPLS OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, 22-Feb-05, 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, 18-Feb-05, 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 reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [2547bis] for support of IPv6. In BGP/MPLS IP 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 IPv6 VPN 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, IP-in-IP, GRE and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. "MPLS/BGP Layer 3 Virtual Private Network Management Information Base", Thomas Nadeau, 7-Feb-05, 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, 23-Feb-05, In any Layer-3 and Layer-2 VPN 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 layer-2 VPN architectures and Virtual router-based layer-3 VPNs [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). In the context of L2VPNs, an auto-discovery mechanism enables a PE to determine the set of other PEs having VPN members in common along with information relative to each specific L2VPN endpoints such as attachment circuit identifier, topology information, etc. Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. "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. "Definition of Textual Conventions for Virtual Private Network (VPN) Management", Benson Schliesser, Thomas Nadeau, 7-Feb-05, 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, 23-Feb-05, 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. "CE-to-CE Member Verification for Layer 3 VPNs", Ronald Bonica, 10-Jan-05, This document describes a CE-based verification mechanism that VPN customers can use to detect security breaches caused by misconfiguration of the provider network. "Security Framework for Provider Provisioned Virtual Private Networks", Luyuan Fang, 23-Nov-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. "Requirements for Multicast in L3 Provider-Provisioned VPNs", Thomas Morin, 4-Feb-05, This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within L3 Provider Provisioned virtual private networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. LDAP (v3) Revision (ldapbis) ---------------------------- "LDAP:String Representation of Distinguished Names", Kurt Zeilenga, 14-Feb-05, 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, 10-Feb-05, 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, 17-Nov-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 [LDAPURL] and in other applications. "LDAP: Authentication Methods and Connection Level Security Mechanism", Rod Harrison, 14-Feb-05, This document describes authentication methods and connection level security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of TLS (Transport Layer Security) using the StartTLS operation. This document details the simple Bind authentication method including anonymous, unauthenticated, and plain-text password mechanisms and the SASL (Simple Authentication and Security Layer) Bind authentication method including DIGEST-MD5 and EXTERNAL mechanisms. This document discusses various authentication and authorization states through which a connection to an LDAP server may pass and the actions that trigger these state changes. "LDAP: Uniform Resource Locator", Mark Smith, Tim Howes, 4-Jan-05, This document describes a format for a Lightweight Directory Access Protocol (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 LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", Kathy Dally, Steven Legg, 18-Feb-05, 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, 14-Feb-05, 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, 22-Feb-05, 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, 11-Feb-05, 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, 22-Feb-05, 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) --------------------------------------------------------------------------------- "Goals for Internet Messaging to Support Diverse Service Environments", Jeff Wong, 20-Dec-04, This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process. The LEMONADE Working Group -- Internet Messaging to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail. "Internet Message Access Protocol (IMAP) CATENATE Extension", Pete Resnick, 17-Feb-05, 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, 7-Dec-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, 14-Feb-05, 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"). The Lemonade profile relies upon extensions to other protocols; specifically URLAUTH, CATENATE, Lemonade Command Extensions in the IMAP protocol [RFC 3501] and BURL in the SUBMIT protocol [RFC 2476]. In addition, the Lemonade profile contains Lemonade Command extensions for quick reconnect and media conversion. "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. "SMTP Submission Service Extension for Future Delivery", Gregory White, Gregory Vaudreuil, 22-Feb-05, 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", Chris Newman, 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. "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, 24-Feb-05, 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, 25-Feb-05, 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, 22-Feb-05, 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. "Dynamic MANET On-demand Routing Protocol (DYMO)", Ian Chakeres, 15-Feb-05, The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless multihop networks. It offers quick adaptation to dynamic conditions, low processing and memory overhead, low network utilization, and determines unicast routes between nodes within the network. 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. "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, 23-Feb-05, 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. "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. "IPv6 Multicast Deployment Issues", Pekka Savola, 16-Feb-05, This memo describes known issues with IPv6 multicast, and provides historical reference of how some earlier problems have been resolved. "Overview of the Internet Multicast Addressing Architecture", Pekka Savola, 21-Feb-05, 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. Media Gateway Control (megaco) ------------------------------ "The Megaco/H.248v2 Gateway Control Protocol, version 2", Christian Groves, Marcello Pantaleo, 3-Apr-03, This document describes the second version of the general-purpose gateway control protocol standardized as Megaco in the IETF and as Recommendation H.248 (now H.248.1) in the ITU-T. It is common text with Recommendation H.248.1 (05/02), published by the ITU-T. Megaco v2 includes the corrections to RFC 3015 which resulted in RFC xxxx [draft-ietf-megaco-3015corr-02.txt], plus the following new capabilities: - ability to audit specific properties, events, signals and statistics - use of serviceChange to indicate that capabilities have changed in the Media Gateway - playing a signal on the Root Termination - limiting the number of repetitions of transaction pending - allowing topology to be set per stream - ability to audit context properties - new Nx64K multiplex type - provision for digit buffering when a digit map completes. In addition, the use of the Modem Descriptor was deprecated. A detailed list of changes from draft-ietf-megaco-3015corr- 02.txt/H.248.1 (03/02) to this document is given in Appendix II at the end of this document. "Megaco/H.248 Call flow examples", Madhubabu Brahmanapally, Prerepa Viswanadham, Krishna Gundamaraju, 15-Nov-04, The Megaco/H.248 call flow examples draft illustrates the usage of Megaco - Version 1 protocol [Ref:3] defined between the Media Gateway Controller and Media Gateway. In light of the vast features presently incorporated and continuously evolving features of the protocol, it serves the purpose of representing typical use case scenarios. There are a lot of possible scenarios for usage of MEGACO protocol. It is not the intent of the draft to represent the inter-working functionality among various protocols, however, an attempt is made to depict its usage in such a case for the purpose of completeness in the larger perspective. An attempt has been made to illustrate the supplementary call services using MEGACO. The call flows can be categorized in to two sub sections, 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. "Definitions of Managed Objects for Middlebox Communication", Juergen Quittek, Martin Stiemerling, Pyda Srisuresh, 31-Jan-05, 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, 3-Dec-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, 10-Jan-05, 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. "Mobile IPv4 Regional Registration", Eva Gustafsson, 23-Nov-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. Mobility for IPv6 (mip6) ------------------------ "Mobile IPv6 Management Information Base", Glenn Keeni, Ken-ichi Nagami, Kazuhide Koide, Sri Gundavelli, 25-Jan-05, 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", Kent Leung, 11-Feb-05, IPsec is specified as the sole means of securing all signaling messages between the Mobile Node and Home agent for Mobile IPv6. A flexible model for security between the mobile node and home agent is required from the perspective of deployment of the Mobile IPv6 protocol. One instance of such deployment need comes from networks that are built on 3GPP2 standards. This document proposes an alternate method for securing the signaling messages that are responsible for performing Registration of a mobile node at a home agent. "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. "Mobile IPv6 and Firewalls Problem statement", Franck Le, 21-Feb-05, 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, 22-Feb-05, This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. "Mobile Node Identifier Option for Mobile IPv6", Kent Leung, 11-Feb-05, Mobile IPv6 defines a new Mobility header which is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include NAI, FQDN, IMSI, MSISDN, etc. This document defines a new mobility option that can be used by Mobile IP6 entities to identify themselves in messages containing a mobility header. "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 11-Jan-05, Mobile IPv6 uses IPsec to protect signaling between the mobile node and the home agent. This document defines how IPsec can 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. MIPv6 Signaling and Handoff Optimization (mipshop) -------------------------------------------------- "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, 29-Dec-04, This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce 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 handover 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. "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, 18-Feb-05, 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, 30-Nov-04, This document describes how to express media transport over TCP 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. "Session Description and Capability Negotiation", Dirk Kutscher, Joerg Ott, Carsten Bormann, 23-Feb-05, This document defines a language for describing multimedia sessions with respect to configuration parameters and capabilities of end-systems. The description language is independent of specific application scenarios (session announcement, session setup for interactive communication etc.) and is not limited to specific media types, capabilities, or configuration parameters. "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Jari Arkko, 8-Feb-05, 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, 23-Feb-05, 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). "Session Description Protocol Security Descriptions for Media Streams", Flemming Andreasen, Mark Baugher, Dan Wing, 1-Feb-05, 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, 23-Feb-05, 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. "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. "The SDP (Session Description Protocol) Label Attribute", Orit Levin, Gonzalo Camarillo, 17-Jan-05, 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, 2-Dec-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, 9-Feb-05, 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. "An Extension to the Session Description Protocol (SDP) for Media Loopback", Kaynam Hedayat, 28-Dec-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. "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Gonzalo Camarillo, 13-Jan-05, This document specifies how to describe BFCP streams in SDP session descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and their answers. "Security Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, Dan Wing, 16-Feb-05, 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. IKEv2 Mobility and Multihoming (mobike) --------------------------------------- "Design of the MOBIKE protocol", Tero Kivinen, Hannes Tschofenig, 21-Feb-05, The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing protocol extensions to the Internet Key Exchange Protocol version 2 (IKEv2) to enable its use in the context where there are multiple IP addresses per host or where IP addresses of an IPsec host change over time (for example due to mobility). Multiprotocol Label Switching (mpls) ------------------------------------ "LSP Hierarchy with Generalized MPLS TE", Kireeti Kompella, Yakov Rekhter, 11-Sep-02, To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. "Link Bundling in MPLS Traffic Engineering", Kireeti Kompella, Yakov Rekhter, Lou Berger, 27-Dec-04, For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct which is described in this document. This document updates the interface identification TLVs defined in GMPLS Signaling Functional Description, [RFC3471]. "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, 20-Jan-05, 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, George Swallow, 22-Feb-05, 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. "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. "Definition of an RRO node-id subobject", Jean Vasseur, 8-Feb-05, 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. Such functionality has been listed as a clear requirement in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. 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, 23-Dec-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, 22-Feb-05, 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, 16-Feb-05, 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, 22-Nov-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. "A Framework for MPLS Operations and Management (OAM)", David Allan, Thomas Nadeau, 19-Nov-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. "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Rahul Aggarwal, 31-Jan-05, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered (TE) 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. "Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", Seisho Yasukawa, 18-Feb-05, This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution specific details nor application specific requirements in this document. It is intended that the requirements presented in this document are not limited to the requirements of packet switched networks, but also encompass the requirements of L2SC, TDM, lambda and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. Multicast Security (msec) ------------------------- "GSAKMP", Hugh Harney, 12-Jan-05, 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, 8-Dec-04, This document introduces TESLA, short for Timed Efficient Stream Loss-tolerant Authentication. TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers; uses low cost operations per packet at both sender and receiver; can tolerate any level of loss without retransmissions; and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time synchronized with the source in order to verify messages, but otherwise receivers need send no messages. TESLA alone cannot support non-repudiation of the data source to third parties. This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. "HMAC-authenticated Diffie-Hellman for MIKEY", Martin Euchner, 2-Feb-05, 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, 15-Feb-05, This memo describes the use of the RSA Digital Signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC XXXX and the revised IP Authentication Header (AH) as described in RFC YYYY. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. "The Use of TESLA in SRTP", Mark Baugher, 14-Feb-05, 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, 3-Jan-05, 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. "The Key ID Information Type for the General Extension Payload in MIKEY", Elisabetta Carrara, 14-Feb-05, 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, e.g., the Multimedia Broadcast/Multicast Service specified in the 3rd Generation Partnership Project. "Bootstrapping TESLA", Steffen Fries, Hannes Tschofenig, 18-Jan-05, 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. Site Multihoming in IPv6 (multi6) --------------------------------- "IPv4 Multihoming Motivation, Practices and Limitations", Joe Abley, Benjamin Black, Vijay Gill, 4-Jan-05, Multihoming is an essential component of service for many sites which are part of the Internet. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). "Things MULTI6 Developers should think about", Eliot Lear, 6-Jan-05, 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, 7-Jan-05, 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, 11-Feb-05, 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. "Hash Based Addresses (HBA)", Marcelo Bagnulo, 27-Dec-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 prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound. "Functional decomposition of the M6 protocol", Marcelo Bagnulo, Jari Arkko, 27-Dec-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]. "Multi6 Application Referral Issues", Erik Nordmark, 11-Jan-05, 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. "Multihoming L3 Shim Approach", Erik Nordmark, Marcelo Bagnulo, 13-Jan-05, This document specifies a particular approach to IPv6 multihoming. 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. "Failure Detection and Locator Selection in Multi6", Jari Arkko, 8-Feb-05, 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. Network Mobility (nemo) ----------------------- "Network Mobility Support Goals and Requirements", Thierry Ernst, 22-Feb-05, 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, 22-Feb-05, This document defines a terminology for discussing network mobility issues and solution requirements. "NEMO Home Network models", Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli, 8-Feb-05, 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, 22-Feb-05, 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, 21-Feb-05, 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, Ken Crozier, 16-Nov-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, 7-Feb-05, 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, Ted Goddard, 22-Feb-05, This document describes a 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) -------------------------------------------- "Internet Standards Documentation (ISDs)", John Klensin, John Loughney, 8-Feb-05, 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. The document also specifies a set of minor standards process changes to accommodate and integrate the new style of doing things that is represented by the new document series. "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). "Standing Documents Describing IETF Processes and Operations", John Klensin, 8-Feb-05, The "ISD" model for specifying the definition, status, and content of Internet Standards does not appear to be satisfactory for the documents that describe IETF procedures, structure, or relationships with other bodies. Those documents have traditionally be published as BCPs and described as "process" BCPs. This document proposes an special document series for those process documents, paralleling the ISDs. Network File System Version 4 (nfsv4) ------------------------------------- "XDR: External Data Representation Standard", Mike Eisler, 8-Feb-05, This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. "RPC Numbering Authority Transfer to IANA", Robert Thurlow, 4-Feb-05, 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, 4-Feb-05, 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, J. Bruce Fields, 22-Feb-05, NFS version 4 [rfc3530] (NFSv4) specifies a flavor of Access Control Lists (ACLs) resembling Windows NT ACLs. A number of operating sys- tems use a different flavor of ACL based on a withdrawn POSIX draft. NFSv4 clients and servers on such operating systems may wish to map between NFSv4 ACLs and their native ACLs. To this end, we describe a mapping from POSIX draft ACLs to a subset of NFSv4 ACLs. "On the Use of Channel Bindings to Secure Channels", Nicolas Williams, 23-Feb-05, 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, 21-Feb-05, 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", Brent Callaghan, Thomas Talpey, 21-Feb-05, A protocol is described providing RDMA as a new transport for ONC RPC. The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. "NFS Direct Data Placement", Brent Callaghan, Thomas Talpey, 21-Feb-05, 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 Session Extensions", Thomas Talpey, 21-Feb-05, 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. Next Generation Transition (ngtrans) ------------------------------------ "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Fred Templin, Tim Gleeson, Mohit Talwar, Dave Thaler, 28-Jan-05, 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. NNTP Extensions (nntpext) ------------------------- "Network News Transport Protocol", Clive Feather, 10-Feb-05, 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, 17-Jan-05, This memo defines an extension to the Network News Transport Protocol [NNTP] to provide connection-based security (via Transport Layer Security [TLS]). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. "NNTP Extension for Streaming Feeds", Jeffrey Vinocur, 17-Jan-05, This memo defines an extension to the Network News Transport Protocol [NNTP] to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency. "NNTP Extension for Authentication", Jeffrey Vinocur, 17-Jan-05, 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) ----------------------------- "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]. "Securing FTP with TLS", Paul Ford-Hutchinson, 10-Feb-05, 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 which 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]. That this specification is in accordance with the FTP RFC [RFC-959] and relies on the TLS protocol [RFC-2246] and the FTP security extensions [RFC-2228]. "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. "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. "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. "Quick Transaction Protocol - QTP", Allan Cornish, Michael Cox, Robert Neill, Ian Palmer, Angus Telfer, Cliff Wignell, Cameron Young, 17-Nov-04, QTP is a simple protocol for multiplexing short-duration connections over an arbitrary transport service such as UDP. QTP is an open standard to allow dial-up Credit Authorization Terminals (CAT) or Point-Of-Sale (POS) terminals to connect into IP hosts. These transactions require fast connection times, efficient concentration of many sessions, fault tolerant operation, and the ability to transfer access network addressing (called and calling numbers) along with transaction data. "Cisco Systems' Simple Certificate Enrollment Protocol(SCEP)", Xiaoyi Liu, Cheryl Madson, David McGrew, Andy Nourse, 14-Feb-05, 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. "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, 15-Nov-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. "Randomness Requirements for Security", Donald Eastlake, Jeffrey Schiller, Stephen Crocker, 14-Jan-05, 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. "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. "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. "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 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, 2-Dec-04, In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. "LDAP Control to Specify Chaining Behavior", Jim Sermersheim, 22-Feb-05, This document describes a Lightweight Directory Access Protocol (LDAP) request control that allows specification of chaining behavior for LDAP operations. By using the control with various LDAP operations, a directory client (DUA), or directory server (DSA) specifies whether or not a DSA or secondary DSA chains operations to other DSAs or returns referrals and/or search result references to the client. "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", Luca Martini, 16-Feb-05, 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, 22-Feb-05, 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, 10-Feb-05, This document define Uniform Resource Identifiers for Domain Name System resources. "Explicit Multicast (Xcast) Basic Specification", Richard Boivie, 17-Jan-05, 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, 15-Jul-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, 27-Dec-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-Feb-05, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support persistence. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. "SMB Filesharing URL Scheme", Christopher Hertel, 10-Jan-05, 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, 27-Dec-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. "OSPF-xTE: An experimental extension to OSPF for Traffic Engineering", Pyda Srisuresh, Paul Joseph, 3-Jan-05, This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE LSAs to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. Further, When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that Non-TE nodes in the AS are uneffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as SONET/TDM and optical networks. "Simple Explicit Multicast (SEM)", Ali Boudani, Bernard Cousin, 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, 1-Feb-05, 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, 17-Feb-05, 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. "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. "Diameter Mobile IPv6 Application", Stefano Faccin, 29-Nov-04, Mobile IPv6 capable mobile nodes can roam between networks that belong to their home service provider as well as others. Roaming in foreign networks is enabled as a result of the service level and roaming agreements that exist between operators. One of the key protocols that allows this kind of a roaming mechanism to be enabled is Diameter. This Internet Draft specifies a new application to Diameter that enables Mobile IPv6 roaming in networks other than its home. "Basic Network Media Services with SIP", Eric Burger, 21-Feb-05, 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 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. "Scripting Media Types", Bjoern Hoehrmann, 23-Feb-05, This memo describes media types for the ECMAScript and JavaScript programming languages. "Including additional properties in WebDAV PROPFIND/allprop requests", Julian Reschke, Stefan Eissing, 3-Jan-05, Recent specifications extending the Web Distributed Authoring Protocol (WebDAV) restrict the set of properties returned automatically upon a PROPFIND/allprop request. This specification defines a method to add specific properties to the set of properties returned upon PROPFIND/allprop. "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, 10-Feb-05, 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, 19-Nov-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, 9-Feb-05, 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, 14-Feb-05, 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, 23-Feb-05, 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. "Registration of GSTN SMS Service Qualifier", Erik Wilde, 31-Jan-05, 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). "URI scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 31-Jan-05, 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. "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, 18-Jan-05, 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, 14-Feb-05, 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, 14-Feb-05, 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. "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, 3-Feb-05, 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, 3-Feb-05, 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. "GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit", Hamid Ould-Brahim, 1-Mar-05, 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). "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' /)]]]. "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. "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. "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. "HTTP Header Field Registrations", Mark Nottingham, Jeffrey Mogul, 21-Feb-05, 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. "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. "Sieve -- 'body' extension", Jutta Degener, 1-Dec-04, This document defines a new primitive for the 'sieve' language that tests for the occurrence of one or more strings in the body of an e-mail message. "A Protocol for Anycast Address Resolving", Shingo Ata, Hiroshi Kitamura, Masayuki Murata, 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, 5-Jan-05, 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. "MIME Type Registration for MPEG-4", Yuen Lim, David Singer, 2-Dec-04, This document defines the standard MIME types associated with MP4 files. 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, 22-Feb-05, 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. "URI Fragment Identifiers for the text/plain Media Type", Erik Wilde, 27-Dec-04, This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text MIME entity, identified by character count or range, line count or range, or a regular expression. These identification methods can be combined to identify more than one sub-resource of a text/plain MIME entity. Fragment identifiers may also contain hash information to make them more robust. "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. "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. "A UUID URN Namespace", Michael Mealling, 5-Jan-05, 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 Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. "Secure Ad hoc On-Demand Distance Vector (SAODV) Routing", Manel Zapata, 17-Nov-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, 22-Feb-05, 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, 31-Jan-05, This document describes the interface to the EAP protocol in smartcards, which may store multiple identities associated to EAP methods and appropriate credentials. "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. "Selectively Reliable Multicast Protocol (SRMP)", Mark Pullen, 23-Nov-04, The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can be used to carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. "Split Multi-link Trunking (SMLT)", Roger Lapuh, Dinesh Mohan, 10-Dec-04, This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC 2338]. "An Approach for Using LDAP as a Network Information Service", Luke Howard, M Ansari, 23-Feb-05, This document describes a mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. A set of attribute types and object classes are pro- posed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organiza- tional nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, lead- ing eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. "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. "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. "Media Server Control Markup Language (MSCML) and Protocol", Jeff Van Dyke, Eric Burger, Andy Spitzer, 29-Dec-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. "SIP Telephony Device Requirements and Configuration", Ian Butcher, Steven Lass, Dan Petrie, Henry Sinnreich, Christian Stredicke, 21-Jan-05, 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. "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. "RTP Payload Format for Vorbis Encoded Audio", Phil Kerr, 3-Jan-05, This document describes a RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and details the delivery mechanisms for the decoder probability model, referred to as a codebook, metadata and other setup information. "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). "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, 23-Feb-05, Out of order arrival of packets is a common occurrence on the Internet, and it will be more widespread as link speeds increase. Percentage packet reordering as a metric of reordering is vague and unclear. A good reorder metric will capture the occurrence and characteristics of reordering comprehensively, and will have broader utility than merely distinguishing among different reordered sequences. "Using CMS to Protect Firmware Packages", Russell Housley, 25-Jan-05, 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. "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, 17-Nov-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 MPLS Traffic Engineering", Jaudelice de Oliveira, 17-Jan-05, 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 accommodate the newly signaled higher priority LSP. The preempted LSPs are then rerouted by their respective Head-end LSR. A preempted TE LSP can either be hard preempted (default mode as defined in RFC3209) or soft preempted ([SOFT-PREPT]). In the former case, the preemption results in clearing the corresponding state that provokes a traffic disruption. In the later case (soft preemption), the Head- end LSR of a soft preempted TE LSP is notified such that it can perform a non-disruptive reroute, using the so-called “Make before break” mechanism. This draft documents a preemption policy that 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 (or the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs in order to minimize the bandwidth wastage), preempt the LSPs that will have the maximum chance to be reroutable. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability 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. "A Model of IPv6/IPv4 Dual Stack Internet Access Service", Yasuhiro Shirasaki, 28-Jan-05, This memo shows an example of how to provide IPv6 / IPv4 dual stack services to home users. In order to simplify user setup, these service should have mechanism to configure IPv6 specific parameters automatically. We focus on two basic parameters, prefix and addresses of IPv6 DNS servers, and specify the way to deliver them to Customer Premises Equipments (CPE) automatically. This memo is a digest of the user network interface specification of NTT communications' dual stack ADSL access service. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", Ned Freed, John Klensin, 13-Jan-05, This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. "The LDAP No-Op Control", Kurt Zeilenga, 14-Feb-05, 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. "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 "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 Terminology Definition", Mikio Hashimoto, 22-Feb-05, The purpose of this document is to clarify the usage of terms for IPv6 Anycast and help increase its popularity. This document discusses not only Anycasting's terminology but also its categorization and clarifies its outline. In this document, we focus on network-layer Anycast, which is defined in IPv6 specifications. "Pre-Midcom Requirements for Traversal of NATs for traffic not supported by STUN", Rohan Mahy, 22-Feb-05, STUN (Simple Traversal of UDP for NATS) specifies a mechanism which enables nodes in a private network to determine if they are behind a NAT, to discover their remapped address and port, and for many types of NATs to send UDP traffic through them. In addition TCP connections initiated from the private side of NATs already works. This document specifies requirements for a mechanism that enables traversal of expected TCP traffic through all NATs, and traversal of UDP traffic through symmetric NATs. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, 21-Feb-05, 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). "Lightweight Mobility Detection and Response (LMDR) Algorithm for TCP", Yogesh Swami, K Le, 14-Feb-05, 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, 23-Feb-05, 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 Cryptographic Key Management", Steven Bellovin, 11-Jan-05, 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 -- 'editheader' extension", Jutta Degener, 1-Dec-04, This document defines three new actions for the 'sieve' language that add, delete, and change e-mail header fields. "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. "Textual Representation of IPv4 and IPv6 Addresses", Andrew Main, 24-Feb-05, Historically, the conventional textual representations of IPv4 and IPv6 addresses have been poorly specified. This document gives precise definitions of these conventions, together with advice for implementors. "Use of SRV records for POP3, POP3S, IMAP and IMAPS.", Gary Bajaj, 1-Dec-04, DNS records for the mail services POP3, POP3S, IMAP and IMAPS do not currently provide failover switching as do the DNS MX records for SMTP. This document looks at the issues involved and recommends a solution using SRV records. "Routing Policy Specification Language next generation (RPSLng)", Larry Blunk, Joao Luis Damas, Florent Parent, Andrei Robachevski, 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, 14-Feb-05, 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, 22-Feb-05, 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. "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). "A Namespace For NFS Version 4", Robert Thurlow, 21-Feb-05, Recent work on Replication and Migration for NFSv4 has reminded us of a more fundamental problem: NFS currently lacks a coherent enterprise or global namespace. With changes in a minor revision of NFS Version 4, this can be addressed to make services like replication and migration of filesystems fully functional. "Ad Hoc IP Address Autoconfiguration", Jae-Hoon Jeong, 16-Feb-05, 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). "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. "Teredo: Tunneling IPv6 over UDP through NATs", Christian Huitema, 18-Jan-05, 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, 15-Nov-04, HTTP Digest as specified in [4] 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 specifies version 2 of the HTTP Digest AKA algorithm [6]. 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. "Suggested Practices for Registration of Internationalized Domain Names (IDN)", John Klensin, 16-Feb-05, This document explores the issues in registration of internationalized domain names (IDNs). The basic IDN definition potentially allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, it is necessary for the IDN registration process to impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules, including adaptation of methods developed for Chinese, Japanese, and Korean domain names to other languages and scripts. "Dissemination of flow specification rules", Pedro Marques, 17-Dec-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 more-specific components of the traffic aggregate defined by an IP destination prefix. "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. "Interworking between SIP and QSIG for call diversion", John Elwell, 27-Dec-04, This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks) for calls that undergo diversion. 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. "Tunnelling of QSIG over SIP", John Elwell, 13-Jan-05, This document specifies tunnelling of "QSIG" over the Session Initiation Protocol (SIP). This enables calls between "islands" of circuit switched networks that use QSIG signalling to be interconnected by an IP network that uses SIP signalling without loss of QSIG functionality. "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. "SIP Service Quality Reporting Event", Alan Johnston, 25-Jan-05, This document discusses the motivation and requirements for the delivery of service quality reports from SIP endpoints to non-participants in the session. A publication mechanism using a new SIP events package is proposed as a solution. An event package "svcqual" and an application/svcqual MIME type is defined in this document along with some example call flows. "Secure Origin BGP (soBGP) Certificates", Brian Weis, 21-Feb-05, 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, 14-Feb-05, 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. "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. "A Mechanism to Secure SIP Identity headers inserted by Intermediaries", Mary Barnes, 7-Dec-04, This draft discusses a standard mechanism for securing information in SIP requests and responses, inserted by intermediaries, which may be used by other intermediaries or the endpoints as the basis for services. The requirements are based on the need for a general middle-to-middle and middle-to-end security mechanism applicable to both headers and message bodies. This mechanism is optional, however, the use of it enhances the overall security of SIP by ensuring the integrity of the information inserted by an intermediary. "An ENUM Registry Type for the Internet Registry Information Service", A Newton, Andrew 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, 15-Feb-05, The Media Objects Markup Language (MOML) is a modular and extensible language to define media processing objects which execute on media servers. The base language 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 the base MOML, or extend 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, 15-Feb-05, 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 multimedia 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 conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML with other languages such as the Media Objects Markup Language (MOML) or VoiceXML to interact with individual users or with groups of conference participants. "The Calling Party's Category tel URI Parameter", Rohan Mahy, 22-Feb-05, This document specifies a new parameter for the tel URI that represents the Calling Party's Category, a parameter used in SS7 ISUP signaling. "Address Resolution for IP datagrams over MPEG-2 networks", Gorry Fairhurst, Marie-Jose Montpetit, 9-Feb-05, This document describes the current mechanisms to bind IPv4/IPv6 addresses and flows to MPEG-2 Transport Streams (TS)and how these methods interact with well known protocols for address management like DHCP, ARP, NAT and DNS. For MPEG-2 subnetworks like any other IP networks 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, an IP address must be associated with a Packet ID (PID) and specific transmission multiplex either statically or via the use of some specific tables. Address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In this document the different mechanisms for address resolution for MPEG-2 networking as well as their usage are reviewed. "Tunnel SAFI", Gargi Nalawade, 18-Nov-04, There is a need for Tunnel end-point discovery within and across Autonomous Systems. BGP is the only protocol that is widely-spoken across Autonomous Systems and can carry this information. This document defines how BGP speakers can convey Tunnel end-point reachability information. "End-to-middle security in the Session Initiation Protocol(SIP)", Kinji Ono, Shinya Tachimoto, 21-Feb-05, 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 intermediaries except those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for an intermediary to notify the UA about its need to inspect an S/MIME-secured message body, and to notify the need for the message body to be transmitted securely. "Memorandum for multi-domain Public Key Infrastructure (PKI) Interoperability", Masaki SHIMAOKA, 6-Jan-05, 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. "A URN Namespace for the TV-Anytime Forum", Wataru KAMEYAMA, 6-Jan-05, This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Thomas Schmidt, Matthias Waehlisch, 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. "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, 16-Feb-05, 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", Steven Legg, Daniel Prager, 22-Feb-05, The XML Enabled Directory (XED) leverages existing Lightweight Directory Access Protocol (LDAP) and X.500 directory technology to create a directory service that stores, manages and transmits Extensible Markup Language (XML) format data, while maintaining interoperability with LDAP clients and X.500 agents. This document introduces the various XED 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. "Registering Internationalized Domain Names under .PL", Andrzej Bartosiewicz, 30-Nov-04, This document describes rules of Internationalized Domain Name (IDN) registration under .PL - county code top level domain name (ccTLD). All the rules are based on the idea that the Registry registers the ACE (ASCII Compatible Encoding) label version of the IDN instead of IDN's Unicode form. This document also includes the list of accepted Unicode code points for IDN registration uder '.PL' ccTLD. "Dual Stack IPv6 Dominant Transition Mechanism (DSTM)", Jim Bound, 13-Jan-05, The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant network. Nodes will still need to communicate with IPv4 nodes that do not have a Dual IP layer supporting both IPv4 and IPv6. The Dual Stack IPv6 Dominant Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. "Registration and Administration Guideline for Chinese Domain Names", XiaoDong Lee, 23-Feb-05, Most of the Chinese domain names will have variants, this memo specifies the proposed procedure to register and administrate Chinese domain names based on [IDN-ADMIN] to avoid the conflict among the variants. "Requirements for Ad Hoc IP Address Autoconfiguration", Jae-Hoon Jeong, 21-Feb-05, 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. The nodes in ad hoc network need to have the capability to maintain or share 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 an ad hoc network, it has to be assigned a unique IP address or autoconfigure its own 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 mobile nodes with such an IP address autoconfiguration in distributive environments. 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, 2-Dec-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. "A Differentiated Service Two Rate Three Color Marker for Efficient handling of in-Profile Traffic", Osama Aboul-Magd, Sameh Rabie, 30-Nov-04, 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 of the in-profile traffic. Furthermore this marker doesn’t impose peak rate shaping requirements on customer edge (CE) devices. "A Uniform Resource Identifier (URI) Scheme for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 10-Dec-04, This document defines a Uniform Resource Identifier (URI) scheme for use in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). "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 'info' URI Scheme for Information Assets with Identifiers in Public Namespaces", Herbert Van de Sompel, 13-Jan-05, 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, 29-Nov-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. "Deflate transmission mode for FTP", Jeff Preston, Tim Saunders, 14-Jan-05, 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. "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). "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, 10-Jan-05, 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. "IMAP Extension for SASL Initial Client Response", Robert Siemborski, 23-Feb-05, To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. "SMTP Service Extension for Authentication", Robert Siemborski, 23-Feb-05, This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554 and replaces it as a Proposed Standard. "POP3 SASL Authentication Mechanism", Robert Siemborski, 23-Feb-05, This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. In order to consolidate all of the authentication related information for POP3 into a single document, this document obsoletes RFC 1734 and RFC 3206, replacing them as a Proposed Standard. It also updates information contained in Section 6.3 and Section 8 of RFC 2449. "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. "EPP parameters for 8.4.e164.arpa Registry", Tomek Zygmuntowicz, 21-Jan-05, 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. "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. "DNSSEC Opt-In", Roy Arends, 27-Dec-04, In DNSSEC (RFC 2535bis, [3], [4], and [5]), delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an experimental 'Opt-In' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. "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, 11-Jan-05, 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, 9-Feb-05, 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, 22-Feb-05, 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 shared key between the sender and receiver. The new parameters are used to establish the shared key. "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. "A Delivery Mechanism for Session-Specific Session Initiation Protocol (SIP) Session Policies", Volker Hilt, 14-Feb-05, This specification defines a delivery mechanism for session-specific Session Initiation Protocol (SIP) sessions policies. "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. "Example call flows using SIP security mechanisms", Cullen Jennings, Kumiko Ono, 21-Feb-05, This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementors build interoperable SIP software. It is purely informational. To help facilitate interoperability testing, it includes certificates used in the example call flows and a CA certificate to create certificates for testing. "Mobile IPv6 Internet-based Remote Interoperability Testing Description", TJ Kniveton, 21-Jan-05, This document describes how implementors of Mobile IPv6 can use IPv6-based network facilities to perform remote testing of their implementation with other groups participating in this testing program. The document aims to describe how one may become part of a testing group, what can be tested through this method, and the steps necessary to connect to remote Mobile IPv6 entities. This draft is not meant for deployment, and no change in Mobile IPv6 implementation is needed in order to participate in testing. "Soft Permanent Virtual Circuit Interworking between PWE3 and ATM", George Swallow, Mikey Spiegel, 22-Feb-05, 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]. "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. "Policy Based Mobile IP Handoff Decision (POLIMAND)", Stefan Aust, 22-Feb-05, A handover is the process during which a mobile node is handed over between access networks. Especially for vertical handovers in overlay networks the mobile node changes the access network using multiple interfaces including different link layers, e.g., WLAN, GPRS, and UMTS. Handovers occur as a consequence of lower layer (i.e., link- layer) handovers that signify a switch of the physical connection to a new location. For the duration of a handover, a mobile node is unable to send or receive traffic. The length of this disruption is considered critical because it affects the performance of the communication. An additional factor is the link layer selection. It implies the selection of the most suitable link layer from which a mobile node should receive services. "Session Initiation Protocol (SIP) Event Notification Throttles", Aki Niemi, 22-Feb-05, 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, 20-Dec-04, This memo describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirection Transport (FLUTE) protocol. "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. "MANET Extension of OSPF using CDS Flooding", Richard Ogier, 22-Feb-05, This document describes and evaluates a family of interoperable flooding methods for mobile ad-hoc networks, which use a distributed algorithm for computing a connected dominating set (CDS) based on 2-hop neighbor information. The different methods are interoperable because the CDS computed by each method contains a "minimal" CDS, which is computed by the most efficient of the described methods. Simulations are presented to compare the different methods with respect to CDS size and average stretch factor. This document also describes how the proposed CDS algorithms can be used to achieve reliable flooding of LSAs in OSPF. In this context, the CDS nodes generalize the concept of a Designated Router to a multi-hop network. "Tunneling IPv6 with private IPv4 addresses behind NAT devices", Liu Min, Wu Xianguo, Cai Yibing, Jin Mingye, Li Defeng, 16-Nov-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. "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, James Polk, 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'. "Service Authentication Architecture Using Extensible Authentication Protocol (EAP) Key", Hiroyiki Ohnishi, 23-Feb-05, In a public wireless local area network (WLAN) access service using Mobile IP, network elements (NEs), such as access points (APs), DHCP server (DHCPS) and home agents (HAs), are required to authenticate users to prevent unauthorized usage. In this document, we discuss authentication/authorization process using Extensible Authentication Protocol (EAP) key derived during access authentication. "A 'traceroute' facility for IP Multicast.", Bill Fenner, 15-Feb-05, This draft describes the IGMP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires a special packet type and implementation on the part of routers. This speci- fication describes the required functionality in multicast routers, as well as how management applications can use the new router func- tionality. "The LDAP Change Sequence Number Syntax and Matching Rules", Jim Sermersheim, 22-Feb-05, This document defines a syntax schema element for the Lightweight Directory Access Protocol ([LDAP]) which is used to hold a Change Sequence Number (CSN). In general, a change sequence number represents the place and time that a directory entity was changed. It may be used by various attributes for various LDAP replication, and synchronization applications. "Calendar Server Extensions for WebDAV (CalDAV)", Lisa Dusseault, 11-Feb-05, 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. "Tags for Identifying Languages", Addison Phillips, Mark Davis, 15-Feb-05, 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. "Datagram Transport Layer Security", Eric Rescorla, Nagendra Modadugu, 21-Feb-05, 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. "Multiple protocol support in getnameinfo API", Jun-ichiro Hagino, 21-Dec-04, IPv6 basic API [Gilligan, 2003] defines protocol-independent API for address-to-string conversion, i.e. getnameinfo(3). Current specification, however, assumes that there are two transport-layer protocols - TCP (SOCK_STREAM) and UDP (SOCK_DGRAM), specifically in port number-to-service name conversion. The assumption prohibits getnameinfo(3) from supporting other transport-layer protocols, such as SCTP or DCCP. This document proposes a backward-compatible update to getnameinfo(3) specification to allow the use of other transport-layer protocol in port number-to-service name conversion. This document does not define any new (wire-level) protocol. "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. "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. "The EAP-PSK Protocol: a Pre-Shared Key EAP Method", Florent Bersani, 14-Feb-05, This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. "Considerations in Validating the Path in BGP", Russ White, Bora Akyol, Nick Feamster, 27-Dec-04, A good deal of thought has gone into, and is currently being given to, validating the path to a destination advertised by BGP. The purpose of this work is to explain the issues in validating a path with BGP, in the expectation that it will help in the evaluation of schemes such as [SOBGP] and [S-BGP] that seek to improve path validation. "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, 27-Dec-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. "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, 30-Dec-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. "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, 21-Feb-05, This document specifies the usage of Explicit Congestion Notification (ECN) markings for real-time inelastic flows such as voice, video conferencing, and multimedia streaming. We build on the principles of RFC 3168, "The Addition of Explicit Congestion Notification to IP", and apply them to real-time inelastic traffic in DiffServ networks. The method specified in this document has the requirement that these real-time inelastic flows can be distinguished from other flows and may receive separate treatment from the network. "OAM Procedures for VPWS Interworking", Mustapha Aissaoui, 21-Feb-05, 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]. "Control Protocol Extensions for Setup of TDM Pseudowires", Sasha Vainshtein, 17-Feb-05, This document defines extension to the PWE3 control protocol [PWE3- CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of TDM pseudowires. "Signalling Interworking for Asynchronous Transfer Mode Virtual Private Wire Service", Matthew Bocci, 16-Nov-04, This Internet Draft describes a method 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) or the ATM Inter-Network Interface (AINI). 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, 22-Feb-05, 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. "Procedures for handling liaison statements to and from the IETF", Fred Baker, 18-Jan-05, 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 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. "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. "Future work addressing issues with the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 4-Feb-05, This draft explores several possible remedies for a set of issues that have been identified with the Session Initiation Protocol's non-INVITE transaction. These proposed solutions are in rough form and have not yet accumulated working group consensus. They range from minor extensions to protocol behavior to fundamentally changing the non-INVITE transaction model. "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", Alper Yegin, Hannes Tschofenig, Dan Forsberg, 25-Jan-05, DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. "Transporting Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 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). "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. "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. "The Archived-At Message Header Field", Martin Duerst, 23-Feb-05, 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, 22-Feb-05, 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) and the Session Description Protocol (SDP). This document describes a mechanism to create centralized conferences where MSRP is the media sent between participants. Additionally, this document specifies new advanced MSRP functionality required in centralized conferences, such as a new MSRP primitive to send private messages through the conference server, a mechanism to identify users with nicknames, etc. "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. "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. "Benefits and Motivation for Session Mode Instant Messaging", Rohan Mahy, 22-Feb-05, The SIMPLE working group describes one or more messages sent completely independently as 'pager-mode' messages, whereas messaging associated with as part of a 'session' with a definite start and end is called session mode messaging. The SIMPLE community has received numerous comments and complaints from the larger IM community that session mode is more complex than pager mode messaging. However, session mode messaging has a number of benefits which are not available in pager mode, but these benefits have not been widely articulated and this value is not well understood outside the SIP/ SIMPLE community. This document attempts to describe the benefits of session mode, such as explicit rendezvous, integration with other media, direct client-to-client operation, and brokered privacy and security, in an accessible manner. "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 Conference Server Control for XCON", Cullen Jennings, 22-Feb-05, Conference servers have many controls that change how the media is combined for the various conference participants. It is necessary to describe these controls to the clients connected to a centralized conference, so that the clients can render a user interface and allow the user to manipulate them. "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. "LDAP Turn Operation", Kurt Zeilenga, 14-Feb-05, 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. "Push Extensions to the IMAP Protocol (P-IMAP)", Stéphane Maes, 23-Feb-05, 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, 23-Feb-05, 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. "A note about 3rd party bombing in Mobile IPv6", Francis Dupont, 10-Jan-05, Mobile IPv6 introduces some new kinds of reflection attacks, as known as 3rd party bombing. This memo analyses these attacks and makes some recommendations: the goal is to avoid anything, including in new optimized mechanisms, which can make the life of bad guys easier. "Inter-domain Requirements for SIMPLE", Orit Levin, 24-Feb-05, 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. "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, 23-Feb-05, 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, 23-Feb-05, 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. "Middlebox Traversal Issues of Host Identity Protocol (HIP) Communication", Martin Stiemerling, 22-Feb-05, The Host Identity Protocol (HIP) fundamentally changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network-layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include middleboxes. It pinpoints issues in the current HIP specifications that are the causes of problems for communicating across middleboxes. "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. "Framework for Layer 1 Virtual Private Networks", Tomonori Takeda, 22-Feb-05, 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. "IPv6 distributed security requirements", Jordi Palet, Alvaro Vives, G Martinez, A Gomez, 21-Feb-05, 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, as already described by [1]. "Iowa Internet Annoyance Logging Protocol(IIALP) pronounced E'-alp", George Davey, 2-Dec-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. "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, 31-Jan-05, 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. "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. "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. "XHTML+Voice - application/xhtml+voice+xml", Gerald McCobb, 15-Nov-04, This document describes the registration of the MIME sub-type application/xhtml+voice+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. The XHTML+Voice 1.2 language specification is maintained by the VoiceXML Forum at . "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. "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, 14-Feb-05, 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. "Qos Signaling for PW", Himanshu Shah, 24-Feb-05, This document discusses how a tail-end PE can signal the Quality of Service parameters of the local Attachment Circuit to the head-end PE for appropriate Pseudowire generation from head to tail end PE. "GRSVP-TE signaling extension for LSP ownership handover from Management Plane to Control Plane and vice versa.", Diego Caviglia, Francesco Lazzeri, Nicola Ciulli, 1-Mar-05, This memo introduces a new flag in the Administrative Status object, namely the "Handover" flag, and defines its use within GRSVP-TE signaling. This flag SHOULD be used in order to allow LSPs, originally created and controlled by the Management Plane (MP), to be transferred to Control Plane (CP) domain and vice-versa. The result of the Handover flag use in GRSVP-TE is that, at the end of the setup signaling flow, an LSP that was created thru Management Plane operations is moved under Control Plane domain and control. Conversely, at the end of a deletion procedure, the LSP that was under the Control Plane domain is moved back to the Management Plane domain. Both the above procedure are not traffic affecting and can be performed with "in service traffic". "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Jordi Palet, Miguel Diaz, 24-Jan-05, To be able to automate setting up IPv6-in-IPv4 tunnels, it is important to be able to automatically determine the tunnel end-point for the tunneling mechanism. This memo presents a short analysis and conclusions on the different approaches for discovering 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. "Expanded Address Allocation for Private Internets", Tony Hain, 2-Feb-05, This document updates RFC 1918 and identifies additional IPv4 address space for use in private networks. "IPv6 Security Problem Statement", Alvaro Vives, 21-Feb-05, 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, 23-Feb-05, The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is especially useful when the access network does not have a direct roaming relationship with the peer's home network, so that a mediating network, such as a roaming consortium or broker, is used. "User Session Tracking in RADIUS", Glen Zorn, 6-Jan-05, This document defines a pair of new messages and a new attribute designed to allow RADIUS servers to cleanly track user sessions. "DNS Based Blacklists and Whitelists for E-Mail", John Levine, 16-Nov-04, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become a de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. "Generalized Traffic Engineering Protocol", Eiji Oki, 21-Feb-05, 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, 22-Feb-05, 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. "RADIUS Dynamic Authorization Server MIB", Stefaan De Cnodder, 18-Feb-05, 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 server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. "The APPLICATION/MBOX Media-Type", Eric Hall, 7-Feb-05, This memo requests that the application/mbox media-type be authorized for allocation by the IESG, according to the terms specified in RFC 2048 [RFC2048]. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. "RBridges: Transparent Routing", Radia Perlman, 21-Feb-05, 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 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. "Dynamic Authorization Client MIB", Stefaan De Cnodder, 18-Feb-05, 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. "RADIUS Error Messages", Glen Zorn, 14-Feb-05, This document describes new RADIUS protocol elements designed to allow the communication of packet and attribute errors between RADIUS servers and clients. "Light Weight Access Point Protocol (LWAPP)", Pat Calhoun, 24-Feb-05, In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. "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, 16-Nov-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 that SAs can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying, and need not be tied to it. Repeated authentication can be achieved by simply repeating the Initial exchange by whichever side has a stricter policy. However, in the remote access scenario it is usually up to a human user to supply the authentication credentials, and often EAP is used for authentication, which makes it unreasonable or impossible for the remote access gateway to initiate the exchange. This document describes how the original Responder can send 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. If the Initiator fails to do so, the Responder may close all tunnels. "Licklider Transmission Protocol - Specification", Scott Burleigh, 21-Dec-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. "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. "Internet Mail Architecture", David Crocker, 16-Feb-05, Over its thirty-four 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, in the form of Mail User Agents (MUA), and the transmission world, in the form of the Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). Core aspects of the service, such as address and message style, have remained remarkably constant. However public discussion of the architecture has not kept pace with the real-world refinements. This document offers an enhanced Internet Mail architecture to reflect the current service. "EAP-Double-TLS Authentication Protocol", Mohamad Badra, Pascal Urien, 30-Nov-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 a secure connection established by the TLS Pre Shared Key (PSK) handshake to exchange additional information between the client and the 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 and to update security attributes for next sessions. EAP-Double-TLS 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. "Guideline for use of XML with iCalendar elements", Tim Hare, 16-Nov-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. "TLS Session Resumption without Server-Side State", Joseph Salowey, 21-Feb-05, 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 new TLS handshake messages and TLS hello extensions. "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, 16-Feb-05, 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. "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. "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. "Zone Suffix Option for DHCPv6", Renxiang Yan, 28-Dec-04, This document specifies a new DHCPv6 (DHCP for IPv6) option which is passed from an DHCPv6 server to an DHCPv6 client to specify the zone suffix name used to construct and perform domain name update. "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Sina Mirtorabi, Abhay Roy, 13-Jan-05, 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. "Dialstring parameter for the sip URI", Brian Rosen, 14-Feb-05, RFC3966 explicitly states 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, 18-Feb-05, 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. "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). "Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery", Greg Daley, 15-Feb-05, 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. "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, 20-Dec-04, This document gives guidance on securing IPv6-in-IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. This document describes packet formats, IPsec security policy database for various scenarios, address configuration procedures, and the usage of the Extensible Authentication Procotol. "Graceful Shutdown in MPLS Traffic Engineering Networks", Zafar Ali, 22-Feb-05, Graceful shutdown is a method for explicitly notifying a set of nodes 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 requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. "The Codecs Parameter for "Bucket" Media Types", Randall Gellens, 17-Feb-05, 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, 30-Jan-05, 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, 6-Jan-05, 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, 15-Feb-05, This document defines a pair of RADIUS Attributes designed to allow both the secure transmission of encryption keys and strong authentication of any RADIUS message. "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. "Client SMTP Validation (CSV)", Dave Crocker, 21-Feb-05, 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. "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", Russell Housley, 19-Nov-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. "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. "Use of Context Transfer Protocol (CTP) for PANA", Julien Bournelle, 18-Feb-05, The PANA protocol offers a way to authenticate clients in IP based access networks. However, in roaming environments IP clients might change of gateways and new EAP authentication from scratch may occur. To enhance IP handover in mobile environments, the Context Transfer Protocol (CxTP) could be used. This protocol could recover from previous PANA Authentication Agent the PANA security context previously established. The aim of this document is to analyze and to describe the different approaches to perfom the transfer. "Message Submission", Randall Gellens, John Klensin, 22-Feb-05, 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. "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. "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. "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. "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. "U-turn Alternates for IP/LDP Local Protection", Alia Atlas, 22-Feb-05, 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 failure, whether link, node or shared risk link group (SRLG). 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. "Extending the Space Available for TCP Options", Wesley Eddy, 11-Jan-05, 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, 16-Feb-05, 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, 16-Feb-05, 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. "IPv6 Label Switching Architecture (6LSA)", Sham Chakravorty, 22-Feb-05, This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet transmission technique that uses the IPv6 packet header Flow Label 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) or other service delivery. Through fast swapping of 20-bit labels instead of 128-bit IPv6 address look-ups, the architecture also provides memory and processing savings, the latter through significantly reduced address fetches for the low-powered, handheld devices. Although the label from the source is delivered to the destination unmodified, conforming to the basic tenet of the existing defintion of the 3-tuple flow, the intermediate network nodes in 6LSA are allowed to temporarily replace the original label with a label of local significance. This enables 6LSA flows to be hop-specific although session-based and as such a unique QoS delivery technique for bandwidth constrained media. 6LSA also enhances security since disruption by man-in-the-middle attacks through label changes may not affect flows end-to-end but only over a single hop. "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]. "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. "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. "OCSP Extensions to IKEv2", Michael Myers, Hannes Tschofenig, 18-Feb-05, 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. "Securing Proxy Neighbour Discovery Problem Statement", Greg Daley, 18-Feb-05, Proxy Neighbour Discovery is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. "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. "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, 14-Feb-05, 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. "Mobility Protocol Options for IKEv2 (MOPO-IKE)", Pasi Eronen, 22-Feb-05, 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. "Carrying ATM reachability information in BGP", Chaitanya Kodeboyina, 29-Nov-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. "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. "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, 21-Feb-05, 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. "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 Services in Session Initiation Protocol (SIP)", Cullen Jennings, 22-Feb-05, 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. "RADIUS Extensions for IEEE 802", Paul Congdon, 18-Feb-05, In certain network scenarios it is desirable to either filter user traffic or redirect it 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 proposes additional attributes to be used by AAA clients, whether in an IEEE 802.1X or Internet Service Provider environment. "External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3)", Kaushik Narayan, 21-Feb-05, This specification defines a framework for SNMPv3 authentication and key distribution with support for various authentication systems such as RADIUS, X.509 certificates, Local Accounts, Kerberos etc. Support for these authentication systems for SNMPv3 allows for a common identity to be used with/shared across all management protocols since the other network management interfaces such as the NetConf protocol and device Command Line Interface (CLI) are already using these authentication systems. "SIP Computational Puzzles", Cullen Jennings, 21-Feb-05, One of the techniques used in SPAM prevention and various solutions for denial of service attacks is to force the SIP client requesting a service to perform a calculation that limits the rate and increases the cost of the request. 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. Although the computation is expensive for the UAC to compute, it is cheap for the UAS to verify. The solution also allows for proxies to compute and check the puzzle on behalf of the UAC or UAS. "Multicast in BGP/MPLS IP VPNs Management Information Base", Susheela Vaidya, 22-Nov-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]. "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. "Diameter Quality of Service Application", Frank Alfano, 22-Feb-05, This document describes a Diameter Application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) 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 consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. "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. "Generic Security Requirements for Routing Protocols - Opened Questions", Jean-Jacques Puig, 5-Jan-05, This document introduces and presents problematics of the 'Generic Security Requirements for Routing Protocols' document. "Inter domain MPLS Traffic Engineering - RSVP-TE extensions", Arthi Ayyangar, Jean Vasseur, 27-Jan-05, 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. "Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO Basic Support", Romain Kuntz, 22-Feb-05, 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. "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. "Using SAML for SIP", Hannes Tschofenig, 23-Dec-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. "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels", Francois Le Faucheur, 14-Feb-05, 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, 21-Feb-05, 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. "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. "Applicability of GMPLS protocols and architectures to Layer 1 Virtual Private Networks", Tomonori Takeda, 22-Feb-05, 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. "The PROTO Process: Working Group Chair Document Shepherding", Henrik Levkowetz, David Meyer, 15-Feb-05, The methodologies described in this document have been designed to facilitate a transition in IETF document flow processing. A set of processes and procedures, known as the PROTO process, are specified in which a working group chair serves as the primary document shepherd for a document which has been submitted to the IESG for publication. Note that this role has traditionally been filled by the AD responsible for the working group. "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. "Use of IPFIX for Export of Per-Packet Information", Guido Pohl, 22-Feb-05, 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-Feb-05, 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, 22-Feb-05, 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". "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. "MIME Type Registrations for 3GPP2 Multimedia files", Harinath Garudadri, 21-Jan-05, 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, 21-Feb-05, 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. "Optimized Route Cache Protocol (ORC)", Ryuji Wakikawa, 19-Nov-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, 22-Feb-05, The NEMO Basic support protocol [1] specifies the operation of a Mobile Router. The Mobile Router has a bi-directional tunnel to its Home Agent through which it reverse tunnels all traffic. When the Mobile Router roams and connects to an access network that only implements IPv4, it needs to use IPv6 transition tunneling mechanisms to reach its Home Agent. This will result in a NEMO tunnel inside a transition tunnel. This document describes protocol extensions to the NEMO Basic support protocol to maintain IPv6 connectivity for the Mobile Router via its Home Agent with IPv6-over-IPv4 encapsulation with no special boxes to be deployed anywhere in the network. "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, 29-Dec-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. "Multi-Hop Pseudo-Wires Signalling Using LDP", Chi Yudong, 2-Feb-05, This document describes a signalling solution for setup and maintenance of multi-hop pseudo-wires. This signalling solution is a natural extention of the method described in "Pseudowire Setup and Maintenance using LDP" [PWE3-CTRL]. The main purpose of this document is to solve the scaling issues in single hop pseudo-wire architectures. "XML Media Types", Murata Makoto, 10-Feb-05, 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. Major differences from [RFC3023] are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, and the addition of XML 1.1. "RADIUS Extension for Management Authorization", David Nelson, 22-Feb-05, This document describes RADIUS attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities (NASes). 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 the base RADIUS specification. Provisions are also introduced for enhancing auditability of individual management operations. "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, Dipnarayan Guha, 23-Feb-05, 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, 21-Jan-05, 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. "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-Feb-05, The growing SIP message size and the ensuing IP fragmentation, scalability and performance efficiencies gained by multiplexing SIP sessions over fewer reliable transport connections, efficient use of security certificates etc. are engendering widespread use of connection-oriented protocols for SIP transport. A variety of SIP transport related issues are currently being discussed in the IETF including connection reuse, persistent connections, outbound connection flows, SIP over SCTP, NAT traversal, and SIP/TCP race conditions. This document attempts to unify these techniques by describing practical guidelines for implementers and takes a broad stroke at defining SIP Connection Management. We hope to abstract the diverse connection techniques into a few generic connection characteristics, which then help define a few common connection models and use cases. "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. "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). "Goals and Benefits of Multihoming", Thierry Ernst, 22-Feb-05, 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. "ICMP attacks against TCP", Fernando Gont, 28-Dec-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 several counter-measures to eliminate or minimize the impact of these attacks. "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, 22-Feb-05, 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. "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, 12-Jan-05, This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. "IPvLX - IP with virtual Link eXtension", Fred Templin, 18-Feb-05, 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 for addressing with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. This document proposes IPvLX - IP with virtual Link Extension. "The file URI Scheme", Paul Hoffman, 3-Jan-05, 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, 3-Jan-05, 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, 3-Jan-05, 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, 3-Jan-05, 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, 3-Jan-05, 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, 3-Jan-05, 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. "Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 17-Jan-05, 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, 23-Feb-05, 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, 3-Jan-05, 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, Authentication and Authorization Issues in Well Managed IP Multicasting Services", Tsunemasa Hayashi, 23-Feb-05, 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", Rohan Mahy, 22-Feb-05, 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, 16-Feb-05, 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-Feb-05, 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, 31-Jan-05, 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, 21-Feb-05, 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, 10-Feb-05, 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). At the time of this writing there are three vendors implementing CAP. It has already been determined that some changes are needed. In order to get implementation experience the participants felt that CAP needed to be released so that many years of work could be preserved. Many properties in CAP can be used by other iCalendar protocols and have had many years of debate. "Requirements for IETF Draft Submission Toolset", Alex Rousskov, 27-Dec-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, 14-Feb-05, 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. "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, 17-Feb-05, 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, 21-Feb-05, The EAP Smart Card Protocol (EAP-SC) defines an EAP Method and Multiplexing model for the support of Smart Card based authentication methods. EAP-SC provides a uniform framework for interfacing with Smart Cards within the EAP [RFC3748] context. EAP- SC provides for encapsulation of other EAP methods (such as [EAP- TLS], [EAP-SIM] and [EAP-AKA]). "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-Dec-04, The required and suggested algorithms in the original IKEv1 specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. "ENUM Validation Information Mapping for the Extensible Provisioning Protocol", Bernie Hoeneisen, 23-Feb-05, This document describes an EPP extension framework for mapping information about the validation process that has been 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 ENUM domain names. "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, 2-Dec-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). "MIME type registration for RTP Payload format for H.224", Roni Even, 10-Dec-04, In conversional video applications far end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 MIME type. It defines the syntax and the semantics of the SDP parameters needed to support far end camera control protocol using H.281. "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. "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, 21-Feb-05, 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, 25-Jan-05, 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, 17-Feb-05, 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, 31-Jan-05, 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, Corby Wilson, 22-Feb-05, 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, 3-Jan-05, 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, 16-Nov-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, 22-Feb-05, 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, 23-Nov-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, 23-Nov-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, 21-Feb-05, This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", Wassim Haddad, 16-Feb-05, 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, 21-Feb-05, 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 after completion of the TLS handshake, in effect providing an extended handshake prior to the start of upper layer data communications. Each TLS/IA message contains 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, 31-Jan-05, 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, 3-Feb-05, 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, 21-Feb-05, 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, Marcelo Bagnulo, 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, 14-Feb-05, 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. "Lightweight Directory Access Protocol (LDAP) schema definitions for X.509 Certificates", Kurt Zeilenga, 14-Feb-05, 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 networks (MRN)", Kohei Shiomoto, 23-Feb-05, 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, 22-Feb-05, 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 UAs with Outbound Only Connections", Cullen Jennings, Alan Hawrylyshen, 22-Feb-05, Often with SIP a request can only be routed over an existing connection or flow, such as when there is a firewall or network address translation (NAT) device in the network path. 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. This work shows how existing SIP mechanisms can be used to allow the UA to register multiple times over different connections or flows and the proxies can use the instance-id in the contact header to identify that the multiple flows go to the same UA. It can then choose which flow to use to route requests to this UA. "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, 22-Feb-05, 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, 8-Dec-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, 18-Feb-05, 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, 3-Feb-05, 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. "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, 23-Feb-05, 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, 18-Feb-05, 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, 23-Feb-05, 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 Signaling Layer Protocol (NSLP), named Metering NSLP, which allows the dynamic configuration of Metering Entities on the data path. An accompanying document [I-D.ietf-fessi-nsis-m-nslp-framework] makes a problem statement, describes scenarios for charging, Quality of Service monitoring, and monitoring for network security issues such as intrusion detection, elaborates requirements and discusses the applicability of NSIS to the problem. This document suggests a Metering NSIS protocol design, outlines protocol operation, discusses commonalities and differences to other NSLPs, and defines Metering NSLP messages. "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. "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 Data Model", Orit Levin, Gur Kimchi, 22-Feb-05, This document is a part of a suite of protocols being developed in the XCON Working Group and defines a client-server Centralized Conferencing Control Protocol (CCCP) for query, creation, and manipulation of both the XCON system information (e.g. supported templates) and a particular conference information during the conference lifetime cycle (e.g. reservation and state). An XCON server, which implements a CCCP server, provides the means for authorized CCCP clients (e.g. conference participants) to affect the behavior of a conference in the XCON system. "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, 17-Dec-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, 10-Feb-05, 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, 16-Feb-05, 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 (NAT) on the upstream data path. This message routing method is used by NSIS NATFW nodes behind a NAT to allocate a public reachable IP address and/or port number. The current way to do so has been named 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, but may be extend to Firewalls. "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, 23-Feb-05, 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, 23-Feb-05, This memo describes misconfigurations of DNS authoritative name server and its effect of increasing the load in DNS resolver server. In some cases we recommend re-checking DNS authoritative servers with a viewpoint of current RFC and point tough DNS resolver server implementation requirements. "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, Dipnarayan Guha, 23-May-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, 23-Feb-05, 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 shows how PCEMP messages might help preserving the path computational entities in the L1 VPN peer nodes. 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, 23-Feb-05, 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, Julien Bournelle, 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, 22-Nov-04, This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. "Things to think about when Renumbering an IPv6 network", Tim Chown, 23-Feb-05, 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, 23-Feb-05, 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, 21-Feb-05, In the core of a high capacity network, service differentiation is still needed to support applications' utilization of the network. 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 document 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 and Data Model for Centralized Conferencing", Mary Barnes, Chris Boulton, 15-Feb-05, This document defines the framework for Centralized Conferencing (XCON), which is applicable to participants using different call control signaling protocols and exchanging media over networks with potentially different characteristics. The XCON Framework defines the XCON data model, the XCON logical entities, the naming conventions, and outlines the standard conferencing protocols (complementary to the call control signalling protocols) for building advanced conferencing applications. The framework binds all the defined components together for the benefit of conferencing system builders. "TCP/IP based TML (Transport Mapping Layer) for ForCES protocol", Hormuzd Khosravi, 21-Feb-05, 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, 23-Feb-05, 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, 16-Nov-04, This document describes a Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol (SNMP) architecture defined in RFC3411. 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, 8-Feb-05, 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, 23-Feb-05, 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, Rob Austein, Leslie Daigle, Bert Wijnen, 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, 2-Feb-05, 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 and Analysis", Fan Zhao, 22-Feb-05, This document describes the routing optimization problem in NEMO and analyzes the related approaches to solve this problem. "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, 21-Feb-05, 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, 21-Feb-05, 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, 23-Feb-05, 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, 21-Feb-05, 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, 15-Feb-05, 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, 23-Feb-05, 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, 2-Dec-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. "Using Transport Layer Security (TLS) with Kerberos 5", Simon Josefsson, 15-Nov-04, This document specify how the Transport Layer Security (TLS) protocol is used in conjunction with the Kerberos 5 protocol. "A proposal to replace HIP base exchange with IKE-H method", Ren Yan, 15-Nov-04, This document describes using version 2 of the Internet Key Exchange (IKE) to replace current HIP protocol's base exchage. IKE-H is an extension of IKE used for performing mutual authentication and establishing and maintaining security associations. It can be used to provide continuity of communications between not only those hosts independent of the networking layer but also security gateway. IKE-H is an extension to the IKEv2. It supports HIP identity authentication method and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secure communication channel between the hosts or security gateway. "Deprecation of 'ip6.int'", Geoff Huston, 11-Feb-05, This document advises of the deprecation of the use of 'ip6.int' for Standards Conformant IPv6 implementations. "Simple Lightweight RFID Reader Protocol", P. Krishna, David Husak, 21-Feb-05, Radio Frequency Identification (RFID) is a technique whereby a device, known as an RFID 'reader', can remotely sense the presence of, and access embedded memory on, a transponder known as a 'tag'. Tags may be affixed to objects as a means of tracking the location and movement of said objects within facilities equipped with RFID readers. Typically, readers communicate with upstream devices, in this document referred to as 'controllers', to receive control commands and upload read tag information. This draft specifies the Simple Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp'), to be used to convey configuration, control, status, and tag information between controllers and readers in an IP- based network. "Requirements for Morality Sections in Routing Area Drafts", Adrian Farrel, 2-Dec-04, It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a deline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. This document specifies the requirement for all new Routing Area Internet-Drafts to include a 'Morality Considerations' section, and gives guidance on what that section should contain. "Structure of the IETF Administrative Support Activity (IASA)", Rob Austein, Bert Wijnen, 14-Feb-05, 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 ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. "Online Signing of Negative and Wildcard Responses", R Gieben, 17-Nov-04, This draft contains a number of loose ends and does not include any text on any (known) corner cases. Its primary goal is to document the choices the DNSEXT working group has on the subject of fixing the NSEC enumeration in DNSSEC. If at any point in time the working group feels this idea needs further work, this draft will be updated. DNSSECbis [RFC LIST] allow for zone enumeration by walking NSEC chains. It also has a large impact on the zone size at the initial deployment stage. This draft proposes a method to address these issues by the use of online signing of negative and wildcard responses. "Email Forwarding and Redirection Trace Headers", William Leibzon, 17-Nov-04, This memo defines Redirected email trace header which can be used to identify changes made to source and destination parameters of email message by SMTP forwarding and redirection systems and to identify what type of redirection took place. Original-* headers are also defined to show changes made to other headers by forwarding and redirection systems. "Subject: [tags] Considered Harmful", Peter Koch, 18-Nov-04, Various mailing lists modify the Subject: header field of messages sent to the list to contain a kind of identifier enclosed in square brackets. Every now and then this 'feature' is also requested for the main IETF list. This document collects pros and cons of this approach, tries to identify the real issue and will, in a later stage, try to give a recommendation. "Standardization of Multilingualizing Domain Names(MLDN)", Rifaah Ekrema, 18-Nov-04, Until now, many standards was issued to standardize creating and managing IDN (Internationalized Domain Names), all those standards discussed the technical problem issued from the need to keep the structure of the internet that uses standard (ASCII) domain names untouched; using this pretext those standards forced some rules that make lingual grammars for some languages not respected on the language domain names. This document will try to define a new type of domain names called the 'multilingual domain names' (MLDNs) , these names are supposed to espect the grammatical and spelling of every language so at least, every language can use the words of its own dictionary in its own domain names. The system supposed to manage the reservation and the resolution of the new domain names (MLDNs) must also respect the infrastructure of the traditional domain names system (DNS) untouched so it will not jeopardize the stability of the internet. In the rest of the document we will refer to that system by MLDNS (Multi-Lingual Domain Names System). MLDNS Will use the same large repertoire of Unicode characters to compose its domain names and that means the use of none-ASCII characters, this use must allow all languages to have their domain names that respect their language properties and rules. Also it must depends on a technique that keeps the stable DNS system untouched. "A Format for IPv6 Scope Zone Identifiers in Literal URIs", Bill Fenner, Martin Duerst, 21-Feb-05, This document specifies the format to be used when specifying a zone identifier with a literal IPv6 address in URIs and IRIs. While this combination is expected to be needed rarely, it is important to specify the exact syntax. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular (PoC)", Andrew Allen, 8-Feb-05, This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance (OMA),For Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application. The P-headers are used for requesting and indicating the alerting mode of the handset which is particular to the PoC application. "IPv6 Multihoming with Alternate Path Encoding", Kevin Loch, 28-Jan-05, This memo provides a method for multihoming IPv6 networks. A multihomed site assigns IPv6 interface addresses using some of the network bits from one or more alternate networks. IPv6 routers may use this encoded path information when making routing decisions. If a sufficient number of IPv6 routers use this method then benefits of multihoming can be realized by any multihomed IPv6 site. This method may also be used for separate site load distribution as a limited form of anycast. "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) Protocol", Wenhui Zhou, 19-Nov-04, This document presents a set of objectives or requirements for the Control and Provisioning of Wireless Access Points (CAPWAP) protocol. It presents the requirements from different aspects including architecture, user (client) access, service, control, management and security. "Digest Authentication Examples for Session Initiation Protocol (SIP)", Paul Smith, Ian Clarkson, 19-Nov-04, RFC3261 [2] recommends that SIP requests be authenticated using HTTP Digest authentication as defined in RFC2617 [3], and many vendors have successfully added this function to their products. However implementation bugs are still being observed both at interoperability events and in the field. "RNIC Interoperability", John Carrier, Jim Pinkerton, 22-Nov-04, This document describes a mechanism for enabling RDMA Network Interface Cards (RNICs) that implement both the IETF and RDMAC versions of the DDP and RDMAP protocols to interoperate with legacy RNICs that are based on the RDMAC version of the protocols. The proposed scheme uses MPA Request/Reply Frames to negotiate the protocol version as well as MPA marker and MPA CRC. A ULP or other supporting entity must perform this negotiation on behalf of the RDMAC RNIC because RDMAC MPA does not define an MPA connection scheme using MPA Request/Reply frames. This draft also makes specific recommendations for minor changes to the IETF MPA, DDP, and RDMAP internet drafts to aid in interoperability. "Application of a multi6 protocol to nemo", Marcelo Bagnulo, 22-Nov-04, The goal of this note is to analyze the possible application of a multi6 protocol to provide nemo multihoming support. We will first state the basic assumptions behind a multi6 protocol design and then we will analyze each of the multihoming configurations for nemo described in [1] in order to determine if the multi6 can provide the support required. "MPLS and GMPLS Change Process", Loa Andersson, 22-Feb-05, The MPLS and GMPLS protocol suites have become quite popular for a growing number of applications and deployment scenarios. One result of this popularity is a large number of suggestions for modifications and extensions. The IETF needs to be flexible and responsive in how it handles these suggestions, and has a responsiblity to supervise the growth and evolution of MPLS and GMPLS protocols. This memo describes the process through which individuals, working groups and external standards bodies can influence the development of the MPLS and GMPLS standards. This process means that extensions and changes to protocols specified by these working groups can only be made through the IETF, the body that created the (G)MPLS ((Generalized) Multiprotocol Label Switching) technologies. When possible, existing liaison relationships are used. "Last-hop Threats to Protocol Independent Multicast (PIM)", Pekka Savola, 17-Jan-05, Security threats analysis has been done on some parts of the multicast infrastructure, but the threats specific to the last-hop attacks by hosts on the PIM routing protocol have not been well described in the past. This memo aims to fill that gap. "IPv4 Path Based Routing", Decao Mao, 23-Nov-04, This document describes a solution to the IPv4 address shortage problem. The solution is to be implemented within the IPv4 framework, rather than inside a "next generation" IP protocol. By organizing local networks as an "intranet hierarchy" attached to the Internet, nodes inside the hierarchy can be uniquely addressed with path descriptions. Two IPv4 options, Source-Side Path-info and Destination-Side Path-info, are added into the IPv4 protocol, so that up to 2 path descriptions can be carried in the IPv4 header. Further, a currently unused flag bit in the IPv4 header is used to extend the logical IPv4 header, so that options can also be carried "out-band". Core routers in the Internet will ignore the unrecognized new options and the extension, and thus need not be replaced or updated. "Treating unknown Router-LSA link types", Vishwas Manral, 9-Dec-04, This document attempts to discuss and clarify the text in [OSPFv2] and [OSPFv3], about dealing with unknown link types in router LSA's. "SUA Implementor's guide", Lode Coene, John Loughney, 29-Nov-04, This document contains a compilation of all defects found up until the publication date for SUA [RFC3868] [1]. 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 SUA to clarify errors in the original SUA document. This document updates RFC3868 and text within this document supersedes the text found in RFC3868. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 29-Nov-04, This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. "Requirement for (G)MPLS implantation over Ethernet", Jaihyung Cho, 29-Nov-04, In this draft, we propose requirement to implement MPLS technology for Ethernet switched network. Ethernet has become major building block in local area network and the area of deployment is quickly expanding to core network. While there have been industry needs to overcome weakness of Ethernet, MPLS has not been considered as key technology to improve Ethernet. Currently MPLS [RFC3031] and GMPLS [GARCH] architecture do not define label-switching function on L2SC interface, i.e. over LAN media. Hence, it is necessary to discuss lightweight implementation of MPLS for Ethernet. Since there is disparity in requirements depending on hierarchy of Ethernet, it is appropriate to separate discussion in Customer Premise Network (CPN), Access Network (AN) and Core Network (CN). Some candidate methods to consider for label encoding for Ethernet are discussed. "Nonce response matching for router reachability in IPv6", Greg Daley, 30-Nov-04, IPv6 Neighbour Discovery does not provide a mechanism which allows a node to match its router solicitations to advertised responses. The Nonce Neighbour Discovery Option was originally defined for Secured Neighbour Discovery. This draft describes the use of the Nonce Option for generic router reachability testing. "Proposed changes to the format of the IANA IPv6 Registry", Geoff Huston, 31-Jan-05, This document proposes a revised format for the IANA IPv6 address registries. Rather than a formal definition of the format, it is described by giving examples of the (current as of publication of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as updating it to a more useful and generally accepted format. "Protocols for MPEG-2 network configuration", Marie-Jose Montpetit, 1-Dec-04, This document describes novel protocols 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). In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and specific transmission multiplex. In this documents 2 mechanisms based on standard XML semantics and multimedia signalling are introduced to comply to established IP over DVB AR established. These protocols are seen to complement the current approaches based on SI table with a more IP centric approach. "IMAP4 ACL extension - list of rights for various IMAP commands", Alexey Melnikov, 1-Dec-04, This document lists Access Control rights (RFC 2086) required for various IMAP extensions. "Time Space Label Switching Protocol (TSL-SP) Description for Optical Burst Switched Netwoks", Nora Liao, 1-Dec-04, In this article, we propose a protocol of time-space label switching. First we give the definition to time-space label and time-space label, switched paths, then expatiate on the process of building and removing time-space label switched paths, finally bring forward the resource forecasting scheme and the architecture for OBS Networks, which based on time-space label switched protocol. "Mobile Network Prefix Delegation", TJ Kniveton, Pascal Thubert, 2-Dec-04, This paper extends the Nemo Basic Support [10] for a Mobile Router to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically. The proposed prefix delegation mechanism is agnostic to the way the prefixes are managed and provisioned at the Home Agent; it might be used for bootstrapping, resynchronization at binding creation or after a loss of states (eg MR reboot), MNP Renumbering, and configuration checking for loop avoidance. "Interim Status Report on Data Flows", Carl Malamud, 2-Dec-04, This document is an interim status report and focuses on workflow characterization of IETF support processes. "The iam Service", Carl Malamud, 2-Dec-04, This document describes the iam service, an alternative to WHOIS. "NSLP NAT/FW State Machine", Constantin Werner, 2-Dec-04, This document describes the state machines for the NSIS Signaling Layer Protocol for Network Address Translation/Firewall signaling (NAT/FW NSLP). A set of state machines for NAT/FW NSLP entities at different locations of a signaling path are presented in order to illustrate how NAT/FW NSLP may be implemented. "The Session Initiation Protocol (SIP) Accept-Disposition Header Field", Gonzalo Camarillo, 2-Dec-04, This document defines the SIP Accept-Disposition header field. User agents use this header field to indicate the disposition types they support. "Media subtype registration for media type text/troff", Bruce Lilly, 14-Feb-05, A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. "Requirements for inter domain Pseudo-Wires", Luca Martini, 22-Feb-05, This document describes the necessary requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. "SXDF - Simple Extensible Data Format", Norbert Bollow, 3-Dec-04, The Simple Extensible Data Format (SXDF) defined in this document aims to combine the nice properties of XML (of providing a universal, text-based data format which allows adding additional data fields without breaking existing application programs) with a simple syntax which can be parsed efficiently by computer programs. This data format is intended for over-the-wire use in webservice protocols, where there is generally no interest in being able to directly medify the representation of the data with a standard text editor. "QQP - Quick Queues Protocol", Norbert Bollow, 3-Dec-04, QQP is a protocol which describes how a Sender transmits some SXDF data to a Receiver, and what the Receiver will do with the data. QQP plays the role of transport protocol for the QRPC webservice protocol, similar to how XML-RPC and SOAP often use HTTP as transport protocol. "QRPC - Queueable Remote Procedure Calls", Norbert Bollow, 3-Dec-04, The QRPC (Queueable Remote Procedure Calls) protocol is a fast and versatile general-purpose webservice protocol. QRPC can be used as a faster replacement for XML-RPC or SOAP, or it can be used for more general kinds of webservices which integrate technical and business processes across trusted or untrusted networks. QRPC brings the flexibility of the UNIX inter-process communication mechanism with pipes, signals and redirection of 'standard input', 'standard output' and 'standard error' to the realm of webservices. "Licklider Transmission Protocol - Motivation", Scott Burleigh, 7-Dec-04, This document describes the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. 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 has applications in other environments as well. "SCTP Sockets API Extension for Congestion Handling", Vivek Bansal, R Ezhirpavai, 7-Dec-04, This draft defines extension to the SCTP Socket API draft[1] for Congestion Handling. SCTP Protocol has been widely accepted by the VoIP forum. SIGTRAN protocols (M3UA/SUA/M2UA/M2PA etc) provide procedures for handling congestion notification from the SCTP Stack layer. This draft provides mechanism for SCTP applications to enable/ disable notification of congestion indications over SCTP Socket Interface. This draft suggests notification to application at onset and abatement of congestion. "Licklider Transmission Protocol - Extensions", Stephen Farrell, 7-Dec-04, In an Interplanetary Internet setting deploying the Bundling protocol being developed by the Delay Tolerant Networking Research Group, Licklider Transmission Protocol (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. It is stateful and has no negotiation or handshakes. "Bootstrapping Mobile IPv6", James Kempf, 22-Feb-05, This document defines an easy mechanism of boot-strapping Mobile IPv6 service. The boot-strapping mechanism includes locating a home agent, dynamic home-address allocation and setting up initial security association with the home-agent using IKE version 2 and EAP. "Applications of IPv6 Anycasting", Shingo Ata, 24-Feb-05, This document describes the applications and characteristics of Anycast, which is network addressing and routing scheme that routes data through the best destination. The primary purpose of this document is to describe the many advantages and applications of Anycast and hopefully, to motivate you to consider new applications of Anycast. "DNSSEC NSEC2 Owner and RDATA Format", Ben Laurie, 9-Dec-04, The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be used to provide authenticated denial of existence of DNS owner names and types; however, it also permits any user to obtain a listing of all DNS owner names in a zone. This can accomplished via successive DNS queries for all NSEC RRs in that zone. "Cryptographic Domain Ownership Verification (CDOV) Protocol", David Venable, 10-Dec-04, This document defines the Cryptographic Domain Ownership Verification (CDOV) protocol which may be used by Certificate Authorities (CA) to verify that a certificate belongs to the owner of the appropriate DNS domain name prior to signing. "Random NSEC RR generation", Gustavo Lozano, 10-Dec-04, The purpose of this memo is to describe a mechanism that allows an authoritative server to answer NSEC RRs without exposing the zone to "walk enumeration" and without the need of online signing. "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", Mark Townsley, 14-Dec-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. "NSIS QoS Signaling Policy for Networks Using Y.1541 QoS Classes", Jerry Ash, 14-Dec-04, This draft describes a QoS-NSLP signaling policy based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QSP extensions include additional QSPEC parameters and QSP control processing guidelines. "The QName URN Namespace", Rich Salz, 15-Dec-04, This specification defines a Uniform Resource Name namespace for XML namespace-qualified names, QNames. As long as the URN is encoded in the same character set as the document containing the original QName, the Qname URN provides enough information to maintain the semantics, and optionally the exact syntax, of the original name. "Spam reducing protocol", Wilbert Kruithof, 7-Jan-05, A highly spam resistant protocol is shown, which could be implemented for negligible costs. Accepted email's do the sender not cost money, not accepted ones do. A decentralized server for keeping track of money and information is needed. The protocol, in which encryption naturally appears and can be used transparently aside of the existing mail protocol, allows to freely distribute your emailadress. The protocol avoids the micro payment problem. "Load Sharing in Multihomed Host", M Liu, 16-Dec-04, In order to reach the goal of load sharing and traffic engineering in multihoming, there must be some mechanism for the local host to make a selection of the "best" source locator to used. Obviously the selection includes the objective to select a currently viable path. What's more, it also includes the objective to select a path with larger bandwidth, which is more difficult to judge than reachability. In this memo, we propose a simple mechanism to determine the availability and bandwidth condition between a multihomed host and its ISP. It will help to share the load among multiple paths and provide better performance for the host's traffic. This mechanism could be part of traffic engineering functions, which could be used as the basis of locator selection before initial session establishment and aslo could be used to trigger locator swithes to avoid loss of connectivity, long delay or large loss rate. "The Atom Notification Protocol", James Snell, 1-Feb-05, This memo presents a protocol for posting notifications of new or updated content using a combination of the Atom Syndication Format and HTTP POSTs. "A File Aggregation Scheme for FLUTE", Christoph Neumann, 16-Dec-04, This document introduces a logical and physical file aggregation scheme for File Delivery over Unidirectional Transport (FLUTE). The logical file aggregation mechanism is a generalized grouping mechanism, allowing to logically group files. The physical file aggregation scheme allows, additionally to a logical grouping, to more efficiently use Forward Error Correction (FEC) in the context of FLUTE, in particular when dealing with a large number of "small" files. Unlike a solution based on the creation of an archive, the object aggregation scheme (1) avoids the need to perform preliminary transformations on the content and (2) preserves the possibility to extract a subset of the content, which may be critical aspect with some partially reliable broadcasting test cases. "v6tc Protocol Exploration", Florent Parent, 17-Dec-04, This document aims to provide a rough sketch on different approaches to meet the zeroconf/assisted tunneling requirements for a simple IPv6-in-IPv4 tunnel set-up mechanism. "DHCPv6 Relay Agent Remote ID Option", Bernie Volz, 20-Dec-04, This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. "DHCPv6 Relay Agent Subscriber-ID Option", Bernie Volz, 20-Dec-04, This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. "SMTP Option for DHCPv6", Cristian Cadar, 21-Dec-04, This document describes the SMTP option for Email related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The purpose of the DHCPv6 option for Simple Mail Transfer Protocol (SMTP) Server addresses is to route SMTP messages throughout the Internet to a mail server. "Bootstrapping Mobile IPv6 using PANA", Julien Bournelle, 23-Dec-04, A mobile node using Mobile IPv6 needs a home address, a home agent address and a security association with its home agent. The problem is to find a way to dynamically configure those data in order to ease Mobile IPv6 deployment. "Overview of the Internet Multicast Routing Architecture", Pekka Savola, 29-Dec-04, The lack of up-to-date documentation on IP multicast routing protocols and procedures has caused a great deal of confusion. To clarify the situation, this memo describes the routing protocols and techniques currently (as of this writing) in use. "Generalization of iSER for SCTP, Infiniband and other Network Protocols", John Hufferd, 27-Dec-04, The iSCSI Extensions for RDMA document [iSER] currently specifies the RDMA data transfer capability for [iSCSI] over iWARP/TCP. This document generalizes the iSER document to permit it to be used with other RDMA capable protocols such as iWARP/SCTP, InfiniBand, etc. It also describes what should be defined in the InfiniBand Trade Association and what are appropriate for IETF. "DNSSEC Experiments", David Blacka, 27-Dec-04, In the long history of the development of the DNS security [1] extensions, a number of alternate methodologies and modifications have been proposed and rejected for practical, rather than strictly technical, reasons. There is a desire to be able to experiment with these alternate methods in the public DNS. This document describes a methodology for deploying alternate, non-backwards-compatible, DNSSEC methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. "Internationalized Domain Name Mapping for the Extensible Provisioning Protocol", Janusz Sienkiewicz, 28-Dec-04, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names using Internationalized Domain Name (IDN) identifiers. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for IDN domain name processing. "Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel", Claudio DeSanti, 28-Dec-04, This document specifies the way of encapsulating IPv6, IPv4 and ARP packets over Fibre Channel. This document specifies also the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. "Bounding Longest Match Considered", Russ White, Ted Hardie, 29-Dec-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. "Framework for (G)MPLS implementation in Ethernet based Customer Premise Network", Jaihyung Cho, 29-Dec-04, In this draft we propose a framework for implementation of (G)MPLS technology in Ethernet based Customer Premise Network (ECPN). Major goals of this framework are improving QoS capability of Ethernet using (G)MPLS technology and facilitating secure access of commercial service, such as IP-TV or videophone, in local area network. Key solution to achieve the goal is MAC address swapping which uses 48bits of Ethernet address in MAC header as labels. Ethernet switches supporting this technique identify flows of different applications according to MAC addresses. ARP or ICMPv6 is used for terminal-to-terminal label negotiation and path establishment. Policy can be imposed in controlling user connection. Unauthorized user flows are filtered in MAC level. Compatibility with legacy Ethernet is provided best because it does not require modification in Ethernet format nor relies on VLAN tag. This architecture and technology will be aligned with architectural framework for Ethernet based Access Network and Core Network. "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", Gabriel Montenegro, 22-Feb-05, This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. "Requirements for Providing Information on IETF Internet-Drafts", Alex Rousskov, 22-Feb-05, This document specifies what information IETF should provide about an IETF Internet-Draft. Information requirements cover submitted, posted, published, expired, and other personal or Working Group drafts. "State of Peer-to-Peer(P2P) communication across Network Address Translators(NATs)", Pyda Srisuresh, 3-Jan-05, This memo documents the methods known to be in use by the TCP/UDP based peer-to-peer (P2P) applications for communication in the presence of network address translators (NATs) at the current time. This memo is not an endorsement of the methods in use, but merely an attempt to undertsand the techniques used. "OSI Directory IPv6 NSAPA Format", Arun Pandey, 3-Jan-05, The X500 Directory specifies an encoding of Presentation Address, which utilizes OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. X500 Directories not being heavy users of OSI Session layer services can be run in a pure TCP/IP environment. This is possible by incorporating minimal OSI presentation and session layer services in the X500 Directory, thus allowing the X500 Directory to run in a pure TCP/IP environment. "Extension to IODEF-Document Class for Phishing Reports", David Jevans, Patrick Cain, 3-Jan-05, Phishing, a broadly-launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing credentials, is expanding on the Internet. Corporations, Service Providers, consumer agencies, and financial institutions have started to collect and correlate phishing attack information to better plan out mitigation activities and to assist in prosecution. Early on it became obvious that a common format for the data reported or exchanged between this parties was necessary. "Basic Internet Calendaring and Scheduling Core Object Specification (iCalendar Basic)", Doug Royer, 31-Jan-05, This is the second release of a iCalendar. After having learned from RFC-2445. This document represents the common objects needed for basic calendaring. The VTODO, VJOURNAL, VTIMEZONE, recurrence rules (RDATE remains), and scheduling and their associated properties have been removed. These removals are expected to appear in new memos at a later time and will be independent extensions of this specification. The new EXTENSIONS property will exist to allow for compatible sets of extensions. "Sender Policy Framework: Authorizing Use of Domains in E-MAIL", Meng Weng Wong, 3-Jan-05, E-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. "Use of IKEv2 in The Fibre Channel Security Association Management Protocol", Fabio Maino, David Black, 9-Feb-05, This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. "Robust Enhancement to the Neighbor's Retransmission List when one or more LSA Checksum and length are in Error", Mitchell Erblich, 5-Jan-05, The ability to process LSAs within a Update packet requires that the length field be correct to generate the next offset within the packet. During the rare times that a checksum error and length LSA fields are incorrect, the beginning of later LSAs header's can't be determined. This draft specifies a transparent method to allow all valid LSAs to be processed even when these corrupted LSAs exist on the neighbor's retransmission list. "Support of unidirectional links in OSPFv2", Sina Mirtorabi, 5-Jan-05, This document describes how to support unidirectional links in OSPF and addresses its challenges. Unidirectional link routing (UDLR) describes a link-layer tunneling mechanism in order to abstract the network layer from unidirectional links and makes it transparent to routing protocols. Although this solution can be used, it can be cumbersome for user due to configured tunnels and generates extra overhead for control packets and encapsulation of tunnels. This document proposes the necessary extensions to OSPF in order to support unidirectional links. "An Authentication Scheme using AAAA in Hierarchical MIPv6", Y. Mun, 5-Jan-05, To reduce the amount of the signaling messages occurred in movement, Hierarchical Mobile IPv6 (HMIPv6) has been introduced as the hierarchical mobility management architecture for MIPv6 by regarding the micro movement. "A Uniform Resource Name (URN) Namespace for the CLEI Code", Kaj Tesink, 5-Jan-05, This document describes a Uniform Resource Name (URN) namespace [RFC3406] that is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213 [T1.213], for the assignment of the CLEI Code, for usage within messages standardized by ANSI. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI Code and supplier’s Product ID (Manufacturer's name, part number along with it's version number). "RSA key exchange for the SSH Transport Layer Protocol", Ben Harris, 6-Jan-05, This memo describes an RSA-based key-exchange method for the SSH protocol. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. "The OpenPGP mail and news header", Simon Josefsson, 7-Jan-05, This document describes the OpenPGP mail and news header field. The field provide information about the sender's OpenPGP key. See for more information. "Implementer-friendly Specification of Message and MIME-Part Header Fields and Field Components", Bruce Lilly, 14-Feb-05, Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. "Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont, Jean-Michel Combes, 10-Jan-05, This document defines a procedure which performs a "care-of address test" using a state cookie for routing optimization in Mobile IPv6 not protected by the routing routability procedure, i.e., protected by some alternative mechanisms like pre-shared secret or pre-established IPsec security associations. "An IPv6 Prefix for Cryptographically Generated IDs", Francis Dupont, 10-Jan-05, This document proposes the allocation of a dedicated prefix for Cryptographically Generated IDs (CGIDs). This prefix makes the distinction between a CGID and a real IPv6 global address trivial. "TLS Sign", Ibrahim Hajjeh, 11-Jan-05, TLS protocol provides authentication and data protection for communication between two entities. However, missing from the protocol is a way to perform non-repudiation service. This document defines extensions to the TLS protocol to allow it to perform non-repudiation service. It is based on [TLSSign] and it provides the client and the server the ability to sign by TLS, handshake and applications data using certificates such as X.509. "Structure of an International Emergency Alert System", Fred Baker, Brian Carpenter, 11-Jan-05, The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. "Encapsulation Extension for Mobile IPv4", Vikas Goel, 11-Jan-05, This document specifies a new extension for use by Mobility Agents operating Mobile IP for IPv4 [ii]. The new extension allows home agent to specify the kind of encapsulation type it supports currently. This extension is supplied within the Registration Reply message. The mobility agent SHOULD relay this extension to mobile node. In this way, mobile node and Foreign Agent discover the encapsulation type to be used with the home agent. "A URN namespace for the Open Geospatial Consortium (OGC)", Carl Reed, 13-Jan-05, This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC (such as OGC Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). The formal Namespace identifier (NID) is "ogc". "Mobile IPv4 Message String Extension", Venkateshwara Sastry, 13-Jan-05, This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply message. This extension carries a text string that can be displayed on Mobile Node user interface. "Protocols for Application and Desktop Sharing", Jonathan Lennox, 13-Jan-05, This document defines several protocols to support accessing general graphical user interface (GUI) desktops and applications remotely, either by a single remote user or embedded into a multiparty conference. The protocols are designed to allow sharing of, and access to general windowing system applications that are not expressly written to be accessed remotely. "Kerberos Cryptosystem Negotiation Extension", Larry Zhu, 17-Jan-05, This document specifies an extension by Kerberos to negotiate new encryption types between the client-server peers. "Routing hyperactivity problem statement", Pars Mutaf, 17-Jan-05, The optimization offered by reactive routing relies on the observation that under normal activity a host makes a low rate of outgoing sessions to new or different hosts, and connections are locally correlated. This contrasts the fundamental behavior of address scanning worms that search for new hosts to infect at high speeds. Consequently, each infected node will frequently flood the network with route request messages targeted at possibly non-existing addresses. "Time Zone Registry", Doug Royer, 31-Jan-05, This is a submission for the creation of an new IANA Time Zones registration process. This is a registry for iCalendar "VTIMEZONE" calendar component information. Time zones and their definitions are required in order to schedule and synchronize meetings and software. The condition in which these time zones change are subject to civil authority rulings are are not always determinable by software algorithms. "Security Review of Two MASS Proposals", Russell Housley, 18-Jan-05, A small group conducted a speedy security review of two MASS proposals: DomainKeys and Identified Internet Mail (IIM). This short document provides the findings. "Network Address Translation - Protocol Translation (NAT-PT)", Soohong Park, 18-Jan-05, This document specifies an IPv4-to-IPv6 transition mechanism. This solution attempts to provide transparent routing to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of Network Address Translation and Protocol Translation. The scheme described does not mandate dual stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation scheme and V6/V4 protocol translation scheme. "QoSjava: An Open and Scalable Architecture Decoupling QoS Requirements from QoS Techniques", Xiaohui Huang, 26-Jan-05, QoSJava, an architecture decoupling QoS reuirements from QoS techniques is proposed in this draft. Referring to the idea of Java, QoSJava can conceal the heterogeneity of different QoS mechanisms as well as different vendors' devices. Users' requirements are translated into a "middle language", i.e. deployment task specification. And QoS mechanisms adapter plus Device Driver constitute the "Virtual Machine" of QoSJava. Thus network devices can be configured and QoS requirements can be fulfilled automatically. Moreover, QoSJava is not only compatible with current QoS mechanisms and devices, but open to new QoS solutions and advanced facilities in the future. "Requirements for Mid Call Communication in the SIP", Jinkyung Hwang, 20-Jan-05, In its current form, Session Initiation Protocol (SIP) allows session invitations, instant messages, and other requests to be delivered from one party to another. However it doesnot explicitly permit midcall events such as hook/flash from the user to be passed on to the network application server. Without such ability, it is not clear how SIP can be used to provide certain network controlled services. This document identifies a set of requirements for extensions to SIP to provide a MidCall-based communications framework. "Media Type Extension Negotiation in the Session Initiation Protocol (SIP) Accept Header Field", Volker Hilt, 20-Jan-05, This specification defines the profile parameter for the SIP Accept header field. This parameter is used to negotiate support for MIME media type extensions. "DNS update in IPv6 stateless configuration", Renxiang Yan, 20-Jan-05, This document specifies a method to update domain name for IPv6 node whose address is configured using IPv6 stateless address configuration. It is implemented by defining a new option in Router Advertisement (RA) / Router Solicitation (RS) messages. "Certificate Exchange Messaging for EDIINT", Dale Moberg, 20-Jan-05, The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). "A P2P Approach to SIP Registration", David Bryan, Cullen Jennings, 21-Jan-05, This document outlines the motivation and requirements for a Peer-to-Peer (P2P) based approach to building a SIP registrar using distributed hash tables, and presents the architectural design for such a system. This design removes the need for central servers from SIP, while offering full backward compatibility with SIP, allowing reuse of existing clients, and allowing P2P enabled nodes to communicate with conventional SIP entities. A basic introduction to the concepts of P2P is presented, backward compatibility issues addressed, and the security considerations are considered. "The Camellia Cipher Algorithm and Its Use With IPsec", Akihiro Kato, 24-Jan-05, This document describes the use of the Camellia 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). "Evaluation of existing Routing Protocols against ASON routing requirements", John Drake, 24-Jan-05, The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). "IRC Client Capabilities Extension", Keith Mitchell, 24-Jan-05, IRC (Internet Relay Chat) is a long-standing protocol for real-time chatting. The basic client-server protocol is a very simple text-based protocol with no explicit mechanism for introducing or negotiating backwards-incompatible extensions. This memo presents a mechanism for negotiation of such extensions. "Requirements for Document Notification Service", Stanislav Shalunov, 1-Feb-05, The output of the IETF consists of documents. The IETF process is largely related to changing the status of documents. Active participation in the work of the IETF often consists of writing or editing documents or providing input to the process of changing the documents' status. Passive participation often consists of reading documents and observing the changes of their status. This document describes the requirements for an automated service that helps the IETF participants to learn about the existence and follow the changes of status of any particular document. "Distributed Prefix-Delegation Scheme for NEMO", Guillaume Chelius, 25-Jan-05, This document proposes a distributed prefix delegation scheme for IPv6 mobile networks by allowing a consensus on the prefix part of Ipv6 addresses for each link of the network. "Message Header From Field Made Optional", Bruce Lilly, 14-Feb-05, The requirement for the presence of a syntactically-valid message header From field in the Internet Message Format presents a problem in some circumstances. This memo (if approved) amends the Internet Message Format specifications to make that field optional. Discussion of the subject matter covered in this memo has taken place on the ietf-822 mailing list, and that would be a suitable place for discussion of this document. "The EAP-SKL protocol", Thomas Otto, 22-Feb-05, This document describes EAP-SKL, an Extensible Authentication Protocol (EAP) method which provides authenticated key establishment based on a pre-shared key. EAP-SKL relies on SKEME (Secure Key Exchange MEchanism protocol), and hence may benefit from its simplicity and the provable security. EAP-SKL is designed to be a minimalistic EAP method comparable to EAP-MD5 by offering more flexibility and more security. In fact, EAP-SKL complies with the mandatory requirements for an EAP method which is intented for deployment in Wireless LAN environments. "IPFIX Aggregation", Falko Dressler, 27-Jan-05, IPFIX Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX exporters) and analyzers (IPFIX collectors). Using aggregation techniques, measurement information of similar flows is aggregated into one metaflow. The degree of similarity can be defined using aggregation rules. To achieve further reduction of the amount of data exchanged while still transmitting all required information to the collector, the IPFIX protocol and Information Model is slightly extended to allow two new data types and a new template / template set. "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", Jari Arkko, Christian Vogt, 27-Jan-05, The Mobile IPv6 protocol favors sending packets via the minimum routing path between a mobile node and its correspondent node over sending them through a home agent. This feature is called route optimization. Route optimization requires authentication and authorization of initially unacquainted and untrusted parties--a requirement that was rather new to the Internet community at the time Mobile IPv6 was designed. To solve the problem, the so-called return-routability procedure was built into Mobile IPv6. It lets the mobile node retrieve from the correspondent node two cryptographic tokens, which the mobile node can use to authenticate itself and prove its presence at a claimed new location after movement. Recently, a number of improvements or optional alternatives have been suggested to the standard procedure. Many of these improvements attempt further reduction of signaling messages and latency, but other improvements such as better security have also been suggested. This paper summarizes the goals for enhancements to route-optimization, discusses the security threats that such enhancements must consider, and categorizes the techniques that one can use for optimization. The paper highlights the key ideas of various recent proposals, and it evaluates the performance gain that such proposals can yield. It also discusses how significant enhancements to Mobile IPv6 are compared to ongoing optimization work in other parts of the network stack. Finally, the paper identifies needs for additional research. "Media Gateway Control Protocol (MGCP) Ownership Packages", Bill Foster, 28-Jan-05, In the Media Gateway Control Protocol Specification [2], there is nothing preventing multiple Call Agents talking to the same endpoint. However, this can present a problem if they are both trying to control the endpoint at the same time. The packages defined in this document solve this problem and provide new (and better) mechanisms for endpoint ownership control. "Attaching Meaning to Solicitation Class Keywords", Carl Malamud, 21-Feb-05, This Internet-Draft proposes a mechanism for finding information about solicitation class keywords which are defined in RFC 3865, the No Soliciting SMTP Service Extension. The mechanism uses a DNS NAPTR Resource Record to associate a URI with a solicitation class keyword. "Requirements for a media server control protocol", Roni Even, 28-Jan-05, This document addresses the communication between an application server and media server. The current work in SIPPING and XCON working groups show these logical functions but do not address the physical decomposition and the protocol between the entities. The document presents the architecture and the requirements from the protocol. The document lists current work that is relevant to the problem. "An additional mode of key distribution in MIKEY", Dragan Ignjatic, Lacshminath Dondeti, 28-Jan-05, The MIKEY specification [2] describes several modes of key distribution to setup SRTP [4] sessions, viz., pre-shared key, public-key, and an optional Diffie-Hellman key exchange. In the public-key mode the initiator encrypts a random key with the responder's public key and sends it to the responder. In many VoIP calling scenarios, the initiator may not know the responder's public key or in some cases the responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. "Writing Internet-Drafts and Requests For Comments using troff and nroff", Bruce Lilly, 14-Feb-05, Internet Drafts and RFCs have traditionally been produced using a variety of tools, including nroff. This memo describes production of Internet Drafts and RFCs using a set of troff/nroff macros suitable for that purpose. Public comments regarding this memo may be sent to the rfc-interest mailing list. "Next Generation Effort for IETF Multicast/Unicast Delivery", Joel Jaeggli, 31-Jan-05, This memo describes one proposal for continuing and expanding the broadcast and recording effort while reducing the number of volunteers required and the expenses associated with providing the previous service "SIP Session Border Control Requirements", Medhavi Bhatia, 31-Jan-05, Typical policy implemented at network border deals with security and enforcement of service level agreements at the network level. For multimedia sessions, such policy can be applied not only at higher layers but can be provided in a more granular and extended fashion. "Extensions for Differentiated Services-aware Traffic Engineered LSPs", Ina Minei, 31-Jan-05, This document specifies the extensions necessary to set up multi- class diffserv-aware traffic engineered label switched paths (LSPs). A multi-class diffserv-te LSP carries traffic from multiple traffic classes and is set up along a path that satisfies the bandwidth constraints defined for each of the classes it carries. "NAT Behavioral Requirements for TCP", Senthil Sivakumar, 31-Jan-05, Inconsistent behavior by NATs makes it difficult for the application developers and network administrators to predict the operation of NATs. This document describes the behavior required by NATs when handling TCP traffic. It also specifies the address and port binding behavioral requirement, timeout aspects and adjusting the sequence numbers and the acknowledgement numbers when changing the payload length. "Labels in Subject Headers Considered Ineffective At Best", Carl Malamud, 21-Feb-05, This Internet-Draft discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This Internet-Draft discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. "IMAP4 extension to CONDSTORE for reporting messages expunged since last synchronization", Alexey Melnikov, 31-Jan-05, This document defines an extension to IMAP Conditional Store extension, which gives a disconnected client ability to receive notifications about messages expunged since last synchronization. "SIP, P2P, and Internet Communications", Alan Johnston, 31-Jan-05, This somewhat terse draft discusses issues related to the application of peer to peer (P2P) technologies to SIP in particular, and Internet communications in general. While early work involving P2P and SIP proposes running P2P protocols over SIP messaging, this draft proposes the opposite layering - replacing SIP discovery and rendezvous functionality with a general P2P protocol. This layering of SIP on top of P2P has many advantages. A number of DHT (Distributed Hash Table) P2P protocols that solve some similar functions are given as examples. Finally, an approach to the discovery of NAT traversal relays using a logically separate P2P network is proposed. "Source Address Selection Policy Distribution for Multihoming", Arifumi Matsumoto, 31-Jan-05, 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. "Procedure to handle (G)MPLS-TE control plane saturation", Jean-Louis Le Roux, 31-Jan-05, This document defines extensions to RSVP-TE (Resource Reservation Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to signal control plane resources saturation, when an LSR runs out of control plane resources available to support a new LSP. Such notification may serve as trigger for the impacted Head-end LSR to take appropriate actions. "Simple MANET Address Autoconfiguration", Thomas Clausen, Emmanuel Baccelli, 1-Feb-05, In this draft, a simple autoconfiguration mechanism for MANETs is developed. The mechanism aims at solving the simple, but common, problem of one or more new nodes emerging in an existing network. A solution is proposed, which allows these new nodes to acquire an address and participate in the network. The method is simple, both algorithmically and in the requirements to the network. While this is a partial solution to the general autoconfiguration problem, the mechanism described in this draft can satisfy the requirements for a great number of real-world situations. Though examples are given with OLSR [1] [11] being the routing protocol in use, nothing prevents the described mechanisms to work along with other routing protocols. "Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX (Explicit Identification of One-Way Hash Functions)", Russell Housley, 1-Feb-05, Dan Brown from Certicom has submitted a specification for Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX. This document proposes a different approach for identifying the one-way hash function used with the ECDSA signature algorithm. "URN Namespace for Federated Content", Dave Tessman, 1-Feb-05, This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. "Addressing and Messaging in Generalized Multi-Protocol Label Switching (GMPLS) Networks: Best Practices", Kohei Shiomoto, 1-Feb-05, This document describes best practices in addressing and messaging in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSR) based on experience gained in deployments and interoperability testing. The document recommends best practices for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends best practices. "Use of ARP and Flood Routing Technique for LSP setup in ECPN", Jaihyung Cho, 1-Feb-05, In this memo, we first discuss some weaknesses of proposals employing RSVP in local network, such as RFC2814, 2815, 2816, and propose extension of ARP (Address Resolution Protocol) and [LSE] technique for solution to provide QoS in Ethernet based Customer Premise Network (ECPN). Framework architecture of LSE (Label Switched Ethernet) as a method of GMPLS implementation for Ethernet is described in [LSE]. ARP is proposed for integrated signaling and routing protocol in ECPN. This document describes overview of ARP extension, procedure for label negotiation and method for QoS routing. Major features of this ARP extension are; support for label switching, incorporation of routing function, compatibility with legacy Ethernet and enhanced security. "nanoIP", Zach Shelby, 2-Feb-05, This Internet-Draft proposes protocols specifically for use with embedded devices for networking. These protocols offer similar services at the socket layer as UDP or TCP, but do so with much less overhead and lower implementation complexity. These protocols together are part of the nanoIP protocol suite. "nanoIP", Zach Shelby, 2-Feb-05, This Internet-Draft proposes protocols specifically for use with embedded devices for networking. These protocols offer similar services at the socket layer as UDP or TCP, but do so with much less overhead and lower implementation complexity. These protocols together are part of the nanoIP protocol suite. "Common Format and MIME Type for CSV Files", Yakov Shafranovich, 18-Feb-05, This document documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". "Media Gateway Control Protocol VoIP RTCP-XR Metrics Package", David Auerbach, 3-Feb-05, This document defines a Media Gateway Control Protocol (MGCP) package to control the collection of metrics supported by RTCP Extended Report as specified in RFC 3611. The package allows for the call agent to enable or disable the collection of these metrics. It also allows the call agent to control whether or not the gateway will respond to remote requests for metric collection from a peer gateway. "Service-Oriented Address Assignment using DHCPv4", Syam Madanapalli, Soohong Park, 3-Feb-05, This document introduces a new option in DHCPv4 for Service-Oriented Address assignment for a particular type of service that DHCPv4 Clients provide. The Service-Oriented Address can be either Anycast/Shared Unicast or a Well-known Unicast Addresses. This address assignment is much similar to other address type assignments, except that Service-Oriented Address assignment requires the specification of Service Type of the node that is requesting the address. "Bootstrapping a Symmetric IPv6 Handover Key from SEND", Rajeev Koodli, 4-Feb-05, 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. "IKEv2 Clarifications and Implementation Guidelines", Pasi Eronen, 17-Feb-05, This document clarifies some areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The intent is not to introduce any changes to the protocol, but rather to provide descriptions less prone to ambiguous interpretations, and thus encourage the development of interoperable implementations. Readers are advised that this document is work-in-progress, and may contain incorrect interpretations. "End-to-End Capabilities Support for Remote Authentication Dial In User Service (RADIUS)", Avi Lior, Farid Adrangi, 7-Feb-05, This document describes a new RADIUS attribute, End-to-End-Capability which can be used by a NAS to indicate its AAA capabilities to the home AAA server. "RADIUS Mobile IPv4 extensions", Madjid Nakhjiri, 7-Feb-05, Mobile IPv4 specifies mechanisms that need assistance from a AAA server and a AAA infrastructure. Examples of such mechanisms are those providing key management and authentication services during a mobile node’s registration process with MN-AAA authentication extension. Although Diameter Mobile IP application is being specified to support the needs of Mobile IPv4 from the AAA infrastructure’s point of view, such support does not exist within RADIUS framework. This document defines the RADIUS attributes that provide support for Mobile IPv4 operation. "A mini-FRR(Fast Rerouting) mechanism for IP/MPLS network", Shaoling Sun, 7-Feb-05, This document analyzes the weakness of current fast rerouting mechanisms in IP network[1] and MPLS enabled network [2]describes a simple fast rerouting mechanism for IP/MPLS network, and with these points in mind, proposes the simple fast reroute mechanisms based on the intrinsic characteristics of IP network and MPLS network, and illustrates the principles of these mechanisms in node protection and link/path protection. "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", JP Vasseur, 7-Feb-05, The set up of a full mesh of MPLS TE LSPs among a set of Label Switch Router (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment requires the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IG (OSPF and IS-IS) traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group in this document). "A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", JP Vasseur, 7-Feb-05, This document specifies a per-domain path computation method 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. "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", Igor Bryskin, Adrian Farrel, 1-Mar-05, Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of physical technologies and across several architectural models. The ITU-T has specified an architecture for the management of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a far wider set of contexts than just ASON. Thus the definitions presented in this document do not provide exclusive or complete interpretations of the GMPLS concepts. The intention of this document is simply to allow the GMPLS terms to be applied within the ASON context. "TFTP Server Address DHCP Option", Richard Johnson, 8-Feb-05, This memo defines the "TFTP Server Address" option as it is currently in use by Cisco Systems. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC-3942 [7] , which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Binomial Congestion Control At Receivers for Multicast (BARM)", Bing Zhang, Zengji Liu, 8-Feb-05, This document specifies Binomial congestion control At Receivers for Multicast (BARM). BARM is a single rate multicast congestion control protocol for streaming media applications in the best effort Internet environment. Combining aspects of window-based and rate-based congestion control, the protocol shifts most of the congestion control mechanisms to multicast receivers. A congestion window is maintained and updated by each receiver independently according to TCP-friendly binomial algorithm, and is converted to the expected sending rate which is then fed back to the sender if permitted. To suppress feedback implosion, a representative receiver is selected among receivers and a distributed suppression mechanism is used. BARM has good TCP-friendliness, smoothness, scalability, and acceptable responsiveness. "The broadcast program resource identifier in the MPEG-2 transport stream over ISDB system", Shigeru Aoki, Masahito Kawamori, 8-Feb-05, The Uniform Resource Identifier (URI) scheme "arib:" has been devised to allow acquiring the current or future scheduled publications of broadcast media content from the internet. These broadcast media contents are distributed with the MPEG-2 TS [ISO/IEC 13818-1] on the ISDB (Integrated Services Digital Broadcasting) broadcast system, which is specified in the [ITU-R BT.1306] and [ITU-R BS.1114]. "MIB for Fibre-Channel's Fabric Shortest Path First Protocol", Claudio DeSanti, 8-Feb-05, 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 Fabric Shortest Path First (FSPF) routing protocol. At present, this memo is in development as part of the SM-FSM project 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 Routing Information MIB", Claudio DeSanti, 8-Feb-05, 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 routing within a Fibre Channel fabric which is independent of the usage of a particular routing protocol. At present, this memo is in development as part of the SM-RTM project of T11.5 (http://www.t11.org). The plan is that it will later become a work item of IETF's IMSS working group. "XML Pipelining with Chunks for IRIS", Andrew Newton, 8-Feb-05, This document describes a simple TCP transport binding for the Internet Registry Information Service (IRIS). "RADIUS Authentication Server MIB (IPv6)", David Nelson, 9-Feb-05, This memo updates RFC 2619 by extending the MIB defined in RFC 2619 to add support for IPv6 address formats. "MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements", Fred Baker, James Polk, 9-Feb-05, The Defense Information Systems Agency of the United States Department of Defense, with its 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: "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. "Extracting RFCs", Scott Bradner, 9-Feb-05, Many people have expressed a desire to extract material from IETF RFCs for use in documentation, text books, on-line help systems, and for similar uses. In addition, some IETF RFCs contain MIBs and other types of program code that could be compiled. This document proposes an update to RFC 3667 and 3668 to explicitly permit extracting material for a wide range of uses. "Extension to RFC 3775 for Alerting the Mobile Node to Home Agent Unavailability", James Kempf, 9-Feb-05, RFC 3775 contains no way for a home agent to notify a mobile node that the home agent will shortly become unavailable, and suggest possible substitutes. A mobile node can suddenly find itself without mobility service. This document describes a simple protocol to inform the mobile node when its home agent is about to become unavailable and whether the mobile node should re-run bootstrapping to find a new home agent. "IPv4 Mobility through Peer Signaling", Subrata Goswami, 9-Feb-05, This document describes a way to perform mobility in IPv4 (potentially IPv6) without requiring any new entity in networks infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using infrastructure entities this method delegates all the mobility function to the end nodes. The method relies on source and destination address translation at the end nodes, and signaling between end nodes to perform hand offs - all these function can be encapsulated in an entity called Mobility Agent (MA) in the end nodes. "Multi-hop Pseudowire Setup and Maintenance using LDP", Florin Balus, 9-Feb-05, [MH PWE3 Requirements] describes the requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. A MH-PW is defined as a PW that spans a number of PW aware, tandem nodes called PW switching points (S-PE) in these domains. "RADIUS Accounting Server MIB (IPv6)", David Nelson, 9-Feb-05, This memo updates RFC 2621 by extending the MIB defined in RFC 2621 to add support for IPv6 address formats. "ECRIT Location Scope Requirements", James Winterbottom, 9-Feb-05, Special kinds of services require user location information to be authenticated and validated within a specific operating domain. An example of such a service is the emergency services network, where the location of a caller is known with in the domain of the telephone network, while the name or true identity of the caller is not intrinsically known. This paper describes the entities and key requirements necessary to provide such a service in an internet environment. "Domain Authorization for PIDF-LO", James Winterbottom, 9-Feb-05, This document describes a standard method for digitally signing Presence Information Data Format Location Object (PIDF-LO) documents using a subset of the XML Digital Signature specification. A digital signature enables the user of a signed PIDF-LO document to attribute that information to an authorized source within the domain of the target entity. A schema is defined for including a domain authorization element in the PIDF-LO and a set of XPath filters for selecting the correct elements for signing. "A Two-way Active Measurement Protocol (TWAMP)", Kaynam Hedayat, 9-Feb-05, The IPPM One-way Active Measurement Protocol [OWAMP] provides a common protocol for measuring one-way metrics between network devices. OWAMP [OWAMP] can be used in both directions independently to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This draft proposes a Two-way Active Measurement Protocol, based on the One-way Active Measurement Protocol [OWAMP], that will accommodate two-way or round-trip measurements. "Reciprocation of SMTP Trace Record", Christopher Harrison, 10-Feb-05, In much the same way one can track a parcel, this document proposes a simple method for returning the trace record of an e-mail to the SMTP originator (sender) as it passes through relays and gateways; passively, without the recipient's intervention. Delays can thus be explained and important e-mails (or paranoid e-mailers) can rest knowing their message has at least arrived at its destination. Much like parcel tracking, this is more of a gimmick than useful! "Route Advertisement Option for IPv6 Multicast Prefixes", Jerome Durand, Pekka Savola, 10-Feb-05, This document defines a way to advertise IPv6 multicast prefix availability using Neighbor Discovery (RFC2461). This multicast RA option can be used by routers to announce a set of multicast prefixes that can be on the link to form new group addresses. "Interworking of Protocol for Carrying authentication for Network Access (PANA) and Remote Authentication Dial In User Service(RADIUS).", Avi Lior, Alper Yegin, 10-Feb-05, This document provides information on the use of Remote Authentication Dial In User Service (RADIUS) with the Protocol for Carrying Authentication for Network Access (PANA). "IRC RPL_ISUPPORT Numeric Definition", Lee Hardy, 10-Feb-05, IRC (Internet Relay Chat) is a long-standing protocol for real-time chatting. Servers often provide features that are backward compatible with older clients, but do not provide a reliable method for making clients aware of what extensions exist. This memo presents a method for servers to advertise such extensions to clients. "SCL: A SIP Processing Configuration Language", E Shim, 10-Feb-05, SIP, a widely accepted Internet standard protocol for VoIP, is flexible enough to allow different extensions. The SIP-ALG (SIP Application Layer Gateway) in NAT/Firewall or, more broadly, the SBC (Session Border Controller) needs to be configured to handle properly SIP messages with extensions. We propose an XML-based SIP Processing Configuration Language, by which one can define the legitimate SIP message components and the way for the SBC to handle SIP messages, legitimate or not. "HTTP Enabled Location Delivery (HELD)", James Winterbottom, 10-Feb-05, This document describes a means by which a client-device may request location from a Location Server using HTTP as a GeoPriv 'using protocol'. "Multicast Emulation over VPLS", Prabakaran Ts, Musthafa As, 10-Feb-05, 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 addresses the above cases by using LDP signaling to emulate Multicast operation over VPLS with out using IGMP and PIM snooping as described in [VPLS-MCAST]. "Circuit Cross-Connect", Kireeti Kompella, 10-Feb-05, Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus. "IMAP Extension for Body Part Conversion", Michael Wener, 10-Feb-05, This document describes an IMAP extension that allows a client to convert and retrieve message MIME parts on demand. The conversion would be from one Content-Type to another. The client can discover the conversion set the server supports. It is assumed that there are two distinct phases: one, server conversion capability discovery, and two, client retrieval of a converted MIME part. In addition to MIME type conversion this document allows for compressed body part retrieval as a special case of conversion. "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) in an IPv6 Network", Alan Davey, Nic Neate, 10-Feb-05, Currently, RSVP-TE signalling over unnumbered links identifies routers using 32-bit Router IDs [RFC3477]. Traffic engineering extensions to IGP protocols for use in IPv6 networks use 128-bit IPv6 addresses to identify routers [OSPFv3-TE], [ISIS-TE]. This document specifies extensions for RSVP-TE signalling over unnumbered links to use 128-bit Router IDs in an IPv6 network. "Stream Tracking Description for Resource Management Guarantees in the Network", Teodora Guenkova-Luy, 10-Feb-05, This document defines an extension to the Session Description Protocol (SDP) and to Session Description Protocol new generation (SDPng - work in progress). The intention of this draft is to provide descriptions in SDP and SDPng that specify the source port of media streams. Such specification within the session description is required in many network quality of service (QoS) management systems in order to be able to track the media streams from their source to their destination. Thus the QoS management system can differentiate the stream tracks end-to-end and guarantee QoS for every single media. "Generalized Multi-Protocol Label Switching (GMPLS) Control Channel Separation with an IPv6 Control Plane", Alan Davey, Nic Neate, 10-Feb-05, This document specifies extensions to GMPLS signalling with control channel separation, [RFC3471], to use 128-bit IPv6 addresses to identify routers in an IPv6 control plane. "Architectural Commentary on Site Multi-homing using Level 3 Shim", Geoff Huston, 11-Feb-05, This document provides a commentary of the Level 3 Shim approach to site Multi-homing (L3Shim) as described in [ID.L3SHIM], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a framework for this analysis the approach described in [ID.ARCH]. "A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government", Ferry Hendrikx, Colin Wallis, 11-Feb-05, This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning and managing persistent resources and XML artefacts for the New Zealand Government. Discussion and comments on this draft should be sent to the authors' addresses located at end of this document. "Experience with the LDP protocol", Ina Minei, 11-Feb-05, The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. "A probabilistic scheme for fast Router Advertisement responses in IPv6", Greg Daley, 11-Feb-05, The IPv6 Neighbour Discovery RFC provides for random delays of between 0 to 500 milliseconds, in order to spread responses to solicitations when multiple routers exist on a link. This document describes an alternative scheme for responding to Router Solicitations which estimates the number of routers on the link, and aims to reduce the delay spread for responding Router Advertisements. "Considerations on the IPv6 Host density Metric", Geoff Huston, 11-Feb-05, This memo provides an analysis of the Host Density metric as currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. It is noted that for large allocations there are very significant variations in the target efficiency metric between the two approaches. The memo notes that the IPv6 address assignment efficiency metric would benefit from a detailed technical review, particularly relating to large scale deployments of public infrastructure. "Encoding Instructions for the Robust XML Encoding Rules (RXER)", Steven Legg, 11-Feb-05, This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 type as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an ASN.1 Schema document. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. "New mode for rfc3640: AAC-BSAC with MPEG-21 gBSD", Bernhard Feiten, 11-Feb-05, This draft proposes a mode for RFC 3640 to support an MPEG-4 AAC-BSAC audio codec format with an optional attached bitstream description. The bitstream description employs the MPEG-21 generalized Bitstream Syntax Description Language (gBSDL). The description is attached as auxiliary header and can be used to support adaptation. "Requirements for Scalable Remote Access to Applications", Vlad Stirbu, 11-Feb-05, This memo describes the requirements for accessing graphical user interface (GUI) applications remotely, so that devices with different form factors and UI capabilities can scale and adapt the exported UI to their local platform UI look and feel (LAF). "Harmonization of Session and Capability Descriptions between SDPng and MPEG-21 Digital Item Adaptation", Teodora Guenkova-Luy, 11-Feb-05, The delivery and the adaptation of multimedia content in distributed, heterogeneous environments, involving device and/or application mobility, require flexible control and management mechanisms in the terminals and/or in media gateways. MPEG-21 Digital Item Adaptation (DIA) provides normative description formats supporting the adaptation of so-called Digital Items, but it does not define interactions with existing transport and control technologies, in order to remain independent. This draft presents a practical approach for harmonizing MPEG-21 DIA application with Session Description Protocol next generation (SDPng). The proposed mechanism allows the definition of system configurations, performance constraints and adaptation information within the scope of SDPng using the format of MPEG-21 DIA. Furthermore, the converged format enables the integration of session management and negotiation protocols (e.g. Session Initiation Protocol - SIP) that use such enhanced SDPng descriptions within an MPEG-21 conformant environment. "Using ESP transport format with HIP", Petri Jokela, 11-Feb-05, This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). "Requirements for discovery of dynamic SSM sources", Rami Lehtonen, 11-Feb-05, This draft identifies the need for discovering new SSM sources in a multicast session. It also defines the basic requirements for such functionality. "Connectivity Scenarios for MANET", Simone Ruffino, 11-Feb-05, This Internet Draft aims at describing a wide spread set of possible connectivity scenarios involving mobile ad-hoc networks, in order to provide reference for standardization effort in this field. The aspects considered for definition and classification of the scenarios are number and characteristics of the gateways that connect MANET nodes to external networks. Analysis will range from a scenario where no connectivity is provided, i.e. an isolated MANET, to more complex scenario where a MANET has multiple mobile Gateways. "IPv6 Support on Mobile Ad-hoc Network", Ryuji Wakikawa, 11-Feb-05, This draft defines the IPv6 addressing architecture for Mobile Ad-hoc Network. This document includes problem statements when manet using IPv6, IPv6 addressing model, IPv6 manet node's required addresses. Note that this document does not discuss how an IPv6 address is allocated to each manet node. "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", Sathya Narayanan, 11-Feb-05, Hosts experiencing rapid link-layer changes may require further configuration change detection procedures than more traditional fixed hosts. DNA is defined as the process by which a host collects appropriate information and detects the identity of its currently attached link to ascertains the validity of its IP configuration. "Detecting Network Attachment in IPv6 - Best Current Practices for Routers", Sathya Narayanan, 11-Feb-05, Hosts experiencing rapid link-layer changes may require more frequent configuration change detection procedures than traditional fixed hosts. This document describes practices available to network deployers in order to support hosts Detecting Network Attachment in IPv6 networks. "Evaluation of Cellular Extensible Authentication Protocol (EAP) Methods agaist IEEE 802.11 requirements", Pasi Eronen, 11-Feb-05, This document evaluates two Extensible Authentication Protocol (EAP) methods, EAP-AKA and EAP-SIM, against the EAP method requirements for Wireless LANs given in [802.11 REQ]. "IMAP4 extension to SEARCH command for controlling what kind of information is returned", Alexey Melnikov, Dave Cridland, 11-Feb-05, This document extends SEARCH and UID SEARCH commands with result specifier, which can control what kind of information is returned. Several result specifiers are defined: minimal value, maximal value, all found messages and number of found messages. A new response ESEARCH is also specified. "A Name-Value Language (ANVL)", John Kunze, 15-Feb-05, ANVL (A Name-Value Language) is a simple record syntax based on email headers. An ANVL record is a sequence of data elements ending in a blank line. An element consists of a label, a colon, and an optional value, and a long value may be folded (continued) onto the next line by inserting a newline and indenting the next line. A value folded across several lines is treated as if the lines were joined on one long line; any line beginning with `#' is treated as a "comment". "LRDP: The Lightweight Remote Display Protocol", Vlad Stirbu, 11-Feb-05, This memo describes an application layer protocol for a framework that enables accessing graphical user interface (GUI) applications remotely, so that devices with different form factors and UI capabilities can scale and adapt the exported UI to their local platform UI look and feel (LAF). Specified in the Extensible Markup Language (XML), the protocol defines generic user interface (UI) operations and a mechanism for extending these operations for specific application needs. "Mobile IPv4 Host Configuration Vendor Specific Extensions", Kent Leung, 11-Feb-05, An IP device requires basic host configuration to be able to communicate. For example, the IP address on the interface and the DNS server for a hostname to IP address lookup. This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to- Point Protocol/IP Control Protocol (PPP/IPCP). However, both DHCP and PPP/IPCP provides host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as foreign network. The information to configure the host needs to be based on the home network. This document describes the extensions used to provide the base host configuration in the Registration Request and Reply messages. "Sieve Extension: Relational Tests", Wolfgang Segmuller, Barry Leiba, 12-Feb-05, This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. "IANA Registration for ENUMservices conf-web and conf-uri", Alan Johnston, 14-Feb-05, This document registers the 'ENUMservices' 'conf-web' with the 'http:' and 'https:' URI schemes, and 'conf-uri' using the URI schemes 'sip:', 'sips:', and 'h323:' as per the IANA registration process defined in the ENUM specification RFC3761. These ENUMservices indicate that the telephone number is associated with a conference and provide additional information and ways to participate in the conference. "Aggregate RSVP Reservations for IPsec Tunnels", Francois Le Faucheur, 14-Feb-05, [RSVP-IPSEC] defines RSVP extensions for IPSec which permit support of reservations for individual IPsec flows, but it does not support aggregate reservations between the IPSec devices with Diffserv [DIFFSERV] classification and scheduling. Conversely, [RSVP-AGG] defines how to aggregate individual RSVP reservations over Aggregate IP reservations when the aggregation region supports Diffserv, but it does not address the case where the aggregator and deaggregator use IPSec. However, there are scenarios requiring aggregate reservations for IPsec tunnels. This document specifies the incremental RSVP extensions beyond those defined in [RSVP-IPSEC] and [RSVP-AGG] to support such reservations. "Routing in a Nested VPN", Fred Baker, 14-Feb-05, This document discusses the general problem of routing in an IPv6 Nested Virtual Private Network. A solution is proposed based on one-way hashes of IP Prefix values. The concepts extend to IPv4, but with difficulty due to the number of bits in question. "Lightweight Multicast Address Discovery Problem Space", Pekka Savola, 14-Feb-05, Typically applications developers have requested static IANA assignments for the applications, even if the applications would typically be only used within a site, between consenting sites, or would not eventually even use multicast at all. This memo describes this problem space, and summarizes a number of proposed approaches to mitigating these problems. "Content-Script and Accept-Script Header Fields", Bruce Lilly, 14-Feb-05, Some written text in some languages can be represented in multiple scripts, or writing forms. This memo proposes mechanisms for identification and negotiation of script for written text. "Information Currency Systems", J. Bedell, 14-Feb-05, Networked information systems enable the creation of new instruments to apply economic models and mechanisms to the management of digital information. This document describes the message formats and operations used in the first such implementation of 'information currency'. "Using DTLS as a Transport for SIP", Cullen Jennings, Nagendra Modadugu, 14-Feb-05, This draft specifies how to use Datagram Transport Layer Security (DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security over a datagram protocol. "SIP Offer/Answer with Multipart MIME", Cullen Jennings, 14-Feb-05, This document addresses the issues around using multipart with the SIP offer/answer framework. It specifies a way to make an offer with a multipart/alternative MIME body and for the answer to indicate which of the parts was selected for the answer. This is needed for general backwards compatibility to allow migration in situations such as moving from SDP to SDPng or moving from non end-to-end encrypted SDP to encrypted SDP. "Usage Scenarios and Requirements for Multi-hop EAP Lower Layer", Gerardo Giaretta, 14-Feb-05, All EAP lower layers that have been defined for network access authentication have the requirement that an EAP peer and an EAP authenticator are in the same IP subnet. This draft describes some scenarios where relaxing this requirement so that the EAP peer and the EAP authenticator are multiple IP hops away from each other could be useful or necessary. The draft also extracts a set of requirements for the design of such a multi-hop EAP lower layer based on the scenarios. "The basic requirements for emergency services via the Internet", Richard Stastny, Brian Rosen, 14-Feb-05, We present a short list of the basic requirements for emergency services via the Internet. "Requirements for Path Computation Element (PCE) Discovery", Jean-Louis Le Roux, 14-Feb-05, This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with their capabilities. It is intended that solutions that specify procedures and protocol extensions for such PCE discovery satisfy these requirements. "Routing extensions for discovery of Traffic Engineering Node Capabilities", JP Vasseur, Jean-Louis Le Roux, 14-Feb-05, It is highly desired in several cases, to take into account Traffic Engineering (TE) node capabilities during TE LSP path selection, such as for instance the capability to act as a branch LSR of a P2MP LSP. This requires advertising these capabilities within the IGP. For that purpose, this document specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. "GMPLS constraints consideration for CSPF path computation", Tomohiro Otani, 14-Feb-05, This draft provides the guideline to consider generalized multi- protocol label switching (GMPLS) traffic-engineering (TE) attributes for constraint-based shortest path first (CSFP) path computation at a source node in a GMPLS network environment. This draft summarizes most possible cases of GMPLS constraint TE attributes at an ingress node, transiting nodes and an egress node to establish a GMPLS label switched path (LSP) appropriately. "A Framework of Media-Independent Pre-Authentication (MPA)", Yoshihiro Ohba, 14-Feb-05, This document describes a framework of Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that has a potential to address issues on existing mobility management protocols and mobility optimization mechanisms. MPA is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. This document also shows an initial implementation of MPA in our testbed and some performance results to show how existing protocols could be leveraged to realize the functionalities of MPA. "The HTTP ADDMEMBER Method", Julian Reschke, 14-Feb-05, Frequently, servers may want to allow resource creation through HTTP, but are not able to support HTTP's PUT method for creating new resources, as resource names are completely controlled by the server. This document proposes a new HTTP method called 'ADDMEMBER' with semantics similar to those of PUT, except for the fact that the server chooses the URI for the newly created resource. "Transmitting Confidential Data in RADIUS", Glen Zorn, 14-Feb-05, This document defines a pair of RADIUS Attributes designed to allow the secure transmission of sensitive or confidential data between RADIUS clients and servers. "Mobility Header Signaling Message", Brian Haley, 14-Feb-05, This document specifies a new Mobility Header message type that can be used between a mobile node and home agent to signal an event that requires attention. "How to store traceroute measurements and related metrics", Saverio Niccolini, 14-Feb-05, This memo describes a standard way to store traceroute measurements and possibly their related metrics. To better address the traceroute measurements storing issue, the authors first of all give a definition of the traceroute tool, describe the tool itself as well as its parameters and the default values on the most common operating systems and the output results that can be stored. Afterwards, the common information model with the base elements of the traceroute measurement storing is defined dividing the information elements in two semantically separated groups (configuration elements and results ones). On the basis of the information model a data model is then proposed in order to actually store the traceroute measurements. Finally the relevant metrics related to traceroute measurements are defined using the metrics already standardized in the IPPM working group, where they are found to be applicables. "NFSv4.1: Directory Delegations", Brain Wickman, 14-Feb-05, NFS version 4 (NFSv4) introduces the use of file delegations to improve the ability of clients to cache file data and to provide locks in certain sharing environments without performing a round-trip communication to the server. Directory caching in NFSv4, however, is similar to previous versions and generates unnecessary revalidation traffic to maintain consistency weaker than delegations can provide. This document addresses the issues involved in providing a directory delegation mechanism and specifies a new operation, REQUEST_DELEGA- TION, to enable directory delegations. "Regulating Publication of Event State Information", Jacco Brok, 14-Feb-05, The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism for a User Agent Client (UAC) to publish event state information to a User Agent Server (UAS). Generally, the UAC is free to monitor certain resources at a certain rate and publish changes of their event state, for instance with a document based on the Presence Information Data Format (PIDF) for the presence event package. However, for a UAC on a mobile device, monitoring some resources can be costly in terms of battery and computing, for instance GPS or voice analysis. Although some mechnisms exist for a UAC to deduce whether event state publication is needed and at what rate publish messages may be sent, but these are rather coarse and reactive in nature. This memo defines a solution for a UAS to regulate monitoring and publications by providing detailed information to the UAC regarding which resources to monitor, at what rate, the urgency and the required probability. "Issues Related to Receiver Access Control in the Current Multicast Protocols", Tsunemasa Hayashi, 14-Feb-05, This I-D lists and describes issues related to receiver access control in current multicasting protocols which are especially important to commercial, large-scale multicasting. A few common business models for content and network provision are presented to provide background and explain the motivation of this work. Four existing possible multicasting architectures (with or without some form of access or content control) are presented. Then each architecture is analyzed with respect to how it can or cannot satisfactorily address each issue. This I-D concludes that for many of these issues the possible architectures based on present standards as they now exist require non-standardized solutions to meet common use requirements. This I-D recommends for requirements to be defined that would set the groundwork for creating standardized ways to overcome these limitations. "Network Bandwidth Parameters for Remote Authentication Dial In User Service (RADIUS).", Avi Lior, 14-Feb-05, 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. "Host Identity Protocol (HIP) Registration Extension", Teemu Koponen, L Eggert, 14-Feb-05, This document specifies a registration mechanism for the Host Identity Protocol that allows hosts to register with services. "Evaluation of existing GMPLS Protocols against Multi Region Networks", Jean-Louis Le Roux, 14-Feb-05, This document provides an evaluation of Generalized Multi-Protocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi Region Networks (MRN). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy the requirements of Multi Region Networks, and provides guidelines for potential extensions. "NAT Classification Test Results", Cullen Jennings, 14-Feb-05, 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. This draft is not complete and has only a few test results but it is worth discussing all the testing we wish to do before all the test results are collected. "LSP Stitching with Generalized MPLS TE", Arthi Ayyangar, JP Vasseur, 14-Feb-05, In certain scenarios, there may be a need to combine together two different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to-end (e2e) LSP is achieved and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. It might be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. "Distributed Black/White Lists", Andrew Newton, Yakov Shafranovich, 14-Feb-05, Many traditional, centrally-managed blacklists and whitelists describe Internet end-points by characteristics such as connectivity type or network function, and these characteristics are often used to infer behavior from which authorization is derived. However, it is often the case that connectivity type or network function are not related to good or bad behavior. This document describes a means of creating blacklists and whitelists representative of Internet end-points based on observed behavior by many participants in a distributed monitoring network. The authors hope that distributed lists will mitigate some of the problems associated with existing centrally managed lists. While the concept, architecture, and data model are general enough to be applied to any type of network service, the authors of this document are specifically addressing the problem of spam in blogs. "Implementation Guide for Referrals in NFSv4", D Noveck, David Noveck, 14-Feb-05, RFC3530 describes a migration feature using the NFS4ERR_MOVED error code and the fs_locations attribute. The description focuses on the case of migration (i.e. relocation) of a file system already known to the client. The simpler limiting case in a which a file system not previously known to the client was located elsewhere, which we here call a referral, was not clearly described. Because of this and also because of some inconsistencies and ambiguities in the text of RFC3530, there has been confusion about how the client and server should interact in performing a referral. This document provides a guide to the implementation of referrals, and in so doing, addresses the relevant problems in RFC3530. "Considerations on the IPv6 Host density Metric", Geoff Huston, 14-Feb-05, This memo provides an analysis of the Host Density metric as currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. It is noted that for large allocations there are very significant variations in the target efficiency metric between the two approaches. The memo notes that the IPv6 address assignment efficiency metric would benefit from a detailed technical review, particularly relating to large scale deployments of public infrastructure. "Lemonade and the challenges of Intermediaries", Stephane Maes, Dave Crocker, 22-Feb-05, This document discusses some of the issues posed by firewalls and other intermediaries to deployment of some basic IETF technologies. The intent of this document is to track such issues, explore possible approaches elegant or not that have been proposed so far to address them and initiate discussion on how such issues should be appropriately addressed by IETF. This first version 00 is provided to initiate discussion. Most of the content should be considered as initial place holders. "RTP Payload Format for ECN Probing", Corey Alexander, Jozef Babiarz, 14-Feb-05, This memo defines a Real Time Transport Protocol (RTP) payload format for use when probing for congestion using Explicit Congestion Detection (ECN). This payload format is intended for use with the probing mechanisms described in [3]. While defined in terms of the specific application of admission control, it is desirable to overlay this format with other probing mechanisms so as to reduce the number of probing packet formats. "Admission Control Use Case for Real-time ECN", Corey Alexander, 14-Feb-05, This document describes Admission Control as a use case for the mechanisms described in "Congestion Notification Process for Real-Time Traffic" [1] and the RTP payload format defined in "RTP Payload Format for ECN Probing" [2]. "Extended Generic Security Service Mechanism Inquiry APIs", Nicolas Williams, 14-Feb-05, This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended for use in mechanism composition, but also to reduce instances of hardcoding of mechanism identifiers in GSS applications. "Stackable Generic Security Service Pseudo-Mechanisms", Nicolas Williams, 14-Feb-05, This document defines and formalizes the concept of stackable pseudo-mechanisms, and associated concept of composite mechanisms, for the Generic Security Service Application Programming Interface (GSS-API), as well as several utility functions. "IP Address Location Privacy and IP Mobility", Rajeev Koodli, 14-Feb-05, In this document, we discuss Location Privacy as applicable to IP Mobility. We discuss two problems: disclosing a new IP address to a correspondent, and revealing a fixed identity to an eavesdropper. We document some of the previous discussion on possible solutions. "Solutions for IP Address Location Privacy in the presence of IP Mobility", Rajeev Koodli, 14-Feb-05, In this document, we discuss solutions to the following two problems: disclosing a new IP address (CoA) to a correspondent, and revealing a fixed identity (HoA) to an eavesdropper. "Industrial-Strength P2P SIP", Philip Matthews, 14-Feb-05, If internet telephony networks based on peer-to-peer and Session Initiation Protocol (SIP) technology are to become as viable as existing centralized telephony services, the peer-to-peer SIP technology must offer all the features of existing technologies. This draft lists some features which are in some way "challenging" for peer-to-peer SIP to support, and proposes a structure for the resulting protocol suite. "RADIUS Authentication Client MIB (IPv6)", David Nelson, 14-Feb-05, This memo updates RFC 2618 by extending the MIB defined in RFC 2618 to add support for IPv6 address formats. "RADIUS Accounting Client MIB (IPv6)", David Nelson, 14-Feb-05, This memo updates RFC 2620 by extending the MIB defined in RFC 2620 to add support for IPv6 address formats. "IRIS - A Routing Registry (rreg) Type for the Internet Registry Information Service", Kengo Nagahashi, 14-Feb-05, This document describes an IRIS registry schema for Internet Routing 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. "Filtering Capabilities for IP Network Infrastructure", Christopher Marrow, George Jones, 14-Feb-05, [I-D.practices] lists operator practices related to securing networks. This document lists filtering capabilities needed to support those practices. Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, tradeoffs, etc. "Multicast in VPLS", Rahul Aggarwal, 14-Feb-05, This document describes a solution for overcoming the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures for propagating multicast control information, learned from local VPLS sites, to remote VPLS sites, are described. These procedures do not require IGMP-PIM snooping on the SP backbone links. "Associating SMPTE time-codes with RTP streams", David Singer, 14-Feb-05, This document describes a mechanism for associating SMPTE time-codes with media streams, in a way that is independent of the RTP payload format of the media stream itself. "Design Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN)", Bryan Ford, 14-Feb-05, This document discusses design principles and behavioral properties required to make Network Address Translators (NAT) more predictable and compatible with diverse application protocols. First, this document presents a concrete architectural model for NAT devices and defines important terms used in conjunction with NAT design. This architectural model sets the stage for a set of concrete recommendations for NAT implementors and vendors, as being contemplated by the BEHAVE working group. The recommendations made by this document are independent of transport protocol; a set of companion documents provide behavioral recommendations specific to particular transport protocols. "A Simple Privacy Extension for Mobile IPv6", Francis Dupont, 14-Feb-05, This draft presents a simple privacy extension for Mobile IPv6 that prevents eavesdroppers from identifying the packets sent or received from a particular mobile node. This extension also allows a mobile node to hide its identity from correspondent nodes when the mobile node initiates the communication. "Split-View DNSSEC Operational Practices", Suresh Krishnaswamy, 14-Feb-05, The security extensions to the Domain Name System (DNSSEC) allow for integrity protection, whereby it is possible to make a determination of the verity of data returned from the Domain Name System in response to a query. Current operation of the Domain Name System also allows for the creation of multiple views of data, where the answer returned in response to a query is dependent on the origin of the query. Data integrity and the ability to return possibly conflicting values as in split-views may be construed to be mutually conflicting goals; but this apparent dichotomy is resolvable in practice through proper configuration. This document provides recommendations for correctly configuring the split-view DNSSEC environment in a typical enterprise network. "Dynamic AS Switching at AS Confederation Edge", Susan Hares, Pratik Bose, 14-Feb-05, This document provides a mechanism for Autonomous Systems within an AS Confederation to survive the disconnection to other AS within the AS confederation without dropping peers. When all links to the other AS in the Confederation break, this mechanism allows the AS to revert to local AS to continue communication with E-BGP peers. This mechanism has two parts: Capability signaling between the two parties at connection start to save two AS (internal and AS Confederation AS) and a mechanism to signal the switch between AS Confederation AS and internal AS. "Path Computation Element (PCE) Communiation Protocol Requirements", Jerry Ash, 14-Feb-05, Constraint-based path computation is a fundamental building block for traffic engineering systems such as MPLS and GMPLS networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the communication protocol requirements for a Path Computation Element (PCE)-based model. "ForCES TML API", Jamal Salim, 14-Feb-05, This document proposes an API between the ForCES PL and TML layer with an end goal of reducing the effort of implementation of forces PL level (and therefore expediting the deployment of multiple TMLs). "Conference State Change Protocol (CSCP)", Cullen Jennings, Adam Roach, 15-Feb-05, Conference State Control Protocol (CSCP) is a means to modify the state in a conference service. It extends the Binary Floor Control Protocol and adds commands to get, set, add, and delete fields in the conference state. "Privacy for Mobile and Multi-homed Nodes (MoMiPriv): Formalizing the Threat Model", Wassim Haddad, 15-Feb-05, This memo describes threats violating the privacy based on identifiers used at the MAC and IP layers, in the context of a mobile and multi-homed environment. "Enriching Bootstrapping with Authorization Information", Hannes Tschofenig, 15-Feb-05, Some work has been done in the area of bootstrapping in the IETF recently. Bootstrapping refers to the process of creating state (typically security associations) between two or more entities based on a trust relationship between these two or more parties and a trusted third party. So far work has mostly focused on creating security associations. This document aims to attach authorization information to the bootstrapping process. "The LDAP Don't Use Copy Control", Kurt Zeilenga, 15-Feb-05, This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. "Security Association for application bootstrapping", Mayumi Yanagiya, 15-Feb-05, In [ID-yanagiya-eap-saa-00], [ID-ohba-mip6-boot-arch-dhcp-01], and [ID-yegin-eap-boot-rfc3118-01], it is assumed that a peer and service authenticator execute the authentication or authorization process with a key derived from EAP Keying materials. However, [EAP-Key-04] does not assume that a network element that does not support EAP, such as a DHCP server or Mobile IP home agent, uses the EAP key to authenticate/authorize the user. Thus, it is necessary to define a new security association and key for the application authenticator. "IA type for Mobile IPv6 bootstrapping", Mayumi Yanagiya, 15-Feb-05, When we use DHCPv6 to bootstrap Mobile IPv6 service, stateful DHCP should be used to assign the home address. In [RFC3315], two types of IA are specified: IA_NA and IA_TA. When stateful DHCPv6 is used in a local network, the "care-of address" is carried as one of the IA_NA options. On the other hand, when autoconfiguration [FRC2462] is used, care-of address is generated on mobile node and there is no way to assign home address stateful. Thus, we introduce a new IA type to assign the home address. "Using HIP with Legacy Applications", Tom Henderson, 15-Feb-05, The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family (e.g., AF_HOST), but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. "Generalizing the HIP base protocol", Tom Henderson, 15-Feb-05, The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. This draft observes that HIP can be viewed as an instance of a more general migration towards decoupling identity from location in the Internet architecture, and shows how other proposals (mobile IP, multi6, mobike, and i3) fit into this framework. We argue that if the HIP base protocol were to be slightly generalized, it might be useful to other related efforts and might allow more experimental flexibility. Specifically, an extensible identifier TLV, the ability to define usage profiles for the HIP handshake, and a relaxation of the requirements that specific HIP messages carry specific parameters are the three changes suggested. "The XML Enabled Directory: Matching Rules", Steven Legg, Daniel Prager, 15-Feb-05, The XML (Extensible Markup Language) Enabled Directory (XED) allows the definition of directory attributes whose syntaxes are defined in terms of XML Schema types, RELAX NG patterns or Document Type Declaration (DTD) element type declarations. This document enables the matching of directory attribute values of such syntaxes by extending existing Lightweight Directory Access Protocol (LDAP) and X.500 directory matching rules. "An alternative to XML Configuration Access Protocol (XCAP) for manipulating resource lists and Authorization lists, Using HyperText Transport Protocol (HTTP) extensions for Distributed Authoring and", Rohan Mahy, 15-Feb-05, This document describes an alternative to XCAP (XML Configuration Access Protocol) for manipulating SIMPLE resource and authorization lists using WebDAV. This alternative is motivated by initial performance data that suggest that when XCAP Servers verify requests satisfy a required property of HTTP (idempotency), performance may drop non-trivially. "A Location Event Package using the Session Initiation Protocol (SIP)", Rohan Mahy, 15-Feb-05, This document describes a Session Initiation Protocol (SIP) event package to carry location data about named SIP resources. Inherent in this event package are filters which limit notifications to compelling events which are described by the filters. The resulting location information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO). Location disclosure is limited to voluntary disclosure by a notifier that possesses credentials for the named resource. "Problems in Calendaring and Scheduling Standards", Cyrus Daboo, 15-Feb-05, Current calendaring and scheduling standards are fraught with a number of significant problems, that have hindered wide deployments of interoperable products. This informational document lists the problems with the current standards documents as a means to help identity areas where revisions of the documents are required. "Architecture and Design Principles of the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 15-Feb-05, The Session Initiation Protocol (SIP) and its many extensions and supporting technologies define a solution for multimedia communications on the Internet. Much of the design and architecture for SIP is based on a key set of architectural principles which, while commonly discussed on mailing lists and other forums, have not been explicitly captured. This document seeks to rectify that gap by outlining the key set of architectural and design principles underlying SIP. "Packet Tunneling for Route Optimization in MN-to-MN Communications", Eric Wu, 15-Feb-05, Mobile IPv6 provides mobility support for mobile devices moving around the Internet. It specifies that when a mobile host wishes for peers to communicate directly to its visited location, that the peer send packets using a Routing Header, Type 2. Corresponding packets from the mobile use a Home Address option. When two moving devices communicate, they may wish to use a the most direct data path between their respective locations. Use of this direct data path incurs the cost of both Routing Header and Home Address Options, in each direction. This document provides a simple means of reducing this overhead. "Matching Language Identifiers", Addison Phillips, Mark Davis, 15-Feb-05, This document describes different mechanisms for comparing and matching the language identifiers defined by RFC3066bis. Possible algorithms for language negotiation and content selection are described. Portions of this document obsolete RFC 3066. [1] "EAP Tunneled TLS Authentication Protocol Version 1 (EAP-TTLSv1)", Paul Funk, Simon Blake-Wilson, 15-Feb-05, EAP-TTLS is an EAP type that utilizes TLS to establish a secure connection between a client and server, through which additional information may be exchanged. The initial TLS handshake may mutually authenticate client and server; or it may perform a one-way authentication, in which only the server is authenticated to the client. The secure connection established by the initial 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. "Additional Values for the NAS-Port-Type Attribute", Glen Zorn, 15-Feb-05, This document defines a set of new values for the NAS-Port-Type RADIUS Attribute. "SUA Implementor's guide", Lode Coene, John Loughney, 15-Feb-05, This document contains a compilation of all defects found up until the publication date for SUA [RFC3868] [1]. 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 SUA to clarify errors in the original SUA document. This document updates RFC3868 and text within this document supersedes the text found in RFC3868. "Temporal Enumerated Ranges (TEMPER)", John Kunze, 15-Feb-05, TEMPER (TEMPoral Enumerated Ranges) is a simple date and time syntax for representing points, lists, and ranges of timestamps. The syntax is designed to be trivial to parse, easy for humans to read, and friendly to simple lexical sorting algorithms. TEMPER consists of 4-, 8-, and 14-digit points, point ranges, and lists of points and ranges. "Ad hoc network autoconfiguration: definition and problem statement", Shubhranshu Singh, 15-Feb-05, A Mobile Ad hoc Network (MANET) is formed by the association of wireless and mobile devices capable of communicating among themselves even if there is no networking infrastructure available. The autonomous nature of these networks, requires the existence of an autoconfiguration mechanism. This document provides definition, problem statement and solution guidelines for ad hoc network autoconfiguration. "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", James Winterbottom, 15-Feb-05, The GeoPriv PIDF-LO specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented so that the number of options that need to be implemented in order to make use of it are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for message and call routing applications. For such applications to interoperate successfully location information will need to be normative and more constrained than is currently described in the PIDF-LO specification. This paper makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further looks at existing communications standards that make use of geodetic information for routing purposes and recommends a subset of GML that MUST be implemented by applications to allow message routing to occur. "Considerations of point-to-multipoint route optimization using PCEMP", Jun Choi, 15-Feb-05, This draft describes the basic concepts of point-to-multipoint (p2mp) path computation on the basis of the Path Computation Element Metric Protocol (PCEMP). PCEMP, being soft-memory based, has the capability of dynamic configuration of its finite state machines (FSMs) in the participating PCEMP peers, and thus can support a wide variety of traffic engineering techniques that are needed to guarantee bandwidth demand and scalable fast protection and restoration in PCE based p2mp frameworks. To take advantage of bandwidth considerations and fast restoration mechanisms, the centralized Controller, which is the key element in a PCE node, is used for path computation in case of p2mp paths and can be used in a scenario where reliable multicasting of bandwidth-on-demand services becomes an important criteria for multiple-domain and/or inter-domain PCE based architectures. "Requirements for planned maintenance of BGP sessions", Nicolas Dubois, 22-Feb-05, To ease the maintenance of BGP-4 [BGP-4] sessions and limit the amount of traffic that is lost during planned maintenance operations on routers, a solution is required in order to gracefully shutdown a router or a session. "PWE3 Applications & OAM Scenarios", Simon DeLord, 15-Feb-05, The present document introduces some considerations and further requirements from several service providers (SPs) concerning deployment and monitoring of VPWS (either circuit- or packet-based) services built using PW emulation. These connections can either be homogeneous or heterogeneous, and they can be deployed over networks (access & core) belonging to the same SP or different SPs. This document considers aspects on both service architecture and service supervision (OAM) by describing different implementation solutions and detailing the Pros and Cons of each solution. This document targets to provide clarification and applicability guidelines for the on going OAM work. "Policy Decisions for Users with Access to Multiple Services", Jari Arkko, Pasi Eronen, 23-Feb-05, This draft relates to the use of Authentication, Authorization, and Accounting (AAA) where the same user credentials can be used on many different types of devices, ranging from wireless access points to Virtual Private Network (VPN) gateways. More specifically, this draft discusses how AAA servers can determine what incoming service was provided, and how they can use this information as a basis for policy decisions. "A stateless Ping Client for simple tests of GIMPS implementations", Ingo Juchem, 15-Feb-05, When implementing signaling protocols such as CASP or GIMPS, implementers need a way to test the functionality and measure the runtime properties of their own implementations. In this document, we try to provide a sketch for such a testing tool, a simple, stateless Ping Client, which works similar to ICMP Ping messages. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, 15-Feb-05, Session Mobility is the seamless transfer of media of an ongoing communication session from one device to another. This document describes the general methods and specifies the flows for providing this service as part of the Session Initiation Protocol (SIP). The basic steps involved in session mobility which are describe are service discovery to locate devices to use as transfer targets, for which the Service Location Protocol (SLP) is used, session transfer, and, sometimes, reconciliation of device capability differences. The described session mobility methods include the possibility of transferring any subset of the active media to one or more devices. "DNS transport issues", Kazunori Fujiwara, 15-Feb-05, This memo describes DNS transport issues in DNS shared unicast environment. Recently, many root DNS servers and some TLD servers have introduced DNS shared unicast technique for DNS authoritative services, this may cause some problems. "Early Binding Updates for Mobile IPv6", Christian Vogt, 15-Feb-05, Mobile IPv6 defines a return-routability procedure for secure use of route optimization between unacquainted nodes. The handover latency caused by the procedure can significantly impact delay-sensitive applications, however. This document presents an optimization to Mobile IPv6 that eliminates the latency. The optimization is realized as an optional, and fully backward-compatible, extension to Mobile IPv6. "MOBIKE Extensions for PF_KEY", Udo Schilcher, Hannes Tschofenig, 15-Feb-05, PF_KEY is a generic key management API used for communication between a trusted user level key management daemon and a key engine within the operating sytem. With the extension of IKEv2 for mobility and multihoming (MOBIKE) the existing capabilities of PF_KEY with regard to the creation, maintenance and deletion of security assocations became insufficient. This document defines an extension to update an entity in the security association database. Additionally, it is necessary to reflect the newly offered integrity and encryption algorithms with IKEv2 in PF_KEY. "Packet reordering in Extended CRTP (ECRTP)", Thima Koren, 15-Feb-05, Extended RTP Header Compression (ECRTP) is tolerant to packet misordering. This document describes how ECRTP validates packets that arrive out of order. "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", Nandakishore Kushalnagar, Gabriel Montenegro, 15-Feb-05, This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. Additional goals may be found necessary over time and may be added to this document. "MRT routing information export format", Larry Blunk, 15-Feb-05, This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. "To publish, or not to publish, that is the question.", Alain Durand, Tim Chown, 15-Feb-05, This document aims at restarting the discussion on what is allowed to publish in the global DNS and what is not. The latest attempt was documented in [1] in an unsuccessful effort to clarify what to do with IPv4 private addresses RFC1918 [2] in the DNS. Since then, a number of similar issues coming from the IPv6 world have popped up and there is a sense that situation need to be clarified by a BCP. "A Processing Model for Presence", Jonathan Rosenberg, 15-Feb-05, This document defines the underlying data processing operations used by Session Initiation Protocol (SIP) for Instant Messaging Leveraging Presence Extensions (SIMPLE) presence agents and presence user agents. The data processing operations described here include composition, privacy filtering, and watcher filtering. "Application Design Guidelines for Traversal of Network Address Translators", Bryan Ford, 15-Feb-05, This document defines best current practices by which application designers can create applications that communicate reliably and efficiently in the presence of network address translators (NAT), particularly when the application has a need for "peer-to-peer"-style (P2P) communication patterns in addition to traditional client/server-style communication. There is no single NAT traversal algorithm that will make a P2P application reliably work over all deployed NATs. Following the guidelines described in this document, however, allows a P2P application to work reliably over a majority of existing NATs, as well as all future NATs that conform to the requirements specified in companion documents. The NAT traversal techniques described here do not require the use of special proxy or relay protocols, do not require specific knowledge about the network topology or the number and type of NATs in the path, and do not require any low-level modifications to IP or transport-layer protocols that might require special privileges on the end hosts. "Mobile IPv6-based Global Anycasting", Shingo Ata, 15-Feb-05, Today, the use of anycasting is quite limited. In this document we explain a new network architecture for global anycasting to solve (1) in practical use and able to realize with existing technology easily, (2) about support for stateful communications keeping a session information at the end nodes such as TCP. The architecture is based on MIPv6 because there are many similarities between MIPv6 and global anycast. "All DRs all RPs model", Jerome Durand, Dave Thaler, 15-Feb-05, This document defines a new model for IPv6 ASM (Any Source Multicast) where the Designated Router (DR) on each LAN can serve as a Rendezvous Point (RP) for group addresses formed from the RP address. This keeps group-to-RP mapping simple, while providing for multicast address allocation coordination to be kept within a subnet. "An Overview of Approaches to Detecting Network Attachment in IPv6", Brett Pentland, 15-Feb-05, This document is a discussion of potential solutions to the problem of rapidly and reliably detecting attachment to a network and determining when host configuration change is required. "Extensions to Return Routability Test in MIP6", Fan Zhao, 23-Feb-05, This draft proposes some extensions to the Return Routability Test in MIP6 to address the location privacy issue and enable CN as well as MN to promptly detect the attack that could compromise the security of MIP6 RO mechanism. "Framework for Metering NSLP", Ali Fessi, 15-Feb-05, This document describes an architectural framework for a new NSLP, which allows the dynamic configuration of Metering Entities on the data path to record monitoring and measurement data and report it to a data collector. Different scenarios are described where such a path-coupled configuration of the Metering Entities can be useful. Currently, the focus is on three scenarios: metering for accounting, QoS monitoring and monitoring for network security. Moreover, this document suggests the appropriate parameters to be configured for each scenario. Furthermore, it gathers requirements for a path-coupled configuration protocol of Metering Entities. Finally, the applicability of the NSIS architecture for this purpose is discussed. "The mailto URI scheme", Martin Duerst, Larry Masinter, 15-Feb-05, This document defines the format of Uniform Resource Identifiers (URI) for designating electronic mail addresses. The syntax of 'mailto' URIs from [RFC2368] is extended to be compatible with IRIs ([RFC3987]) for better internationalization. "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service", Magnus Westerlund, 15-Feb-05, 3GPP has defined a packet-switched streaming service that uses SDP and RTSP with some extensions. This document provides information about these extensions and registers the SDP extensions with IANA. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Patch Operations", Jari Urpalainen, 15-Feb-05, Many prevailing systems nowadays utilize XML documents. Sometimes there's need to do some minor changes to the documents and therefore it is useful to transport only the changes e.g. over the network. This document describes XML patch operations which can be used to achieve this goal by defining XML elements which can be embedded within a transported XML change document. "Aggregation PE", Marko Kulmala, 15-Feb-05, This document describes operation of aggregation PE and applications for it. Aggregation PE installs VPN-IPv4 routes into VRFs and acts as BGP next hop when it readvertises VPN-IPv4 routes with MP-BGP to other PE routers. This eliminates the need to LSP connectivity (or some other type of tunnels) between packet's ingress and egress PE. "Retargeting and Security in SIP: A Framework and Requirements", Jon Peterson, 15-Feb-05, Retargeting, the alteration by intermediaries of the destination of a Session Initiation Protocol (SIP) request, is a common practice performed during the routing of a call. Some forms of retargeting, however, give rise to security problems and potential functional gaps in SIP. This document provides a general framework for discussion of the security problems relating to retargeting, and gives requirements for mechanisms that might overcome these problems. "DHCPv6 Options for Fast Handovers", Takeshi Ogawa, 15-Feb-05, When a standard Mobile IP node (MN) changes its wireless network attachment point (performs a handover), it gets new IP layer configuration information (a new network prefix and address of a new default gateway) from a new access router and tries to know whether it has moved to other subnet. If it has, it changes its IP layer configuration. During such a handover process,it cannot send and receive IP packets from its corresponding node(CN), so a service disruption is caused. In this document, we introduce new DHCP options. With them, DHCP servers can send new information before a handover to be used after the handover, and MNscan reduce handover process time. "Address autoconfiguration in Optimized Link State Routing Protocol", Anis Laouiti, 15-Feb-05, One of the MANET protocols which have been recently promoted to experimental RFC is the OLSR routing protocol[3]. This document aims at complementing the OLSR routing protocol specifications to handle autoconfiguration. The corner stone of this autoconfiguration protocol is an advanced duplicate address detection algorithm. We propose a comprehensive autoconfiguration scheme whose basic idea is to avoid conflicts in the 2-hop neighborhood of each node. We have designed two algorithms to perform this task. These algorithms are shown to work in any case of multiple conflicts, especially during network mergers. "Topology complications from Network Address Translator deployments", Bryan Ford, Pyda Srisuresh, 15-Feb-05, This document identifies and provides recommendations for dealing with issues that have arisen recently from the ubiquitous deployment of network address translators (NAT), and the unconventional network topologies that are often constructed with them. First, the simplicity of administering networks through the combination of NAT and DHCP is increasingly leading to the deployment of multi-level hierarchies of inter-connected private networks involving overlapping private IP address spaces. The creation of these multi-level hierarchies is often unintentional, since each level of NAT is typically deployed by a separate administrative entity such as an ISP, a corporation, or a home user. Second, the popularity of corporate virtual private networks (VPN) in conjunction with NAT leads to problems in which the private IP address space of the network through which a remote client is attached may unintentionally conflict with the private IP address space of the corporate network into which the remote client is tunneled. This document specifies best current practice recommendations for addressing the issues identified. "Application Programming Interface to a Trigger Database for MOBIKE", Udo Schilcher, Hannes Tschofenig, 15-Feb-05, One of the functionality of MOBIKE is to create and to maintain a set of available addresses and to provide them to the communication partner. A MOBIKE peer should have some information about the status of each address in order to execute the respective actions (e.g., switching from one preferred address to another). This information, which will be referred as trigger, is distributed over a number of protocols daemons at an end host. To make this information available to the MOBIKE daemon it is necessary to store it centrally at the host (called trigger database) and to enable the protocols to insert the triggers and to allow MOBIKE to obtain timely information. "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Shinta Sugimoto, Francis Dupont, 15-Feb-05, This document describes need for interface between Mobile IPv6 and IPsec/IKE and show how two protocols can interwork each other. We propose a mechanism to realize this interaction by extending PF_KEY framework. Proposed mechanism makes it possible for Mobile IPv6 to inform IPsec/IKE about the movement. Receiving the message, IPsec components can take necessary actions to update corresponding entry in SPD and SADB. In addition, IKE can use the notification for keeping its IKE connection alive. "Goals for Tunneling Configuration", Jordi Palet, 15-Feb-05, This memo describes the set of goals for a tunneling setup protocol that could be used in several network cases to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity through a simplistic tunneling mechanism. The basic network cases, which may have different sets of goals, are also introduced, including 3GPP and other Service Providers. Two cases are analyzed in the Service Provider scenario, one which apply to simplistic mechanism where the user is already authenticated by other network existing means, and another which also takes care of the user authentication. "Emergency Call Requirements for IP Telephony Services In Japan", Hiroshi Arai, Motoharu Kawanishi, 15-Feb-05, This memo introduces the status of study in Japan regarding the communication for emergency reports using public IP telephony services. First, it provides the information on the background and history, and then it summarizes the functional requirements from the relevant authorities. "The SDP (Session Description Protocol) Content Attribute", Jani Hautakorpi, Gonzalo Camarillo, 15-Feb-05, This document defines a new Session Description Protocol (SDP) media-level attribute, 'content'. The 'content' attribute defines the content of the media stream in more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big screen or small screen) based on their content. "Problem Statement: IP Address Configuration for IPDVB", Martin Stiemerling, 15-Feb-05, Future IPDVB networks will require a more powerful IP address configuration management as currently provided in such networks. Current discussions within the IPDVB working group have shown that the future usage scenarios and requirements for dynamic configuration of IP addresses are not yet clear defined. This memo identifies the problem space for IP address resolution and configuration in IPDVB networks. "Functionality of Existing Session Border Controller (SBC)", Gonzalo Camarillo, 15-Feb-05, This document gives an overview to Session Border Controllers (SBCs) and to the functions they perform. The way how SBCs relate to the telecommunication architectures is also presented. The purpose of this document is to help the IETF community understand what functionality existing SBCs provide so that the appropriate working groups can decide whether or not new standard solutions need to be developed to provide such functionality (or a subset of it) in a standard way. Working groups may also develop recommendations on how to use existing standard mechanisms to provide such functionality. "IPv6 Transcition in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 15-Feb-05, This document describes how IPv4 SIP (Session Initiation Protocol) nodes can communicate with IPv6 SIP nodes. Additionally, this document also describes how a SIP user agent that supports IPv4 can exchange media with one that supports IPv6. Both single and dual-stack user agents are considered in the discussions. "Preferred Alternatives for Tunnelling HIP (PATH)", Pekka Nikander, 15-Feb-05, With the extensions defined in this document Host Identity Protocol (HIP) can traverse legacy Network Address Translators (NATs) and certain Firewalls. The extension will be useful as part of the base exchange and with the HIP Registration Extension. By using a rendezvous server an additional entity inside the network is utilized, which not only allows but also supports more restrictive NATs to be traversed. "Direct Signaling for Mobile IPv6 Return Routability Procedure", Eric Wu, 15-Feb-05, In Mobile IPv6, mobile nodes must complete Return Routability Procedure and binding process before route optimization for data packet transmission is performed. This requires signaling exchange between the mobile and correspondent node. For the current specification, signaling is restricted to be routed to the mobile's and correspondent node's home addresses. "The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)", Gonzalo Camarillo, German Blanco, 15-Feb-05, This document specifies the SIP P-User-Database P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. "The Protected One-Time Password Protocol (EAP-POTP)", Magnus Nystrom, 15-Feb-05, This document describes a general EAP method suitable for use with One-Time Password (OTP) tokens, in particular tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X and IKEv2. "Subpoenas in the IETF: Procedures", Harald Alvestrand, 15-Feb-05, This document describes a proposal for the IETF's procedures for handling subpoenas served on the IETF. This is an adaptation of the ad-hoc procedures that the IESG has applied for the last two such events. "Session retention during SIP INVITE/Replaces", John Elwell, 15-Feb-05, This document proposes a method or retaining a session when a SIP dialog between two UAs is replaced by another dialog between those same two UAs in order to update dialog-related information such as identity. "Simple PPP over Ethernet (sPPPoE)", Jeff Haag, 15-Feb-05, This document defines a simple method for carrying PPP frames over Ethernet. PPP control packets are carried over a PPP ethertype, while IP packets may be carried as native IP over Ethernet. This has particular application in migration of ATM access networks to Ethernet. "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", Mark Townsley, 15-Feb-05, 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. "IP to VPLS Interworking", Cheng-Yin Lee, 16-Feb-05, This document describes how standard IP devices connected to existing and heterogeneous access technologies can communicate with each other as if they were connected to a common LAN segment. In particular, it describes the interworking of IP and VPLS. "NAT Behavioral Requirements for TCP", Nagendra Modadugu, 16-Feb-05, This document specifies requirements for NAT devices when handling TCP traffic. In order to arrive at the requirements, basic terminology regarding NAT TCP handling is defined. The purpose of this document is to provide a specification of TCP handling by NAT devices so that TCP-using applications can work consistently. "A Scheme of Mobile Firewall in Mobile IPv6", Ying Qiu, 16-Feb-05, More and more activities rely on mobile devices. It is an important issue on how to protect mobile users engaged in mobile services. Unfortunately, the conventional firewalls are in appropriate for mobile network. Furthermore, with a conventional firewall, an administrator of mobile nodes is not able to monitor / control dynamically the mobile node's activities when the mobile node roams. In this draft, we introduce a new concept of mobile personal firewall and propose a concrete scheme that matches mobile environment and exploits mobile network facilities. "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Christian Vogt, Jari Arkko, 16-Feb-05, 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 HIP Mobility with Concurrent IP-Address Tests", Christian Vogt, 16-Feb-05, End-host mobility with the Host Identity Protocol uses IP-address tests to protect against malicious packet redirection and third-party flooding. The tests cause handover signaling delays to increase by one round-trip time. This document proposes a credit-based strategy that allows peers to securely resume active communications after handover as soon as possible, and to pursue a concurrent IP-address test subsequently. The optimization thus eliminates the additional handover delay that IP-address tests entail. "Internet Code Point Assignments", Eric Gray, 16-Feb-05, This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 - particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. "Pseudo Wire Protection", Ping Pan, 16-Feb-05, This document describes a mechanism that helps to protect and recover user traffic when carried over pseudo-wires. The mechanism requires some minor modification to the existing pseudo-wire setup procedure, and is fully backward compatible. "GMPLS Deployment in Existing IP/MPLS networks", Zafar Ali, 16-Feb-05, One of the biggest challenges faced by GMPLS technology is “how it can be deployed” in a manner least impacting to existing IP/ MPLS networks. GMPLS architecture document lists [RFC3945] three different scenarios in which GMPLS technology can be deployed: overlay, augmented and integrated. Reference [GMPLS-mig] addresses the problem of migration from MPLS to GMPLS networks using the integrated model. This draft addresses the same problem space for augmented model and illustrates the applicability of augmented model in deploying GMPLS technology in existing IP/ MPLS networks. "MPLS/ GMPLS Interworking", Kenji Kumaki, 16-Feb-05, In order to deploy GMPLS technology in the existing IP/ MPLS networks, some interworking aspect of GMPLS/ MPLS needs to be addressed. One of the important aspects of MPLS/ GMPLS interworking is ability to effectively use GMPLS services in IP/ MPLS networks. This includes ability to specify GMPLS LSPs in signaling requests based on the type of the setup desired, as well as considerations for the operation aspects of using GMPLS LSPs. "Network initiated handover in fast mobile IPv6", Telemaco Melia, Rui Aguiar, 16-Feb-05, 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. Several proposals [5] and [6] were made in order to improve the handover delay to support real-time traffic, such as Voice over IP. These proposals keep a fundamental characteristic of Mobile IP, namely the handover process is triggered by the Mobile Terminal. This document expands this concept to cover situations where the handover has to be performed by network management issues, such as spectrum allocation. The document describes a control architecture based on the policy management. "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", Paul Funk, Simon Blake-Wilson, 16-Feb-05, 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. "RADIUS Security Roadmap", Robert Moskowitz, 16-Feb-05, RADIUS has become the defacto protocol between network edge devices (e,g, dial NAS or Wireless AP) and a backend Authentication Server. In this environment the backend Server is often called a (RADIUS Server). RADIUS is gaining very broad penetration, even into homes, because of its use with wireless authentication. Because of the amount of deployed infrastructure already in place, we believe that RADIUS will not be supplanted by another authentication service in the foreseeable future. Because the widespread deployment in wireless has different infrastructure requirements than what is required for dialup, RADIUS requirements, especially trust between Edge devices and RADIUS Servers needs to be addressed. This document sets the requirements for RADIUS security and then sets forth technologies that will satisfy those requirements. "NENA Requirements for Emergency Call processing", Brian Rosen, Nadine Abbott, 16-Feb-05, The National Emergency Number Association (NENA)'s mission is to foster the technological advancement, availability, and implementation of a universal emergency telephone number system in North America. NENA has an active effort to develop a new architecture for emergency call handling known as 'i3' being developed in its Long Term Definition working group. The following requirements are a subset of the requirements of the i3 work which relate to ecrit work. NENA understands the global nature of the Internet, and is eager to work with the IETF to ensure that emergency call processing meets the needs of users in North America. "NENA Requirements for Extensions to PIDF-LO", Brian Rosen, Nadine Abbott, 16-Feb-05, The National Emergency Number Association (NENA)'s mission is to foster the technological advancement, availability, and implementation of a universal emergency telephone number system in North America. In our efforts to support emergency calls coming over the Internet, we have identified several issues with the present definition of the PIDF-LO object. We present our requirements to address these shortcomings. "SAML in Authorization Policies", Christian Guenther, 16-Feb-05, Rules of an authorization policy prescribe under which conditions an entity or subject has which permissions. Existing policies support identity-based authorization by matching the authenticated identity of the entity requesting access to a resource with the available policies. This document is about formulating policy rules that express conditions with respect to SAML assertions, thereby supporting non-identity-based authorization and anonymity. "Session Initiation Protocol Semi Regular Examples", Miki Hasebe, 16-Feb-05, This document gives examples of Session Initiation Protocol (SIP) semi-regular call flows. The elements in these call flows include SIP User Agents and Clients. The scenarios include SIP session establishment. Call flow diagrams and message details are shown. "Dynamic AS Re-Associaiton", Susan Hares, Pratik Bose, 16-Feb-05, This document provides a mechanism for Autonomous Systems within an AS Confederation to survive the disconnection to other AS within the AS confederation without dropping peers. When all links to the other AS in the Confederation break, this mechanism allows the AS to revert to local AS to continue communication with E-BGP peers. This mechanism has two parts: Capability signaling between the two parties at connection start to save two AS (internal and AS Confederation AS) and a mechanism to signal the switch between AS Confederation AS and internal AS. "Requirements for Firewall Configuration Protocol", Gabor Bajko, 16-Feb-05, This document defines requirements for a Firewall Configuration Protocol, has been produced by a number of 3GPP2 member companies and presents their view for the requirements to a next generation firewall configuration protocol. "BGP Point to Multipoint LSP", Satoru Matsushima, 23-Feb-05, This document specifies the way that is to make point to multipoint (p2mp) LSP using BGP. BGP update messages is used to notify to consult which is a p2mp LSP's ingress LSR and branch LSRs and indicate upstream of LSP with MPLS label information from downstream LSR. "LESS: Language for End System Services in Internet Telephony", Xiaotao Wu, Henning Schulzrinne, 17-Feb-05, In Internet telephony, end systems can take a large role in providing services, especially in networks without pre-configured infra-structure, such as peer-to-peer networks. Since we believe that end system services differ in their requirements from network services, we define a new service creation scripting language called the Language for End System Services (LESS). LESS inherits man characteristics from the Call Processing Language (CPL). It contains commands and events for direct user interaction and the control of media applications. This document defines the basic elements of LESS and several commonly used LESS extensions. "BFD Extensions for MPLS FEC mismatch detection", Zhai Suping, 18-Feb-05, 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 detecting the MPLS FEC mismatch. The proposal is based on the FEC mismatch mechanism of ITU-T Y.1713. The proposed solution covers the mpls network when use BFD as the fault detection mechanism. "SAML in Authorization Policies", Christian Guenther, 22-Feb-05, Rules of an authorization policy prescribe under which conditions an entity or subject has which permissions. Existing policies support identity-based authorization by matching the authenticated identity of the entity requesting access to a resource with the available policies. This document is about formulating policy rules that express conditions with respect to SAML assertions, thereby supporting non-identity-based authorization and anonymity. "IDN aware application implementation guideline", Yoshiro Yoneya, 23-Feb-05, Since IDN Standards [RFC3490-3492] were published, some of gTLDs and ccTLDs began IDN registration and resolution service. Furthermore, many major Web browsers became IDN aware. IDNs seem to be popularized soon. Meanwhile, IDN introduces huge number of characters which can represent domain name, so it increases human misreading of domain name with similar looking characters. This issue was discussed deeply during IDN standardization and service development, and as a result, JET Guideline [RFC3743] and ICANN IDN Guideline [ICANN-IDN] was published. Even if TLD registries comply such guidelines, bad-faith guys may use IDNs to deceive human eyes with similar looking characters. To protect users from such deceiver, implementation guideline for how to handle IDNs at the User Interface level is important. This document is intended to be such guideline for application implementers. "Securing OLSR Problem Statement", Thomas Clausen, Emmanuel Baccelli, 23-Feb-05, In this draft, we examine security issues related to proactive routing protocols for MANETs. Specifically, we investigate security properties of OLSR and describe possible attacks against the integrity of the network routing infrastructure. "Fast Handoff by L2 Trigger in MPLS-based Mobile IP Networks", Yujun Kuang, 25-Feb-05, This document extends the integration of Mobile IP (MIP) and Multi- Protocol Label Switch (MPLS) with Layer2 Triggers (L2T) to expedite handoff and route optimization procedures. In the proposal, MPLS acts as only a fast second layer switch technique to setup a connection-oriented communication network, while MIP or IP acts as a signaling protocol to operate, administrate and manage MPLS network. L2Ts in this proposal are introduced to trigger signaling process of rerouting, extension and recovery of label switch paths (LSP) rather than to trigger registration or binding update of new care-of address (CoA), in traditional MIP. Moreover, in the proposed architecture, IP-in-IP tunneling is replaced by LSPs to support mobility, which reduces packet overhead thus mitigates network burden and makes it easy to support quality-of-service (QoS) or class-of-service (CoS). Therefore, the proposed scheme is well suited for time-constrained or delay-sensitive applications. Next Steps in Signaling (nsis) ------------------------------ "Next Steps in Signaling: Framework", Robert Hancock, 13-Dec-04, The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on on existing work on signaling requirements, this document proposes an architectural framework for these 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 separate upper layers for each specific signaling application. "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, 22-Feb-05, 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, Xiaoming Fu, 1-Dec-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, 23-Feb-05, 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, 22-Feb-05, 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, 23-Feb-05, 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 design uses existing transport and security protocols under a common messaging layer, the General 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 transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signaling" framework. "QoS-NSLP QSpec Template", Jerry Ash, 18-Feb-05, The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs, which are derived initially from the IntServ and DiffServ QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. "Applicability Statement of NSIS Protocols in Mobile Environments", Sung-Hyuck Lee, 23-Feb-05, 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. "RMD-QOSM - The Resource Management in Diffserv QoS model", Attila Bader, 18-Feb-05, This document describes an NSIS QoS 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. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. RMD ingress edge nodes aggregate the requests and signal the aggregated requests through internal nodes along the data path to the egress edge nodes. Egress nodes reconstitute the original, disaggregated, requests and continue forwarding them along the data path towards the final destination. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Jon Callas, 23-Nov-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. "OPES SMTP Use Cases", Abbie Barbir, Martin Stecher, 10-Feb-05, This document describes OPES SMTP use cases and deployment scenarios. Operations & Management Open Area (opsarea) ------------------------------------------- "Guidelines for Authors and Reviewers of MIB Documents", C.M. Heard, 2-Feb-05, 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. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Framework for Operational Security Capabilities for IP Network Infrastructure", George Jones, 19-Jan-05, 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]. "Security Best Practices Efforts and Documents", Chris Lonvick, 24-Jan-05, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Operational Security Current Practices", Merike Kaeo, 15-Feb-05, This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. 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, 3-Jan-05, This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) Version 2 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, 10-Feb-05, 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, 21-Feb-05, This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. "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, 15-Feb-05, 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. "Multi-Topology (MT) Routing in OSPF", Peter Psenak, 23-Feb-05, This draft describes an 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 unicast traffic, multicast traffic, different classes of service, or in-band network management. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. "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. "OSPF for IPv6", Dennis Ferguson, 23-Feb-05, This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. 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, 30-Dec-04, This document defines the Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method, and it can be used on any link that can carry IP. PANA protocol specification covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. "PANA enabling IPsec based Access Control", Mohan Parthasarathy, 21-Dec-04, PANA (Protocol for carrying Authentication for Network Access) is a 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-Feb-05, 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, 29-Dec-04, PANA (Protocol for carrying Authentication for Network Access) 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 document 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 wireless LANs. "PANA Mobility Optimizations", Dan Forsberg, 18-Jan-05, This specification describes PANA optimizations for handling mobility. Proposed optimizations aim reducing protocol latency and signaling associated with PANA-based network access AAA. 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", Nidhi Bhaskar, 18-Feb-05, 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. "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. "PIM Sparse-Mode IETF Proposed Standard Requirements Analysis", Tom Pusateri, 23-Feb-05, This analysis provides supporting documentation to advance the Protocol Independent Multicast (PIM) Sparse-Mode routing protocol from the IETF Experimental status to Proposed Standard. PIM Sparse- Mode was first published as RFC 2117 in 1997 and then again as RFC 2362 in 1998. The protocol was classified as Experimental in both of these documents. The PIM Sparse-Mode protocol specification was then rewritten in whole in order to more fully specify the protocol. It is this new specification that is to be advanced to Proposed Standard. "Format for using PIM proxies", A Boers, 15-Feb-05, This document describes a generic TLV encoding format to be added to PIM. "The RPF Vector Proxy", IJsbrand Wijnands, 17-Feb-05, This document describes a use of the PIM Proxy as defined in draft-pim-proxy [Forthcoming] 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. 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, 28-Dec-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, 21-Feb-05, SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. "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, 10-Feb-05, 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)", Jim Schaad, 25-Jan-05, This document describes the Certificate Request Message Format (CRMF) syntax and semantics. 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. This document does not define a certificate request protocol "Certificate Management Messages over CMS", Michael Myers, Xiaoyi Liu, Jim Schaad, Jeff Weinstein, 14-Feb-05, This document defines the base syntax for CMC, a Certificate Management protocol using CMS (Cryptographic Message Syntax). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Crytpography Standard), and 2. The need in S/MIME (Secure MIME) for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. "CMC Transport", Jim Schaad, 15-Feb-05, This document defines a number of transport mechanisms that are used to move [CMC] messages. The transport mechanisms described in this document are: HTTP, file, mail and TCP. "CMC Extensions: Server Side Key Generation and Key Escrow", Jim Schaad, 1-Feb-05, This document defines a set of extensions to the CMC (Certificate Management over CMS) protocol that address the desire for having two additional services: 1) Server side generation of keys, 2) server-side escrow and subsequent recovery of key material. These services are provided by the definition of additional control statements within the CMC architecture. "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. "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, 7-Jan-05, 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. "Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile.", Serguei Leontiev, 8-Feb-05, This document describes identifiers and appropriate parameters for the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, and also ASN.1 encoding scheme for digital signatures and public keys, used in Internet X.509 Public Key Infrastructure (PKI). This specification extends [RFC3279], 'Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' and, correspondingly, [RFC3280], 'Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile'. All implementations of this specification MUST also satisfy the requirements of [RFC3280]. "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. "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", Russell Housley, Tim Moore, 25-Jan-05, This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. "Internet X.509 Public Key Infrastructure Authority Information Access CRL Extension", Stefan Santesson, Russell Housley, 26-Jan-05, This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation Lists (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. Path MTU Discovery (pmtud) -------------------------- "Path MTU Discovery", Matt Mathis, 22-Feb-05, 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. "Accommodating an MTU of 1500 in PPPoE", John Fitzgibbon, 28-Jan-05, Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC 2516, mandates a maximum negotiated MRU of 1492. This memo proposes relaxing that restriction to allow a maximum negotiated MRU of 1500. This can be achieved by treating the PPPoE Header and Protocol ID as part of the Ethernet Header, taking advantage of the fact that most network devices have buffers for the Ethernet Header and Payload that are at least 1522 octets in size. To aid backward compatability, the proposal recommends testing the link with MRU-sized Echo-Request packets if an MRU greater than 1492 has been assumed or negotiated. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Nick Duffield, 5-Jan-05, 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, 17-Feb-05, 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, 18-Feb-05, This memo defines managed objects for sampling and filtering techniques for IP packet selection. 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. Pseudo Wire Emulation Edge to Edge (pwe3) ----------------------------------------- "SONET/SDH Circuit Emulation over Packet (CEP)", Andrew Malis, 21-Feb-05, 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 MPLS Networks", Luca Martini, 21-Feb-05, An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an MPLS network. This enables service providers to offer "emulated" ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudo wire. 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, 21-Feb-05, Layer 2 services (such as Frame Relay, ATM, ethernet) can be "emulated" over an 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 a 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. "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, 11-Feb-05, This document defines a generalized method of performing fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) protocols and services. "Encapsulation Methods for Transport of Frame Relay Over MPLS Networks", Luca Martini, Claude Kawa, 21-Feb-05, 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 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. The second mode is known as port mode or many-to-one mapping mode. "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, 22-Feb-05, This document defines the specific requirements for edge-to-edge-emulation of circuits carrying Time Division Multiplexed digital (TDM) signals of the Plesiochronous Digital Hierarchy) (PDH) as well as the Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", Luca Martini, Mark Townsley, 21-Feb-05, 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, 3-Feb-05, 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, 21-Feb-05, 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, 31-Jan-05, 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, 17-Feb-05, This document describes methods for structure-aware transport of TDM traffic over packet switched networks using pseudowires. "Managed Objects for TDM over Packet Switched Network (PSN)", Orly Nicklass, 3-Feb-05, 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, 21-Feb-05, The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for PWE3 ATM cell encapsulation. "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, 21-Feb-05, This document specifies the mapping of defect states between a Pseudo Wire and the Attachment Circuits (AC) of the end-to-end emulated service. This document covers the case whereby the ACs and the PWs are of the same type in accordance to the PWE3 architecture [PWEARCH] such that a homogenous PW service can be constructed. "PWE3 Control Word for use over an MPLS PSN", Stewart Bryant, 22-Feb-05, 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, 23-Feb-05, 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. "RADIUS Extension for Digest Authentication", Baruch Sterman, 21-Feb-05, Several protocols use the authentication mechanisms of the Hypertext Transfer Protocol, HTTP. This document specifies an extension to the Remote Authentication Dial In User Service (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. "Chargeable User Identity", Farid Adrangi, 21-Feb-05, This document describes a new RADIUS attribute, Chargeable User Identity. This attribute can be used by a home network to identity a user for the purpose of roaming transactions that occur outside of the home network. Resource Allocation Protocol (rap) ---------------------------------- "COPS Over TLS", Jesse Walker, Amol Kulkarni, 8-Feb-05, 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, 12-Jan-05, 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, 21-Feb-05, 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, 2-Feb-05, 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, 4-Feb-05, 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, 11-Feb-05, 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-Dec-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, 6-Jan-05, 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, 2-Feb-05, 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, 2-Feb-05, This memo specifies two transport mappings of the Real-time Application Quality of Service Monitoring (RAQMON) information model defined in [RAQMON-FRAMEWORK] 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). "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) ---------------------------------- "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. "Raptor Forward Error Correction", Michael Luby, 15-Feb-05, This document describes the systematic Raptor forward error correction code and its application to reliable delivery of data objects. 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, 23-Feb-05, 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, 17-Jan-05, 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]. "Formal Notation for Robust Header Compression (ROHC-FN)", Ghyslain Pelletier, 23-Feb-05, This document defines ROHC-FN: a formal notation to unambiguously specify header compression field encodings, when defining new profiles within the ROHC (RFC3095 [4]) framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles, and can thereby help simplifying future profile development work. "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, 18-Feb-05, This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. "SigComp Users' Guide", Mark West, Abigail Surtees, 18-Feb-05, This document provides an informational guide for users of the SigComp protocol. The aim of the document is to assist users when making SigComp implementation decisions; for example the choice of compression algorithm and the level of robustness against lost or misordered packets. "RObust Header Compression (ROHC):Context Replication for ROHC Profiles", Ghyslain Pelletier, 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, 15-Feb-05, 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, 17-Feb-05, 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. "SigComp Torture Tests", Abigail Surtees, Mark West, 15-Feb-05, This document provides a set of 'torture tests' for implementers of the SigComp protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. 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, 1-Dec-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, 5-Jan-05, 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. "BGP Security Requirements", Blaine Christian, 21-Feb-05, The security of BGP is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routed system, is more complex. This document describes a set of requirements for securing BGP, including securing peering relationships between BGP speakers, and authenticating the routing information carried within BGP. Reliable Server Pooling (rserpool) ---------------------------------- "Architecture for Reliable Server Pooling", Michael Tuexen, 22-Feb-05, 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, 22-Feb-05, 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, 21-Feb-05, 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, 21-Feb-05, 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, 21-Feb-05, 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, 7-Jan-05, 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 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. Resource Reservation Setup Protocol (rsvp) ------------------------------------------ "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. 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, 21-Feb-05, This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node or shared risk link group (SRLG). The goal of this technology is to reduce the micro-looping and packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "The Anonymous SASL Mechanism", Kurt Zeilenga, 22-Feb-05, 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, 22-Feb-05, 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, 17-Feb-05, 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) 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, 18-Feb-05, SSH is a protocol for secure remote login and other secure network services over an insecure network. "SSH Authentication Protocol", Chris Lonvick, 18-Feb-05, 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, 18-Feb-05, 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, 18-Feb-05, SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. "Generic Message Exchange Authentication For SSH", Martin Forssen, Frank Cusack, 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. "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, 18-Feb-05, 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. 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. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Mail Filtering Language: Variables Extension", Kjetil Homme, 4-Feb-05, In advanced filtering rule sets, it is useful to keep state or configuration details across rules. This extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. "SIEVE Email Filtering: Spamtest and Virustest Extensions", Cyrus Daboo, 3-Feb-05, The SIEVE email filtering language "spamtest", "spamtestpercent" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. "Sieve Mail Filtering Language: Body Extension", Jutta Degener, 7-Feb-05, This document defines a new primitive for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. "Sieve Mail Filtering Language: Editheader Extension", Jutta Degener, 7-Feb-05, This document defines two new actions for the "sieve" language that add and delete email header fields. "IMAP flag Extension", Alexey Melnikov, 8-Feb-05, Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords. "Sieve Email Filtering -- Subaddress Extension", Ken Murchison, 8-Feb-05, On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. 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, 23-Feb-05, 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, 23-Feb-05, 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. This document obsoletes RFC 3057. "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, 3-Jan-05, 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, 21-Feb-05, 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, 9-Feb-05, 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, 25-Jan-05, 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, 9-Feb-05, 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, 23-Feb-05, 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, 21-Feb-05, 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, 22-Feb-05, 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, 14-Jan-05, 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, 14-Jan-05, 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, 22-Feb-05, 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. "Presence Authorization Rules", Jonathan Rosenberg, 23-Feb-05, 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, 22-Feb-05, 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, 23-Feb-05, This document defines the underlying presence data model and 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. "Partial Publication of Presence Information", Mikko Lonnfors, 22-Feb-05, 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. "An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, 16-Feb-05, 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. 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, 31-Jan-05, 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, Redirect and Registrar servers. "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 16-Feb-05, 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 (SCTP) as a Transport for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 4-Feb-05, This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP (Session Initiation Protocol) 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. "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, 16-Feb-05, The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, 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, 18-Jan-05, This document 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 document defines a new optional SIP header, History-Info, for capturing the history information in requests. "Communications Resource Priority for the Session Initiation Protocol (SIP)", Henning Schulzrinne, James Polk, 22-Feb-05, 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. "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, 23-Feb-05, 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. "Problems identified associated with the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 4-Jan-05, 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, 4-Jan-05, 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. "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. "Suppression of Session Initiation Protocol REFER Method Implicit Subscription", Orit Levin, 21-Feb-05, This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP extension tag 'norefersub' is defined to indicate support for this extension. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Session Initiation Protocol Service Examples", Alan Johnston, Robert Sparks, 14-Feb-05, This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join headers. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, 22-Feb-05, This document defines a framework and requirements for multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals which embody the spirit of SIP applications as used on the Internet. "Best Current Practices for NAT Traversal for SIP", Chris Boulton, Jonathan Rosenberg, 21-Feb-05, 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. "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 23-Nov-04, This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user, an receive notifications about the changes in state of INVITE initiated dialogs that the user is involved in. "A Session Initiation Protocol (SIP) Event Package for Conference State", Jonathan Rosenberg, 22-Feb-05, 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. "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, 23-Feb-05, 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, 30-Nov-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. "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, 23-Feb-05, 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. "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, 29-Dec-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). "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 16-Feb-05, This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications, and defines a new Refer-To header field parameter and option tag in support of that framework. 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, 9-Dec-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. "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. "Framework for Transcoding with the Session Initiation Protocol", Gonzalo Camarillo, 22-Feb-05, This document defines a framework for transcoding with SIP. This framework includes how to discover the need of transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed; the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "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. "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", Jon Peterson, 17-Feb-05, This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol. While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. "Session Initiation Protocol (SIP) Session Policies - Document Format and Session-Independent Delivery Mechanism", Volker Hilt, 14-Feb-05, This draft defines a delivery mechanism for SIP session policies that is independent of a specific SIP session. It also defines the Basic Session Policy Format (BSPF), which is a minimal, XML-based format for session policies. "Requirements and Framework for Session Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List Services", Gonzalo Camarillo, Adam Roach, 2-Dec-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. "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Alan Johnston, 2-Dec-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, 2-Dec-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 MESSAGE 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, 11-Jan-05, 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, 2-Dec-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 Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. "Certificate Management Service for The Session Initiation Protocol (SIP)", Cullen Jennings, Jon Peterson, 22-Feb-05, This draft defines a Credential Service that allows SIP User Agents to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service. The Credential Service also allows users to store and retrieve their own certificates and private keys. "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, 21-Feb-05, 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. "The Session Initiation Protocol (SIP) and Spam", Jonathan Rosenberg, 14-Feb-05, 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. 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). "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS)", Serguei Leontiev, 7-Feb-05, This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption arbitrary message contents. "Certificate extension for S/MIME Capabilities", Stefan Santesson, 9-Feb-05, 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. "Enhanced Security Services for S/MIME", Jim Schaad, 29-Nov-04, This document describes the structures and procedures necessary to provide a number of additional security services for S/MIME. These services are: - signed receipts - security labels - secure mailing lists - signing certificate validation These services can be used by any CMS (Cryptographic Message Syntax) based protocol. Configuration Management with SNMP (snmpconf) --------------------------------------------- "Policy Based Management MIB", Steven Waldbusser, Jon Saperia, Thippanna Hongal, 21-May-04, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of SNMP infrastructures as well as a scripting language and a script execution environment. Speech Services Control (speechsc) ---------------------------------- "Requirements for Distributed Control of ASR, SI/SV and TTS Resources", David Oran, 29-Jan-04, This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to-speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. "Media Resource Control Protocol Version 2(MRCPv2)", Saravanan Shanmugham, 22-Feb-05, 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 and Signed syslog Messages", John Kelsey, Jon Callas, 23-Nov-04, This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. "The syslog Protocol", Rainer Gerhards, 18-Feb-05, This document describes the syslog protocol which is used to convey event notification messages. This protocol utilizes a layered architecture, which enables use of any number of transport protocols for transmission of syslog messages. It also provides a message format which allows vendor-specific extensions to be provided in a structured way. "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, 17-Feb-05, This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP's loss recovery algorithms treat the receipt of three duplicate acknowledgments as an implicit indication of congestion in the network. This is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to disambiguate true segment loss from segment reordering. In addition, we specify a change to TCP's congestion reaction decision point, as well (but, do not require such a change to use NCR). This document specifies the changes to TCP, as well as the costs and benefits of these modifications. "Transmission Control Protocol security considerations", Randall Stewart, 23-Nov-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, Markku Kojo, 18-Nov-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, 28-Jan-05, 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. "Defending TCP Against Spoofing Attacks", Joseph Touch, 14-Feb-05, Recent analysis of potential attacks on core Internet infrastructure indicates 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 or between web servers and well-known large-scale caches, 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. Internet Traffic Engineering (tewg) ----------------------------------- "Protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering", Francois Le Faucheur, 21-Dec-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, 14-Dec-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, 17-Dec-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, 14-Dec-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, 17-Nov-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, 7-Dec-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]. "Using OpenPGP keys for TLS authentication", Nikos Mavroyanopoulos, 26-Jan-05, This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. "The TLS Protocol Version 1.1", Tim Dierks, Eric Rescorla, 8-Dec-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, Hannes Tschofenig, 23-Feb-05, 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. "Transport Layer Security (TLS) Extensions", Simon Blake-Wilson, 29-Dec-04, This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. Internet Open Trading Protocol (trade) -------------------------------------- "XML Voucher: Generic Voucher Language", Ko Fujimura, Masayuki Terada, 14-Jan-05, 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, 22-Feb-05, 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, 23-Feb-05, 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, 23-Feb-05, 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, 22-Feb-05, 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. "Implementing MLPP for Voice and Video in the Internet Protocol Suite", Fred Baker, James Polk, 8-Feb-05, The Defense Information Systems Agency of the United States Department of Defense, with its 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 two documents: "Extending the Session Initiation Protocol Reason Header to account for Preemption Events", "Communications Resource Priority for the Session Initiation Protocol". "A Resource Reservation Extension for the Reduction of Bandwidth of a Reservation Flow", James Polk, Subha Dhesikan, 10-Feb-05, This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations or other forms of RSVP tunnels. "Configuration Guidelines for DiffServ Service Classes", Jozef Babiarz, 14-Feb-05, 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) mechanism. 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. Usenet Article Standard Update (usefor) --------------------------------------- "News Article Format", Charles Lindsey, 23-Nov-04, This document specifies the syntax of network news (Netnews) 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, 16-Feb-05, 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. "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-Feb-05, This document describes a procedure that can be used to renumber a network from one prefix to another. 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. "IPv6 Enterprise Network Analysis", Jim Bound, 10-Jan-05, 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 notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a dual IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. "Reasons to Move NAT-PT to Experimental", Cedric Aoun, Elwyn Davies, 3-Feb-05, This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document requests that the IETF reclassifies RFC 2766 from Standards Track to Experimental status. "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman Asadullah, 14-Feb-05, This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence 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. 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, 18-Feb-05, 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, 18-Feb-05, The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. 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 VRRP over IPv4 and IPv6", Kalyan Tata, 12-Jan-05, 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. "Timer Enhancements to Reduce Failover Times for the Virtual Router Redundancy Protocol for IPv4", Robert Hott, 15-Feb-05, This memo identifies a new requirement for the Virtual Router Redundancy Protocol (VRRP) for IPv4 and proposes candidate implementation approaches to address this requirement. 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(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The new requirement is for VRRP for IPv4 to support sub-second fail over from the Master. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources", Jim Whitehead, 10-Feb-05, 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. "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, 17-Feb-05, 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, 9-Feb-05, WebDAV servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) 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. "Requirements for Floor Control Protocol", Henning Schulzrinne, 3-Jan-05, 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, 10-Jan-05, 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.