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. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", Gabriel Montenegro, Nandakishore Kushalnagar, 13-Jul-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. "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", Nandakishore Kushalnagar, Gabriel Montenegro, 13-Jul-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. 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, 18-Mar-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. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", Clay Sikes, 26-May-05, 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. "Definitions of Managed Objects for New Generation Asymmetric Digital Subscriber Lines (NG-ADSL)", Moti Morgenstern, 6-Jun-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 parameters of "Asymmetric Digital Subscriber Line" family of interface types, especially including ADSL, ADSL2, and ADSL2+. Atom Publishing Format and Protocol (atompub) --------------------------------------------- "The Atom Syndication Format", Robert Sayre, Mark Nottingham, 14-Jul-05, This document specifies Atom, an XML-based Web content and metadata syndication format. "The Atom Publishing Protocol", Robert Sayre, Joe Gregorio, 10-May-05, 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-06.txt). "Atom Feed Autodiscovery", Phil Ringnalda, Mark Pilgrim, 10-May-05, This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the element. Audio/Video Transport (avt) --------------------------- "Tunneling Multiplexed Compressed RTP ('TCRTP')", B Thompson, Tmima Koren, Dan Wing, 13-Sep-04, This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path to reduce the bandwidth used when multiple RTP streams are carried over that path. "An RTP Payload Format for Generic FEC", Adam Li, 28-Jun-05, This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation, and it is a generalized algorithms that includes Uneven Level Protection (ULP). The payload format described in this draft allows end systems to apply protection using arbitrary protection lengths and levels, in addition to using arbitrary protection group sizes. It enables complete recovery or partial recovery of the critical payload and RTP header fields depending on the packet loss situation. This scheme is completely backward compatible with non-FEC capable hosts. Those receivers that do not know about FEC can simply ignore the protection data. This specification obsoletes RFC 2733 and RFC 3009. "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 Unicast Feedback", Julian Chesterfield, 20-Jul-05, This document specifies an extension 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 available or not desired. 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, 8-Mar-05, 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, 20-Jul-05, This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, otherwise better known as: JPEG 2000. JPEG 2000 features are considered and there are provisions in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode one way and decode many different ways. Extending from a single 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, 15-Jun-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 sets up an IANA registry to which other event code assignments may be added. This memo specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, all compliant implementations taking part in out- of-band negotiations of media stream content MUST indicate what events they support. Aside from clarifications to the original document, this adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. "RTP Payload Format for AC-3 Audio", Jason Flaks, 28-Jun-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. "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Joerg Ott, Elisabetta Carrara, 20-Jul-05, An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 29-Jun-05, 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 network musical performance) 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, 29-Jun-05, 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 Format for H.261 Video Streams", Roni Even, 27-Apr-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, 27-Apr-05, 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 Format for 3GPP Timed Text", Jose Rey, Y Matsui, 13-Jun-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, 18-Jul-05, This memo specifies a profile called "RTP/AVPCC" for the use of the real-time transport protocol (RTP) and its associated control protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is an equation based congestion control scheme for unicast flows operating in a best effort Internet environment. This profile provides RTP flows with the mechanism to use congestion control in best effort IP networks. "RTP Payload Format for BroadVoice Speech Codecs", Juin-Hwey Chen, 18-Apr-05, This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs developed by Broadcom Corporation. The document also provides specifications for the use of BroadVoice with MIME and SDP. "RTP Payload Format for ATRAC Family", Matthew Romaine, 8-Jul-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 also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. "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, 27-Apr-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. "RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base", Alan Clark, Amy Pendleton, 14-Jul-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). "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, 15-Jun-05, 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 media type. It defines the syntax and the semantics of the SDP parameters needed to support far end camera control protocol using H.224. "Definition of Events For Modem, FAX, and Text Telephony Signals", Henning Schulzrinne, 11-Jul-05, This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-09) 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 Payload Format for Priority & Header Processing RTP Payload Format for JPEG 2000 Video Streams BEAM extension", Andrew Leung, 20-Jul-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 for the payload header. There is an additional MIME and SDP marker signaling for implementations of this document. "A No-Op Payload Format for RTP", Flemming Andreasen, 26-May-05, This document defines an no-op payload format for the Real-time Transport Protocol (RTP), and a mechanism to request transmission of an early RTCP report. This can be used to verify RTP connectivity and to keep Network Address Translator (NAT) bindings and Firewall pinholes open. "Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec", Sassan Ahmadi, 8-Jun-05, This document is an addendum to RFC xxxx, which specifies the real-time transport protocol for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document contains the information related to the new operating mode of VMR-WB. All provisions, restrictions, use cases, features, etc. that are specified in RFC xxxx are applicable to the new operating mode without any exception. No new media type registration is included in this document as the new VMR-WB mode, defined in this document, will use the same media type specified in RFC xxxx (i.e., audio/VMR-WB). Note that the RFC xxxx was developed with sufficient flexibility for future extensions and thereby it allows the addition of new operating modes without any impacts on the interoperability of terminals supporting different versions of the VMR-WB standard. "MIME Type Registration of RTP Payload Formats", Stephen Casner, Philipp Hoschka, 13-Jul-05, This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Simple Traversal of UDP Through Network Address Translators (NAT) (STUN)", Jonathan Rosenberg, 20-Jul-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, 19-Jul-05, This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also 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. "IGMP Proxy Behavior", Dan Wing, 16-May-05, This document describes the behavior of an IGMP Proxy, as implemented in NAT devices, and places requirements on such devices. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Bidirectional Forwarding Detection Management Information Base", Thomas Nadeau, Zafar Ali, 8-Jul-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 for modeling Bidirectional Forwarding Detection (BFD) protocol [BFD]. "BFD For MPLS LSPs", Rahul Aggarwal, 18-Jul-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, 12-Jul-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, 12-Jul-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, 12-Jul-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. "Generic Application of BFD", Dave Katz, David Ward, 15-Jul-05, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol in environments not specifically documented in other specifications. 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, 12-Jul-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 mechanisms. "Benchmarking Terminology for Resource Reservation Capable Routers", Krisztian Nemeth, 21-Jul-05, The primary 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. "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. "Terminology for Benchmarking IPsec Devices", Michele Bustos, 21-Jul-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 [RFC1242], [RFC2544], [RFC2285] 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, 27-Jun-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", Brent Imhoff, Scott Poretsky, 27-Jun-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, 27-Jun-05, This draft provides considerations for IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence benchmarking 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, Shankar Rao, 18-Jul-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 Guidelines for Accelerated Stress Benchmarking", Shankar Rao, Scott Poretsky, 18-Jul-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 Guidelines 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]. These guidelines can be used as the basis for additional methodology documents that benchmark specific network technologies under accelerated stress. "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", David Newman, Timmons Player, 22-Jun-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. "Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities", Scott Poretsky, Shankar Rao, 14-Jul-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 when subjected to instability with eBGP-4. Descriptions of Test Topology, Benchmarks and Reporting Format are provided in addition to procedures for conducting various test cases. This methodology is based upon the accelerated stress methodology guidelines [6] and is to be used with the companion terminology document [4]. "Methodology for Benchmarking Accelerated Stress with Operational Security", Scott Poretsky, Shankar Rao, 14-Jul-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 when subjected to instability as described in [7]. Descriptions of test topology, benchmarks and reporting format are provided in addition to procedures for conducting various test cases. This methodology is based upon the accelerated stress methodology guidelines [6] and is to be used with the companion terminology document [4]. 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, 1-Aug-05, This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", Vivian Ngai, Ernest Bell, 1-Aug-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 two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) 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 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM) and P802.1v (TM). 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 supplements RFC 1493bis, and obsoletes RFC 2674. (NOTE for RFC Ed.: all instances of 'RFC 1493bis' will need to be updated to reflect the new RFC number for draft-ietf-bridge- bridgemib-smiv2-10.txt) Better-Than-Nothing Security (btns) ----------------------------------- "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, 5-Jul-05, The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, currently requires authentication via IKE of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, pre-shared certificates and associated asymmetric keys, or the use of Kerberos. The need for authentication information and its associated identities between network layer entities can be a significant obstacle to deploying network security. This document explains the rationale for extending to the Internet network security suite to enable use of IPsec security mechanisms without full IKE authentication. These extensions are intended to protect communication "better than nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate and can achieve their intended benefit. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "Light Weight Access Point Protocol", Pat Calhoun, 6-Jul-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. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. "CAPWAP Tunneling Protocol (CTP)", Inderpreet Singh, 5-Jul-05, With the overwhelming choice of proprietary implementations of centralized control and management of wireless access points and access controllers there is a great demand for a standard protocol and architecture that enables the deployment of large scale wireless networks. This document describes the CAPWAP Tunneling Protocol, a protocol that allows for the centralized control and provisioning of a large number of wireless access points from access controllers. It is supported by an architecture where the MAC layer of the RF technology is terminated within the AP. This allows for the protocol to be extensible to multiple radio technologies. It assumes an IP connection between the access points and access controllers and has signaling primitives to enable wireless station mobility between access points. Therefore, seamless Layer 3 subnet mobility is seamlessly enabled by this protocol. "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", S Govindan, 21-Jun-05, This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address Architecture, Operation, Security and Network Operator Requirements that are necessary to enable interoperability among wireless local area network (WLAN) devices of alternative designs. "Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 27-Jun-05, The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP). "SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 1-Jun-05, The CAPWAP problem statement [3] describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another. "LWAPP Self Evaluation", Pat Calhoun, 28-Jun-05, The IETF's CAPWAP working group has requested that all candidate protocols submitted must provide a document which evaluates how each protocol meets the objectives. This document describes in detail how the LWAPP protocol meets the CAPWAP objectives. "Evaluation of Wireless LAN Control Protocol (WiCoP)", Saravanan Govindan, 7-Jun-05, The Wireless LAN Control Protocol (WiCoP) enables control of WLANs made of different types of wireless termination points. It addresses an immediate concern for WLAN deployments. This draft presents an evaluation of WiCoP with respect to the CAPWAP Objectives. It also highlights WiCoP's advantges over other CAPWAP candidate protocols. "Evaluation of CAPWAP Tunneling Protocol (CTP)", Paulo Francisco, 28-Jun-05, This document presents a self evaluation of the CAPWAP Tunneling Protocol (CTP) with respect to the requirements presented in the CAPWAP Objectives draft. This work is to aid in the official working group evaluation of the candidate protocols for CAPWAP. "SLAPP Evaluation", Partha Narasimhan, 21-Jun-05, The CAPWAP Working Group (WG) is currently looking into defining a protocol that would enable interoperability in an IEEE 802.11 based wireless local area network (WLAN) comprised of Wireless Termination Points (WTP) and Access Controllers (AC) belonging to different vendors. This document presents a self-review of Simple Light Access Point Protocol (SLAPP), one of the candidate protocol proposals submitted to the CAPWAP WG for consideration as a CAPWAP protocol. The WG has requested that the authors of all candidate proposals to provide a document which evaluates how their submission meets the objectives, taxonomy, and problem statement. 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 Multiprotocol Label Switching (GMPLS) Management", Thomas Nadeau, 2-Jun-05, This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol 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, 2-Jun-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, 2-Jun-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 (LSR). "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", Eric Mannie, Dimitri Papadimitriou, 30-Mar-05, 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, 30-Mar-05, 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, 19-Jul-05, The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SLRGs) can be excluded is also specified in this document. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", Jonathan Lang, Bala Rajagopalan, 30-Mar-05, 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, 20-Jul-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 RSVP-TE", Adrian Farrel, 24-May-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 recovery 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 Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", Jonathan Lang, 5-Apr-05, This document describes protocol specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that is protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document. "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-May-05, This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement 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. "A Framework for Inter-Domain MPLS Traffic Engineering", Adrian Farrel, 7-Jul-05, This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) 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 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP)", JP Vasseur, 25-May-05, This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering LSPs. A loosely routed LSP is defined as one that does not contain a full explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no ERO, with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR). This document proposes a mechanism that allows a TE LSP head-end LSR to trigger a new path re- evaluation on every hop having a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path in use) or that the TE LSP must be reoptimized because of some maintenance required on the TE LSP path. The proposed mechanism applies to the cases of intra and inter-domain (IGP area or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. "A Transport Network View of the Link Management Protocol", Don Fedyk, 6-May-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, 19-Jul-05, This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. 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 RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object 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 RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. "Inter domain GMPLS Traffic Engineering - RSVP-TE extensions", Arthi Ayyangar, JP Vasseur, 19-Jul-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. "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, 21-Jun-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 data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control 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 wider contexts than ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply to allows the GMPLS terms to be applied within the ASON context. "Label Switched Path Stitching with Generalized MPLS Traffic Engineering", Arthi Ayyangar, JP Vasseur, 15-Jul-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. "A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", JP Vasseur, 15-Apr-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. "Evaluation of existing Routing Protocols against ASON Routing Requirements", Dimitri Papadimitriou, 20-Jul-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). This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. "Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks", Kohei Shiomoto, 21-Jun-05, This document explains and clarifies the use of addresses 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 (LSRs) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document recommends a proper approach 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 solutions. It finally discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "IRIS - An Address Registry (areg) Type for the Internet Registry Information Service", A Newton, 15-Jul-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, 8-Jun-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 Transfer Protocol for the the Internet Registry Information Service", Andrew Newton, 14-Jul-05, This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. "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. "A Common Schema for Internet Registry Information Service Transfer Protocols", Andrew Newton, 14-Jul-05, This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. "XML Pipelining with Chunks for the Information Registry Information Service", Andrew Newton, 14-Jul-05, This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transfered between clients and servers using chunks to achieve pipelining. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control", Sally Floyd, Eddie Kohler, 11-Mar-05, 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. "Problem Statement for DCCP", Sally Floyd, 24-Jun-05, This document gives the problem statement underlying the development of an unreliable transport protocol incorporating end-to-end congestion control. This is also the problem statement underlying the development of DCCP, the Datagram Congestion Control Protocol. DCCP implements a congestion- controlled, unreliable flow of datagrams suitable for use by applications such as streaming media or on-line games. "Profile for DCCP Congestion Control ID 3:TFRC Congestion Control", Jitendra Padhye, Sally Floyd, Eddie Kohler, 11-Mar-05, This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly send rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. "Datagram Congestion Control Protocol (DCCP) User Guide", Thomas Phelan, 27-Apr-05, This document is an informative reference discussing strategies for using DCCP as the transport protocol for various applications. The focus is on how applications can make use of the capabilities, and deal with the idiosyncrasies, of DCCP. Of particular interest is how UDP applications, which have traditionally ignored congestion control issues, can adapt to a congestion controlled transport. "Datagram Congestion Control Protocol (DCCP)", Eddie Kohler, 11-Mar-05, 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", Sally Floyd, Eddie Kohler, 21-Jul-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 proposes 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. This variant is referred to in RFC 3448 as TFRC-PS, for applications that might vary their packet size in response to congestion. 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. Flows using the VoIP variant of TFRC compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with DropTail queues in units of bytes), the current VoIP variant of TFRC can receive considerably more than its share of the bandwidth. (We note however that in all scenarios the VoIP variant of TFRC is better, in terms of congestion in the network, than the same application in the absence of congestion control). "Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally Floyd, 21-Jul-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 introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with both the default TFRC and with the VoIP variant of TFRC. "Strategies for Streaming Media Applications Using TCP-Friendly Rate Control", Thomas Phelan, 22-Jul-05, This document discusses strategies for using streaming media applications with unreliable congestion-controlled transport protocols such as the Datagram Congestion Control Protocol (DCCP) or the RTP Profile for TCP Friendly Rate Control. Of particular interest is how media streams, which have their own transmit rate requirements, can be adapted to the varying and sometimes conflicting transmit rate requirements of congestion control protocols such as TCP-Friendly Rate Control (TFRC). Also explored is the resulting network behavior of streams using these strategies in competition with TCP-based streams, and the fairness between these streams and TCP-based streams. 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 FQDN Conflicts among DHCP Clients", Mark Stapp, Bernie Volz, 29-Jun-05, DHCP provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name to IP address and IP address to name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and describes a strategy for the use of the DHCID DNS resource record in resolving those conflicts. "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, 30-Jun-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. "DHCP Server-ID Override Suboption", Richard Johnson, 30-Jun-05, 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. "Subnet Allocation Option", Richard Johnson, 30-Jun-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. "Detecting Network Attachment (DNA) in IPv4", Bernard Aboba, 28-Jun-05, The time required to detect movement between networks, and to obtain (or continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses to define a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. "Authentication of DHCP Relay Agent Options Using IPsec", Ralph Droms, 26-May-05, 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", Bill Sommerfeld, Ted Lemon, 23-Jun-05, This document specifies the format that is to be used for encoding DHCPv4 client identifiers, so that those identifiers will be inter- changeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC2131 and RFC2132 with respect to the handling of DHCP client identifiers. "DHCP Option for Proxy Server Configuration", Senthil Balasubramanian, 13-Jul-05, This document defines a new Dynamic Host Configuration Protocol (DHCP) option, which can be used to configure Proxy Servers in TCP/IP for standard protocols like HTTP, FTP, NNTP, SOCKS, SNMP, SLL and etc. Proxy Servers provide controlled and efficient access to the Internet, include access control mechanisms for different types of user requests and cache 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, 13-Jul-05, 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 both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues, and identifies future work to be undertaken. "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. "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. "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. "DHCP Options for Broadcast and Multicast Control Servers", Kuntal Chowdhury, 3-Aug-05, This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for 3rd generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive broadcast and multicast service. Dynamic Host Configuration Protocol can be used to configure the MN to acccess a particular controller. This document defines the related options and option codes. "DHCPv6 Relay Agent Subscriber-ID Option", Bernie Volz, 8-Apr-05, 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. "DHCPv6 Relay Agent Remote ID Option", Bernie Volz, 8-Apr-05, 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. Distributed Management (disman) ------------------------------- "Event MIB", Ramanathan Kavasseri, Benoit Claise, 20-Jul-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 that can be used to manage and monitor MIB objects and take action through events. This document obsoletes RFC 2981. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. "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) ---------------------------------- "Goals of Detecting Network Attachment in IPv6", 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, 21-Jul-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 document provides a non-exhaustive catalogue of information available from well-known access technologies. "DNA with unmodified routers: Prefix list based approach", Erik Nordmark, JinHyeock Choi, 15-Jul-05, Upon establishing a new link-layer connection, a host determines whether a link change has occurred, that is, whether or not it has moved at layer 3 and therefor needs new IP configuration. This draft presents a way to robustly check for link change without assuming any changes to the routers. We choose to uniquely identify each link by the set of prefixes assigned to it. We propose that, at each attached link, the host generates the complete prefix list, that is, a prefix list containing all the valid 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 loss. "DNA solution framework", JinHyeock Choi, Erik Nordmark, 22-Apr-05, This draft captures the authors' opinions and is intended to serve as input to the discussion for the solution in the DNA WG. It presents a few assumptions for DNA solution. The draft proposes the solution to be based on 1) link identity, 2) RS/RA exchange formed so that a host can determine whether it has moved from a single RA, and 3) Quick delivery of an RA. The draft sketches what rough shape DNA solution could take, including the necessary interaction with Duplicate Address Detection and the Multicast Listener Discovery protocol. It also enumerate a few tasks to be worked on and issues to be resolved for efficient DNA solution. "Detecting Network Attachment in IPv6 - Best Current Practices for hosts.", Sathya Narayanan, 11-Jul-05, Hosts experiencing rapid link-layer changes may require efficient IP configuration change detection procedures than 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. This document details best current practice for Detecting Network Attachment in IPv6 hosts using existing Neighbor Discovery procedures. Since there is no explicit link identification mechanism in the existing Neighbor Discovery for IP Version 6, the document describes implicit mechanisms for identifying the current link. "Detecting Network Attachment in IPv6 - Best Current Practices for Routers", Sathya Narayanan, 5-Jul-05, Hosts experiencing rapid link-layer changes may require to do configuration change detection procedures more frequently than traditional fixed hosts. This document describes practices available to network deployers in order to support such hosts in Detecting Network Attachment in IPv6 networks. 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)", Bernard Aboba, 18-Jul-05, 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", David Blacka, 20-Jul-05, In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC 4034 [4], and RFC 4035 [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. "DSA Keying and Signature Information in the DNS", Donald Eastlake, 19-Jul-05, 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, 19-Jul-05, The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. "Elliptic Curve KEYs in the DNS", R Schroeppel, Donald Eastlake, 19-Jul-05, The standard method for storing elliptic curve cryptographic keys and signatures in the Domain Name System is specified. "Domain Name System (DNS) Case Insensitivity Clarification", Donald Eastlake, 20-Jul-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. "The Role of Wildcards in the Domain Name System", Edward Lewis, 7-Jul-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, 22-Jun-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 and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. "RFC 3597 Interoperability Report", Jacob Schlyter, 19-May-05, This memo documents the result from the RFC 3597 (Handling of Unknown DNS Resource Record Types) interoperability testing. "DNSSEC Hash Authenticated Denial of Existence", Ben Laurie, 29-Jun-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. A complete zone file can be used either directly as a source of probable e-mail addresses for spam, or indirectly as a key for multiple WHOIS queries to reveal registrant data which many registries (particularly in Europe) may be under strict legal obligations to protect. Many registries therefore prohibit copying of their zone file; however the use of NSEC RRs renders policies unenforceable. This document proposes a scheme which obscures original ownernames while permitting authenticated denial of existence of non-existent names. Non-authoritative delegation point NS RR types may be excluded. "Storing Certificates in the Domain Name System (DNS)", Simon Josefsson, 10-Jun-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). This document obsolete RFC 2538. "DNSSEC Experiments", David Blacka, 20-Jul-05, In the long history of the development of the DNS security extensions [1] (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. "Minimally Covering NSEC Records and DNSSEC On-line Signing", Samuel Weiler, Johan Ihren, 12-May-05, This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC4034. 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. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, 24-May-05, This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of possible DNSSECbis errata. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 11-Jul-05, Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, RR header bits, and AFSDB subtypes. "Derivation of DNS Name Predecessor and Successor", Geoffrey Sisson, Ben Laurie, 14-Jul-05, This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC-secured zone. Domain Name System Operations (dnsop) ------------------------------------- "Encouraging the use of DNS IN-ADDR Mapping", Daniel Senie, 3-Aug-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, 19-Jul-05, This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. "Identifying an Authoritative Name Server", David Conrad, 31-Mar-05, With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid. Existing ad hoc mechanisms for addressing this concern are not adequate. This document attempts to describe the common ad hoc solution to this problem, including its advantages and disadvantasges, and to characterize an improved mechanism. "Operational Considerations and Issues with IPv6 DNS", Alain Durand, 19-Jul-05, This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehaviour, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. "DNS Response Size Issues", Paul Vixie, Akihiro Kato, 21-Jul-05, With a mandated default minimum maximum message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit. "DNSSEC Operational Practices", R Gieben, Olaf Kolkman, 2-May-05, 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. "IPv6 Host Configuration of DNS Server Information Approaches", Jae-Hoon Jeong, 5-May-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 the deployment scenarios in four kinds of networks, such as ISP, Enterprise, 3GPP, and Unmanaged networks, considering multi-solution resolution. Therefore, this document will give the audience a guideline for IPv6 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, 19-Jul-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. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "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. "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", Terry Harding, Richard Scott, 7-Apr-05, This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content-types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. Entity MIB (entmib) ------------------- "Entity MIB (Version 3)", Keith McCloghrie, Andy Bierman, 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) ------------------------------- "IANA Registration for Enumservices email, fax, mms, ems and sms", Rudolf Brandner, 11-May-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, 1-Jul-05, 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, 10-May-05, 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, 19-Jul-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, 21-Jul-05, This document defines the forwarding element (FE) model used in the Forwarding and Control Element 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, RFC 3564 [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, 19-Jul-05, This specification documents the Forwarding and Control Element Separation protocol. This protocol is designed to be used between a Control Element and a Forwarding Element in a Routing Network Element. "TCP/IP based TML (Transport Mapping Layer) for ForCES protocol", Jon Maloy, 21-Jul-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. "ForCES Intra-NE Topology Discovery", Hormuzd Khosravi, 1-Apr-05, This document describes a mechanism for discovering inter-FE topology and topology maintenance. Such a mechanism is essential for all these elements in the set to behave as a single Network Element, as required by the ForCES architecture as well as to perform certain optimizations at the FE by making use of the topology. The discovery mechanism only operates during post-association phase of ForCES protocol. 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, 31-May-05, This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing 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, postal community names and building information. The option allows multiple renditions of the same address in different scripts and languages. "A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, 20-Jul-05, This document defines an authorization policy language for controling access to location information. It extends the authorization framework of the common policy markup language to provide location- specific access control. "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 Document Format for Expressing Privacy Preferences", Henning Schulzrinne, 20-Jul-05, This document defines a framework for authorization policies controling access to application specific data. This framework combines common location- and 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, 18-Jul-05, This document describes RADIUS attributes for conveying access network ownership and location information based on a civic and geospatial location format. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and addressed in this document. "Location Types Registry", Henning Schulzrinne, Hannes Tschofenig, 18-Jul-05, This document creates a registry for location types. The place types 'aircraft', 'airport', 'bus', 'automobile', 'residence', 'hotel', 'industrial', 'library', 'shopping-area', 'government-building', 'office', 'restaurant', 'school', 'watercraft', 'station', 'street', 'theater', 'hospital', 'train', 'truck', 'public', 'worship', 'convention center' and 'public-transport' are created with this document. Additional place types can be added on a 'First Come First Served' policy. "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Hannes Tschofenig, 19-Jul-05, The Presence Information Data Format Location Object (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 routing applications. To allow successfully interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the PIDF-LO. This document 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 location dependent routing to occur. Global Routing Operations (grow) -------------------------------- "BGP Communities for Data Collection", Dave Meyer, 21-Sep-04, BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network, and to its peers and customers. With the advent of large scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This document defines standard (outbound) communities and their encodings for export to BGP route collectors. "BGP MED Considerations", Danny McPherson, 8-Jun-05, The BGP MED attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, there are a number of issues which may arise when utilizing MEDs in dynamic or complex topologies. This document discusses implementation and deployment considerations regarding BGP MEDs and provides information which implementors and network operators should be familiar with. "BGP Wedgies", Tim Griffin, Geoff Huston, 10-Jun-05, 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, 20-Jul-05, As the Internet has grown, and as systems and networked services within enterprises have become 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. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. "Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", Tony Li, Vince Fuller, 13-Jun-05, This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original CIDR spec [RFC1519], with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. "MRT routing information export format", Larry Blunk, 6-Jul-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. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol", Robert Moskowitz, 23-Jun-05, This memo specifies the details of the Host Identity Protocol (HIP). HIP provides a rapid exchange of Host Identities (public keys) between hosts and uses a Sigma-compliant [REF] Diffie-Hellman key exchange to establish shared secrets between such endpoints. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP) [24], it provides encryption and/or authentication protection for upper layer protocols such as TCP and UDP, while enabling continuity of communications across network layer address changes. "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 Multihoming with the Host Identity Protocol", Pekka Nikander, 19-Jul-05, This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", Pekka Nikander, Julien Laganier, 14-Jul-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 Extension", Julien Laganier, Lars Eggert, 14-Jul-05, This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. "Using ESP transport format with HIP", Petri Jokela, 5-Jul-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). Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Managed Objects of EPON", Lior Khermosh, 11-Mar-05, 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 802.3-2004. The document contains a list of management entities based on the registers defined in the Institute of Electrical and Electronic Engineers, IEEE 802.3-2004 Annex 30A and mainly partitioned accordingly. "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", Edward Beili, 5-Apr-05, 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, 24-Mar-05, 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. "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", Edward Beili, 18-Apr-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 IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 3636. This memo extends that specification by moving MAU type object identities and some other relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module, first version of which is defined in this document. Thus, when the new MAU types are defined by IEEE, only the IANA MIB module needs to be modified, leaving the MAU MIB module unchanged. In addition, management information is added for the management of Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. This memo also obsoletes RFC 2668 and RFC 1515. Internet Architecture Board (iab) --------------------------------- "Internet Denial of Service Considerations", Eric Rescorla, Mark Handley, 21-Jul-05, This document provides an overview of possible avenues for denial-of- service attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. "Architectural Implications of Link Indications", Bernard Aboba, 5-Jul-05, This document describes the role of link indications within the Internet Architecture. While the judicious use of link indications can provide performance benefits, inappropriate 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, 8-Jun-05, This note discusses how to extend the DNS with new data for a new application. DNS extension discussion too often circulates around reuse of the TXT record. This document lists different mechanisms to accomplish the extension to DNS, and comes to the conclusion that the use of a new RR Type is the best solution. "What's in a Name: False Assumptions about DNS Names", Jonathan Rosenberg, 20-Jul-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. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. 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, 16-May-05, This document is an IAB (Internet Architecture Board) report on the role of the IRTF (Internet Research Task Force), both on its own and in relationsip to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. "Process for the IAB and IESG selection of IAOC members", Geoff Huston, Bert Wijnen, 8-Jun-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. "The IEEE 802/IETF Relationship", Bernard Aboba, 5-Jul-05, Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and AAA applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. 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, 14-Jul-05, 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, 14-Jul-05, 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", Yakov Rekhter, 6-Jul-05, This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. "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. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 14-Jul-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, this MIB defines objects that facilitate the manage- ment of the Border Gateway Protocol Version 4 (BGP4). "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 21-Jun-05, 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, 27-Jun-05, This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating 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, 5-Apr-05, 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", Dave 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. "Autonomous System Confederations for BGP", Paul Traina, 13-Jul-05, The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. "BGP-4 MIB 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, 21-Jun-05, 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, 1-Apr-05, 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 Emergency Telecommunications Service (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) ------------------------------------------ "Considerations on the Extensibility of IETF protocols", Scott Bradner, Thomas Narten, 20-Mar-05, This document discusses issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions need to be reviewed by the larger IETF community. The document also recommends that major extensions to IETF protocols only take place through normal IETF processes or in coordination with the IETF. "Area Review Teams for Early Cross-functional Reviews", Alex Zinin, 23-May-05, This document contains a proposal for cross-functional IETF review process that can be initiated at early stages of a document life cycle. The approach is based on existing experience with area directorates and other expert groups within the IETF. Please send any comments on this document to the IESG (iesg@ietf.org) "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. "Choosing between Informational and Experimental Status", Brian Carpenter, 9-Jun-05, This document reproduces the rules for classifying documents as Informational and Experimental from RFC 2026, and amplifies those rules with guidelines relevant to ongoing IESG evaluations. It is not intended to change any of the underlying principles. "A question on Media Type Registrations", Ted Hardie, 31-May-05, This document poses a question to the community on the future of the IANA Media Type Registry. It presents three potential future courses of development and asks that feedback on these be provided to the IESG. "DISCUSS Criteria in IESG Review", Jon Peterson, 7-Jul-05, This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued. It also discusses procedures for DISCUSS resolution. 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, 1-Apr-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, 16-May-05, IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists 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, 14-Jul-05, 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, 28-Jun-05, The ACL (Access Control List) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of 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, 30-Mar-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 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, 28-Mar-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) --------------------------------- "Requirements for the Format for INcident information Exchange (FINE)", Yuri Demchenko, 10-May-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. "Incident Handling: Real-Time Inter-Network Defense", Kathleen Moriarty, 2-May-05, Network security incidents such as system compromises, worms, viruses, phishing incidents, and Denial of Service (DoS), typically result in the loss of service, data, and resources both human and system. Network Providers need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper outlines a proactive inter-network communication method to facilitate sharing incident handling data and 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 reporting or tracking a security incident across networks. A complete solution integrating incident detection, source identification, reporting and communication capabilities, and methods to stop attack traffic are necessary to attain higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. "Extension to IODEF-Document Class for Phishing, Fraud, and Other Non-Network Layer Reports", Patrick Cain, David Jevans, 19-Jul-05, This document extends the INCH XML incident reporting format for reporting phishing, fraud, widespread spam, and other non-network layer attacks and incidents. The extensions are an outgrowth of the Anti-Phishing Working Group (APWG) activities in data collection and sharing. Although we use the term "phishing attack", the data format extensions are flexible enough to support information gleaned from activities throughout the entire phishing life cycle and extensible enough to be used for other types of electronic crime incidents such as fraud. The extensions support very simple reporting as well as optional fields for detailed, forensic reports and supports single phish/fraud incidents as well as consolidated reports of multiple phish incidents. 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 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 Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems", Richard Woundy, Kevin Marez, 21-Jun-05, This memo is a revision of the standards track RFC 2669. Please see "Revision Descriptions" below for a description of changes. This document obsoletes RFC 2669. 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) ------------------- "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", Gorry Fairhurst, Bernhard Collini-Nocker, 22-Jun-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 a Unidirectional 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, 2-May-05, This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has 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. "Address Resolution for IP datagrams over MPEG-2 networks", Gorry Fairhurst, Marie-Jose Montpetit, 16-Jun-05, This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. IP Flow Information Export (ipfix) ---------------------------------- "Architecture for IP Flow Information Export", Ganesh Sadasivan, 27-May-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 IPFIX-REQS [1]. "Information Model for IP Flow Information Export", Juergen Quittek, 14-Jul-05, This memo defines an 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 Specification", Benoit Claise, 15-Jul-05, This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process. "IPFIX Applicability", Tanja Zseby, 5-Jul-05, This document describes what type of applications can use the IP Flow Information Export (IPFIX) protocol and how they can use the information provided by IPFIX. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. IP over InfiniBand (ipoib) -------------------------- "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, 30-Mar-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. "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. IP over Resilient Packet Rings (iporpr) --------------------------------------- "Mapping of IP/MPLS Packets into IEEE 802.17 (Resilient Packet Ring)", Marc Holness, Glenn Parsons, 12-Jul-05, This document specifies a basic standard method of encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient Packet Ring (RPR) datagrams. 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, 21-Jun-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, including the context information required for all metrics. 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 oriented toward reordering affects on TCP. 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. "Defining Network Capacity", Phil Chimento, Joseph Ishac, 21-Jun-05, Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to build a common language that can be used when discussing and analyzing a diverse set of current and future estimation techniques. 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. "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 iSNS (Internet Storage Name Service)", Kevin Gibbons, 18-Jul-05, The iSNS protocol provides storage name service functionality on an IP network that is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor and control multiple iSNS Client and Servers, including information about registered objects in an iSNS Server. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. "Definitions of Managed Objects For iFCP", Kevin Gibbons, 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. "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, 29-Jun-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, 29-Jun-05, iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of the Remote Direct Memory Access Protocol (RDMAP). The iWARP protocol suite provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as defined by the iWARP protocol suite. "iSCSI Implementer's Guide", Mallikarjun Chadalapaka, 12-Jul-05, iSCSI is a SCSI transport protocol and maps the SCSI family of application protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. IP Security Protocol (ipsec) ---------------------------- "IP Encapsulating Security Payload (ESP)", Stephen Kent, 10-Mar-05, 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, 21-Mar-05, 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", Russ 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, 1-Apr-05, 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. IP Security Policy (ipsp) ------------------------- "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. IP Telephony (iptel) -------------------- "A Telephony Gateway REgistration Protocol (TGREP)", Manjunath Bangalore, 21-Jul-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 Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between internet telephony administrative domains (ITAD). TGREP shares a lot of similarities with the TRIP Protocol. It has similar procedures and Finite State Machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. TGREP entities are valid trip implementations, but they do only a subset of what they otherwise could. In particular, a gateway is always in Send mode, the LS peering with it is always in Receive mode. "Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs)", Cullen Jennings, Vijay Gurbani, 27-May-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. This work is being discussed on the iptel@ietf.org mailing list. "New Parameters for the "tel" URI to Support Number Portability", James Yu, 14-Jul-05, This document defines several new parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)- related information that can be passed to the next-hop network node after an NP database dip has been performed. This work is being discussed on the iptel@ietf.org mailing list. "The ENUM Dip Indicator parameter for the "tel" URI", Richard Stastny, 18-Apr-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) --------------------------------- "IPv6 Node Information Queries", Matt Crawford, Brian Haberman, 14-Jul-05, This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", Alex Conta, 14-Jul-05, 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, Dave Thaler, 30-Jun-05, 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 in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. "A Method for Generating Link Scoped IPv6 Multicast Addresses", Jung-Soo Park, 21-Jul-05, 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 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. "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, 23-May-05, This specification defines the addressing architecture of the IP Version 6 protocol. 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". "IPv6 Stateless Address Autoconfiguration", Susan Thomson, 12-May-05, 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. "IP Version 6 over PPP", Srihari Varada, 15-Jun-05, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. This document is an update to RFC 2472 and, hence, obsoletes it. "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, 19-Jul-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, 25-May-05, Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. 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, 30-Mar-05, 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. "Neighbor Discovery Proxies (ND Proxy)", Dave Thaler, 15-Jul-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. The behavior of one common type of IPv4 ARP Proxy deployed today is documented herein for informational purposes, but this document concentrates on describing similar behavior for IPv6. IS-IS for IP Internets (isis) ----------------------------- "Management Information Base for IS-IS", Jeff Parker, 11-Jul-05, This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks. This memo defines a 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. 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, 2-Jun-05, This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. "IS-IS Extensions in Support of Generalized MPLS", Kireeti Kompella, Yakov Rekhter, 27-Oct-03, This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. "M-ISIS: Multi Topology (MT) Routing in IS-IS", Tony Przygienda, 9-May-05, This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. "Point-to-point operation over LAN in link-state routing protocols", Naiming Shen, 14-Jul-04, The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. "A Policy Control Mechanism is IS-IS Using Administrative Tags", Christian Martin, Brad Neal, Stefano Previdi, 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, 19-May-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, 25-May-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, 25-May-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. Kerberized Internet Negotiation of Keys (kink) ---------------------------------------------- "Kerberized Internet Negotiation of Keys (KINK)", Shoichi Sakane, 20-Jul-05, This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. 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, 3-Jun-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. "A PRF API extension for the GSS-API", Nicolas Williams, 1-Aug-05, This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application 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. "A PRF for the Kerberos V GSS-API Mechanism", Nicolas Williams, 14-Jun-05, This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Programming Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. "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. "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. "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. "GSS-API Naming Extensions", Nicolas Williams, 16-May-05, The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming and authorization model. Kerberos WG (krb-wg) -------------------- "Public Key Cryptography for Initial Authentication in Kerberos", Brian Tung, Larry Zhu, 21-Jul-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 using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. "Generating KDC Referrals to locate Kerberos realms", Larry Zhu, Karthik Jaganathan, 21-Jul-05, The memo 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. "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. "OCSP Support for PKINIT", Larry Zhu, 21-Jul-05, This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. 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. "Kerberos Cryptosystem Negotiation Extension", Larry Zhu, 21-Jul-05, This document specifies an extension to the Kerberos protocol where the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. "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) ------------------------------------------------- "PPP over L2TP Tunnel Switching", Vipin Jain, 18-Mar-05, PPP over L2TP Tunnel Switching, also called L2TP Multihop, is the process of forwarding PPP payload from an L2TP session to another L2TP session over a different tunnel. It facilitates moving the logical termination point of an L2TP session, based on layer 2 characteristics or administrative policies, to different LNS. This document introduces the L2TP tunnel switching nomenclature and defines the behavior of standard AVPs in tunnel switching deployment. The scope of this document is limited to the discussion of switching PPP frames over L2TPv2 or L2TPv3 tunnels. "Frame-Relay over L2TPv3", Mark Townsley, 7-Jun-05, 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 status change notification. "Fail Over extensions for L2TP "failover"", Vipin Jain, 15-Jun-05, 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, 6-Jun-05, 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, 2-May-05, 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, 21-Jun-05, 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 over L2TPv3", Sanjeev Singh, 3-May-05, 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, 6-Jul-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, 11-Apr-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, 18-Jul-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, i.e., it creates 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. This document describes the control plane functions of signaling pseudo-wire labels, extending [PWE3-CTRL]. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3-ETHERNET]. "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", Eric Rosen, 20-Jul-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, 19-Jul-05, A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions 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. "L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, 18-Jul-05, This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. "ARP Mediation for IP Interworking of Layer 2 VPN", Himanshu Shah, 21-Jul-05, 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 pseudo-wire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudo-wire 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 pseudo-wire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either draft-ietf-l2vpn-arp-mediation-02.txt Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. In particular, the applicability of ARP mediation to ISIS is not addressed as IS-IS PDUs are not sent over IP. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "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 IP VPN extension for IPv6 VPN", Jeremy De Clercq, 1-Aug-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 tunneling 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-Apr-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. "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Eric Rosen, 24-Jun-05, 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, 17-May-05, 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. This document updates draft-ietf-l3vpn-rfc2547bis-03.txt. "Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks", Yakov Rekhter, 21-Jul-05, This draft describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE). The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", Hamid Ould-Brahim, 28-Jun-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 main purpose of an auto-discovery mechanism is to enable a PE to dynamically discover the set of remote PEs having VPN members in common. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of VPN members configured on that PE. Once that information is received the remote PEs will then identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to either establish layer-2/3 VPN connectivity or to learn remote site VPN routes. This draft defines a BGP based auto-discovery mechanism for layer-2 VPN architectures and Virtual router-based layer-3 VPNs. This mechanism is based on the approach used by 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. "Virtual Router Management Information Base Using SMIv2", Elwin Stelzer, 1-Aug-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 networks using Virtual Routers (VR). "Definition of Textual Conventions for Virtual Private Network (VPN) Management", Benson Schliesser, Thomas Nadeau, 8-Apr-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, 11-Apr-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. "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]. "Constrained VPN Route Distribution", Pedro Marques, 23-Jun-05, 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, 14-Jul-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. "Layer-3 VPN Import/Export Verification", Michael Behringer, 25-Mar-05, Configuration errors on Provider Edge (PE) routers in Layer-3 VPN networks based on [RFC2547] can lead to security breaches of the connected VPNs. For example, the PE router could be mistakenly configured such that a connected Customer Edge (CE) router belongs to an incorrect VPN. Here we propose a scheme that verifies local and remote routing information received by the PE router before it installs new VPN routes into the Virtual Routing & Forwarding Instance (VRF). The proposed changes affect only the PE routers. "Multicast in MPLS/BGP IP VPNs", Eric Rosen, Rahul Aggarwal, 1-Jun-05, 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 (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, 3-Jun-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. "LDAP: Schema for User Applications", Andrew Sciberras, 11-Jul-05, This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification [Roadmap]. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as, White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", Steven Legg, 23-Jun-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, 15-Mar-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, 22-Jun-05, 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, 19-Jul-05, This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to schedule future delivery of a message, to optimize submission and to efficiently reconnect in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol [RFC3501] extensions and BURL extension to the SUBMIT protocol [RFC2476]. "IMAP4 Extensions for Quick Reconnect", Corby Wilson, Alexey Melnikov, 18-Jul-05, This document defines a quick reconnect IMAP4 extension, which gives a mobile client the ability to resume a previously abandoned session, without the need to perform a full synchronization sequence. The goal is to minimize the ammount of data transfered at login after a dropped connection. "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", Randall Gellens, 26-May-05, 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, 3-Aug-05, 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, 19-Jul-05, There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. "Evidence Record Syntax (ERS)", Ralf Brandner, 8-Apr-05, In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. "Requirements for Data Validation and Certification Services", Tobias Gondrom, 21-Jun-05, 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. The data being validated may correspond to assertions about real-world facts or events. This document establishes the need for components to be used in addition to or in conjunction with long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. "Long-term Archive Protocol (LTAP)", Aleksej Jerman-Blazic, 19-Jul-05, This document describes a service operated as a trusted third party to securely archive electronic document called Trusted Archive Authority. We describe a architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. Attention: This version 0 document has been submitted in order to meet IETF deadlines. An updated is expected very soon. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 14-Jul-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 the creation of user defined extensions for private interchange. "Matching Tags for the Identification of Languages", Addison Phillips, Mark Davis, 29-Jun-05, This document describes different mechanisms for comparing, matching, and evaluating language tags. Possible algorithms for language negotiation and content selection are described. "Initial Language Subtag Registry", Doug Ewell, 3-Aug-05, This memo defines the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. 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, 18-Jul-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, 16-May-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 (DYMO) Routing", Ian Chakeres, 22-Jun-05, The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless multihop networks. It offers adaptation to changing network topology and determines unicast routes between nodes within the network. "Simplified Multicast Forwarding for MANET", Joseph Macker, 14-Jul-05, This document describes the Simplified Multicast Forwarding (SMF) protocol that provides a basic IP multicast forwarding capability within mobile ad-hoc networks. While it supports edge interoperability with a conventional IP multicast infrastructure, SMF is designed to have limited applicability as a forwarding mechanism for multiple hop multicast packets within MANET routing areas. SMF uses a simplified forwarding mechanism that delivers multicast packets to all MANET multicast receivers within a MANET routing area. The core design does not use group and membership specific information in favor of reduced complexity and state maintenance within the mobile topology region. The design accounts for the unique nature and behavior of MANET interfaces and takes advantage of particular efficient relay set algorithms previously designed and applied in the MANET routing designs. MBONE Deployment (mboned) ------------------------- "Source-Specific Protocol Independent Multicast in 232/8", Dave 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. "Automatic IP Multicast Without Explicit Tunnels (AMT)", Dave Thaler, 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) "PIM-SM Multicast Routing Security Issues and Enhancements", Pekka Savola, Rami Lehtonen, Dave 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. "Lightweight Multicast Address Discovery Problem Space", Pekka Savola, 23-Mar-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. "Accounting, Authentication and Authorization Issues in Well Managed IP Multicasting Services", Haixiang He, 15-Apr-05, This Internet Draft (I-D) describes problems in the area of accounting and access control for multicasting. General requirements for accounting capabilities including quality-of- service (QoS) related issues are listed. This I-D assumes that these capabilities can be realized by functions implemented at edges of a network based on IGMP or MLD. By such functions, information obtained from edge routers would be logged in a dedicated database. Finally, cases for Content Delivery Services (CDS) are described as application examples which could benefit from multicasting accounting and access control capabilities as described in the I-D. It is proposed that this I-D be used as a starting point for further discussion on these issues. "Overview of the Internet Multicast Routing Architecture", Pekka Savola, 12-Jul-05, 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. "Issues Related to Receiver Access Control in the Current Multicast Protocols", Hiroshi Ohta, 5-Jul-05, This I-D evaluates the extent to which current multicasting protocols can be used to address common requirements for commercial, large- scale IP multicasting. 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. Media Gateway Control (megaco) ------------------------------ "The Megaco/H.248v2 Gateway Control Protocol, version 2", Christian Groves, Marcello Pantaleo, 3-Apr-03, This document describes the second version of the general-purpose gateway control protocol standardized as Megaco in the IETF and as Recommendation H.248 (now H.248.1) in the ITU-T. It is common text with Recommendation H.248.1 (05/02), published by the ITU-T. Megaco v2 includes the corrections to RFC 3015 which resulted in RFC xxxx [draft-ietf-megaco-3015corr-02.txt], plus the following new capabilities: - ability to audit specific properties, events, signals and statistics - use of serviceChange to indicate that capabilities have changed in the Media Gateway - playing a signal on the Root Termination - limiting the number of repetitions of transaction pending - allowing topology to be set per stream - ability to audit context properties - new Nx64K multiplex type - provision for digit buffering when a digit map completes. In addition, the use of the Modem Descriptor was deprecated. A detailed list of changes from draft-ietf-megaco-3015corr- 02.txt/H.248.1 (03/02) to this document is given in Appendix II at the end of this document. Middlebox Communication (midcom) -------------------------------- "Definitions of Managed Objects for Middlebox Communication", Juergen Quittek, 16-Mar-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 3989. Mobility for IPv4 (mip4) ------------------------ "Low Latency Handoffs in Mobile IPv4", Karim Malki, 19-Jul-05, 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. "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, 21-Jun-05, 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) 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 RFC3344 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 RFC3344. This document obsoletes RFC3012. "Mobile IPv4 Dynamic Home Agent Assignment", Miland Kulkarni, 19-May-05, Mobile IPv4 [1] 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. "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, 5-Jul-05, 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, 8-Mar-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, 7-Jun-05, This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home Address destination options and type 2 Routing header extension headers. It discusses the common data structures and definitions that might be used by advanced Mobile IPv6 socket applications. "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", Charles Perkins, 30-Jun-05, 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, 27-May-05, This document is an 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-Jul-05, A mobile node needs at least the following information: a home address, home agent address and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discuss the issues involved with how the mobile node can be bootstrapped for Mobile IPv6 and various potential deployment scenarios for bootstrapping the mobile node. "Mobile IPv6 and Firewalls: Problem statement", Franck Le, 5-May-05, Network elements such as 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. Current IP networks are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development. "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", Vijay Devarapalli, 19-Jul-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, 27-Jun-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. "Goals for AAA-HA interface", Gerardo Giaretta, 2-May-05, 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. "Mobile IPv6 bootstrapping in split scenario", Gerardo Giaretta, 28-Jun-05, A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials preconfigured on the Mobile Node. The solution defined in this document solves the boostrapping problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile Node's mobility service is authorized by a different service provider than basic network access, and is therefore generically applicable to any bootstrapping case. "Mobility management for Dual stack mobile nodes A Problem Statement", Hesham Soliman, George Tsirtsis, 15-Jul-05, 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. 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. "Mobile IPv6 Fast Handovers for 802.11 Networks", Pete McCann, 14-Apr-05, 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, 16-Jun-05, 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, 19-Jul-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, 14-Jun-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, 20-Jul-05, This memorandum defines RTSP version 1.1 which is a revision of the Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 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, 13-Jun-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, 29-Jun-05, 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 Offer/Answer Protocols", Jonathan Rosenberg, 20-Jul-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. "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", Jonathan Lennox, 7-Jul-05, 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 SDP 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. "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, 6-Jul-05, 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, 20-Jul-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. "Connectivity Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, 3-May-05, This document defines a new connectivity precondition for the Session Description Protocol precondition framework described in RFC 3312 (and its update, RFC4032). A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been verified successfully. The method of verification may vary depending on the type of transport used for the media. For reliable connection-oriented transports such as TCP verification is achieved by successful connection establishment. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. IKEv2 Mobility and Multihoming (mobike) --------------------------------------- "Design of the MOBIKE Protocol", Tero Kivinen, Hannes Tschofenig, 20-Jul-05, The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing extensions for the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", Pasi Eronen, 15-Jul-05, This document describes the MOBIKE protocol, a mobility and multihoming extension to IKEv2. MOBIKE allows mobile and/or multihomed hosts to update the (outer) IP addresses associated with IKE and IPsec Security Associations (SAs). The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another while keeping the connection with the VPN gateway active. Multiprotocol Label Switching (mpls) ------------------------------------ "ICMP Extensions for MultiProtocol Label Switching", Ronald Bonica, 3-Aug-05, This memo proposes extensions to ICMP that permit Label Switching Routers to append MPLS information to ICMP messages. "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...) "Detecting MPLS Data Plane Failures", Kireeti Kompella, George Swallow, 16-May-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, 22-Jun-05, 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. "Definition of an RRO node-id subobject", Jean Vasseur, 31-May-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 Label Switched Path (TE LSP) on a downstream Label Switch Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an IGP area or an Autonomous System. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-domain TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining 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, 21-Jul-05, 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 (MPLS) network, but also because they MAY impact service level specification commitments for customers of that network. This document describes requirements for user and data plane operations and management for MPLS. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks, similarly some of these requirements have appeared in other documents. This draft specifies Operations and Management requirements for Multi-Protocol Label Switching, as well as for applications of Multi-Protocol Label Switching such as pseudowire voice and virtual private network services. Those interested in specific issues relating to instrumenting MPLS for Operations and Management purposes are directed to the Multi-Protocol Label Switching Architecture specification. "MPLS Traffic Engineering Soft Preemption", Matthew Meyer, 16-Jun-05, 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 Engineering Label Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined supporting only immediate TE LSP displacement upon preemption. The utilization of a preemption pending flag helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under- provisioned until the TE LSP(s) 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, 19-Jul-05, This document defines a means 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] are extended to do the actual probing. "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", Adrian Farrel, 26-May-05, 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. 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, 1-Aug-05, 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, 6-Jul-05, 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, 31-Mar-05, This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching. The document is structured to outline how Operations and Management 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, 19-Jul-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, 5-Jul-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. The requirements presented in this document are not limited to the requirements of packet switched networks, but also encompass the requirements of Layer two Switching (L2SC), Time Division Multiplexing (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. "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. Multicast Security (msec) ------------------------- "GSAKMP: Group Secure Association Group Management Protocol", Hugh Harney, 17-May-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. "HMAC-authenticated Diffie-Hellman for MIKEY", Martin Euchner, 4-Apr-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/SHA-1 Signatures within ESP and AH", Brian Weis, 22-Jun-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. -- Note to RFC Editor: Please replace RFC XXXX with the RFC -- number that is assigned to draft-ietf-ipsec-esp-v3 and -- replace RFC YYYY with the RFC number assigned to -- draft-ietf-ipsec-rfc2402bis. Please also modify normative -- references [ESP] and [AH] that point to these drafts with -- their respective RFC numbers. Lastly, informative references -- [IKEV2] and [AES-GCM] should be changed to their assigned -- RFC numbers, assuming they are published before this -- document. "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 v1: Group Policy Token V1 with Application to GSAKMP", Hugh Harney, Andrea Colegrove, 8-Jul-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. "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, 24-May-05, With the Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA) a protocol for providing source authentication in multicast scenarios has been introduced. TESLA uses MAC chaining for this purpose. A mapping for TESLA to the Secure Real-time Transport Protocol (SRTP) has been published which assumes that TESLA parameters are made available by out-of-band mechanisms. This document specifies MIKEY payloads for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast or broadcast. "ECC Algorithms For MIKEY", Andrew Milne, 7-Jul-05, This document proposes extensions to the authentication, encryption and digital signature methods described for use in MIKEY, employing elliptic-curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards. It should be noted that this document is not self-contained; it uses the notations and definitions of [MIKEY]. "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", Dragan Ignjatic, 8-Jul-05, The MIKEY specification describes several modes of key distribution to setup secure RTP sessions -- using pre-shared keys, public-keys, and optionally a 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 communication 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. "Multicast Extensions to the Security Architecture for the Internet Protocol", Brian Weis, 11-Jul-05, The Security Architecture for the Internet Protocol [RFC2401BIS] describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets, as well as manually configured IP multicast packets. This document further defines the security services for IP multicast packets within that Security Architecture. Site Multihoming in IPv6 (multi6) --------------------------------- "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. "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, 28-Jun-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", Chan-Wah Ng, 20-Jul-05, This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Issues are classified according to the Working Group which is the best chartered to solve them. "NEMO Management Information Base", Sri Gundavelli, 19-Jul-05, 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 functionality. "Network Mobility Route Optimization Problem Statement", Chan-Wah Ng, 5-Jul-05, With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies, and provides for the motivation behind Route Optimization (RO) for NEMO. Network Configuration (netconf) ------------------------------- "NETCONF Configuration Protocol", Rob Enns, 30-Jun-05, The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (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 Remote Procedure Call (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, 7-Apr-05, 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, 25-Apr-05, The Network Configuration 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 the Simple Object Access Protocol (SOAP). 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 SOAP over HTTP and SOAP over BEEP bindings for NETCONF. "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", Margaret Wasserman, Ted Goddard, 11-Apr-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, 22-Apr-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. "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, 6-May-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.1: Directory Delegations and Notifications", Saadia Khan, 25-Mar-05, This document proposes adding directory delegations and notifications to NFS Version 4 [RFC3530]. It is hoped that these changes will be part of a new minor version of NFS, such as NFSv4.1. "NFSv4 Session Extensions", Thomas Talpey, 8-Jul-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. "Implementation Guide for Referrals in NFSv4", David Noveck, Rodney Burnett, 8-Jul-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. 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 Transfer Protocol", Clive Feather, 9-Jun-05, The Network News Transfer 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, 27-Jun-05, This memo defines an extension to the Network News Transport Protocol (NNTP) to allow an NNTP client and server to use 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", Ken Murchison, Jeffrey Vinocur, 27-Jun-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. This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. "NNTP Extension for Authentication", Jeffrey Vinocur, 10-Jun-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. This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. 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 Authorization Control", Rob Weltman, 9-Jun-05, This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of as the current authorization identity associated with the connection. "The application/smil and application/smil+xml Media Types", Philipp Hoschka, 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. "Additional ECC Groups For IKE", Daniel Brown, 3-Jun-05, This document describes new ECC groups for use in IKE [IKE] in addition to the Oakley groups included therein. These groups are defined to align IKE with other ECC implementations and standards, and in addition, many of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [IKE]. "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", Jim Sermersheim, Ludovic Poitou, 19-Jul-05, Password policy as described in this document is a set of rules that controls how passwords are used and administered in Lightweight Directory Access Protocol (LDAP) based directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts. "Transport of Layer 2 Frames Over MPLS", Luca Martini, 8-Mar-05, This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. "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, 8-Jul-05, 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. "IKE Authentication Using ECDSA", Jerome Solinas, 31-May-05, This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) protocol. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE without introducing any changes to existing IKE operation. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 26-May-05, This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other Internet Drafts relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. "SILC Packet Protocol", Pekka Riikonen, 26-May-05, This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol specified in the Secure Internet Live Conferencing, Protocol Specification Internet Draft [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 26-May-05, This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. SKE use best parts of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY Key Determination protocol [OAKLEY]. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol is transparent to the authentication data which means that it can be used to authenticate the user with, for example, passphrase (pre-shared secret) or public key (and certificate) based on digital signatures. "Alternative Certificate Formats for the PKIX Certificate Management Protocols", Mikhail Blinov, Carlisle Adams, 20-Apr-05, 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 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. "IP Flooding in Ad hoc Mobile Networks", Charles Perkins, 30-Jun-05, An ad hoc mobile network is a collection of nodes, each of which communicates over wireless channels and is capable of movement. Nodes participating in such an ad hoc network communicate on a peer-to-peer basis. Flooding is often a desired form of communication in these networks, as it can enable both the dissemination of control information and the delivery of data packets. This document describes a method for sending packets to every node in an ad hoc network. "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. "UMAC: Message Authentication Code using Universal Hashing", Ted Krovetz, 15-Jul-05, 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 to generate the pseudorandom pads and internal key material. "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. "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", Bob Joslin, 19-Apr-05, This document describes a mechanism for distributed configuration of similar directory user agents. This document defines a schema for configuration of these DUAs that may be discovered using the Lightweight Directory Access Protocol in RFC 3377[1]. A set of attribute types and an objectclass are proposed, along with specific guidelines for interpreting them. A proposal of using attribute and objectclass mapping allows DUAs to re-configure their schema to that of the end user's environment. 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, 25-May-05, This document define Uniform Resource Identifiers for Domain Name System resources. See for more information. "Explicit Multicast (Xcast) Basic Specification", Richard Boivie, 22-Jul-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 traditional 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. This document describes a new scheme for multicast - named Explicit Multi-unicast (Xcast) - that complements the existing schemes. Whereas the existing schemes can support a limited number of very large multicast sessions, Xcast can support a very large number of small multicast sessions. This is achieved by explicitly encoding the list of destinations in the data packets, instead of using a multicast address. The co-operation of Xcast - a data plane mechanism - with existing control planes is described and scenarios for gradual deployment are investigated. Encodings for both IPv4 and IPv6 are proposed. This document discusses concepts and optional ideas in several areas and does not provide a complete technical specification at this point. However, significant experience has been obtained in implementation, in interoperability testing and in operational experiments. The details of these experiments will be discussed in a forthcoming informational RFC [BCP-2004]. This draft combines with previous drafts: [BOIV], [IMAI], [OOMS]. "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. "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 File Sharing URI Scheme", Christopher Hertel, 14-Jul-05, The Server Message Block (SMB) protocol is one of the most widely used network file system protocols in existence. This document describes a scheme for an SMB Uniform Resource Indicator (SMB URI) which can be used to identify SMB workgroups, servers, server shares, directories, files, inter-process communications ports (named pipes), and devices--the objects in the SMB network file system space. "SILC Commands", Pekka Riikonen, 26-May-05, This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages. "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. "An IPv6 Provider-Independent Global Unicast Address Format", Tony Hain, 8-Jul-05, 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 [1] and the "IPv6 Addressing Architecture" [2]. 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, 8-Jul-05, This document discusses the expected use of the Provider Independent address format discussed in the companion document GEO [1] in the Internet. Several parties have expressed interest in using this approach as a good fit for managing their networks. With the long timeframe that the multi6 effort has taken, this approach provides a scalable multi-homing approach for use in the interim. 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. "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. "Multicast DNS", Stuart Cheshire, Marc Krochmal, 1-Jul-05, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. "Simultaneous Bindings for Mobile IPv6 Fast Handovers", Karim Malki, Hesham Soliman, 18-Jul-05, Fast Handover for Mobile IPv6 [1] minimizes the amount of service disruption when performing layer-3 handovers. This draft extends the Fast Handover protocol with a simultaneous bindings function to minimize packet loss at the MN. Traffic for the MN is therefore bicast or n-cast for a short period to its current location and to one or more locations where the MN is expected to move to shortly. This removes the timing ambiguity regarding when to start sending traffic for the MN to its new point of attachment following a Fast Handover and allows the decoupling of layer-2 and layer-3 handovers. It also saves the MN periods of service disruption in the case of ping-pong movement. "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. "Datatypes for WebDAV properties", Julian Reschke, 29-Apr-05, 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. "Requirements for a Protocol to Replace AppleTalk NBP", Stuart Cheshire, Marc Krochmal, 1-Jul-05, One of the implicitly understood goals amongst the participants working on "Multicast DNS", "Link-Local Multicast Name Resolution", "Zeroconf Name Service", "Bonjour" (or whatever you like to call it) is the ability to retire AppleTalk Name Binding Protocol, NetBIOS naming, and the like, and replace them with an all-IP solution. This document outlines the specific properties required of an IP replacement for AppleTalk Name Binding Protocol. "Scripting Media Types", Bjoern Hoehrmann, 7-Jun-05, This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. "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, 20-Jul-05, The Dublin Core Metadata Workshop Series began in 1995 with an invitational workshop which brought together librarians, digital library researchers, content experts, and text-markup experts to promote better discovery standards for electronic resources. The resulting metadata element set is perhaps the most widely adopted convention for structuring resource descriptions designed to bridge networked information systems and content providers in the publishing, library, museum, scholarly, archival, and government communities. It defines fifteen metadata elements for resource description in a cross-disciplinary information environment. "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. "IPv4 Address Conflict Detection", Stuart Cheshire, 14-Jul-05, When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination) problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect after-the-fact that it has happened, so that the host or administrator may respond to rectify the problem. "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. "A Media Resource Control Protocol Developed by Cisco, Nuance, and Speechworks.", Saravanan Shanmugham, 6-Apr-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) "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. "Global connectivity for IPv6 Mobile Ad Hoc Networks", Ryuji Wakikawa, 19-Jul-05, This document describes how to provide Internet connectivity with mobile ad-hoc networks. It describes how to obtain a globally routable address and internet-gateway operation. Once a manet node obtains a global address from an internet-gateway, it may exchange data with nodes on the Internet. Data goes through the internet-gateway with a routing header specifying the gateway. This connectivity method is not dependent on a particular manet protocol. Further, use of global connectivity with Mobile IPv6 is specified. "Considerations for LDAP Extensions", Kurt Zeilenga, 22-Jul-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. "The Managed Object Aggregation MIB", Glenn Keeni, 19-Jul-05, This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a (user) specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. "Registration of GSTN SMS Service Qualifier", Erik Wilde, 3-Aug-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, 3-Aug-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, 26-May-05, 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. "Media Gateway Control Protocol Fax Package", Flemming Andreasen, 24-Mar-05, This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. "IMEI-based universal IPv6 interface IDs", Francis Dupont, Loutfi Nuaymi, 25-Apr-05, 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, 30-Mar-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, 19-Jul-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 of 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, 11-Jul-05, 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. "The 'doi' URI Scheme for Digital Object Identifier (DOI)", Norman Paskin, 26-May-05, This document defines the 'doi' Uniform Resource Identifier (URI) scheme for the Digital Object Identifier (DOI). DOIs are identifiers for entities of significance to the content industries. The 'doi' URI scheme allows a resource associated with an entity identified by a DOI to be referenced by a URI for Internet applications. A 'doi' URI is dereferenced to a set of service descriptions through discoverable resolution mechanisms. "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, 5-May-05, 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. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, 6-Apr-05, This document describes the applicability of the Relialeble Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "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). "SILC Message Flag Payloads", Pekka Riikonen, 26-May-05, This memo describes the data payloads associated with the SILC Message Flags, as defined in the SILC Packet Protocol specification [SILC2]. The purpose of the Message Flags is to augment the function of the Message Payload used to send both private and channel messages, by allowing the sender to tell the receiver what type of data the payload includes, and how the data should be processed. Some of the Message Flags may define additional payloads to be associated with the flag, and this memo describes these payloads. "User Online Presence and Information Attributes", Pekka Riikonen, 26-May-05, This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network. "BGP Persistent Route Oscillation Solution", Daniel Walton, 15-Jul-05, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-type route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first set, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED-type route oscillations (subject to certain commonly adopted topological constrains). "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, 29-Jun-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. "A Protocol for Anycast Address Resolving", Shingo Ata, 20-Jul-05, 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. "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, 9-Jun-05, 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. "Mobile IPv6 for multiple interfaces (MMI)", Nicolas Montavont, 15-Jul-05, Mobile IPv6 [1] allows a MN to maintain its IPv6 communications while moving between subnets. This document presents the problematic for a MN that has multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and propose MMI (Mobile IPv6 for Multiple Interfaces) which describes the use of Mobile IPv6 to support multiple interfaces. One one hand, these extensions focus on the MN ability to use a backup interface for communications and on the other hand to spread flows between the MN own interfaces. "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. "Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno, 26-May-05, This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11. "Secure Ad hoc On-Demand Distance Vector (SAODV) Routing", Manel Zapata, 18-Mar-05, 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, 14-Jun-05, 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, several suggestions that have been made to provide needed functionality, 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, 1-Jul-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. "Decorrelated Loss Recovery (DCLOR) Using SACK Option for Spurious Timeouts", Yogesh Swami, Khiem Le, 7-Apr-05, 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, 30-Jun-05, The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can be used to carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer that combines short messages, peforms NAK suppression, and incorporates the TCP-Friendly Multicast Congestion Control of Widmer and Handley, dropping best- effort traffic in order to achieve congestion control; and a selectively reliable transport (SRT) sublayer that formats best- effort and reliable transmissions and also creates negative acknowledgements when loss of reliable messages is detected. In SRMP, selection between reliable and best-effort messages is performed by the application. The protocol bundles messages within a configured time interval, attempting to achieve a configured bundle size which typically is set to the expected smallest MTU in the delivery path. The bundle header carries the latest sequence number for each reliable transmission. Rate reduction is achieved when necessary by dropping best-effort messages at random. "Split Multi-link Trunking (SMLT)", Roger Lapuh, 18-Jul-05, 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]. SMLT is an improvement over Multi-Link Trunking (MLT), a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT is MLT with links of a link-aggregation group connected to ports on two different devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. In many cases those devices act as bridges (switches) as well as L3 routers (Routing Switches). These two redundant SMLT aggregation devices can share one or more VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an active-active router concept, where both SMLT aggregation device route traffic for a common VRRP-ID, thus load balancing traffic not only for L2 but also for L3. "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, 3-May-05, 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, 7-Jul-05, 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", Henry Sinnreich, 13-Jun-05, This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well defined set of interoperability and multi-vendor supported core features, so as to enable similar ease of purchase, installation and operation as found for PCs, PDAs analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings. "DNS-Based Service Discovery", Marc Krochmal, Stuart Cheshire, 1-Jul-05, This document describes a convention for naming and structuring DNS resource records. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of that desired service, using only standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD. "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, 18-May-05, 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", Russ 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. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Lode Coene, 8-Apr-05, This document describes the applicability of the Relialeble Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "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. "IPv6 Socket API for source address selection", Erik Nordmark, 14-Jul-05, The IPv6 default address selection document, RFC 3484, describes the rules for selecting source and destination IP addresses, and indicates that the applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic or advanced IPv6 socket API documents. This document fills that gap by specifying socket level options add new flags for the getaddrinfo() API to specify preferences for address selection that modify the default address selection algorithm. The socket APIs described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the Care-of-address for communication. "vCard Extensions for Instant Messaging (IM)", Cullen Jennings, 18-Jul-05, 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. "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. "RTP Payload Format for the Speex Codec", Greg Herlein, 5-Apr-05, Speex is an open-source, patent-free, voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP) and a preliminary method of using Speex within H.323 applications. "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. "Instant Message Delivery Notification (IMDN) for Common Presence and Instant Messaging (CPIM) Messages", Eric Burger, 19-Jul-05, This document describes a mechanism for instant message delivery notification (IMDN) in the CPIM (Common Presence and Instant Messaging) environment. The mechanism follows the procedures of ESMTP message delivery notification (MDN). "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. "Multiple Care-of Addresses Registration", Ryuji Wakikawa, 21-Jun-05, According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, termed the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple access media simultaneously, in which case multiple active IPv6 care-of addresses would be assigned to the mobile node. We thus propose Mobile IPv6 extensions designed to register multiple care-of addresses bound to a single home address instead of the sole primary care-of address. For doing so, a new identification number must be carried in each binding for the receiver to distinguish between the bindings corresponding to the same home address. Those extensions are targeted to NEMO (Network Mobility) Basic Support as well as to Mobile IPv6. "Protecting Internet Routing Infrastructure from Outsider DoS Attacks", Alex Zinin, 23-May-05, The mechanism described in this document helps to secure an Internet Service Provider's router infrastructure from outsider attacks, including (but not limited to) Distributed denial of service (DDoS) attacks based on CPU and/or queue exhaustion (e.g., TCP SYN flooding and flooding of invalid MD5-signed routing protocol packets.) The presented approach is based on explicitly marking control packets from trusted sources by different link-layer encapsulation and does not require any modifications to user data exchange protocols, ICMP, routing protocols or changes to existing hardware in routers, which allows it to be deployed quickly throughout the Internet. "Specifying time intervals in URI queries and fragments of time-based Web resources", Silvia Pfeiffer, Craig Parker, 30-Mar-05, This document specifies a syntax for addressing time intervals within time-based Web resources through URI queries and fragments. This scheme is particularly used for Annodex [1] and CMML [2] Web resources, though it could be picked up by any other time-based Web resource format. Temporal addressing enables, e.g., direct access to a clip inside a video stored on a Web Server, or direct jumps to a specific event within a piece of music. The syntax is not restricted to audio or video Web resources though, but covers all kinds of Web resources that contain time-continuous information. "IPv6 Anycast Terminology Definition", Mikio Hashimoto, 21-Jul-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, 19-Jul-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. "Component Link Recording and Resource Control for GMPLS Link Bundles", Anca Zamfir, 22-Jun-05, Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in RRO is not enough for the administrative purpose. Network service providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As , it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the ERO counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over GMPLS link bundles. "Bundle Protocol Specification", Keith Scott, Scott Burleigh, 20-Jul-05, This document describes the end-to-end protocol, header formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). "Delay-Tolerant Network Architecture", Vinton Cerf, 19-Jul-05, This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. "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. "IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration", Eiji Oki, 19-Jul-05, Over time Multi-Protocol Label Switching (MPLS) traffic engineered networks may be migrated to use Generalized MPLS (GMPLS). This will allow the networks to benefit from many new features that have been added to the GMPLS protocols. Additionally, such migration will facilitate easy interworking of packet networks that are controlled by IP/MPLS-TE protocols and networks that are controlled by GMPLS protocols. During this migration phase MPLS and GMPLS capable elements will have to co-exist and interwork. GMPLS signaling and routing protocols are subtly different from the MPLS protocols and so interworking and migration strategies are needed. This document describes issues associated with interworking of IP/MPLS-TE networks and GMPLS-based optical networks. Then it describes possible migration scenarios, mechanisms to compensate for the differences between MPLS and GMPLS protocols, and how to apply those mechanisms in order to achieve migration from MPLS to GMPLS. "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]. "Lumas-A Language for Universal Message Abstraction and Specification", Peter Cordell, 25-Mar-05, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "EAP IKEv2 Method (EAP-IKEv2)", Hannes Tschofenig, 20-Jul-05, EAP-IKEv2 is an EAP authentication method with cryptographic properties and basic exchanges similar to the Internet Key Exchange (IKEv2) protocol. It provides a flexible EAP method with support for both symmetric and asymmetric authentication, as well as a combination of both. EAP-IKEv2 thereby offers the security benefits of the exchanges for authentication and key agreement of IKEv2 within the AAA framework defined by the IETF. "Load Sharing in Stream Control Transmission Protocol", Ahmed Abd El Al, 19-May-05, Stream Control Transmission Protocol (SCTP) RFC2960 [SXM00] specifications utilize the possible multiple paths between the sender and receiver for retransmission of lost data chunks and as a backup for the primary path, in case of primary path failure. Other than that, all the data chunks are being sent on the primary path chosen by the SCTP user during the association initiation. This memo describes an extension to SCTP that allows endpoints to use the multiple available paths for simultaneous data transmission. The extension maintains SCTP congestion control on each path, so as to ensure fair integration with other traffic in the network. "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. "Internet Application Protocol Collation Registry", Chris Newman, 7-Jul-05, 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, 19-Jul-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. "BaseStream - A Simple Typed Stream Format", Frans Lundberg, 28-Mar-05, BaseStream is a simple binary stream format that serves as a common base for binary formats like XML provides a base for text formats. The binary format consists of typed and possibly named data elements. An instance of the BaseStream format has a corresponding XML representation that makes it possible to use existing XML tools to view, edit, validate, and transform BaseStream data. "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, 20-Jul-05, This document specifies the steps which a mobile 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, 28-Mar-05, 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). "The Continuous Media Markup Language (CMML), Version 2.0", Silvia Pfeiffer, 30-Mar-05, This specification defines the Continuous Media Markup Language (CMML), version 2.0, an XML-based [1] markup language for time-continuous data. It is a sister document to the specification of the Annodex [2] annotation, indexing and hyperlinking format for time-continuous data. A CMML file is essentially a textual representation of an Annodex file. "Teredo: Tunneling IPv6 over UDP through NATs", Christian Huitema, 5-Apr-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'. "Considerations for Mobility Support in NAT-PT", Myung-Ki Shin, Jon Lee, 19-Jul-05, The document specifies considerations for mobility support in NAT- PT (RFC-2766) [1]. "The Annodex exchange format for time-continuous bitstreams, Version 3.0", Silvia Pfeiffer, 30-Mar-05, This specification defines "Annodex", an exchange format for annotated and indexed time-continuous bitstreams. Annodex provides a bitstream format for exchanging multitrack interleaved time-continuous bitstreams and textual meta information attached to temporal fragments of the binary bitstreams. The meta information is given in the Continuous Media Markup Language (CMML). Annodex enables integration of time-continuous bitstreams into the browsing and searching functionality of the World Wide Web. "Implementing Bridged Line Appearances (BLA) Using Session Initiation Protocol (SIP)", Anil Kumar, 7-Jul-05, This document describes the implementation of Bridged Line Appearance (BLA) feature based on Session Initiation Protocol (SIP). The BLA feature is commonly offered in the IP Centrex services and IP-PBX offerings. This feature is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. "History of the IEEE 802/IETF Relationship", Les Bell, Dan Romascanu, Bernard Aboba, 5-Apr-05, Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and AAA applications. This document describes the history of that cooperation, and the policies and procedures that have developed in order to coordinate between the two organizations. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", Vesa Torvinen, Jari Arkko, Mats Naslund, 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. "Suggested Practices for Registration of Internationalized Domain Names (IDN)", John Klensin, 18-May-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. "Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option", Steven Legg, 7-Jun-05, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, which can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. "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. "SIP Service Quality Reporting Event", Alan Johnston, 20-Jul-05, This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for VoIP sessions using RTP [3] as their transport. The definitions of the metrics used in the event package are based on RTCP Extended Reports [4] and RTCP [3]. "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. "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. "Benchmarking Methodology for MPLS Protection Mechanisms", Scott Poretsky, 18-Jul-05, This draft describes the methodology for benchmarking MPLS protection mechanisms. An overview of existing MPLS Protection terminology and functionality is provided as as background for the methodology. The methodology can be applied to any MPLS Protection mechanism such as Headend Reroute, Standby LSP, Fast Reroute Detour Mode, and Fast Reroute Bypass Mode. The data plane is measured to obtain the benchmarking metrics. Discussion is included to explain the differences between MPLS Protection mechanisms, the network events that cause failover, and the benefits of measuring the data plane for black-box MPLS Protection benchmarking. Measurements can be used to compare failover performance of different Label-Switched Routers and evaluate the different MPLS protection mechanisms. "Address Resolution for IP datagrams over MPEG-2 networks", Gorry Fairhurst, 12-Apr-05, This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. "BGPv4 SAFI-Specific Attribute", Ruchi Kapoor, 21-Jul-05, This document defines a new BGP attribute called the SAFI-Specific Attribute. The document also makes the attribute specific to be used by the Tunnel SAFI. The Tunnel-SAFI Specific attribute (also know as the Tunnel Attribute) is used to send out attributes of a Tunnel used by routing for different routing applications. This Tunnel attribute can contain various 'Types', where the Type identifies what kind of Tunnel the TLV describes. "Tunnel SAFI", Gargi Nalawade, 21-Jul-05, The architecture of an MPLS VPN solution relies on the establishment of two layers of reachability information. The first is the association of a prefix, interface, or route table to a VPNv4 label that is used on the egress PE to delineate a Virtual Route Forwarding table. The second is the association of the next-hop to reach the egress PE. By default, the MPLS VPN establishes an LSP tunnel from the ingress PE to the egress PE. A requirement exists to establish an IP tunnel between the ingress and egress PE in lieu of an LSP. The egress PE's tunnel capability needs to be distributed to all the potential ingress PE's as well as the attributes of the tunnel. The tunnel end-point discovery may occur within and across Autonomous Systems. BGP is the logical protocol of choice that is widely deployed for MPLS VPN solutions and can carry this information in a synchronized manner. This document defines how BGP speakers can convey Tunnel end-point reachability information. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, 15-Apr-05, One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router (MR) for use on the links in the mobile network. DHCPv6 prefix delegation can be used for this configuration task. "End-to-middle security in the Session Initiation Protocol(SIP)", Kinji Ono, Shinya Tachimoto, 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", Nelson Hastings, Masaki SHIMAOKA, 8-Jul-05, This memo is intended to describe the foundation necessary to the deployment of a multi-domain PKI. The scope of this memo is to establish and clarify the trust relationships and interoperability between multiple PKI domains. A Certification Authority (CA) is able to extend a certification path by establishing trust with other CAs. Both single- and multi-domain PKIs are established by such trust relationships between CAs. Typical and primitive PKI model is a single-domain PKI that shares the same certificate policy at a specified trust level. A multi-domain PKI is established by combining more than one single-domain PKI. A multi-domain PKI can be categorized as either a multi-trust point model based on the trust list model; or single-trust point model based on the Cross- Certification model. "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, 19-Apr-05, 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. Thus our scheme achieves seamless mobility, even though no bicasting of multicast streams is used. Multicast listeners in addition encounter the option to optimize multicast routing by turning to a direct data reception. "IPv6 Router Advertisement Option for DNS Configuration", Jae-Hoon Jeong, 20-Jul-05, This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. "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. "Abstract Syntax Notation X (ASN.X)", Steven Legg, 15-Jul-05, Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language, therefore ASN.X documents are much easier to parse and manage than original ASN.1 specifications. "Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration", P. Jones, 2-Jun-04, This document defines the MIME sub-type audio/t38. The packetization and usage of this MIME type, which is intended for use within SDP, is specified within ITU-T Recommendation T.38. "Dual Stack IPv6 Dominant Transition Mechanism (DSTM)", Jim Bound, 15-Jul-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, 19-Jul-05, 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. "IS-IS and OSPF Difference Discussions", Manav Bhatia, 22-Jul-05, The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over the years has drawn significant attention to the relative merits and de-merits of one with respect to the other. This draft presents an elaborate comparison between the two routing protocols to explain how the features and functionalities of one differs from the other. Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3] have also been pointed out. "Redundant TCP", Daniel Kilsdonk, 13-Jun-05, This memo documents a process which can be used to avoid network outages during the upgrading of a router's software. In this way, disruptions to the network community are avoided. The upgrade process definition comprises requirements for inserting a replacement router or upgrading the software in a working router within an operational network. To do this, it maximizes the use of accepted internet standards with minimal alteration. "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. "Private VLANs: Addressing VLAN scalability and security issues in a multi-client environment", Sanjib HomChaudhuri, Marco Foschiano, 29-Apr-05, This document describes the concept of layer 2 isolation among devices that are members of the same layer 2 domain. A vlan is a layer 2 broadcast domain in which all devices can establish direct communication with one another at layer 2. As a consequence, devices that are connected to the same vlan have an implicit trust relationship with each other. If 'untrusted' devices are introduced into a vlan, security issues may arise because trusted and untrusted devices end up sharing the same broadcast domain. The traditional solution to this kind of problem is to assign a separate vlan to each device that is concerned about layer 2 security issues. That however is not a scalable solution. The mechanism proposed in this document can offer total layer 2 isolation between devices connected to the same vlan. What that means is that, on the one hand, each customer will enjoy the benefits that come with a separate dedicated vlan, while on the other hand the service provider will enjoy the benefit of consuming as few as two vlan identifiers. "The 'info' URI Scheme for Information Assets with Identifiers in Public Namespaces", Herbert Van de Sompel, 13-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 IMAP COMPRESS=DEFLATE extension", Arnt Gulbrandsen, 3-Aug-05, The COMPRESS=DEFLATE extension allows an IMAP connection to be compressed using the DEFLATE algorithm, such that effective compression is available even when TLS is used. "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. "Internationalization of Email Addresses", John Klensin, 19-Jul-05, Internationalization of electronic mail addresses is, if anything, more important than the already-completed effort for domain names. In most of the contexts in which they are used, domain names can be hidden within or as part of various types of references. Email addresses, by contrast, are crucial: use of names of people or organizations as, or as part of, the email local part is, for obvious reasons, a well-established tradition on the network. Preventing people from spelling their names correctly is, in the long term, inexcusable. At the same time, email addresses pose a number of special problems -- they are more difficult than simple domain names in some respects, but actually easier in others. This document discusses the issues with internationalization of email addresses, explains why some obvious approaches are incompatible with the definitions and use of Internet mail, and proposes a solution -- for both addressing and email internationalization more generally -- that is likely to serve users and the network well for the long term. "A Bound End-to-End Tunnel (BEET) mode for ESP", Pekka Nikander, 1-Jun-05, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, 8-Jun-05, The use of multiple interfaces is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks 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 up this gap and 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. "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. "Conventions for Voicemail URIs in SIP", Cullen Jennings, 18-Jul-05, The SIP protocol is often used to initiate connections to voicemail or unified messaging systems. This specification describes a convention for forming SIP Service URIs that request particular services from unified messaging systems. "The S Hexdump Format", Joachim Strombergson, 23-Mar-05, This document specifies the S 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, 7-Jun-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. "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. "A Delivery Mechanism for Session-Specific Session Initiation Protocol(SIP) Session Policies", Volker Hilt, 14-Jul-05, This specification defines a delivery mechanism for session-specific Session Initiation Protocol (SIP) sessions policies. "The Extended LDAP Data Interchange Format (ELDIF)", Steven Legg, Andrew Sciberras, 5-Jul-05, 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, 18-Jul-05, This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementers 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. This work is being discussed on the sip@ietf.org mailing list. "BGPv4 Soft-Notification Message", Gargi Nalawade, 21-Jul-05, This document defines a new message type, the BGP SOFT-NOTIFICATION message that can notify a peer of an error-condition for a particular AFI/SAFI and soft-reset the AFI/SAFI, without terminating the BGP session and without impacting the other AFI/SAFIs exchanged with the peer. "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]. "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 Extension for Notification Throttling", Aki Niemi, 21-Jul-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, but the mechanism is especially designed to be used in combination with a subscription to a Resource List Server (RLS). "FLUTE Interoperability Testing Guidelines", Harsh Mehta, 21-Jun-05, This document describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirectional Transport (FLUTE) protocol. "MANET Extension of OSPF using CDS Flooding", Phil Spagnolo, Richard Ogier, 20-Jul-05, This document specifies an extension of OSPF for IPv6 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new LSAs back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. "Tunneling IPv6 with private IPv4 addresses through NAT devices", Liu Min, 15-Jul-05, 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 could provide managed IPv6 prefixes with path optimized routing directly between clients. "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. "Discovering LDP Next-Nexthop Labels", Naiming Shen, 19-May-05, This document specifies extensions to LDP in support of next-nexthop label discovery. The next-nexthop label information can be used to fast re-route LDP LSP traffic into an explicitly routed tunnel for nexthop node protection in the case of a link or node failure. "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. "Calendaring Extensions to WebDAV (CalDAV)", Lisa Dusseault, 19-Jul-05, This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports single-user calendar access, calendar management, calendar sharing, and calendar publishing. "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)", Daniel Prager, Steven Legg, 6-Jul-05, This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. "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). "Datagram Transport Layer Security", Eric Rescorla, Nagendra Modadugu, 24-Jun-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 security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. "SixXS Heartbeat Protocol", Jeroen Massar, 6-Jun-05, This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers. "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. "Ncc in Mail Header", Arun Sankar, 5-Apr-05, This draft presents a mechanism to simplify one of the cumbersome aspects of mailing, when one needs to send mails only to a subset of mail-ids from an alias [ALIAS] . The basic intention is only to minimize the complication and difficulty of a mail user when a mail needs to be sent to n - m mail IDs i.e. send it to a group Id of n and exclude m from the alias [ALIAS] list. "The EAP-PSK Protocol: a Pre-Shared Key EAP Method", Hannes Tschofenig, Florent Bersani, 19-Jul-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, 13-Jun-05, 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. "DHCP Option for Configuring IPv6-over-IPv4 Tunnels", Soohong Park, 9-May-05, 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. "Congestion Notification Process for Real-Time Traffic", Jozef Babiarz, 18-Jul-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. Defined in this document are, new ECN semantics that provide two levels of experienced congestion along the path for real- time inelastic flows, the required ECN marking behavior in network nodes, and state the required behavior of end-systems that support this function with an explanation of how the two ECN schemes can co- exist safely in 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, 15-Jun-05, 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. "Control Protocol Extensions for Setup of TDM Pseudowires", Yakov Stein, Sasha Vainshtein, 6-Jul-05, This document defines extension to the PWE3 control protocol [PWE3- CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of TDM pseudowires. "FTP Extensions for recursive and archived file transfers", Rajesh Somasundaran, 29-Apr-05, This document describes some extensions to the File Transfer Protocol [1]. These extensions will allow the protocol recursive and archived file transfers. The following new service commands are introduced for FTP: STRC (Store Recursive) RERC (Retrieve Recursive) STAR (Store Archive) REAR (Retrieve Archive) DLST (Directory List) "Connectivity Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, 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. "A No-Op Payload Format for RTP", Flemming Andreasen, 18-May-05, This document defines an no-op payload format for the Real-time Transport Protocol (RTP), and a mechanism to request transmission of an early 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. "Basic Messaging and Presence Interoperability between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensio", Peter Saint-Andre, 14-Jul-05, This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of presence information and single instant messages between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. "Marking Mail Transfer Agents in Reverse DNS with TXT RRs", Markus Stumpf, 2-May-05, 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. This document is part of the LMAP work of the Anti-Spam Research Group (ASRG) of the IRTF. "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 "Multi-party Instant Message (IM) Sessions using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia-Martin, 20-Jul-05, The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party instant message (IM) sessions, or chat rooms, using the centralized conferencing model. "Emergency Call Information in the Domain Name System", Brian Rosen, 19-Jul-05, Location of a caller is essential to processing an emergency call. Location is needed to correctly route the call, and to correctly dispatch help to the right place. Location can be specified in geographic (latitude, longitude) or civic (country, province, locality) forms. This document proposes a DNS-based mechanism to lookup emergency calling URIs and related emergency information from a known civic location in a specific form. Other companion documents propose a non DNS-based approach to determine civic location from geographic location, and describe how to discover a civic location in the appropriate local form(s) for this application. "How to Gain Prominence and Influence in Standards Organizations", Donald Eastlake 3rd, 26-Oct-04, Following some simple guidelines can make it easier for you to gain prominence and influence in most standards organizations. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Florent Parent, Marc Blanchet, 12-May-05, A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model. "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", Joseph Salowey, 25-Apr-05, This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a client and a server by using the Transport Layer Security (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, 12-Apr-05, 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. "Media Conference Server Control for XCON", Cullen Jennings, Brian Rosen, 18-Jul-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. This work is being discussed on the xcon@ietf.org mailing list. This draft has not changed since the 02 version. "Instance Identifiers for SIP User Agents", Cullen Jennings, 18-Jul-05, There are circumstances in SIP-based communications systems in which it is useful to have a long-term, stable identifier for a particular user agent. This specification outlines requirements and discusses existing standards that can be used to satisfy this need. "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. "Push Extensions to the IMAP Protocol (P-IMAP)", Stéphane Maes, 1-Aug-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 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. "A note about 3rd party bombing in Mobile IPv6", Francis Dupont, 23-Jun-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. "MDT SAFI", Gargi Nalawade, 21-Jul-05, There is a need for transporting Multicast Tunnel attributes within and across Autonomous Systems. This draft defines a new Address- Family that can be used to do the distribution. "Inter-domain Requirements for SIP/SIMPLE", Orit Levin, 21-Jul-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 two or more clouds using SIP/SIMPLE. 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. "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. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Xiaoming Fu, Cornelia Kappler, 15-Jul-05, This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used. "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. "Key reuse in Secure MIME for the Session Initiation Protocol(SIP)", Shinya Tachimoto, Kumiko Ono, 20-Jul-05, The SIP User Agent uses Secure MIME (S/MIME) Cryptographic Message Syntax (CMS) EnvelopedData to protect SIP messages for confidentiality. While SIP messages can be encrypted with different keying materials for each message in a dialog, it usually requires a public key operation for each message and the computational cost of such operations are relatively expensive. This draft proposes a method of bidirectional key exchange to reuse keying materials for S/MIME-secured messages in a dialog and use a symmetric key mechanism instead of an asymmetric key mechanism such as a public key operation. The proposed mechanism also achieves the sharing of keying material among multiple entities simply. "EDNS NSID Extension", Rob Austein, 20-Jul-05, With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which actually responded is to have the name server include this information in the response itself. This note proposes a protocol extension to support this functionality. "Middlebox Traversal Issues of Host Identity Protocol (HIP) Communication", Martin Stiemerling, 14-Jul-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 specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. "Framework and Requirements for Layer 1 Virtual Private Networks", Tomonori Takeda, 29-Jun-05, This document provides a framework and service level requirements 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. "Additional cryptographic algorithms for use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 algorithms.", Vladimir Popov, 22-Jul-05, This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet applications. "Transmission of IP Datagrams over Token-Rail Ethernet", Lance Dodd, 10-Mar-05, This memo describes an experimental method for the transmission of IP datagrams over token-rail ethernet. This specification is primarily useful in Metropolitan Area Networks, but can be applied in economies of scale (N, HO, WIDE, O, and others). This is an experimental, not recommended standard. Distribution of this memo is unlimited. "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]. "Multi-homing for small scale fixed network Using Mobile IP and NEMO", Kenichi Nagami, 4-Mar-05, 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. "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Howard Holgate, 16-Mar-05, This document extends the Point-to-Point Over Ethernet (PPPoE) Protocol [2] with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. "IMAP4 POSTADDRESS extension", Alexey Melnikov, 13-Jun-05, 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. "Extensions to OSPF to Support Mobile Ad Hoc Networking", M Chandra, 21-Apr-05, 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. "Email Submission Between Independent Networks", Carl Hutzler, 6-May-05, 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 seeks 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, 10-Jun-05, 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 Information for the Extensible Authentication Protocol (EAP)", Jari Arkko, Pasi Eronen, 20-Jul-05, EAP is typically 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, retaining the EAP media independence principle. "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. "GMPLS Signaling Extensions for the Transfer of Ownership of Label Switched Paths Between the Management and Control Planes", Diego Caviglia, 30-Jun-05, During migration scenarios it may be desirable to transfer the ownership of a Label Switched Path (LSP) from the Management Plane (MP) to the Control Plane (CP), or vice versa. If the LSP is carrying traffic this change needs to be made "in service," that is, without affecting traffic. This memo provides minor extensions to the Generalized Multi Protocol Label Switching (GMPLS) signaling protocol, GRSVP_TE (Generalized Resource Reservation Protocol with Traffic Engineering Extensions), to enable such transfer of ownership and describes the proposed procedures. "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, 3-May-05, 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. "Identity selection hints for Extensible Authentication Protocol (EAP)", Farid Adrangi, 20-May-05, The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. 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 useful in situations where the peer does not receive a lower layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker. The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. "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. "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, 7-Jun-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, 3-May-05, RBridges provide the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. The design allows for zero configuration of switches within a campus, optimal pair-wise routing, safe forwarding even during periods of temporary loops, and the ability to cut down on ARP/ND traffic. The design also supports VLANs, and allows forwarding tables to be based on RBridge destinations (rather than endnode destinations), which allows internal routing tables to be substantially smaller than in conventional bridge systems. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/RBridge "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. "Nested Nemo Tree Discovery", Pascal Thubert, 15-Jul-05, The purpose of this paper is to describe a minimum set of features that extends the Nemo basic support [4] 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, 4-May-05, 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. "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Russ White, 24-May-05, There is a great deal of concern over the security of internetworks built using the Border Gateway Protocol to provide routing information to autonomous systems connected to the internetwork. This draft provides an architecture for a secure distributed registry of routing information to address these concerns. The draft begins with an overview of the operation of this system, and then follows with various deployment scenarios, starting with what we believe will be the most common deployment option. "Licklider Transmission Protocol - Specification", Scott Burleigh, 21-Jul-05, 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. 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. It is stateful, and has no negotiation or handshakes. "SIP Reason header extension for indicating redirection reasons", John Elwell, 6-Jun-05, This proposes an extension to the SIP Reason header to provide additional information concerning retargeting in SIP, a particular motivation being improved interoperability with PSTN diversion. "Internet Mail Architecture", David Crocker, 30-Mar-05, Over its thirty-four year history, Internet Mail has undergone significant changes in scale and complexity, as it has become a global infrastructure service. 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. Today, Internet Mail is marked by many independent operators, many different components for providing users service and many others for performing message transfer. Public discussion of the architecture has not kept pace with the real-world technical and operational refinements. This document offers an enhanced Internet Mail architecture to reflect the current service. "EAP-Double-TLS Authentication Protocol", Mohamad Badra, Pascal Urien, 17-May-05, EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a full TLS handshake is used to mutually authenticate a peer 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 peer and the server. The secure connection established by the PSK handshake may then be used to allow the server and the peer to securely exchange their identity and to update security attributes for next sessions. EAP-Double-TLS allows peer and server to establish keying material for use in the data connection between the peer and the authenticator. The keying material is established implicitly between peer and server based on the TLS Pre-Shared-Key handshake. "Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)", Mark Delany, 28-Mar-05, "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, 18-May-05, 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 [RFC2446], [RFC2447] and [CAP]. This memo applies to all [RFC 2445] extensions and modifications. "Transport Layer Security Session Resumption without Server-Side State", Joseph Salowey, 15-Jul-05, This document describes a mechanism which enables the Transport Layer Security (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, 7-Apr-05, 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. "Supporting unicast replies to multicast queries in the DNS or DISCOVER opcode defined", Bill Manning, Paul Vixie, 3-Jun-05, The QUERY opcode in the DNS is designed for unicast environments. With the development of multicast capabilities in the DNS, it is desirable to have a more robust opcode for server interactions since a single request may generate replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document documents experimental extensions the core DNS specifications that were made during the TBDS effort, to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed during the TBDS project (1999-2000), funded under DARPA grant F30602-99-1-0523. "Domain Suffix Option for DHCPv6", Renxiang Yan, 21-Jul-05, This document specifies a new DHCPv6 (DHCP for IPv6) option which is passed from a DHCPv6 server to a DHCPv6 client to specify the domain suffix name used to perform domain name update. "DHCP Option for Home Agent Discovery in MIPv6", Alper Yegin, 25-Apr-05, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Sina Mirtorabi, Abhay Roy, 6-Apr-05, This document describes an extensible mechanism to support multiple topologies (MT) in OSPFv3. These topologies can be used within the same address family in order to compute different paths for different classes of service, or belong to different address families allowing an integrated definition of address family with OSPFv3. The extension described in this document can further facilitate any future extensions of OSPFv3. "Dialstring parameter for the sip URI", Brian Rosen, 19-Jul-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, 13-May-05, 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 trusted MTAs, in order to minimize impact on end users, are also presented. "Certificate-based Binding Update Protocol (CBU)", F Bao, 9-Mar-05, 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, 21-Mar-05, 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, 19-Jul-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, 24-May-05, 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. "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, 3-Jun-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. This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) "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, 11-Jul-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, 12-Jul-05, This document defines a set of RADIUS Attributes designed to allow both the secure transmission of encryption keys and strong authentication of any RADIUS message. "Bootstrapping a Symmetric IPv6 Handover Key from SEND", Rajeev Koodli, James Kempf, 6-Jul-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. "Certified Server 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. Certified Server 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 practise of service providers that accredit the networks from which sending systems are connecting. "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. "Dry-Martini: Supporting Pseudo-wires in Sub-IP Access Networks", Ping Pan, 15-Jul-05, Several recent developments have significantly affected the carrier access networks. First, all large carrier backbones have migrated to MPLS. Second, carriers are upgrading access circuits with less expensive and high-speed Ethernet. Finally, the carriers will be offering advanced data services over the access network infrastructure. Subsequently, the carriers have to face challenges in migration cost, data transport efficiency and edge-to-edge user traffic management. The Dry-Martini architecture is designed to help the carriers to alleviate these challenges. It provides an approach to establish and maintain pseudo-wires over any access network infrastructure, while stripping off much of the IP/MPLS routing and signaling features that are irrelevant in access network. As a result, all the existing transport equipment, such as SONET/SDH MSPP, can provide MPLS pseudo- wire functionality without much change to the existing platform. Further, due its simplicity, this approach allows the new access devices, such as PON’s and Ethernet CPE’s, to maintain low cost, while being able to interface with MPLS networks. This document assumes that the reader has at least some familiarity with MPLS and pseudo-wire technologies. "Use of Context Transfer Protocol (CxTP) for PANA", Julien Bournelle, 24-Jun-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. The present document describes a solution based on the Context Transfer Protocol (CxTP) to enhance IP handover in mobile environments. This protocol can recover the previously established PANA security context from previous PANA Authentication Agent. "Message Submission for Mail", Randall Gellens, John Klensin, 22-Apr-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. "U-turn Alternates for IP/LDP Fast-Reroute", 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, 9-May-05, This document describes a method for increasing the space available for TCP options. Two new 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, 14-Jul-05, Dual stack transition mechanism (DSTM) provides connectivity between dual stack hosts (i.e., DSTM clients) 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. "IPv6 Label Switching Architecture", 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. "A Session Initiation Protocol (SIP) Event Package for Device Information", Mahfuzur Rahman, 22-Jun-05, 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. Device status information is particularly important to monitoring applications where a user agent would be able to monitor the status of a SIP device from a remote location and be notified of the changes of status. "IANA Considerations for OSPF", Kireeti Kompella, 23-Mar-05, This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. "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. "Token based Duplicate Network Detection for split mobile network (Token based DND)", Masayuki Kumazawa, 12-Jul-05, 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. "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. "Mobile IPv6 - NSIS Interaction for Firewall traversal", Hannes Tschofenig, 29-Apr-05, 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. "Fast Router Discovery with L2 support", DongYun Shin, JinHyeock Choi, 19-Jul-05, For efficient DNA, a host should quickly receive an RA upon a new link-layer connection. This draft presents a quick RA acquisition scheme with the support of a link-layer entity, PoA (Point of Attachment). Upon a new network attachment, the PoA may either trigger an AR (Access Router) to immediately send an unicast RA, "RA Triggering" or send such an RA for itself, "RA Proxying". We may put "RA Triggering" or "RA Proxying" functionality on a PoA to get the optimized result without IPv6 standard change. "Setup and Maintenance of Pseudowires using RSVP-TE", Rahul Aggarwal, 19-Jul-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. "Lemonade HTTP Binding", Stéphane Maes, 13-Jul-05, As part of the Lemonade work to define extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources, Lemonade HTTP binding describes how an HTTP binding may be provided to provide inband notification and facilitate traversal of firewalls and proxy-based deployments. "Payment for Services in Session Initiation Protocol (SIP)", Cullen Jennings, 19-Jul-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. This draft is being discussed on the sipping@ietf.org mailing list. There is currently work to substantially change this draft to use SAML. "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. "Computational Puzzles for SPAM Reduction in SIP", Cullen Jennings, 18-Jul-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, 31-Mar-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 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, 25-Apr-05, 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, 20-Jul-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. "Required functions of User Interface for the Internet X.509 Public Key Infrastructure", Baehyo Park, 8-Jun-05, This document provides guidance to PKI client software developers on what required functions are needed on user interface of PKI client software for human users to generate and verify digital signatures easily and securely. "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, 20-Jul-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, 1-Jul-05, 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, 20-Jul-05, This document defines a mechanism for using the Security Assertion Markup Language (SAML) in concert with the Session Initiation Protocol (SIP). In particular, it provides a way for SIP to refer to SAML objects, and for recipients of SIP messages to use SAML in order to make more informed authorization decisions. "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. "TCP Extensions for Immediate Retransmissions", Lars Eggert, 29-Jun-05, This document classifies connectivity disruptions along an end-to-end path into four types and describes how standard TCP mechanisms can lead to inefficient or over-aggressive sending behavior when connectivity resumes. The proposed techniques for TCP mobility detection and response (LMDR) can improve behavior for some types of disruptions. This document describes another, complementary and orthogonal modification to TCP's retransmission scheme that improves performance for disruption types that TCP LMDR does not address. This extension is based on connectivity indicators, i.e., generic network events that may indicate that end-to-end connectivity has resumed. This document focuses on TCP modifications that use connectivity indicators to increase performance, but does not define the specifics of such connectivity indicators itself. "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. "SIP Event Notification for Internet Media Guides", Yuji Nomura, Henning Schulzrinne, 21-Jul-05, This document specifies an update notification protocol for Internet Media Guides (IMGs) using SIP event notification. The mechanism achieves the timely delivery of IMGs and avoids that IMG receivers have to poll for updates. "Applicability analysis of GMPLS protocols to Layer 1 Virtual Private Networks", Tomonori Takeda, 19-Jul-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, Dave Meyer, 16-Mar-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. "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, 20-Jul-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", Charles Clancy, William Arbaugh, 6-Jun-05, This Internet Draft defines a provably secure Extensible Authentication Protocol method called EAP-PAX. This method is a lightweight shared-key authentication protocol with optional support for provisioning, key management, and identity protection. "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, 18-Apr-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. "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. "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 NAS-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. "Remote Call Control via Mbus and SIP", Rohan Mahy, 15-Jul-05, Mbus (Message Bus for Local Coordination) was designed with remote call control in mind as an Mbus profile. This document discusses changes necessary to the long abandoned call control profile to address recent requrirement, and conditions of use to make the core Mbus appropriate for use among SIP systems on the Internet. "Setting up Mbus Control Sessions with SIP and SDP", Rohan Mahy, 15-Jul-05, Mbus (Message Bus for Local Coordination) was designed for use on individual hosts, subnets, or small multicast networks. This document describes how to setup an Mbus control session using SIP and SDP. Using SIP to setup Mbus allows for authentication, negotiation of an Mbus secret key, and facilitates NAT and firewall traversal. "Fast End-to-End Restoration Mechanism with SRLG using Centralized Control", Jun Choi, 15-Jul-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, 7-Jun-05, Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The SASP protocol provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. "Reg Event Package Extension for GRUUs", Paul Kyzivat, 15-Jul-05, 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, 15-Jul-05, 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. "Framework for Netconf Data Models", Sandeep Admankar, Sharon Chisholm, 22-Jun-05, This memo defines a framework for defining content for Netconf. It defines requirements to enable interoperability, extensibility, easy parsing, usability and predictable modeling. "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. "Guidelines for Writing an IANA Considerations Section in RFCs", Thomas Narten, Harald Alvestrand, 28-Jun-05, 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 transform 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 protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. "A Proposed Media Delivery Index", James Welch, James Clark, 15-Jun-05, 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 deliver applications such as streaming media MPEG video and Voice over IP 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 a data loss at-a- glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. Included is a set of managed objects for SNMP- based management of IP media streams for which an MDI measurement is obtained. The Media Delivery Index measurement and MIB defined in this memo is intended for Information only. "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. "Server Index Query (SIQ) Protocol", Anthony Howe, 24-Mar-05, 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. "IPsec transport mode in Mobike environments", Francis Dupont, 25-Apr-05, 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. "Media Type Specifications and Registration Procedures", Ned Freed, John Klensin, 1-Aug-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, 4-May-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 made obsolete 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, 9-Mar-05, This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 288 pages of listings offer recommendations to improve the clarity of Internet Standards documents (ISDs) and to make them more easily understood by international readers. The recommendations 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. "RIPv2 Cryptographic Authentication", Randall Atkinson, 3-Jun-05, This note describes a 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 adds significant text to the Security Considerations section. "SMTP Service Extension for Reliable Delivery", Alexey Melnikov, Eric Burger, 5-Jul-05, There is an issue with SMTP that RFC 1047 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. "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, 9-Mar-05, 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. "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, Sujay Godbole, 10-Mar-05, 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, 15-Jul-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, 24-Mar-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. "Command Additions for Dynamic Authorization Extensions to Remote Authentication Dial-In User Services (RADIUS)", Murtaza Chiba, 22-Apr-05, This draft proposes to expand RFC3576 by adding commands that allow for, amongst other things, a query interface for resource management and ways to characterize the Change of Authorization messages. "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", Susan Harris, Paul Hoffman, 5-Jul-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. "Network Address to support OSI over IPv6", Alexey Melnikov, 25-May-05, 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. "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. "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 an IETF Draft Submission Toolset", Alex Rousskov, 12-May-05, This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. "Message Header for Indicating Sender Authentication Status", Murray Kucherawy, 5-May-05, 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. "QoS Signaling in a Nested Virtual Private Network", Pratik Bose, Fred Baker, 19-Jul-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. "Internationalized Domain Names Registration and Administration Guidelines for Arabic Characters Group of Languages (Arabic, Persian, Urdu,...)", Rifaah Ekrema, 24-Jun-05, This document provides guidelines for zone administrators(including but not limited to registry operators and registrars), and information for all domain names holders, on the administration of those domain names which contain characters drawn from Arabic Characters Group of Languages. Other language groups are encouraged to develop their own guidelines as needed, based on these guidelines if that is helpful. The document gives basic guidelines for IDN registrars (as it is the case for IETF Document that talks about Japanese, Chinese and Korean domain name registration "RFC 3490"). The document provides also information for owners of IDN that contains Arabic characters on name reservation process. The document does not cover Arabic gTLD or ccTLD problems. Comments on this document can be sent to the authors at arabic-idn-admin@aietf.org. "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, 5-Jul-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]). Smart Cards are hardware security devices that are widely used in data and voice networks to authenticate users and devices, and to enforce security policies on the client platform. EAP-SC enhances the security of authentication methods by enabling the use of Smart Cards for the secure provisioning and storage of keys and credentials, and the secure execution of security sensitive functions. In addition, EAP-SC provides security requirements for the support of Smart Card based Authentication Methods that ensure a uniform level of security complementary to the underlying authentication method. "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. "Analysis and Minimization of Microloops in Link-state Routing Protocols", Alex Zinin, 23-May-05, 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 change in the topology. It is normal, however, to observe short-term loops during the period of topology update 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. "Quality of Service for Ad hoc Optimized Link State Routing Protocol (QOLSR)", Hakim Badis, 14-Apr-05, 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. "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. "Benchmarking Methodology for Wireless LAN Devices", Tom Alexander, Scott Bradner, 3-May-05, 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 IEEE 802.11 WLAN devices. "Service Location Protocol Extensions for Mobile IPv6", Bilhanan Silverajan, 13-Apr-05, 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. "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", Pierrick Morand, Mohammed Boucadair, 2-May-05, This document 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 IP Network Providers (INP) 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. "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 . "The IMG Envelope", Rod Walsh, 1-Jun-05, 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, 21-Jul-05, This is the initial draft of the HIP-RG experiment report. The report summarizes implications of deploying HIP for the end-host TCP/IP stack, applications, and network infrastructure. "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]. "Guidelines and Registration Procedures for new URI Schemes", Tony Hansen, 30-Jun-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. "Media Policy Templates for XCON", Chris Boulton, Umesh Chandra, 13-Apr-05, 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 manipulate 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 conference properties like what streams are supported, what controls are available etc. "pNFS Operations", Brent Welch, 18-Jul-05, 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 provide sufficient coordination of 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 to delegations in that they are associated with leases and can be recalled by the server, but layout information is independent of delegations. "Network Access Control Protocol (NACP)", Susan Thomson, 31-May-05, 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. "Path Computation Service discovery via Border Gateway Protocol", Pierrick Morand, Mohammed Boucadair, 2-May-05, This draft describes a simple mechanism that ease discovery of remote Autonomous Systems (AS) supporting inter-domain MPLS-based constrained tunnels service (this service is also denoted by Path Computation Service (PCSv)) thanks to the use of Path Computation Elements (PCEs). Remote ASs could be managed by a single or 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. "IMAP extension for referencing the last SEARCH result", Alexey Melnikov, 1-Jun-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. "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. "Diameter Mobile IPv6 Bootstrapping Application using PANA", Junghoon Jee, 18-Jul-05, 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 IKEv2/IKEv1 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 in the integrated bootstrapping scenario are defined. "Extensible Mail Protocol (ExMP)", Steven Taylor, 28-Mar-05, 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. "VPLS Interoperability with CE Bridges", Ali Sajassi, 22-Jul-05, 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. "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, 19-Jul-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 and multi-layer networks (MRN/MLN)", Kohei Shiomoto, 19-Jul-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. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referenced in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-layer Network (MLN). This draft defines a framework for GMPLS based multi-region/multi-layer networks and lists a set of functional requirements. "Common Intrusion Detection Signatures Standard", Adam Wierzbicki, 4-Apr-05, 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. "Lemonade and Mobile e-mail", Stephane Maes, 19-Jul-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 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. "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", Seisho Yasukawa, 14-Apr-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. "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. "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. "NSLP for Metering Configuration Signaling", Falko Dressler, 21-Jul-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.fessi-nsis-m-nslp-framework] makes a problem statement, describes scenarios where such a path-coupled configuration of Metering Entities would be useful, elaborates requirements and discusses the applicability of NSIS to the problem. This document suggests a Metering NSIS protocol design, defines Metering NSLP messages, outlines protocol operation and discusses commonalities and differences to other NSLPs. "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 Various Settings in Support for the Push-to-talk Over Cellular (PoC) Service", Miguel Garcia-Martin, 1-Jul-05, 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, 14-Jun-05, 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. "A Framework for Loop-free Convergence", Stewart Bryant, Mike Shand, 9-Jun-05, 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, 19-May-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. This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. "Loose End Message Routing Method for NATFW NSLP", Martin Stiemerling, 19-Jul-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 locate 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 limited to the usage of locating upstream Network Address Translator. "Traversal of HIP aware NATs and Firewalls", Hannes Tschofenig, 20-Jul-05, The Host Identity Protocol is a signaling protocol which adds another layer to the Internet model and (optionally) establishes IPsec ESP SAs to protect subsequent data traffic. HIP is designed to be a middlebox friendly protocol; it allows middleboxes (such as NATs and Firewalls) to participate in the protocol exchange in order to learn the flow identifier. Additionally, adding authentication and authorization mechanisms can help the middlebox to prevent unauthorized end hosts to gain access to the network. This document provides a problem description, goals and lists a few scenarios. "RTP Payloads for Anti-shadow Redundancy", Qiaobing Xie, Joe Schumacher, 15-Jul-05, 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 countermeasure in resolver", Kazunori Fujiwara, 20-Jul-05, This memo describes misconfigurations of DNS authoritative servers and its effect to old DNS iterative resolver servers we experienced. We recommend re-checking DNS authoritative server configuration and advise using newer iterative resolver server implementations. The recommendations made in this document are based on analysis of abnormal DNS resolver server load at large ISP resolver server which has many customers. This is not protocol issue. "Interaction between SIP and HIP", Hannes Tschofenig, 20-Jul-05, This document investigates the interworking between the Session Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and the benefits that may arise from their combined operation. The aspect of exchanging Host Identities (or Host Identity Tags) in SIP/SDP for later usage with the Host Identity Protocol Protocol (HIP) is described in more detail as an example of this interworking. "Path Computation Element Metric Protocol (PCEMP)", Jun Choi, Dipnarayan Guha, 15-Jul-05, 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). We describe a protocol message format for PCE-PCC and PCE-PCE communications derived from this computation model. 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 along with a PCE peer communication protocol and is in line with the PCE WG Charter. "Framework of PCEMP based Layer 1 Virtual Private Network", Jun Choi, 15-Jul-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, 15-Jul-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 and this draft shows how PCEMP can support that. 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. "Things to think about when Renumbering an IPv6 network", Tim Chown, 20-Jul-05, This memo presents a summary of scenarios, issues for consideration and protocol features 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. "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. "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 19-Jul-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. "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. "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. "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3)", David Harrington, Juergen Schoenwaelder, 26-May-05, 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 describes a framework, not a protocol. It does not provide a complete solution - it rather identifies and discusses some key aspects that need discussion and future work. "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. "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. "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. "Supporting IP Multicast over VPLS", Yetik Serbest, 19-Jul-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. "Reliable Server Pooling Sockets API Extensions", Qiaobing Xie, 20-Jul-05, 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). "Purported Responsible Address in E-Mail Messages", Jim Lyon, 19-May-05, 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, Harry Katz, 19-May-05, 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, Meng Weng Wong, 19-May-05, 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, 18-May-05, This document describes the state machines for the General Internet Messaging Protocol for Signaling (GIMPS). The states of GIMPS nodes for a given signaling flow and their transitions are presented in order to illustrate how GIMPS may be implemented. "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. "A proposal to replace HIP base exchange with IKE-H method", Ren Yan, 27-Apr-05, 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, 27-May-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, 7-Jun-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. "Email Forwarding and Redirection Trace Header Fields", William Leibzon, 3-May-05, This memo defines Redirected email trace header field 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. "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. "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. "Digest Authentication Examples for Session Initiation Protocol (SIP)", Paul Smith, Ian Clarkson, 24-Jun-05, RFC3261 [2] recommends that SIP requests be authenticated using HTTP Digest authentication as defined in RFC2617 [3], and many vendors have successfully added this function to their products. However implementation bugs are still being observed both at interoperability events and in the field. This document provides worked examples of Digest authentication usage in SIP. It is intended to help new SIP implementers, and to provide a common set of test authentication examples against which an implementation may be checked. "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. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 5-Jul-05, 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. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools "Nonce response matching for router reachability in IPv6", Greg Daley, 31-Mar-05, 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. "Mobile Network Prefix Delegation", TJ Kniveton, Pascal Thubert, 21-Jul-05, 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. "NAT/FW NSLP State Machine", Constantin Werner, 19-Jul-05, 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. "Media subtype registration for media type text/troff", Bruce Lilly, 27-May-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. "Licklider Transmission Protocol - Motivation", Scott Burleigh, 21-Jul-05, 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. 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. It is stateful and has no negotiation or handshakes. "Licklider Transmission Protocol - Extensions", Stephen Farrell, 21-Jul-05, In an Interplanetary Internet setting deploying the Bundling protocol being developed by the Delay Tolerant Networking Research Group, the 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. LTP is 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. This document describes extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document. "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. "Random Boundary NSEC", Gustavo Lozano, 20-Apr-05, The purpose of this memo is to introduce the RNXD and RNXRR resource records and the necessary modifications to the DNS protocol that permit secure denial of existence without the zone enumeration problems found in DNSSEC [RFC 4033, 4034 and 4035]. "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. "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, 30-Jun-05, 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. "Bounding Longest Match Considered", Russ White, Ted Hardie, 15-Jul-05, 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 [RFC1771] 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. "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, 27-Jun-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 (SPF) for Authorizing Use of Domains in E-MAIL, version 1", Wayne Schlitt, Meng Weng Wong, 7-Jun-05, E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the SPF protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may 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). "Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) Transport Layer Protocol", Ben Harris, 15-Jul-05, This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. 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", Atom Smasher, Simon Josefsson, 25-May-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, 1-Jun-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. Discussion of this document should take place on the ietf-822 mailing list. "Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont, Jean-Michel Combes, 23-Jun-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, 23-Jun-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, 18-Mar-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 is intended for the user of the Mobile Node. "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. "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, 11-Jul-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 and are not always determinable by software algorithms. This is intended to be a central repository for time zone information. The registry does not presume to be the authority for time zone information or rules. This register is simply a place where time zone definitions may be registered for public access. "Security Review of Two MASS Proposals", Russ 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", Xiaodong Duan, Renxiang Yan, 21-Jul-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", Kyle Meadors, Dale Moberg, 8-Mar-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 and Resource Location", David Bryan, Cullen Jennings, 18-Jul-05, This document outlines the motivation and requirements for a Peer-to- Peer (P2P) based approach for SIP registration and resource discovery 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. This is very early work to explore the characteristics that a P2P system might have. It is less secure in many ways than the traditional approach to SIP but has certain other interesting characteristics that may make it desirable in some situations. This work is being discussed on the sipping@ietf.org mailing list. "The Camellia Cipher Algorithm and Its Use With IPsec", Akihiro Kato, 25-Mar-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). "IRC Client Capabilities Extension", Keith Mitchell, 24-Mar-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, 11-Mar-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, 1-Aug-05, This document describes EAP-SKL, an Extensible Authentication Protocol (EAP) method which provides mutual authentication and key derivation based on a pre-shared secret. EAP-SKL relies on the cryptographic protocol SKEME (Secure Key Exchange MEchanism protocol), and hence may benefit from its simplicity and the provable security. EAP-SKL complies with the mandatory requirements for an EAP method which is intented for deployment in Wireless LAN environments. "IPFIX Aggregation", Falko Dressler, 21-Jul-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 multiple similar flows is aggregated into one meta-flow record. The degree of similarity can be customized using aggregation rules. To ensure efficient communication of both aggregated flows and the aggregation rules used the IPFIX Protocol and IPFIX Information Model are slightly extended to allow two new abstract data types and a new type of template set. "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", Jari Arkko, Christian Vogt, 20-Jul-05, IP mobility support typically implies that packets incur lengthened routing paths by virtue of them being sent through a stationary home agent. However, "route optimization" in the Mobile IPv6 protocol enables normal and direct routing between a mobile node and its correspondent node. To securely allow this feature between initially unacquainted parties, the so-called return-routability procedure was built into Mobile IPv6. Recently, a number of improvements or optional alternatives have been suggested to the standard procedure. This document summarizes the goals for enhancements to route optimization, discusses the security threats that such enhancements must consider, categorizes the techniques that one can use for optimization, highlights the key ideas of various recent proposals, evaluates the performance gain that such proposals can yield, and compares these 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. "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, Lakshminath 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, 6-May-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, 10-Jun-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, 1-Aug-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, 30-Mar-05, NAT devices are available from a number of vendors and are in use by several residential and enterprise users. Yet, there is much variation in how the NAT devices work. Application developers, network administrators and users of NAT devices seek some level of uniformity and predictability in how various of the NAT devices operate. The objective of this document is to specify the operational and behavioral requirements on the NAT devices while processing TCP packets. A NAT device that conforms to the requirements listed in the document will bring predictability in how NATs operate with regard to TCP packet processing. A NAT device is said to be IETF behave compliant when it complies with the requirements outlined in this document and two other companion documents ([BEH-GEN], [BEH-UDP]) which outline the requirements for processing IP, ICMP & UDP. "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, 18-Mar-05, This draft discusses issues related to the application of peer to peer (P2P) technologies to SIP in particular, and Internet communications in general. After an analysis of the P2P and non-P2P capabilities of SIP, this draft proposes that a P2P protocol be standardized in the IETF as a protocol used between a Registrar/Proxy/Redirect server and a Location Service. This allows the operator of a Registrar to decide how much registration state is be stored locally and how much can be distributed using the P2P network to a distributed Location Server. A number of DHT (Distributed Hash Table) P2P protocols that solve some similar functions are given as examples and could be used as input to this work. Finally, existing SIP and P2P work is surveyed with respect to this proposal. "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, 18-Jul-05, This document defines extensions to RSVP-TE (Resource Reservation Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to notify about control plane resources saturation, when an LSR runs out of control plane resources available to support any additional 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)", Russ 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, 26-Apr-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", Kohei Shiomoto, 1-Apr-05, This document explains and clarifies 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 and proper interpretation of published RFCs. "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, 5-Apr-05, This document documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". "RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol", David Auerbach, 15-Jun-05, The main intent of this document is to define a Media Gateway Control Protocol (MGCP) package to control the reporting of metrics supported by the VoIP metrics block in RTCP Extended Reports as specified in [RFC 3611]. It also allows the call agent to control whether or not the gateway will request a peer device via SDP to send the VoIP metrics block in RTCP Extended Reports and whether it will respond positively to such requests from the peer device. Besides this primary focus, this package also allows the reporting of metrics defined for RTCP Sender Reports and Receiver Reports [RFC 3550] and the reporting of session description parameters (based on the ones defined in RFC 2327, RFC 2198 etc.). "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", Paul Hoffman, Pasi Eronen, 15-Jul-05, This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. "End-to-End Capabilities Support for Remote Authentication Dial In User Service (RADIUS)", Avi Lior, Farid Adrangi, 21-Jul-05, This document describes a new RADIUS attribute, End-to-End-Capability which can be used by a NAS to indicate its RADIUS capabilities to the RADIUS server and also allows the RADIUS server to request certain capabilities from the NAS. "RADIUS Mobile IPv4 extensions", Madjid Nakhjiri, 15-Jul-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, 30-Jun-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, 22-Jul-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, 16-Jun-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, 16-Jun-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 Auth Server MIB (IPv6)", David Nelson, 18-Jul-05, This memo updates RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version neutral IP address formats. "Extracting RFCs", Scott Bradner, 8-Jul-05, Many people have expressed a desire to extract material from IETF RFCs for use in documentation, textbooks, 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 RFC3978 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-Segment Pseudowire Setup and Maintenance using LDP", Florin Balus, 18-Jul-05, [MS PWE3 Requirements] describes the requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. The current specification of the PW Architecture [PW ARCH] defines the PW as a single Segment entity, connecting the Attachment Circuits between two Ultimate PEs (U-PE). The current procedures for establishing a single segment PW (SS-PW) is described in [PW Control], where typically an LDP session is established between the ultimate PEs handling the Pseudowire End Service (PWES). No intermediate nodes, between the PEs, are aware of the PW. The purpose of this draft is to specify new LDP extensions, end to end signaling procedures to address the related requirements specified in [MS-PWE3 Requirements]. The proposed procedures follow the guidelines defined in [RFC3036bis] and enable the usage of addressing schemes (L2FECs) and other TLVs already defined for PWs in [PW Control]. The solution described in the draft provides a MS-PW Operational Model, Signaling Procedures consistent with the regular (SS-)PWs, in order to enable seamless implementation, deployment. The resulting MS-PW building blocks accommodate and enhance LDP-VPLS, VPWS solutions with minimal changes in the Information Models and Software Modules related to the L2VPN functionality. "RADIUS Acct Server MIB (IPv6)", David Nelson, 19-Jul-05, This memo updates RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version neutral IP 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", Martin Thomson, James Winterbottom, 28-Jun-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 XML Path Language (XPath) filters for selecting the correct elements for signing. "A Two-way Active Measurement Protocol (TWAMP)", Kaynam Hedayat, 14-Jul-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, 19-Jul-05, This document describes a means by which a IP-device may request location from a Location Server using HTTP as a GeoPriv 'using protocol'. "Multicast Emulation over VPLS", Prabakaran Ts, Musthafa As, 30-Mar-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, 15-Apr-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, 22-Jul-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-Apr-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, 21-Jul-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, 19-Jul-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, 1-Jun-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. "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. "Generic Aggregate RSVP Reservations", Francois Le Faucheur, 1-Jul-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 . Also, [RSVG-AGG] does not address the case where multiple Aggregate reservations are needed for the same DSCP from the same Aggregator to the same Deaggregator. However, there are scenarios requiring aggregate reservations for IPsec tunnels or requiring multiple aggregate reservations for the same DSCP from a given Aggregator to a given Deaggregator. This document specifies the incremental RSVP extensions beyond those defined in [RSVP-IPSEC] and [RSVP-AGG] to support such reservations. "Routing across Nested VPNs", Fred Baker, 19-Jul-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. "Indicating and Negotiating Text Script", Bruce Lilly, 7-Apr-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, 18-Jul-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. This draft is being discussed on the sip@ietf.org mailing list. "SIP Offer/Answer with Multipart Alternative", Dan Wing, Cullen Jennings, 12-Jul-05, SIP needs a mechanism for general backwards compatibility for moving from SDP to SDPng or moving from non end-to-end encrypted SDP to end- to-end encrypted SDP. This document specifies how a SIP offer uses multipart/alternative, and how an answer indicates which part was selected. "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, 28-Jun-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, 21-Jul-05, This draft provides the guideline to consider generalized multi- protocol label switching (GMPLS) traffic-engineering (TE) attributes for constraint-based shortest path first (CSPF) 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 link, transit links and an egress link to establish a GMPLS label switched path (LSP) appropriately. "A Framework of Media-Independent Pre-Authentication (MPA)", Yoshihiro Ohba, 19-Jul-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. [I-D.ohba- mobopts-mpa-implementation] is an accompanying document which shows two sets of implementation of MPA including 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, 15-Jul-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, 21-Jul-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, 21-Jul-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, 14-Jul-05, This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. "Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)", Jean-Louis Le Roux, 19-Jul-05, This document provides an evaluation of Generalized Multi-Protocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLN) and Multi Region Networks (MRN). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. "NAT Classification Test Results", Cullen Jennings, 18-Jul-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. The test results here are very old and work is being done to update them with more current information. This work is being discussed on the ietf-behave@list.sipfoundry.org mailing list "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. "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, 13-Jul-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 draft "Real-time ECN Use Cases". 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]. "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 Auth Client MIB (IPv6)", David Nelson, 18-Jul-05, This memo updates RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version neutral IP address formats. "RADIUS Acct Client MIB (IPv6)", David Nelson, 19-Jul-05, This memo updates RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version neutral IP address formats. "IRIS - A Routing Registry (rreg) Type for the Internet Registry Information Service", Kengo Nagahashi, 21-Jul-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, 20-Jul-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, 19-Jul-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 by which a single multicast tree in the backbone can be used to carry traffic belonging only to a specified set of one or more multicast groups from one or more VPLSs are also described. "Associating SMPTE time-codes with RTP streams", David Singer, 1-Jun-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. "Operating Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN)", Bryan Ford, 9-May-05, This document discusses the operating principles of Network Address Translator (NAT) devices and the behavioral properties required to make NAT more predictable and compatible with diverse application protocols. First, this document presents an architectural model for NAT devices and defines important terms used in conjunction with NAT operation. The architectural model sets the stage for a set of concrete recommendations for NAT implementers. 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, 12-Jul-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, 25-Jul-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, 18-Jul-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, 20-Jul-05, 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. Some work has been done in the area of bootstrapping in the IETF recently. So far, the focus was on creating security associations. This document aims to attach authorization information to the bootstrapping process. "The LDAP Don't Use Copy Control", Kurt Zeilenga, 19-Jul-05, This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension 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, Pekka Nikander, 19-Jul-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 Versioning (DAV)", Rohan Mahy, 14-Jul-05, This document describes an alternative to XCAP (XML Configuration Access Protocol) for manipulating SIMPLE resource and authorization lists using WebDAV. XCAP and WebDAV are similar in that they are both usages of HTTP. Since servers could support both simultaneously, WebDAV support is a logical progression from XCAP for clients that require locking, version control, document moves or other features of WebDAV. "A Location Event Package using the Session Initiation Protocol (SIP)", Rohan Mahy, 15-Jul-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)", Henning Schulzrinne, Jonathan Rosenberg, 20-Jul-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. "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-Jul-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, 20-Jul-05, To ease the maintenance of BGP [BGP] 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, 16-Jun-05, This document provides requirements and a framework for PWE3 Operation Administration and Maintenance (OAM).It extends the PWE3 architecture reference model by including a detailed model of the access portion of the network. This document targets to provide clarification and applicability guidelines for the on going OAM work by describing different implementation solutions and detailing the Pros and Cons of each solution (section 7). "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 tool for simple tests of GIMPS implementations", Ingo Juchem, 20-Jul-05, When implementing signaling protocols such as GIMPS, implementors need a way to test the functionality and measure the performance of their own implementations. In this document, we try to provide a sketch for such a testing tool, a simple, stateless "Ping" NSLP, which works similar to ICMP Ping. This tool is able to traverse a path from a source to a destination along signaling aware network nodes and collect various data that could be useful for identifying each node it is passing. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, 7-Jul-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, 19-Jul-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 system. 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 associations 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, 21-Jul-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, 1-Aug-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, 20-Jul-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, 21-Jul-05, This document motivates and 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 measurement 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 and Multimedia Broadcast/Multicast Service", Per Frojdh, Magnus Westerlund, 14-Jul-05, The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use 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, 20-Jul-05, Several MANET routing protocols have been recently promoted to experimental RFCs. However, autoconfiguration of MANET networks is still an unsettled area. This document proposes a protocol for autoconfiguration for both IPv4 or IPv6. Its corner stone is an conflict-detection algorithm. It aims at conceptual simplicity: essentially, each node periodically sends its addresses and an identifier. Conflicts are detected as identifier mismatches. This protocol might be used with any MANET protocol, although it naturally suits the OLSR routing protocol (on which we focus), with a light increase of control message overhead. "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", Hannes Tschofenig, 20-Jul-05, The purpose of MOBIKE is the creation and maintenance a set of available addresses and provide them to the communication partner. A MOBIKE peer should have some information about the status of each address and interface in order to execute the respective actions. Examples may comprise switching from address or interface 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", Hideki Arai, Motoharu Kawanishi, 16-May-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, 21-Jul-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, 5-Jul-05, Future IPDVB networks will require a more powerful IP address configuration management as it is 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 dynamic IP address configuration in IPDVB networks. "SIP (Session Initiation Protocol)-Unfriendly Functions in Current Communication Architectures", Gonzalo Camarillo, 20-Jul-05, This document gives an overview to SIP-unfriendly functions in current communication architectures. These functions are generally implemented in SBCs (Session Border Controllers). The purpose of this document is to help the IETF community understand what SIP- unfriendly functions can be found in existing networks 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, SIP-friendly 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, 20-Jul-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, 5-Jul-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. "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-Mar-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, 21-Jul-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, 21-Jul-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. Essentially, the mechanism is to enable the network operators to setup multiple primary and backup pseudo-wires, and only use one to carry the data traffic itself. Upon network failure, user traffic can be switched over to the next “best” pseudo-wire base on preference levels. This document first describes the motivation of the work base on the discussions with a number of carriers. Then we define the protocol extension itself. "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. "Operational, Deployment and Interworking Considerations for GMPLS", Kenji Kumaki, 21-Jul-05, In order to deploy GMPLS technology in the existing IP/MPLS networks, various operation, deployment and interworking aspect of MPLS/GMPLS needs to be addressed. From the deployment perspective, 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. Another very important aspect 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. In this draft, we highlight some deployment and MPLS/GMPLS interworking requirements and propose solutions to address them. We also highlight some operation aspects and the possible solution and provide applicability statement for the available options. "Network initiated handover in fast mobile IPv6", Telemaco Melia, 19-Jul-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, 19-Jul-05, 3GPP2 is working in specifying a way to allow the mobile network subscribers to configure the Firewalls in their network according to their needs[3]. "BGP Point to Multipoint LSP", Satoru Matsushima, 20-Jul-05, This document specifies the way that is to make point to multipoint (p2mp) LSP using BGP. BGP update message 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, 15-Jul-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. "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", Jari Urpalainen, 22-Feb-05, Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. Updates to this data requires transporting of the entire XML instance document between hosts, unless there's a mechanism that allows transmitting only the changes of XML documents. This memo describes a framework utilizing XML Path language (XPath) selectors which can be used to apply a set of patches to an existing XML document. "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. "P3P Policy Attributes for LDAP", Mark Wahl, 8-Mar-05, This document defines attributes that can be retrieved via Lightweight Directory Access Protocol version 3 (LDAP) requests, which contain URIs pointing to the privacy policy documents describing access to a directory server and that apply to the contents of a subtree of entries. These attributes enable a directory client to retrieve the privacy policies before sending further requests to the directory server. "MASS impacts upon reputation", Douglas Otis, 28-Mar-05, This document responds to findings in the MASS review by Russell Housley et al, with additional considerations from the perspective of reputation assessment. This also includes speculations on possible solutions and implementations for the MASS proposal: DomainKeys. "Multihoming of (1,1,*) configured networks in Network Mobility Support", Pekka Valitalo, 8-Mar-05, This draft describes, how NEMO support works with multiple care-of addresses, in a multihomed mobile network, when there exists one home agent, one mobile router, and one or more mobile network prefixes. Solution to the problem, how to register multiple care-of addresses bound to a single home address in a NEMO support, is proposed. "MIME media types for SCCP and TCAP Objects", Vikram Nair, 8-Mar-05, This document describes MIME types as per the rules defined in RFC 2048 [2] for application/SCCP and application/TCAP objects, for use in SIP applications. These MIME definitions will be typically used in deployments where interworking to the PSTN is required for call related and non-call related messages exchanged using services of SCCP and TCAP SS7 stack layers. "ROHC (Robust Header Compression) in NEMO network", Ana Minaburo, 7-Jul-05, This document defines the use of ROHC header compression mechanisms for the NEMO Basic Support protocol [7]. The idea is to use both NEMO and ROHC as they have been defined. In the NEMO Basic Support protocol, the tunneling between the Mobile Router (MR) and the Home Agent (HA) of the MR is done over different access technologies. Some of these technologies are wireless (e.g. Wireless LAN, 3G or PPP) and have scarce resources by nature, the use of ROHC compression can be useful to reduce the bandwidth consumption. "Collected extensions to IMAP4 ABNF", Cyrus Daboo, Alexey Melnikov, 18-Jul-05, Over years many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference this document collects most of such ABNF changes in one place. This document updates ABNF in RFC 3501. "Augmented BNF for Syntax Specifications: ABNF", Dave Crocker, Paul Overell, 10-Mar-05, Internet technical specifications often need to define a format syntax. Over the years a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. "IP Fast Reroute Using Notvia Addresses", Stewart Bryant, Mike Shand, 10-Mar-05, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "notvia" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", Ying Qiu, 10-Mar-05, When a mobile node roams, its location information can be revealed by monitoring the IP addresses in its IP packets. This document proposes a technique for hiding a mobile node's care-of adress from its correspondent node and its home address from an eavesdropper using reverse tunelling. It also proposes another technique for preventing movement tracing of a mobile node by an eavesdropper during route optimization. "Common presigned OCSP Response database format", piyush Jain, 16-Mar-05, This specification defines an optimal format for pregenerated Online Certificate Status Protocol (OCSP) response database, that can be generated by a keyed OCSP responder and used by a keyless OCSP responder to serve OCSP queries. "Scalable NAT-PT Solution", Soohong Park, 16-Mar-05, This document provides scalability extension to NAT-PT. The extension is based on the use of DNS-ALG and exchange of load metrics amongst a cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT. mNAT-PT is valuable in connecting large V6 domains to legacy V4 domain. "The PROTO Adviser", Dave Meyer, 16-Mar-05, The PROTO Adviser is a designated IETF community member who will provide support to PROTO document shepherds during the first year or so after the IETF working groups begin using PROTO. He or she primarily serves as a source of institutional knowledge for the shepherds and Chairs (and any community member with an interest in PROTO). This document describes roles of the PROTO Adviser. "RObust Header Compression (ROHC): Support for Reordering and Constant IP-ID", Rohit Kapoor, 17-Mar-05, RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). This document seeks to add support for two issues to basic RoHC profiles, (a) the ability to handle reordering and (b) avoid extra header overhead when IP-ID is a constant value. The first issue can be supported by making the value of p (which is part of the RoHC interpretation interval) configurable. The second issue is already supported in the IP Profile of RoHC (RFC 3843). The discussion of this IP-ID issue in the current document merely replicates the discussion in RFC 3843 regarding constant IP-ID. "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol", Ben Harris, 8-Jul-05, This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol which mitigate the weakness of the cipher's key-scheduling algorithm. "IS-IS BFD Enabled TLV", Christian Hopps, 21-Mar-05, This document describes a TLV for use in the IS-IS routing protocol that allows for the proper functioning of the Bidirectional Forwarding Detection protocol (BFD). There exists certain scenarios in which BFD will fail to detect a forwarding plane failure without use of either this TLV or some other method. "POST Once Exactly (POE)", Mark Nottingham, 21-Mar-05, This specification describes a pattern of use that allows HTTP clients to automatically retry POST requests in a manner that assures no unintended side effects will take place, and defines mechanisms to allow implementations to automatically determine when such patterns are supported. "A Uniform Resource Name Namespace For The EPCglobal Electronic Product Code (EPC)", Michael Mealling, 21-Mar-05, This document describes a URN namespace that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", Marshall T. Rose, Eamon O'Tuathail, 13-May-05, This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. "Integration of Header Compression over IPsec Security Associations", Emre Ertekin, 27-May-05, Internet Protocol security mechanisms, such as IP Security (IPsec) [IPSEC], provides various security services for IP traffic. However, the benefits offered by IPsec may come at the cost of increased overhead. This document identifies a methodology for integrating header compression (HC) over IPsec (HCoIPsec). HCoIPsec proposes to reduce the amount of packet overhead associated with the transmission of traffic over tunnel mode security associations. "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, 7-Jul-05, The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end-to-end performance between 2 points. This memo defines 2 sets of metrics to extend these end-to-end ones. It defines spatial metrics for measuring the performance of segments along a path and metrics for measuring the performance of a group of users in multiparty communications. "RTP payload format for the future scalable and wideband extension of G.729 audio codec", Aurelien Sollaud, 14-Jul-05, This document specifies a real-time transport protocol (RTP) payload format to be used for the future scalable and wideband extension of the International Telecommunication Union (ITU-T) G.729 audio codec. A media type registration is included for this payload format. "LDP Implementation Survey Results", Bob Thomas, Loa Andersson, 23-Mar-05, Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops [RFC3031]). 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. One such protocol called LDP [RFC3036] is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from proposed to draft standard. "ISAN URN Definition", Michael Dolan, 26-Apr-05, The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN. "Firewall Traversal for Mobile IPv6", Yang Shen, 23-Mar-05, As important security devices, firewalls are widely deployed in ISP and enterprise networks. However, currently firewalls, which are essentially designed for fixed networks, are difficult to support Mobile IPv6. Unless firewalls are aware of the detail of mobile IPv6 protocol, they impacts smooth operation of the protocol and can be harmful to mobile IPv6 deployment. "The OCB Authenticated-Encryption Algorithm", Ted Krovetz, Phillip Rogaway, 24-Mar-05, This document specifies OCB 2.0, a shared-key encryption scheme combining privacy and authenticity. This blockcipher-based, single- pass mechanism provides privacy and authenticity for a message, plus authenticity for any associated header. It does this in the most simple and efficient way known. "Collision-Resistant Secure Hashing: CR-SHA1, CR-MD5, et al", Rick van Rein, 24-Mar-05, This specification adapts hash algorithms to make them resist collision attacks. As a result, hash algorithms can be used securely for a much longer period than is currently the case. This is of particular interest to long-lived utilisations such as timestamp signatures. "Native Application Programming Interfaces for the Host Identity Protocol", Miika Komu, 25-Mar-05, This document proposes extensions to the current networking APIs. Using the extented APIs, HIP aware applications can gain a better control of the HIP layer and Host Identifiers. For example, the applications can query and set security and mobility related attributes, or specify their own Host Identifiers in a host. "Handling IPv6 Sources and Destinations in the MPLS and GMPLS TE MIB Modules", Alan Davey, 25-Mar-05, This document describes how to configure or monitor a Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) using the MPLS and GMPLS TE MIB module where the ingress and/or egress routers are identified using IPv6 addresses. "Mobile SCTP (mSCTP) for Internet Mobility", Seok Koh, 28-Mar-05, This document discusses the use of SCTP for Internet mobility support, called mobile SCTP (mSCTP). SCTP can be used for IP mobility from the multi-homing features. The SCTP with the ADDIP extension (or mSCTP) would provide soft handover for the mobile host without support of routers or agents in the networks. For location management, the mSCTP could be used along with Mobile IP, Session Initiation Protocol or Reliable Server Pooling. We discuss the use of mSCTP along with Mobile IP for Internet mobility support. "Requirements for Private Messaging in Centralized Conference Environments", Aki Niemi, Miguel Garcia-Martin, 29-Jun-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). MSRP can be used in a centralized conference just as any other media type. This document provides requirements in support for MSRP in centralized conferences, including requirements to provide private instant messages within a conference. "Anycast Addressing in IPv6", Joe Abley, 28-Mar-05, The IPv6 Addressing Architecture includes some restrictions on the use of anycast addresses. These restrictions were intended to protect the nascient IPv6 Internet from possible harmful consequences that might result from widespread use of anycast as a mechanism to distribute services. "NFSv4 Global Namespace Problem Statement", Charles Fan, 28-Mar-05, NFS is one of the primary data access protocols for NAS, and naturally NFS users have been demanding a global namespace for NFS. This document intends to explain the rational for a global namespace, why it is an important feature for a network file system protocol, and the problems that a global namespace for files would solve. "Attacks on Cryptographic Hashes in Internet Protocols", Paul Hoffman, Bruce Schneier, 6-Jun-05, Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. "The Atom Publishing Protocol (Basic)", Robert Sayre, 28-Mar-05, 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-06.txt). "Label Distribution Protocol Extensions for Point-to-Multipoint Label Switched Paths", Ina Minei, 19-Jul-05, This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described. There can be various applications for P2MP LSPs such as IP multicast. Specification of how such applications can use a LDP signaled P2MP LSP is outside the scope of this document. "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", Paul Hoffman, 23-Jun-05, Some implementations of IP Security (IPsec) may want to use a pseudo- random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. "A Description of the Rabbit Stream Cipher Algorithm", Erik Zenner, 20-May-05, This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit IV. The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with internet protocols where large amounts of data have to be processed. "IP over Burrito Carriers", Mike Schulze, William Lohsen, 31-Mar-05, IP over Burrito Carriers describes an experimental method for the creation of edible data packets. This standard is intended to be implemented in metropolitan area networks due to the preexisting burrito delivery infrastructure. While currently only flour tortillas have been found acceptable for encapsulating the data contained in the packet, tests are underway to determine the viability of using corn tortillas. One must be wary of disreputable IP over Burrito service providers as packet corruption and bad data handling can result in damage to the receiving unit and may result in an extremely messy packet rejection. Conveniently, there is a rating system already in place. While the rating by the health department doesn't ensure proper data encapsulation, it does allow the end user to determine if the service provider's quality to cost ratio is adequate. This is an experimental standard, not a recommended standard. "Indicating Media Handling Feature in Session Initiation Protocol (SIP) for Seamless Session Mobility", Xu Mingqiang, 31-Mar-05, Session mobility allows a user to transfer an ongoing communication session from one device to another device. Seamless session mobility is very important for real time multimedia applications. This document defines a new option tag in SIP to indicate media handling feature during the transfer of communication session from one device to another device to achieve seamless session transfer without disruption of media streams. "Buffer Handling Media Attribute in Session Description Protocol (SDP) for Seamless Session Mobility", Xu Mingqiang, 31-Mar-05, Session mobility allows a user to transfer an ongoing communication session from one device to another device. Seamless session mobility is very important for real time multimedia applications. This document defines a new buffer handling property attribute in Session Description Protocol (SDP) to indicate media handling feature. This new attribute will enable seamless transfer of SIP communication session from one device to another device without disruption of media streams. "The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml and application/pls+xml", Max Froumentin, 6-Jun-05, This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language XML, the Speech Synthesis Markup Language (SSML), The Speech Recognition Grammar Specification (SRGS), Call Control XML (CCXML) and the Pronunciation Lexicon Specification (PLS). "Cisco's Mobile IPv4 Host Configuration Extensions", Kent Leung, 14-Jul-05, An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. 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 provide 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 Cisco vendor- specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. The content is provided for informational purpose only. "Multiple Attachments for EDI-INT", Kyle Meadors, 4-Apr-05, The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided. "Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004", Chih-Chang Hsu, 22-Jul-05, In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a protocol intended for small group multicasting. It combined three similar datagram simulcasting protocols that were submitted as earlier Internet Drafts by a number of different research groups. After that, researchers in those groups worked together to further develop, experiment and conduct standardization in IETF as well as in the open source community. This resulted in several implementations of protocol stacks, systems of multi-party video conference and group management, and mechanisms for harmonizing XCAST with ASM and SSM. In addition, an XCAST backbone for various experiments has been launched to operate inter-continentally. One of the main purposes of this document is to summarize the efforts undertaken by XCAST community as "best current practices" that would then be formally introduced to the IETF/IRTF community. In addition, we raise an issue concerning IANA resource allocation, which prevents us from widely expanding our experimental networks as well as distributing our software. Finally, we request IESG and other experts to check the validity of our proposed protocol and make any suggestions about how IANA can assign appropriate resources accordingly. "IANA Considerations for XCAST (Explicit Multi-Unicast)", Chih-Chang Hsu, 4-Apr-05, XCAST (Explicit Multi-Unicast) is an experimental protocol for small group multicasting. This protocol requires IANA allocations for a new type of multicast address, a routing type of IPv6 routing header, an option type of Destination Option header and an option header of IPv6 Hop-by-Hop Options header. This document contains guidelines to IANA about what allocations are required for XCAST protocol. "Basic iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events", Doug Royer, 4-Apr-05, This is the second release of iTIP. After having learned from RFC-2446 where most of this text comes from. 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. "COSINE LDAP/X.500 Schema", Kurt Zeilenga, 5-Apr-05, This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects. This document obsoletes RFC 1274 and RFC 2247. "SCTP NAT Traversal Considerations", Qiaobing Xie, 5-Apr-05, This document defines and classifies scenarios for the usage of SCTP in networks with NATs and similar middleboxes. "A NULL MX Resource Record means "I never accept email"", Mark Delany, 6-Apr-05, A common strategy of SMTP servers when deciding whether to accept an email or not, is to ensure that the 2821.MailFrom contains a domain willing to accept non-delivery email (aka bounces). When the 2821.MailFrom domain has a DNS MX Resource Record (RR), it is making an explicit statement that it is willing to accept email. However, when the domain has just a DNS A (or AAAA) RR, there is no such clarity as most hosts on the Internet advertise an A RR regardless of whether they want to accept email or not. The NULL MX RR formalizes the existing mechanism by which a domain communicates that it will never accept email. "Definitions of Managed Objects for New Generation Asymmetric Digital Subscriber Lines (NG-ADSL)", Moti Morgenstern, Menachem Dodge, 6-Apr-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 parameters of "Asymmetric Digital Subscriber Line" family of interface types, especially including ADSL, ADSL2, and ADSL2+. "Multicast Extensions for LDP", IJsbrand Wijnands, 6-Apr-05, Forwarding multicast packets efficiently over an MPLS core requires Point-to-Multi-Point (P2MP) or Multi-Point-to-Multi-Point (MP2MP) LSP's between one or more Ingress routers and one or more Egress routers. For efficient forwarding core LSRs need to replicate labeled multicast packets where the branches of the P2MP/MP2MP tree diverge. This draft specifies LDP extensions that enable it to build P2MP/MP2MP LSPs in a receiver initiated manner. "Mobility Header Home Agent Switch Message", Brian Haley, 7-Apr-05, This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. "Diameter/RADIUS Vendor Specific AVP Translation", David Mitton, 8-Apr-05, This document describes how a Diameter protocol application would interact with a RADIUS protocol application with respect to translation of Vendor Specific Attributes and AVPs in both networks. This interactions between Diameter applications and RADIUS specified in this document are in addition to that specified in the Diameter Base, the Diameter NAS Application and RADIUS. In this sense, this document extends the Base Diameter protocol and requests an addition to the RADIUS attribute space. "MPLS Multicast Encapsulations", Toerless Eckert, 8-Apr-05, RFC 3032 established two data link layer codepoints for MPLS: one to indicate that the data link layer frame is carrying an MPLS unicast packet, and the other to indicate that the data link layer frame is carrying an MPLS multicast packet. This specification updates RFC3032 by redefining the meaning of these two codepoints. The former "multicast codepoint" is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". The former "unicast codepoint" is to be used in all other cases. Whether the data link layer payload is a unicast MPLS packet or a multicast MPLS packet is now to be determined by looking up the top label, rather than by the codepoint. "More Fixed Identities for Private Hosts behind NAT IDNAT", Mohammad Awad, 11-Apr-05, In many flavors of the nowadays address translators, real addresses are assigned to private hosts without preserving uniqueness; the same real address can be shared among multiple private hosts and the same private host can also obtain different addresses over the time as well. As a result the addresses used for private hosts reflect some kind of ambiguity on those hosts. This proposal introduces the IDNAT model as a solution for that address ambiguity problem. This solution concentrates on defining another virtual identity to identify private hosts in replacement of the ambiguous assigned real IP address. Through agile practices this identity can be assigned to each of the private hosts, and the hosts themselves will be aware of their assigned Ids which are going to be quite unique throughout the private region as well as the entire Internet realm. Moreover, the new Id will play a centric role in the packets transmission so as to identify the private host outside the private region and hence defeating the undesired ambiguity. "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", Hee Jung, 11-Apr-05, This document proposes a scheme to support Fast Handover over HMIPv6 networks. The MIPv6 mobility could be more enhanced by combining FMIPv6 with HMIPv6, in which MIPv6 is benefited from all the advantages of the respective schemes. This document describes how to use FMIPv6 for HMIPv6 (F-HMIPv6). The F-HMIPv6 is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the tunnel for fast handover is established between MAP and NAR, rather than between PAR and NAR. For this purpose, the MN exchanges the FMIPv6 messages with MAP, not PAR. The F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages. For the F-HMIPv6, it is proposed to define a new flag 'F' in the HMIPv6 MAP option. "Compact Bundled RTP Format for EVRC Speech", Qiaobing Xie, 11-Apr-05, This document defines a compact (header-free) bundled format for EVRC RTP payload format. This compact bundled format is an addition to the bundled format and header-free format as already defined in RFC 3558. It is expected that some VoIP applications, such as Push-to-Talk, may find this compact bundled format more advantageous to use. "PCE Communication Protocol Generic Requirements", Jerry Ash, 3-May-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 or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. There are multiple components in the Path Computation Element (PCE)- based path computation model, including PCE discovery and the PCE communication protocol. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to PCEs. This document specifies generic requirements for a communication protocol between PCCs and PCEs, and between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. "TLS support in ITOT", Alexey Melnikov, 11-Apr-05, This document describes an extension to the ITOT (ISO Transport Service on top of TCP) class 2 service that allows an ITOT Initiator and Responder to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives ITOT agents the ability to protect some or all of their communications from eavesdroppers and attackers. "ASN.1 Schema Representation for XER Encoding Instructions", Steven Legg, 12-Apr-05, ASN.1 Schema is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.1 Schema representation for the XML Encoding Rules (XER) encoding instructions. "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", Magnus Nystrom, 27-Jun-05, This document provides test vectors for the HMAC-SHA-224, HMAC-SHA- 256, HMAC-SHA-384 and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and URIs to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. "Link Characteristics Information for Mobile IP", Soohong Park, 10-Jun-05, This document introduces a model for link characteristic information delivery from the mobile node to the home agent and correspondent node(s). This model allows the home agent and correspondent node(s) to know the characteristics of the link the mobile node is currently attached to. Based on this information, the home agent and correspondent node(s) may shape ongoing traffics according to the current available link capacity (e.g. bandwidth) to the mobile node. This model can be applicable for Mobile IPv4 as well as Mobile IPv6. "An Extensible Format for Email Feedback Reports", Yakov Shafranovich, 16-May-05, This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine readable replacement for various existing report formats currently used in Internet email. "The Virtual Fabric MIB", Scott Kipp, 28-Jul-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 Virtual Fabrics 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. "Proposal for a New Flow Label Definition", Sham Chakravorty, 18-Apr-05, The IPv6 header includes a 20-bit Flow Label field. RFC 3697, "IPv6 Flow Label Specification" [1] specified this field and minimum requirements for using the field. This document first identifies several issues related to the current Flow Label specification; then it discusses the limitations of the current specification and the need for extending the definition to accommodate emerging applications and protocols; finally, a new Flow Label specification is proposed that enables more effective usage of this field. "Binding Packets to FECs in 6LSA", Sham Chakravorty, 18-Apr-05, IETF Internet Draft "IPv6 Label Switching Architecture (6LSA)" [6LSA] [2] proposes using the IPv6 Flow Label field to switch packets through an IPv6 subnetwork. The use of these IPv6 Label Switched Paths (6LSPs) can provide means for traffic engineering and potentially increase the speed of packets traversing a routed network with no increase in bandwidth. The 6LSA draft defines two processes: 1) grouping packets with identical forwarding behavior into a Forwarding Equivalence Class (FEC), 2) forwarding all packets belonging to an FEC along the same path. The assignment of packets to an FEC is called binding. The purpose of this document is to expand on these two processes, discussing specific methods of performing the required functions. "IKEv2 Authentication Using ECDSA", Jerome Solinas, 31-May-05, This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange protocol, version 2 (IKEv2). ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth, compared to other available digital signature methods. This document adds ECDSA capability to IKEv2 without introducing any changes to existing IKEv2 operation. "ECP Groups For IKE", Jerome Solinas, 31-May-05, This document describes new ECC groups for use in the Internet Key Exchange (IKE) protocol in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. "ECC Groups For IKEv2", Jerome Solinas, 31-May-05, This document describes ECC groups for use as Diffie-Hellman groups in the Internet Key Exchange version 2 (IKEv2) protocol. These new groups are defined to align IKEv2 with other standards, particularly NIST standards, and with and to provide more efficient implementation than in previously defined groups. "Considerations for prefix length assignments in the Global Unicast Address Format", Tony Hain, 19-Apr-05, This document discusses the issues that should be considered by service providers as they assign address space to customers. It is informational in nature as allocation policies are developed elsewhere. "Protocol Extensions for Header Compression over MPLS", Jerry Ash, 8-Jul-05, 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 typically 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. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the pseudowires define a point to point instance of each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", Sally Floyd, 14-Jul-05, There have been a number of proposals for alternate semantics for the ECN field in the IP header [ECN]. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe co-existence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. "Registration Templates for Legacy Message Header Field Names", Bruce Lilly, 21-Apr-05, This memo documents several Internet Message Format message header field names and provides registration templates so that the names can be registered in the permanent message header field name registry. "Considerations for the use of the Sender Policy Framework", Andrew Newton, 21-Apr-05, This document describes issues and considerations when deploying the Sender Policy Framework for the purposes of authenticating sending domains with Internet email. "MPLS Upstream Label Assignment and Context Specific Label Space", Rahul Aggarwal, 22-Apr-05, RFC 3031 limits the MPLS architecture to downstream assigned MPLS labels. This document introduces the notion of upstream assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". "Dual Stack Transition Mechanism (DSTM) Options for DHCPv6", Anil Reddy, Jim Bound, 22-Apr-05, The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts. "Evaluation of Possible CAPWAP Protocols", Behcet Sarikaya, Andy Lee, 22-Apr-05, This documents evaluates the protocols submitted to CAPWAP WG in April 2005. The objectives document is used as the evaluation criteria. All of the objectives are considered one by one and three protocols (LWAPP, CTP and WiCoP) are evaluated vis-a-vis these criteria. The results indicate conformance to most of the criteria by all three protocols. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, 22-Apr-05, Stream Control Transmission Protocol RFC2960 [6] provides a reliable communications channel between two end-hosts in many ways similar to TCP RFC793 [2]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind the NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NAT's so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. "A DNS RR for NFSv4 ID Domains", Rick Mesta, 4-May-05, This document describes a new DNS Resource Record (RR) type that will be utilized by NFSv4 clients and servers to determine the domain string to utilize for on-the-wire user/group name attributes and ACL entry information. Discussion and suggestions for improvements requested. "An Unauthenticated, or Leap-of-Faith-Authorization Mode for Bump-In-The-Stack Implementations of IPsec Using Internet Key Exchange Protocols", Nicolas Williams, 2-May-05, This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) using public keys as IKE identities and unauthenticated public keys and/or certificates as IKE credentials. This unauthenticated SA negotiation protocol works by having IKE peers assert public keys as identities using a new IKE ID payload type for the purpose. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). This document focuses on BITS (bump in the stack) mode IPsec, leaving specification of unauthenticated native IPsec to a separate document. We assume an RFC2401bis processing model, specifically a PAD (peer authorization database) separate from the SPD (security policy database). "Keep Old Binding Cache for a bit", Koshiro Mitsuya, 2-May-05, The FMIPv6 specification [1] allows mobile node sending packet using previous Care of Address (PCoA) at a new subnet. But such packets are ignored at home agent or correspondent node because the Binding Cache doesn't contain the PCoA anymore. To avoid this problem, we propose keeping old binding cache for a bit. "The SEED Encryption Algorithm", Hyangjin Lee, 1-Jun-05, This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", Jerry Ash, 3-May-05, This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM control processing guidelines. "The "Pc" field for SMTP", Gururaja Grandhi, 13-May-05, This draft specifies a mechanism by which an SMTP sender can send a copy of mail to multiple recipients, with out exposing other's mail address to recipient and vice versa. "Content-Author and Content-Originator MIME Header Fields", William Leibzon, 4-May-05, This document defines Content-Author and Content-Originator header fields which can be used with MAIL, HTTP and other protocols that use MIME to identify name and optionally email address of the author of piece of MIME content as well as the person or entity responsible for current distribution of the content. "Instant Message Delivery and Read Reports", Hisham Khartabil, 4-May-05, Instant Messaging (IM) refers to the transfer of messages between users in near real-time. This document extends Message/CPIM message format to enable endpoints to request, create and send a delivery report as well as a read report for a page-mode as well as session mode instant messages. This document also describes how SIP entities behave using this extension. "Detecting Network Attachment in IPv6 Networks (DNAv6)", Sathya Narayanan, 19-Jul-05, Efficient detection of network attachment in IPv6 needs the following two components: a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibilities offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes to it difficult to achieve fast RA. A known set of solutions to these two problems was identified and catalogued by the DNA design team. In this memo, an integrated solution is presented, based on a sub-set of the catalogued solutions. This integrated solution consolidates most of the advantages of all known solutions while addressing most of the disadvantages. "Receiver-Driven Extensions to SMTP", Zhenhai Duan, 6-Jul-05, The Differentiated Mail Transfer Protocol (DMTP) provides simple extensions to the Simple Mail Transfer Protocol (SMTP) that enable receivers to exercise greater control over the email delivery process. The current SMTP-based email delivery architecture is fundamentally sender-driven and distinctly lacks receiver control over the message delivery mechanisms. This document describes DMTP that enables receivers to classify senders into three categories -- allowed, denied, and unclassified -- and process the delivery of messages from each category independently. As is the current practice, receivers may directly accept messages from senders in the allowed category and decline senders in the denied category. In addition, DMTP receivers require senders in the unclassified category to store messages on the senders' own mail servers. Such messages are retrieved only if and when the end receivers wish to do so. By granting greater control over message delivery to receivers and imposing greater message storage and maintenance overhead on senders, DMTP provides significant advantages in controlling spam. DMTP also easily operates in conjunction with (but does not require) many currently deployed anti-spam techniques. "Requirements for Emergency Context Resolution with Internet Technologies", Henning Schulzrinne, Roger Marshall, 11-Jul-05, This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. "Security Threats and Requirements for Emergency Calling", Hannes Tschofenig, 20-Jul-05, With the increasing interest to replace parts of the public switched telephone network (PSTN) with the IP-based network, the core functionality of PSTN such as emergency services, has to be offered when using IP-based technologies. Since the PSTN and the Internet follow different design principles their architecture is quite different. This fact has to be considered and security threats for an IP-based emergency environment have to be re-evaluated. This document investigates the potential threats against the IP based emergency architecture. It focuses on some analysis of threats for both the end hosts and the infrastructure that aims to support emergency services. "Inter PCE Communication protocol", Mohammed Boucadair, Pierrick Morand, 9-May-05, 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. "Support of LDP Multicast Label Switched Paths over Point-to-Multipoint Label Switched Path Tunnels", Seisho Yasukawa, Adrian Farrel, 10-May-05, Multiprotocol Label Switching (MPLS) includes the facility to provision point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs) which can be used to construct P2MP tunnels across MPLS networks. The Label Distribution Protocol (LDP) has also been extended to support label distribution for multicast traffic by forming multicast LSPs. When traffic for a user network is carried across a provider network, it is common practice for the traffic to be placed in tunnels. This document examines the requirements to carry multicast MPLS traffic across a provider network within P2MP MPLS tunnels, and sets out solutions that meet those requirements. "IPv6 Multicast Filtering Rules", Arun Thulasi, 10-May-05, This document describes requirements and rules for multicast packets to be filtered in IP before sending it to the upper layer protocols like TCP or UDP. "Dynamic Host Configuration Protocol (DHCP) Location Configuration Information Transmitted Upstream", James Polk, Ralph Droms, 11-May-05, This document updates RFC 3825 to allow explicitly the transmission of DHCP option 123, "Location Configuration Information", from a DHCP client to a DHCP server. Transmission of option 123 from a client to a server allows a client that knows its location through some other means to communicate that location to the DHCP server. "AAA-Key Derivation with Lower-Layer Parameter Binding", Mayumi Yanagiya, Yoshihiro Ohba, 1-Jul-05, This document describes an alternative method for deriving a AAA-Key. The method cryptographically binds EAP lower-layer parameters to the AAA-Key without need to carry those parameters in EAP methods. "NSIS Flow ID and packet classification issues", Hong Cheng, 19-Jul-05, In current NSIS signaling, Flow ID is used for multiple purposes, e.g., providing routing information for signaling traffic, identifying signaling state on NSIS nodes, and supplying packet classification information regarding the data flow being signaled. Due to the incompatibility of these functions, adverse effects are introduced into NSIS operation, especially when addressing information is complicated. In this draft, three scenarios where the Flow ID cannot function properly are discussed, namely the Multiple address case, Make-before-break case, and Address variation case. In view of this, a solution employing a separate NSLP payload object, i.e., Filter List, is proposed. The solution solves the Flow ID usage problem in the three cases, and its operation details and impacts on different aspects of NSIS system are reviewed in the draft. "An IRIS schema for Emergency Service contact URIs", Ted Hardie, 15-Jul-05, This document describes an XML-based protocol for passing location information to a server that returns emergency service contact URIs. It is intended to fit within a larger framework of standards. Specifically, it presumes the existence of a URI scheme appropriate for signalling that emergency service is required and distinguishing among emergency services if appropriate. It also presumes that an entity requesting this response will be able to handle the URIs returned as input to appropriate handlers. "BGP-MPLS IP VPN extensions for ISO/CLNS VPN", Quaizar Vohra, 16-May-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 ISO/CLNS customers. These customers may be islands of ISO/CLNS networks which are part of the Service Provider network itself and are interconnected by the Service Provider's IP core. This method reuses the 2547 style BGP-MPLS VPN model. This document defines an ISO/CLNS VPN address family and describes the corresponding ISO/CLNS VPN route distribution mechanism using "Multiprotocol BGP". "NSIS Extensibility Model", John Loughney, 20-Jul-05, This document discusses the Next Steps in Signaling extensibility model. This model is based upon a two-layer model, where there is a transport layer and a signaling application model. This two-layer provides the ability to develope new signaling applications, while retaining the use of a common transport layer. "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)", James Kempf, Craig Gentry, 18-Jul-05, RFC 3971 and 3972 (SEND) define a protocol for securing resolution of a statelessly autoconfigured IPv6 address to a link address as defined by IPv6 Neighbor Discovery. SEND does this by requiring the autoconfigured addresses to be cryptographically generated by the host from an RSA public key. However, one drawback of SEND is that such addresses cannot be securely proxied. Proxy Neighbor Discovery is important for Mobile IPv6 and in certain other cases. In this document, we describe an extension of SEND to addresses that are cryptographically generated using multiple public keys, called multi- key CGAs. Neighbor Discovery messages for multi-key CGAs are signed with an RSA ring signature, a type of signature that can be generated using the private key of any node but which requires the public keys of multiple nodes to verify. Multi-key CGAs can be securely proxied by all nodes that contribute keys to the address. The advantage of multi-key CGAs over other techniques of secure address proxying, such as trusting the router or using an attribute certificate, is that it preserves location privacy. A receiver cannot determine from the IPv6 address, ring signature, or cryptographic parameters whether the node or the proxy is defending the address, and hence whether the node is on or off the link. "Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec", Sassan Ahmadi, 16-May-05, This document is an addendum to RFC xxxx, which specifies the real-time transport protocol for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document contains the information related to the new operating mode of VMR-WB. All provisions, restrictions, use cases, features, etc. that are specified in RFC xxxx are applicable to the new operating mode without any exception. No new media type registration is included in this document as the new VMR-WB mode, defined in this document, will use the same media type specified in RFC xxxx (i.e., audio/VMR-WB). Note that the RFC xxxx was developed with sufficient flexibility for future extensions and thereby it allows the addition of new operating modes without any impacts on the interoperability of terminals supporting different versions of the VMR-WB standard. "Strengthening Digital Signatures via Randomized Hashing", Shai Halevi, Hugo Krawczyk, 18-May-05, We propose to adopt randomized hashing as a mode of operation for existing and future cryptographic hash functions. The idea is to strengthen hash functions for use in the context of digital signatures without requiring a change to the actual hashing and signing algorithms or to their existing implementations. We suggest that randomization can be achieved via the processing of the input to the function, even if the hash function itself is not randomized. Effective use of such mode of operation requires changes to the standardization of the encoding and processing of digital signatures (e.g., PKCS#1, FIPS186) but has no impact on existing signature and hashing algorithms. We urge the standards community to plan a transition towards these new mechanisms for which we outline specific instantiations. "Optimizing Micromobility Management for Active and Dormant Mobile Nodes", Wassim Haddad, 20-Jul-05, Micromobility protocols address mobile nodes (MN) movements within a particular IP network domain. This document introduces a new protocol "Optimized Micromobility Management" (OMM), to manage Micromobility for active and dormant mobile nodes. The suggested solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and the packet loss. "Distributed New File Transfer Protocol", Guillermo Chin, Fernando Cantero, 18-May-05, This document specifies DNFTP, a new proposal of a protocol to replace the FTP. The fundamental objective is to make it more feature rich, keeping the existent one, to adapt new technologies that have been developing in the last decade like distributed computing, multimedia and concurrency. "DHCPv4 option for PANA Authentication Agents", Suraj Kumar, 18-May-05, This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more of PANA Authentication Agents (PAA). This is one of the many methods that a PANA Client (PaC) can use to locate PANA Authentication Agents (PAA). "3GPP QoS Model for Networks Using 3GPP QoS Classes", Seong-Ho Jeong, 20-Jul-05, QoS interworking between 3GPP wireless and non-3GPP wireline networks will be essential if future IP-based next generation networks are to provide assured-quality end-to-end IP flows. This draft discusses how to achieve QoS interoperability between 3GPP based wireless networks and IETF/ITU-T based wireline IP networks from the NSIS point of view. In particular, this draft tries to describe a QoS- NSLP QoS model based on 3GPP QoS classes and bearer service attributes. "COPS-MAID: COPS Usage for Multi-Access Inter-Domain Service Provider Networks based on MPLS-Diffserv", Gino Carrozzo, 18-May-05, This specification defines some extensions to the COPS protocol under the COPS-MAID client type to be used for the SP Control Plane procedures in a Multimedia Telephony Service (MTS) context. The reference SP network infrastructure is assumed to be based on MPLS/Diffserv Control and Data Planes. The proposed architecture is defined signalling independent because it is able to uphold different signalling protocols used by the MTS-enabled terminals (e.g. SIP, H.323, H.248-Megaco, MGCP, etc.) with a common approach. The overall specification relies on the identification of a common and generalized semantic for the service requests (policy & CAC), which will encapsulate the client-specific information in a common format besides of the specific protocol (e.g. SIP, H.323, etc.). By means of this generalized architecture it is possible to reduce the complexity of the SP Control Plane architecture. "A Problem Statement for Path-Decoupled Signalling in NSIS", Robert Hancock, 20-Jul-05, The NSIS working group is currently developing a protocol suite for signalling which manipulates network state related to data flows. The protocol architecture incorporates the constraint that the signalling protocol will be processed on the nodes which also handle the data flows themselves ("path-coupled signalling"). This document discusses motivations for a relaxation of this constraint in a particular class of scenarios, allowing the signalling and data paths to be decoupled. It includes pointers to related work elsewhere in the IETF and in other standardisation bodies, and includes a recommendation for allowing a particular deployment mode for the NTLP that can cover these types of architectures. "The AES-CMAC-96 Algorithm and its use with IPsec", Junhyuk Song, Jicheol Lee, 31-May-05, National Institute of Standards and Technology (NIST) has newly specified the Cipher based MAC (CMAC) which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode on authentication mechanism of IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. This new algorithm is named AES-CMAC-96. "Internet Message Access Protocol (IMAP) - UIDPLUS extension", Mark Crispin, 26-May-05, The UIDPLUS extension of the Internet Message Access Protocol [IMAP] provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. "The news and nntp URI Schemes", Frank Ellermann, 19-May-05, This memo 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 made obsolete while keeping the information about the schemes on standards track. "Internet X.509 Public Key Infrastructure DNS Service Resource Record otherName", Stefan Santesson, 19-May-05, This document defines a new name form for inclusion in the otherName filed of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with a DNS Service Resource Record. "The news and nntp URI Schemes", Charles Lindsey, 20-May-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 made obsolete while keeping the information about the scheme on standards track. It is based on the earlier draft-hoffman-news-nntp-uri-04.txt written by Paul Hoffman. "IMMP -- Internet Message Mapping Protocol", Sabarish Ramanathan, 24-May-05, The Internet Message Mapping Protocol (IMMP) is designed to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the SMTP protocol and mail receiving protocols (POP, IMAP, web mail also), providing services which are outside the scope of mail access. The services that IMMP provides are mapping mails into appropriate subinbox (inside the inbox) when the messages are received through SMTP, Extended inbox management and Spam guard management. "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", JP Vasseur, 15-Jul-05, This document specifies the Path Computation Element communication Protocol (PCEP) for communications between Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. "Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute (ETSI) Next Generation Network (NGN) simulation services", Roland Jesske, 15-Jun-05, This document describes a set of requirements to the Session Initiation Protocol (SIP) [1] in support for simulation services provided in the context of ETSI Next Generation Networks (NGN). These requirements should help to find SIP solutions to provide the services described within this document. "Common Local Transmit and Receive Ports (Symmetric RTP)", Dan Wing, 6-Jun-05, This document describes common local transmit and receive ports, commonly called "symmetric RTP" and "symmetric RTCP", and explains the advantages of using common local transmit and receive ports. "The AES-CMAC Algorithm", Junhyuk Song, Jicheol Lee, 31-May-05, National Institute of Standards and Technology (NIST) has newly specified the Cipher based MAC (CMAC) which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the authentication mechanism based on CMAC mode of operation with 128-bit Advanced Encryption Standard (AES) cipher block. This new authentication algorithm is named AES-CMAC "Hash/PRF negotiation in TLS using TLS extensions.", Grigorij Chudov, 25-May-05, This document presents a method of negotiating some of the algorithms, used by Transport Layer Security Protocol [TLS], which are not chosen by cipher suite. Those algorithms are hash function used for Finished message, and PRF function. This is done using TLS Extensions [TLSEXT] mechanism. "IRIS Service Lookup System", Leslie Daigle, Andrew Newton, 25-May-05, This document defines an IRIS "service lookup system" registry (slsreg) schema, and IRIS queries/responses to support looking up network service records (NSRs) based on a registered tag (or label). The NSR will include URIs for set types of network services. "TCP SYN Flooding Attacks and Common Mitigations", Wesley Eddy, 25-May-05, This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and defense techniques so that implementers may better evaluate them. "CAPWAP Handover Protocol (CAPWAPHP)", Behcet Sarikaya, 26-May-05, This document describes the Control And Provisioning of Wireless Access Points (CAPWAP) Handover Protocol (CAPWAPHP) which is a protocol allowing the access controller of CAPWAP Working Group architecture to anchor and manage 802.11 handovers of the stations between a collection of wireless Access Points. The protocol, like IEEE's IAPP aims to ensure that a station is connected to a single access point and provides an efficient context transfer mechanism during handover using neighbor graphs. CAPWAPHP is local MAC/ Split MAC/ remote MAC agnostic and can be transported by LWAPP, CTP, WiCoP or SLAPP. "No Overhead Autoconfiguration OLSR", Kenichi Mase, Cedric Adjih, 26-May-05, This document specifies one method for autoconfiguration for the Optimized Link State Routing (OLSR) protocol for ad hoc networks. OLSR is a routing protocol for mobile ad hoc networks, designed for use in multi-hop wireless ad hoc networks ; and as such it specifies how individual nodes can construct routes to each other. To achieve this, it relies on preliminary assignment of unique IP addresses to OLSR interfaces ; hence the task of assigning addresses to interfaces, and checking their uniqueness is defined externally. This document proposes a complementary method, called "No Overhead Autoconfiguration for OLSR" (NOA-OLSR), to perform this task of ensuring uniqueness (Duplicate Address Detection, DAD) of addresses which have been selected. This method consists of modifications in the OLSR specification. "Multicast in Virtual Router-based IP VPNs", Hong-Ke Zhang, 21-Jul-05, This document specifies the procedures required to be implemented for IP multicast traffic to travel from one VPN site to another within a VR-VPN (Virtual Router-based IP VPN).It details the solution according to process in local customer sites, establishing of multicast distribution trees in SP networks and forwarding of multicast data packets. This document is based on Requirements for Multicast in L3 Provider-Provisioned VPNs [MREQT] and specification of Network based IP VPN Architecture using Virtual Routers [VR-VPN] that have been implemented and deployed. "Mitel Usage of DHCPv4 Vendor Options 128 - 135", Peter Blatherwick, 27-May-05, This informational document describes Mitel Network's current usage of DHCPv4 options 128 - 135, in order to provide input for the process of reclassifying the DHCPv4 site-specific options range as part of RFC 3942. This is also intended to complete the process of requesting options 128 - 135 be placed in the "Tentatively Assigned" state by IANA, as described in RFC 3942. "A two stage standards process", Brian Carpenter, 31-May-05, This document proposes several changes of principle to the Internet standards process, especially a reduction from three to two stages in the standards track. "The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", Junhyuk Song, Jicheol Lee, 31-May-05, Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC- PRF-128. "Scheduling Extensions to CalDAV", Bernard Desruisseaux, 31-May-05, This document specifies a set of methods, headers and resource types that define the scheduling extension to the CalDAV protocol. CalDAV itself extends WebDAV, which extends HTTP. The new protocol elements defined here allow interoperable scheduling operations on a CalDAV repository. "DNA Solution: Link Identifier based approach", Syam Madanapalli, JinHyeock Choi, 19-Jul-05, DNA solution consists of 1)link identity detection with a single RA and 2)quick RA acquisition. This draft presents the first component based on Link Identifier. It describes a way for link identity detection with prefix based Link Identifier, 'linkid prefix'. While this document doesn't include the second component, any quick RA acquisition scheme will work with the proposal. The draft is the result of DNA DT discussion. "Metrics for the Evaluation of Congestion Control Mechanisms", Sally Floyd, 31-May-05, This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. This document is intended to be the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols. "NAT Behavioral Requirements for Unicast TCP", Paul Hoffman, 19-Jul-05, This document defines a set of requirements for NATs that handle unicast TCP that would allow many applications, such as peer-to-peer reliable 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. "Report on the IANA IPv4 Address Registry", Geoff Huston, 1-Jun-05, This is a report on an analysis of the IPv4 address registry as published by the IANA [IPv4], comparing the contents of that registry with IPv4 allocation data published by the Regional Internet Registries (RIRs), as well as examining the registry from the perspective of consistency of style and content. "A general mechanism for RTP Header Extensions", David Singer, 1-Jun-05, This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and unregistered. The actual extensions in use in a session are signaled in the setup information for that session. "Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag", Gonzalo Camarillo, 2-Jun-05, This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. "Support of mobile nodes with unidirectional links in MIPv6", Ilka Miloucheva, Olaf Menzel, 2-Jun-05, This document discusses mechanisms for dynamic establishment of bidirectional link layer connectivity of mobile nodes with unidirectional links in Mobile Ipv6 (MIPv6) environment. Requirements are derived from the need to support services in mobile Ipv6 based on unidirectional technologies, for instance Digital Video Broadcasting, using multicast protocols, such as Protocol Independent Multicast Routing – Sparse Mode (PIM-SM) and Multicast Listener Discovery (MLDv2). "The Paradisec URN Namespace", Luke Brown, 2-Jun-05, This document describes a Uniform Resource Name (URN) namespace for the identification of resources in the Pacific And Regional Archive for Digital Sources in Endangered Cultures (PARADISEC) archive. This namespace will provide persistent means of accessing the archives contents allowing for reliable citation. "Email Sender's Declaration of Identity", David MacQuigg, 3-Jun-05, A key item that must be standardized to allow interoperation of different email authentication methods is the ID declaration. Current authentication methods assume that one or another of the existing fields in a mail transfer can be used as the Identity to be verified. Since there is no way to tell which field, if any, the sender is prepared to authenticate, extra DNS queries must be made, in the worst-case, testing all possibilities just to find no authentication is offered at all. This draft proposes a neutral syntax that can be used by all methods. "DHCP Option for Radio Configuration Parameters to Mobile Access Points", Murali Achanta, 2-Jun-05, This document defines a DHCP option that contains Radio specific Parameters for Mobile Access Points, Like Transmit Power, Country code, reserved RF channels. "The UMAC-AE Authenticated-Encryption Algorithm", Ted Krovetz, 3-Jun-05, This document specifies UMAC-AE, a shared-key algorithm that simultaneously encrypts data using a block cipher in counter mode while also authenticating the data with UMAC. At its peak rate, using AES as the block cipher, UMAC-AE encrypts and authenticates data at a cost of about 10% more than simple encryption. UMAC is unencumbered by intellectual property claims and can be used freely. Pairing UMAC with a license-free block cipher, such as AES, provides fast and license-free authenticated encryption. "IANA Carrier/User enumservice Registration", Penn Pfautz, 6-Jun-05, This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. "EAP keying and handover support", Madjid Nakhjiri, 6-Jun-05, The current EAP documentation set, such as [EAP3748], [EAPKEY6], and [RADEAP3579] provide a powerful framework for performing combined authentication and key management using an EAP server and an AAA infrastructure. The framework competently deals with many issues related to network-access control and link security setup. However, when it comes to deploying these specifications for mobile wireless environments, where a peer is required to perform fast and/or heterogeneous handovers, the current framework can be extended with more clear guidelines and possibly specifications in ways that prevent interoperability or security issues. This draft intends to explore some of the complications in deploying the EAP framework for handovers and analyze a few solution alternatives. Further threat analysis of each alternative or providing trade-off guidelines for support of handover may be part of the future revisions of this document. "The IETF Golden Rules", Jacob Palme, 7-Jun-05, This memo presents the following rules, which to some extend can be regarded as the golden rules of IETF, even though there are exceptions when these rules should not be adhered to. - Be liberal in what you accept, and conservative in what you send - Do not munge forwarded data - Modify as late as possible - Cause no harm - Leave nothing undefined - Keep it simple, stupid - No voting, rough consensus - Plain ASCII text is enough "The AS_HOPCOUNT Path Attribute", Tony Li, 15-Jul-05, This document describes the AS hopcount path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP mesh are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. "Bundle Security Protocol Specification", Susan Symington, 8-Jun-05, This document defines the bundle security protocol, which provides data integrity and confidentiality services. We also describe various bundle security considerations including policy options. "The requirement for direct transcoding with Session Initiation Protocol", Taegyu Kang, 8-Jun-05, This document presents a set of Session Initiation Protocol (SIP) call control requirements that support communication with direct transcoding capability. Several solutions are addressed for transcoding service. Direct transcoding requires two kinds of requirements: the service requirement and call control requirement. Service requirement is no constraint of codec adaptation and interoperability of models. Call control requirement is exchange of codec information and minimizing of call set up delay. The model might be applied to general-purpose services satisfying the requirements of multimedia applications without an additional INVITE. "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP", David McGrew, John Viega, 8-Jun-05, This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide data origin authentication, but not confidentiality. GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. "An Internationalized Resource Identifier (IRI) Scheme for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 8-Jun-05, This document defines an Internationalized Resource Identifier (IRI) scheme for use in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). "Automatic configuration of IPv6 addresses for nodes in a MANET with multiple gateways", Simone Ruffino, Patrick Stupar, 8-Jun-05, This Internet Draft relates to Mobile Ad-hoc Networks (MANETs) connected to an external network by means of one or more gateways. A solution that enables MANET nodes to automatically discover a global address is proposed. The proposed solution aims at reducing the latency introduced by a global address change and exposes two algorithms a node may adopt to discover if the used address has to be changed. "Distributing Default Address Selection Policy using DHCPv6", Tomohiro Fujisaki, 9-Jun-05, This document describes a new Dynamic Host Configuration Protocol for the IPv6 (DHCPv6) option for distributing default address selection policy information to a client. "Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand, 9-Jun-05, This draft describes the applicability of loop free convergence technologies to a number of network applications. "Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, 19-Jul-05, This document describes a routing protocol for intermittently connected networks, where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are special cases of networks where the Delay-Tolerant Network architecture[1] is applicable. We define PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity for intermittently connected networks. The document presents an architectural overview followed by the protocol specification. "Multicast Context Transfer in mobile IPv6", Karl Jonas, Ilka Miloucheva, 10-Jun-05, Protocol mechanisms for fast mobile multicast in IPv6 based on multicast listening context transfer are proposed. The focus is the context transfer for mobile multicast listeners using Multicast Listener Discovery protocol Version 2 (MLDv2). Multicast context transfer block and operational considerations for optimised multicast context transfer based on Fast Handovers for Mobile IPv6 and Candidate Access Router Discovery are described. The requirements for MLDv2 context extension and operation at access routers to support multicast context transfer for mobile IPv6 are specified. Interactions of MLDv2 with Protocol Independent Multicast Sparse Mode (PIM-SM) for multicast routing state update based on multicast listening context transfer are overviewed. Operational considerations for MLDv2 and PIM-SM to support multicast receiver and source mobility based on context transfer are discussed. Comparison with other multicast protocol proposals for Mobile IPv6 (MIPv6) is given. "IPv6 Fast Neighbor Discovery Option", Soohong Park, 10-Jun-05, To minimize router delay in response to Router Solicitation message, several scheme are being discussed in IETF. This document suggests a new Neighbor Discovery option which is included in Router Solicitation and/or Router Advertisement messages to achieve fast network attachment. "CAPWAP Taxonomy Recommendations", Pat Calhoun, 18-Jul-05, The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. "OAM Requirements for Point-to-Multipoint MPLS Networks", Seisho Yasukawa, 10-Jun-05, Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs the requirement to detect, handle and diagnose control and dataplane defects is critical. For operators deploying services based on P2MP MPLS LSPs the detection and specification of how to handle those defects is important because such defects may not only affect the fundamental of an MPLS network, but also because they MAY impact service level specification commitments for customers of their network. "Use Cases for Session-Specific Session Initiation Protocol (SIP) Session Policies", Volker Hilt, Gonzalo Camarillo, 13-Jun-05, This draft describes use cases for session-specific Session Initiation Protocol (SIP) sessions policies. "PCE Communication Protocol Application Model", Renhai Zhang, Defeng Li, 28-Jun-05, In an environment where multiple PCEs are responsible for computing paths in a domain, there is a greater possibility of race conditions compared to traditional methods. Fast convergence of network state, e.g. TED, LSPs, is more important for PCEs. Furthermore, load balancing of computation should be considered among these PCEs. This document is not intended to provide a detailed description of all the architectural components of the PCE communication protocol. Rather, it specifies the Global Computing Table (GCT) along with corresponding mechanisms and procedures to resolve some predictable problems in PCEs, especially in situations where multiple PCEs are responsible for computing TE LSPs path in a domain. It is hoped that these mechanisms can cooperate with the PCE communication protocol to improve the abilities of the protocol. "Object-based pNFS Operations", Jim Zelenka, 19-Jul-05, This Internet-Draft provides a description of the object-based pNFS extension for NFSv4. This is a companion to the main pnfs operations draft, which is currently draft-welch-pnfs-ops-02.txt "AAA Key Management", Russ Housley, Bernard Aboba, 13-Jun-05, This document provides guidance to designers of AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as RFCs, as well as to use of AAA key management by any other standards development organizations (SDOs). "US Secure Hash Algorithms (SHA)", Donald Eastlake 3rd, Tony Hansen, 13-Jun-05, The United States of America has adopted a suite of secure hash algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 [RFC 3874], SHA-256, SHA-384, and SHA-512. The purpose of this document is to make code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from [RFC 3174] has also been updated to handle an input string of arbitrary length. Most of the text herein was adapted by the authors from FIPS 180-2. "pNFS Block/Volume Layout", David Black, Stephen Fridella, 18-Jul-05, Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. "AII Types for ATM and Frame Relay to MPLS Control Plane Interworking", Ethan Spiegel, 14-Jun-05, This document describes work in progress in the MFA Forum on ATM and Frame Relay to MPLS Control Plane Interworking. Two implementation agreements are being defined, one for network interworking (between two client network endpoints that communicate across an IP/MPLS network) and one for SPVC interworking (from a client network endpoint to an IP/MPLS network endpoint). Both network interworking and SPVC Interworking use standard PWE3 control for establishment of the pseudowires that transport the ATM or Frame Relay data connections across the IP/MPLS network. New AII type codepoints from the "First Come First Served" range are requested. The need for these codepoints and proposed usage is described. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 21-Jun-05, International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describe the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. "DHCP Option for CLF/NASS", Li Jun, 15-Jun-05, This document defines a new option for CLF(Connectivity Session Location and Repository Function) and/or NASS (Network Attachment Subsystem) discovery in an IP based NGN network. This document defines the related option and option codes. The NGN terminals can get the access network indicator via this DHCP option. "Requesting Answering and Alerting Modes for the Session Initiation Protocol (SIP)", Dean Willis, Andrew Allen, 15-Jun-05, This document defines two SIP extension header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Alert-Mode", expresses a preference as to whether the target node's user interface alerts the user about the request. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. This document also defines use of the SIP extension header field "Answer-Mode", in a response to an INVITE request to inform the requester as to which answer mode was actually applied to this request. There are significant security considerations, especially when the two request options are used together. "Multi-Segment Pseudo Wire Signaling", Himanshu Shah, 19-Jul-05, The pseudowire switching [6] draft describes how a Pseudowire can span across multiple PSN domains. This multi-segment PW (MS-PW) threads through one or more PEs that are not the endpoints of the PW and are called switching PE (S-PE). The switching PE at each hop is configured a-priori with two single hops PW information that enables it to conduct splicing between the two. The configuration of such information at each S-PE for possibly thousands of MS-PWs is cumbersome. We describe a mechanism whereby a S-PE can identify and process the PW control signaling with the information present in the signaling message in a manner that eliminates the requirement to configure PW splicing information. In this mechanism source PE inserts information about the destination PE and the PW endpoint that is recognized by the receiving PE to identify his role as a switching PE and engage in propagating the PW signal towards the destination PE. "SMTP Extension for Advertisement of External-Body Content Retrieval Capability", William Leibzon, 16-Jun-05, This document describes an ESMTP extension by means of which mail agents can report capability to retreive message content from remote location specified with MIME/External-Body type. This allows to save senders from having to send data for content parts that may not be of interest to the recipient and is especially useful when content is available in several alternative formats or languages and its not known which one recipient prefers. "Issues Related to the Management of IPv6 Address Space", Thomas Narten, 16-Jun-05, This document reviews the history of IPv6 address delegation and examines some of the technical implications of various allocation policies in terms of their impact on long-term address space utilization and aggregation. The purpose of this document is to stimulate discussion and foster improved understanding of the implications of various policies, so that appropriate policies are adopted that preserve the long-term scalability of IPv6. "An IANA Registry for DNS SRV service names", Bill Fenner, 21-Jun-05, This document proposes a registry for service names used in DNS SRV records. "Centralized Conferencing (XCON) Using the Message Session Relay Protocol (MSRP)", Chris Boulton, Mary Barnes, 13-Jul-05, A Centralized Conference as defined by the XCON working group is both signaling and protocol agnostic. The primary focus of the XCON work has been centered on the Session Initiation Protocol for signaling and Audio/Video for the media types. This document defines the mechanisms, in the context of the XCON framework, required when using the Message Session Relay Protocol (MSRP) in a Centralized Conference (XCON). "Location-to-URL Mapping Protocol (LUMP)", Henning Schulzrinne, 21-Jun-05, LUMP (Location-to-URL Mapping Protocol) maps geographic locations, described as PIDF-LO objects containing civic or geospatial information, to one or more URLs. It is based on a standard RPC mechanism and supports updates. Clusters are used to ensure scaling and reliability. A flooding mechanism distributes top-level routing information. Naming authority can be delegated in any tree-like fashion, with multiple independent authorities for each level. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 27-Jun-05, Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, RR header bits, and AFSDB subtypes. "NAT Port Mapping Protocol (NAT-PMP)", Stuart Cheshire, 23-Jun-05, This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it. This protocol is implemented in current Apple products including Mac OS X v10.4 Tiger and Bonjour for Windows. "Conforming CRL validation for relying parties", Denis Pinkas, 19-Jul-05, The text currently present in section 6.3 from RFC 3280 is dedicated to CRL validation. This text needs to be more detailed to explain exactly how it can made be sure that a CRL is issued by the right entity. In addition, a text dedicated to the characteristics that conforming applications MUST support needs to be provided: the current text covers the most complex case and is too complicated to be easily simplified. Text is proposed to be included in 3280bis and to partially replace section 6.3 . "Internet service for Resource Reservation in Advance", Dirk Hetzer, 23-Jun-05, Internet service aimed at advance resource reservation for QoS based applications using QoS managers interacting with IntServ/RSVP and Differentiated Service architectures is proposed. Different issues such as resource reservation, timing of requests and dependency of reservations are considered in the advance resource reservation interface. Abstract interface describing the advance resource reservation requests is specified. Mechanisms for advance resource reservation are discussed. "Mobile IPv6 Multicast with Dynamic Multicast Agent", Hong-Ke Zhang, 23-Jun-05, This document addresses the problem of delivering IPv6 multicast traffic to MN (mobile nodes). An approach named DMA (Dynamic Multicast Agent) is proposed. The approach is a combination of MIP- BT and MIP-RS [1], and it is also a hybrid solution of Movement Based Method [2] and Distance Based Method [3]. Such a configuration allows MNs to optimize multicast routes, and meanwhile reduce the number of handoffs by selecting new multicast agents dynamically. In addition to weakening the triangle route problem and diminishing the influence of handoff to multicast, this approach provides global mobility in the Internet with no restriction on network topologies. "Use of IPFIX for Export of Per-Packet Information", Elisa Boschi, Lutz Mark, 24-Jun-05, This document describes the usage of the IP Flow Information Export (IPFIX) protocol for the case of exporting and processing per-packet information. The main idea is to separate the export of the information about packets and flows those packets belong to, using two different records. The association between the records is kept using unique Flow or Template Identifiers. "Analysis of IPv6 Relocation Delays", Christian Vogt, 20-Jul-05, As mobile nodes move to new links, they need to resume their communications in a timely fashion. To communicate, IPv6 nodes need to complete router discovery, address auto-configuration, and other tasks. Unfortunately, this depends on prior completion of the Multicast Listener Discovery (MLD) protocol, introducing a mandatory delay of up to one second. This document discusses where this can be problematic and proposes solutions that can alleviate the problem. "Kerberos based HTTP Authentication in Windows", Karthik Jaganathan, 20-Jul-05, This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and optionally impersonation(the IIS server assuming the windows identity of the principal which has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of SPNEGO implementation are not provided in this document. "Problem Statement for IP Local Mobility", James Kempf, 24-Jun-05, In this document, the well-known problem of localized mobility management for IP link handover is given a fresh look. After a short discussion of the problem and a couple of scenarios, the principal shortcomings of existing solutions are discussed. "BFD initializtion with BGP and static routes", Suping Zhai, 19-Jul-05, This document describes the use of the Bidirectional Forwarding Detection protocol with BGP and the static route over IPv4 or IPv6. The main purpose of this draft is to solve the BFD bootstrap problem with BGP and static routes. As to the encapsulation and demultiplexing issues there have been descriptions in BFD single hop draft [BFD-1HOP] and multi-hop draft [BFD-MULI]. With the BFD interaction with BGP graceful restart, the rules described in BFD single hop [BFD-1HOP] with IS-IS and OSPF graceful restart are also applicable to the BFD with BGP graceful restart, and will not iteratein in this draft. Comments on this draft should be directed to rtg-bfd@ietf.org or to author directly. "The P-Answer-State Header Extension to the Session Initiation Protocol (SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular (PoC)", Andrew Allen, 27-Jun-05, This document describes a private Session InitiationProtocol(SIP) header (P-header) used by the Open Mobile Alliance (OMA),For Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset which is particular to the PoC application. "FEC Grouping Semantics in SDP", Adam Li, 27-Jun-05, "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, 27-Jun-05, This document provides functional requirements for network solutions that support multicast in Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. "Generally Useful Authentication Mechanisms (GUAM)", Joseph Salowey, 27-Jun-05, Generic Security Services API (GSS-API), the Simple Authentication and Security Layer (SASL), the Extensible Authentication Protocol (EAP) and Transport Layer Security (TLS) are examples of four different security frameworks within the IETF. Each of these frameworks have evolved separately towards a common goal of authentication and establishing a cryptographic context. They support different types of security mechanisms and have historically evolved to integrate with different security infrastructures. This document discusses their similarities and differences and how these security mechanisms might start to converge into a more uniform approach involving generally useful authentication mechanisms that can be used in any of these frameworks with a variety of different security infrastructures. "DNS Long-Lived Queries", Kiren Sekar, 27-Jun-05, This document proposes a method of extending unicast DNS to support long-lived queries, thus allowing clients to learn about changes to DNS data without polling the server. "Dynamic DNS Update Leases", Kiren Sekar, 27-Jun-05, This document proposes a method of extending Dynamic DNS Update to contain an update lease life, allowing a server to garbage collect stale resource records. "Use of UTF-8 in RFCs", Paul Hoffman, 27-Jun-05, This document specifies a change to the IETF process in which RFCs are encoded as UTF-8 instead of US-ASCII. "H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths", Doug Leith, Robert Shorten, 27-Jun-05, Our objective in this document is to renew discussion on how the TCP congestion control algorithm might best be modified to improve performance in high bandwidth-delay product paths. We focus on changes to the additive increase element of the TCP AIMD algorithm. "Feed History: Enabling Stateful Syndication", Mark Nottingham, 15-Jul-05, This document specifies a mechanism that allows feed publishers to give hints about the nature of the feed's statefulness, and a means of retrieving "missed" entries from a stateful feed. "A Secure Extension for the Unidirectional Lightweight Encapsulation (ULE) protocol", Haitham Cruickshank, 28-Jun-05, This document proposes a security framework for the Unidirectional- Lightweight Encapsulation (ULE) protocol. It provides threat analysis and defines the requirements for ULE security. It also proposes an extension format for the Unidirectional-Lightweight Encapsulation (ULE) protocol. This work is intended as a work item of the ipdvb WG, and contributions are sought from the IETF on this topic. "QoS-Enhanced Border Gateway Protocol", Mohammed Boucadair, 5-Jul-05, This memo describes a proposal for exchanging QoS-enabled reachability information between service providers. It defines new BGP attributes to be used in order to convey QoS performance characteristics between service providers and it describes how to use these QoS values in order to select the best path. An example of route selection process that takes into account the QoS performance values enclosed in BGP messages is also detailed. "Specifying Media Privacy Requirements in the Session Initiation Protocol (SIP)", Ron Shacham, 28-Jun-05, Participants in a normal phone conversation can assume that, given the appropriate measures are taken against network eavesdropping, what they say is only heard by the other participant. The use of speakerphones or visual output devices displaying video or messaging removes this assumption. In the Session Initiation Protocol (SIP), a call may also be transfered to another device, suddenly compromising the other participant's privacy. Therefore, this document proposes SDP and SIP protocol extensions that allow participants to specify their privacy requirements for the other party's device, and discusses how they may be used in different session scenarios. It also defines an SDP extension for allowing or disallowing the recording of the session. "Registration Policies for the IETF and IANA", John Klensin, 19-Jul-05, For many years, the IETF has maintained, via the IANA, registries of protocol and parameter names and numbers. The primary purpose of these registries is to ensure that different methods and options are properly identified and distinguished. Registration of such names or numbers generally does not necessarily imply approval of the technology in the corresponding protocol. Instead, registration represents the desire to keep choices distinctly identified, separated, and public to avoid conflicts in use. In recent years, various changes in the nature of the instructions given to the IANA, increased perceptions of scarcity in the number spaces associated with some of the parameters, and other issues have led to a shift in emphasis from "registration to keep identifiers unique" toward evaluations of the quality of proposals for and preferences among protocols. This document argues that shift is undesirable. It articulates and clarifies the principles that the reasons for evaluation of registration requests is to ensure a minimum quality of definition, that any assertions of scarcity to restrict registrations must be accompanied by a plan for evaluating and, if appropriate, eliminating the scarcity problem, and that, if a "no scarcity" plan is not possible, to establish criteria for making decisions that are as specific and objective as possible. This document is intended to update the general considerations of RFC 2434, the specific allocation rules of RFC 2780, and the evaluation criteria associated with other documents that condition an IANA registration on Expert Review with IESG oversight or on IESG or IETF action. "Some Requirements for a Media Independent Handover Information Service", Greg Daley, Stefano Faccin, 28-Jun-05, Work within the IEEE's 802.21 working group is aimed at providing media independent handover service, to assist with handovers between heterogeneous link-layer technologies, and across upper-layer subnet boundaries. In order to provide canonical mechanism for media independent handover information to link-layer devices, an information service envisaged as part of the 802.21 solution. This document is a personal effort amongst attendees to solicit assistance from IETF contributors to determine which components of the information service are already available, and the form of the components which still require protocol development. "Low Density Parity Check (LDPC) Forward Error Correction", Vincent Roca, 29-Jun-05, This document describes an Under-Specified FEC Scheme that can be used with the broad class of Low Density Parity Check (LDPC) codes and their application to the reliable delivery of objects on packet erasure channels. Additionally, this document describes the LDPC- Staircase and LDPC-Triangle Forward Error Correction codes, two instances of the LDPC FEC Scheme, in a way that enables fully inter- operable implementations. The LDPC codes belong to the class of large block FEC codes, as defined in RFC3453, which enables them to efficiently encode/decode large objects, in a single block. They also enable a receiver to recover the k source symbols from any set of a little bit more than k encoding symbols. "Media-Independent Pre-Authentication (MPA) Implementation Results", Yoshihiro Ohba, 19-Jul-05, This document describes an initial implementation of Media- independent Pre-Authentication (MPA) optimization. MPA is a mobile- assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. The implementation described in this document shows how existing protocols could be leveraged to realize the functionalities of MPA. It also includes empirical result gathered from experiments performed on a simulated network where the implementation resides. "Anonymity and Unlinkability Extension for CGA-OMIPv6", Wassim Haddad, 29-Jun-05, The "Optimized Mobile IPv6 with CGA" [CGA-OMIPv6] protocol specifies a new route optimization (RO) technique. This document describes a new extension to be added to the CGA-OMIPv6 protocol in order to provide the anonymity and the unlinkability at the IP layer. "Internationalized eMail Address (IMA)", XiaoDong Lee, 29-Jun-05, An email address has two parts - local part and domain part - separated by "@" sign. This document describes a basic solution to internationalized email address (IMA) and includes some preliminary survey results. The proposed solution enables SMTP servers to support IMA. The solution discussed in this document is immediately deployable by interested parties without affecting or breaking any other existing systems. "A New Mechanism for SIP over Mobile IPv6", Pyung-Soo Kim, 29-Jun-05, This draft proposes a new mechanism for Session Initiation Protocol (SIP) over Mobile IPv6. In this mechanism, a home agent (HA) on home subnet acts as a redirect server and a registrar for SIP as well as a home router for Mobile IPv6. Thus, a binding cache in the HA contains location information for SIP as well as home registration entries for Mobile IPv6. An access router on foreign subnet acts as only a router that offers a domain name. To implement the proposed mechanism, some messages used in network layer are newly defined, such as a router advertisement, a router solicitation and a binding update. In the proposed mechanism, a mobile node doesn't require dynamic host configuration protocol (DHCP) and thus both home and foreign subnets don't need DHCP servers, unlike existing mechanisms on Mobile IPv4. "Media Server Request Protocol", Chris Boulton, Tim Melanchuk, 29-Jun-05, This document describes a protocol for application deployment where the application logic and media processing are distributed. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between Application Servers and Media Servers. The motivation for this protocol is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the XCON work group of the IETF. "LRDP: The Lightweight Remote Display Protocol", Vlad Stirbu, 29-Jun-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) remoting operations. "Handover Keys Using AAA", Vidya Narayanan, 30-Jun-05, This document describes a AAA-assisted key management protocol to generate session keys between a mobile node (MN) and an access router (AR) for the purpose of securing handoff signaling messages. As such, it specifies a message exchange between the MN and the AR, payloads to carry keying material and parameters in the AAA infrastructure, and assumptions that must hold in order for this protocol to work. The idea is that the key derived between a mobile node and an access router through this protocol can be used in fast handovers (both IPv4 and IPv6). "The Meta-QoS-Class concept", Pierre Levis, Mohammed Boucadair, 30-Jun-05, This document describes a framework for inter-domain Quality of Service (QoS). It makes use of a new concept denoted by Meta-QoS- Class. This new concept guides and simplifies QoS agreements between providers and opens up new perspectives for a global QoS-enabled Internet. "Analysis of the Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute (ETSI) Next Generation Networks (NGN) simulation service", Roland Jesske, 30-Jun-05, This document analyzes the requirements generated by ETSI to support NGN simulation services implemented with SIP. The document analyzes standard solutions that can meet the requirements. Where a standard solution is not available, the document proposes one or more solutions. The aim is to provoke discussion within the Internet community and get early feedback. "Ports Option Support in DSTM", Myung-Ki Shin, 30-Jun-05, As an extension to the address allocation process for DSTM, this document defines the ports option for DSTM. A DSTM server may also provide a range of port numbers to be used by the client. This would allow the use of the same IPv4 address by several DSTM nodes at the same time, reducing the size of the required IPv4 address pool. "CHAP-based Authentication for DHCPv6", Masazumi Ota, Mayumi Yanagiya, 30-Jun-05, In delayed authentication in DHCPv6[RFC3315], the hardware identifier is used to select the key, and the key is exchanged between the server and the client in advance. Therefore, when a user tries to use a new device, it is necessary to add key information to the new device and DHCPv6 servers. In this document, we propose a procedure for introducing CHAP[RFC1994] into the DHCPv6 authentication procedure. This procedure allows the client get the host configuration information related to the user and exchanges a secret key to use in later sequence. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 1-Jul-05, This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) in support of the European Telecommunications Standards Institute (ETSI) Next Generation Networks (NGN)", Miguel Garcia-Martin, 1-Jul-05, This document describes a private SIP header field (P-header) used by the European Telecommunications Standards Institte (ETSI) in Next Generation Networks (NGN). The P-header is used for triggering services. "Local HA to HA protocol", Vijay Devarapalli, 5-Jul-05, This document describes the use of an Inter Home Agents protocol (HAHA) to achieve Home Agent reliability and load balancing. The protocol allows Home Agents serving the same home link to share the binding cache contents, and switch a mobile node from one home agent to another. It also allows a mobile node to utilize multiple Home Agents simultaneously. A mobile node picks one Home Agent as its primary Home Agent and registers with it. The primary Home Agent synchronizes the binding cache information with other Home Agents. Any of Home Agents can intercept a packet meant for the mobile node and tunnel the packet directly to its current Care-of address. "SAFENeT: Server-based Architecture For Enterprise NAT and Firewall Transversal", Richard Townsend, 5-Jul-05, One of the main challenges hindering the acceptance of VoIP is a standards-based solution for traversing middleboxes such as Network Address Translation (NAT) and FireWall (FW) boxes. This Internet- Draft presents SAFENeT, a protocol that is intended to operate in an enterprise environment and that allows the accommodation of real-time services by the call server, internal to the enterprise network, to communicate with the NAT/FW to enable the transversal of real-time services including VoIP. This document describes the SAFENeT architecture and protocol and shows how it overcomes the problems caused by NATs/FWs. The SAFENeT architecture also enables security features such as data confidentiality and digital integrity to be used for the VoIP traffic traversing the NAT/FW. "Obtaining Additional Permissions from Contributors", Scott Bradner, 5-Jul-05, This is a proposed update to "IETF Rights in Contributions" (RFC 3978 - BCP 78). It proposes a change in the rights required from authors of contributors to the IETF. "External failure propagation", Robert Raszuk, 5-Jul-05, The current BGP specification calls for sending prefix based routing information when a BGP peer fails to all other peers so that they could converge using the new information. Certain network events could be communicated to BGP speakers in an aggregated fashion. This not only minimizes control plane traffic but more importantly reduces the time to react to these events by the The current BGP specification calls for sending prefix based routing information when a BGP peer fails to all other peers so that they could converge using the new information. Certain network events could be communicated to BGP speakers in an aggregated fashion. This not only minimizes control plane traffic but more importantly reduces the time to react to these events by the "RADIUS Attributes for WLAN", Bernard Aboba, 5-Jul-05, IEEE 802.11i defines the use of EAP authentication with IEEE 802.11 wireless LANs. Although AAA support is optional within IEEE 802.11i, it is expected that many IEEE 802.11i authenticators will function as AAA clients. This document proposes additional attributes for use by IEEE 802.11 authenticators. The attributes defined in this document are compatible with those used within Diameter EAP. "PCE Management Interface", Eduardo Grampin, 5-Jul-05, The Path Computation Element (PCE) Architecture provide a framework to support the Constraint-Based Routing (CBR) functionality for traffic engineering systems in Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. The model define the PCC and PCE entities at the Control Plane, which communicate using a Request/Reply protocol. The PCE architecture enable network operators a tight control of the resource assignment by means of the administrative constraints that are included in the Traffic Enginnering Database (TED), and used in the path computation process. Moreover, appropriate objective funtions assist operators in the fulfillment of the overall network objectives. This document present a system architecture for the PCE, namely Routing and Management Agent (RMA), with a standard management interface, which permit established management frameworks to rely on the PCE for the CBR functionality and inject network-wide policies into the PCE path computation process. Some reliability issues of the PCE Architecture are addressed in the document. "Binding Identifier Extension for Mobile IPv4", Nobuo Ogashiwa, 5-Jul-05, This document specifies a new extension for Registration Request message and Registration Reply message in Mobile IPv4. This extension can be added by mobile mode and home agent to Registration Request and Registration Reply messages. This extension carries an identification of binding of a care-of address. "Inter AS option for BGP/MPLS IP VPN", Marko Kulmala, 5-Jul-05, This document describes new Inter-AS option for RFC2547bis services. This option is a hydrid of options A and B that are defined in [2547BIS]. The proposed method can inter-operate seamlessly with a peer that is using rfc2547bis ch 10 option B inter-AS method. In this Inter AS option ASBR 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. Since this option keeps VRFs it will give VPN context at ASBR and inherently provides route filtering based on Route Targets. This option is independent of the interconnecting media. "Transmission of IPv6 Packets over IEEE802.16 Networks", Jae Jin, Yong Kim, 5-Jul-05, This document specifies the transmission of IPv6 packet over 802.16 networks. The specification includes the MTU size of IPv6 packets, the frame format for transmission of IPv6 packets, the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE802.16 networks. It also specifies the content of the Source/Target Link-layer Address option used in Neighbor Discovery Protocol specified in RFC2461 [DISC] when those messages are transmitted on an IEEE802.16 network. "Requirements and Gap Analysis for IP Local Mobility", James Kempf, 6-Jul-05, In draft-kempf-netlmm-nohost-ps, the problems with using global IP mobility management protocols for local mobility and some problems with existing localized mobility management protocols are described. In this document, we explore requirements for localized mobility management in more detail. An extensive gap analysis against the protocols illustrates where existing protocols are able to fulfill the requirements and where they are lacking. "Non-Terminal NAPTR Processing: A Modest Proposal", Lawrence Conroy, 6-Jul-05, Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. "RTP Payload Format for Video Codec 1 (VC-1)", Anders Klemets, 6-Jul-05, This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the proposed Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry and the proposed SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. "Use of the Reason header filed in Session Initiation Protocol (SIP) responses", Roland Jesske, 6-Jul-05, This document proposes the use of the Reason header field in SIP responses. "Mapping non-URIs to contact element in Presence Information Data Format", Jussi Ala-Kurikka, 6-Jul-05, The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The contact element in PIDF is understood as a URI. However, some existing Internet services do not identify users (presentities) natively with a URI. Mapping non-URIs to contact element in Presence Information Data Format (Map2PIDF) specifies the mapping of addresses to a URI in the case of such currently existing services. "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)", Steven Legg, 6-Jul-05, Abstract Syntax Notation X (ASN.X) is primarily an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). "IANA Registration for Enumservice Voice", Rudolf Brandner, 7-Jul-05, This document registers the ENUMservice "voice" (which has a defined sub-type "tel"), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. "Requirements for IPsec Negotiation in the SIP Framework", Makoto Saito, Shingo Fujimoto, 7-Jul-05, It is effective to connect the networked home appliances securely using IPsec [1]. Generally, such devices cannot have the rich calculation resources, and may use the dedicated transport protocol for the media session. The advantages of IPsec are that it doesn't require the rich resources, and is independent of the upper layer protocol. In other words, it is applicable to the various applications. On the other hand, same as the typical usage of IPsec, these network devices should be connected to each other only when they need. Therefore it is desired they can generate the IPsec connections dynamically. Considering above, it makes sense to take advantage of SIP [2] mechanism to build such framework. "Synchronisation of Loop Free Timer Values", Stewart Bryant, 7-Jul-05, This draft describes a mechanism that enables routers to agree on a common convergence delay time for use in loop-free convergence. "MIPv4 Extension for Configuration Options Exchange", Jayshree Bharatia, 7-Jul-05, IP Mobility support for IPv4 [RFC3344] defines a short and skippable extension header format intended to extend the Mobile IP extension address space. Based on the format presented in RFC3344, this draft defines a Mobile IP extension for configuration options, which should be used by any Mobile IP entity to exchange information of the network entities like DNS server address, previous Foreign Agent (FA) address etc. "Optimization of PPP Multiplexing over PPP Multilink", Thima Koren, 7-Jul-05, PPP Multiplexing combines several packets into one larger PPP packet while PPP Multilink fragments large PPP packets into a few smaller PPP packets. This document explains how to optimize the usage of these two protocols together. "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, 7-Jul-05, A Fibre Channel Pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. "IANA Registration for Enumservice Mobile Webpage", Jongyun Ra, 19-Jul-05, This document registers the ENUMservice "mobileweb" using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. "Encoding Instructions for the Generic String Encoding Rules (GSER)", Steven Legg, 7-Jul-05, Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER), and in particular defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. "LowPan Mobility Requirements and Goals", Samita Chakrabarti, 7-Jul-05, IETF LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). Lowpan architecture allows routing to take place at the link layer in order to save payload overhead over the IEEE 802.15.4 link and thus more efficient routing for low power, low data-rate networks such as sensor networks. This document discusses a few scenarios of mobility in LowPan network and states mobility requirements and goals for LowPan networks. "ForCES Protocol Transport Mapping Layer (TML) Over IP Networks", Weiming Wang, Ligang Dong, 8-Jul-05, This document defines ForCES Transport Mapping Layer (TML) over IP networks, the framework and the specifications to meet the ForCES TML requirements. "Getting rid of the cruft: an experiment to identify obsolete standards document", Eliot Lear, Harald Alvestrand, 14-Jul-05, This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify three classes of documents marked as Proposed Standards that should be considered for retirement in some way or another. We propose four options to move forward with further work in this area ranging from doing nothing to accepting the results entirely. "Entire Route Reflect capability", Renhai Zhang, 19-Jul-05, This document defines a new Border Gateway Protocol [BGP4] capability termed 'Entire Route Reflect capability', which would allow a BGP Route Reflector (RR) to reflect all the routes it receives from other client or non-client peers to a peer which would perform load balancing across these routes. "The DNSSEC Lookaside Validation (DLV) DNS Resource Record", Mark Andrews, Samuel Weiler, 8-Jul-05, This document defines a new DNS Resource Record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. These records allow resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or refuse to publish DS records for their children. "Synthetic Location Information in the Domain Name System", Cedric de Launois, 8-Jul-05, This memo defines a new Resource Record (RR) for the Domain Name System (DNS), for experimental purposes. It describes a mechanism to allow the DNS to carry synthetic coordinates about hosts, networks, and subnets. The new resource record, called SLOC, can express synthetic locations in different coordinate spaces. This draft defines the format of the new SLOC RR for the DNS, and reserves a corresponding DNS type mnemonic (SLOC) and numerical code (TBD). "Securing Home Agent List in MIP6", Sachin Dutta, 8-Jul-05, This document identifies one type of the denial of service attack which can be possible in Mobile IP6 and tries to propose a solution for same. Currently in MIP6 each Home Agent is required to maintain a home agent list. This home agent list is generated by receiving RA messages on the home link and the addresses learned are sent to Mobile node when it does Home Agent discovery. On learning this list MN tries to register with addresses in this list one by one in order of preference. Now if the home network is flooded with spurious RA packets having high preference value the home agent list is populated with non reachable addresses and no mobile node is able to register from that home network This document proposes to first carry out reachability confirmation for each home agent entry before adding to Home Agent list "Forward Error Correction (FEC) Streaming Framework", Mark Watson, 8-Jul-05, This document defines a framework for applying Forward Error Correction to UDP flows, primarily intended for streaming media. This framework can be used to define Content Delivery Protocols, in the context of the RMT FEC Building Block, that provide Forward Error Correction for streaming media delivery. Content Delivery Protocols defined using this framework can support FEC Schemes (and associated FEC codes) compliant with the FEC Building Block. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme. "IANA Registration for an Enumservice Containing Number Portability and PSTN Signaling Information", Jason Livingood, Richard Shockey, 8-Jul-05, This document registers the Enumservice “npd” and subtype “tel” using the URI scheme ‘tel:’ as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. "Requirements for a Stage and Studio Multimedia Framework", John Lazzaro, John Wawrzynek, 8-Jul-05, Is the IETF multimedia stack appropriate for use in the digital audio equipment found in recording studios and concert halls? To help answer this question, this memo lists the requirements for a session management framework for stage and studio devices. "TTL Partition Security Mechanism", Miao Fuyou, 8-Jul-05, This draft proposes a TTL-number space "partition" mechanism to shield the access control/management plane of a service provider's (SP) core network from customer traffic. Provider edge routers limit the TTL to a preset maximum value on_USER_data packet that enters core network, and the core network router drops packet with a TTL as small as or smaller than preset value when the packet destination address is the router itself. Since attack packets from a customer site cannot reach the control plane or application of routers in the SP core network, the control plane of the core network is secured against the class of attacks originating outside the core network. "Windows Authorization Data in Kerberos Tickets", Karthik Jaganathan, 8-Jul-05, Microsoft Windows 2000 includes operating system specific data in the Kerberos V5 authorization data field that is used for access control. This data is used to create an NT access token. The access token is used by the system to enforce access checking when attempting to access objects. This document describes the structure of the Windows 2000 specific authorization data that is carried in that field for use by servers in performing access control. "Failover for Multiple Mobile Routers in a Mobile Network", Jiho Ryu, 8-Jul-05, This draft proposed the use of multiple mobile routers in a single NEMO. Failed mobile router is replaced by another mobile router using "prefix peer" relationship among mobile routers in a NEMO. "prefix peer" relationship enables a mobile router's prefix to be handled by another mobile router. "Generalization of iSER for InfiniBand and other Network Protocols", John Hufferd, 8-Jul-05, The iSCSI Extensions for RDMA document [iSER] currently specifies the RDMA data transfer capability for [iSCSI] over iWARP. This document generalizes the iSER document to permit it to be used with other RDMA capable protocols such as InfiniBand. "Loop-free convergence using ordered FIB updates", Pierre Francois, 11-Jul-05, This draft proposes a mechanism to prevent transient loops during non-urgent topology changes by ordering the FIB updates on routers, in networks which use link state routing protocols. This mechanism can be used in case of graceful link shutdowns, metric changes and when a link is enabled. The solution can also be used in conjunction with an IPFRR mechanism wich turns a sudden link failure in a non- urgent change, by ensuring a local protection of the link. After a non-urgent topology change, each routers computes a rank that defines the time at which it can safely update its FIB. A completion message mechanism is also proposed in order to speed up the convergence process. "Host Identity Protocol Location Privacy Extensions", Alfredo Matos, 11-Jul-05, This memo describes a framework for the Host Identity Protocol that provides location privacy and mobility to end hosts. "Interactive Applications using DCCP", Anne-Louise Burness, 11-Jul-05, This document discusses some issues that we, representing a network operator, believe should be addressed if DCCP is to become adopted as the means to congestion control interactive applications. "A Framework for Generalized MPLS (GMPLS) Ethernet", Dimitri Papadimitriou, Jaihyung Choi, 11-Jul-05, Most efforts on Generalized MPLS (GMPLS) have been focused on environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.) and IP/MPLS Packet switched networks. However, 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 provides a framework for GMPLS in support of L2 LSPs in several network environments, in particular, Ethernet. "TESLA source authentication in the ALC and NORM protocols", Sebastien Faurite, 11-Jul-05, This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. This draft only considers the authentication/integrity of the packets generated by the session's sender. "Oscillation Prevention in I-BGP", Tomas Klockar, 11-Jul-05, This memo presents a technique for preventing oscillations in I-BGP. The idea is to utilize already known data in routers to stop oscillation. This builds on the fact that routers can send implicit and explicit withdrawals. Implicit withdrawals are redefined to mean that the route still exist and explicit withdrawal to mean that the route has disappeared. The router can detect and avoid oscillation by storing the implicit withdrawn routes and using them to rule out other routes. The cost is more cheap memory for the RIB-In but no extra expensive memory is needed in the forwarding table. "A Generic Location Privacy Framework", Joao Girao, 11-Jul-05, This memo describes a generic framework that aims at protecting the privacy of its users. It considers both the use of generic identifiers as well as concrete examples of applications. Furthermore, it provides a mobility framework with location privacy in mind. "IPFIX templates for common ISP usages", Emile Stephan, Eric Moreau, 11-Jul-05, Flows and packets observations require several levels of aggregations. Currently switchs and routers analyse flows and export flow information using Netflow. Aggregators are starting to use Netflow or IPFIX to collect basic information and to export aggregated information. In this context, this memo presents potential interoperability issues and proposes to standardize a set of templates to facilitate the exchange of flows and measurements information between ISP. "User Application-to-User Plane Vertical Interface", Jerry Ash, 11-Jul-05, This draft describes a mechanism to map QoS requirements from the User application layer down to the user plane to create an NSIS session. This 'vertical signaling interface' between the user application layer and user plane is needed to communicate these QoS requirements, such as flow priority values, to user plane network elements. "Combined User and Carrier ENUM in the e164.arpa tree", Michael Haberler, Richard Stastny, 11-Jul-05, ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. "NEighborhood Discovery (NED) for Wireless Networks", James Kempf, Rajeev Koodli, 11-Jul-05, In wireless networks, there is a need to discover what types of networks are around a particular node. This need arises both when a node connects initially to a network and when a node needs to perform handover. Characteristics such as type of wireless technology, service provider, bandwidth availability, etc. may all be of interest in making a network connection or handover decision. In addition, a mobile node may require a mapping between the Layer 2 access point identifier and IP link information such as the Mobile IPv4 foreign agent address, or IPv6 access router address and subnet prefixes, so that the node can configure itself for the new IP link prior to moving. This document describes the Neighborhood information Elements Discovery (NED) protocol, for representing information elements that contain neighborhood information. The packet format presented in this document is independent of transport so that multiple mobility protocols can make use of it. "ENUM Validation Token Format Definition", Otmar Lendl, 11-Jul-05, An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. "FPANA: combining PANA and FMIPv6 for fast authentication at handover", Yoshihiko Kainuma, 11-Jul-05, This document proposes a fast authentication protocol called FPANA. A combination of PANA (for node authentication) and FMIP (for fast handover), it offers fast node authentication upon intra-domain handover of a mobile node. Since FPANA makes use of context transfer of the PANA session from the previous access router to the new access router by the HI message of FMIPv6, the PANA session can be set between the mobile node and the new access router prior to the mobile node moving to the new access router. Thus, the mobile node can continue authenticated communication upon intra-domain fast handover. "LDP extensions for Inter-Area LSP", Bruno Decraene, Jean-Louis Le Roux, 11-Jul-05, To facilitate the establishment of Label Switched Paths (LSP) that would span multiple IGP areas in a given autonomous system, this document proposes a new optional label mapping procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the routing table (RIB). Matching is defined by an IP longest match search and does not mandate an exact match. "Simple Mail Transfer Protocol", John Klensin, 11-Jul-05, This document is a largely self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of the obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" mail reading systems and mobile environments. "Operating Virtual concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, 11-Jul-05, This document describes the use of the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and Plesiochronous Digital Hierarchy (PDH) signals. "ENUM Validation Architecture", Alexander Mayrhofer, Bernie Hoeneisen, 11-Jul-05, An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. "Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris Cross, 11-Jul-05, This document proposes a Distributed Multimodal Synchronization Protocol (DMSP) designed to enable multimodal interaction for mobile devices by accessing services in the network. More specifically, this protocol coordinates events of interest between a visual browser or application running on a mobile device with a VoiceXML (Voice Extensible Markup Language) browser running in the network. "Pre-authentication Support for PANA", Yoshihiro Ohba, 11-Jul-05, This document defines an extension to the PANA protocol used for proactively establishing a PANA SA (Security Association) between a PaC in an access network and a PAA in another access network to which the PaC may move. The proposed method operates across multiple administrative domains. "Recommendations on the use of IPv6 in the Session Initiation Protocol (SIP)", Vijay Gurbani, Chris Boulton, 11-Jul-05, Most operational experience with SIP to date has been over the IPv4 network; however, SIP implementations that support IPv6 are starting to emerge. IPv6 support in Session Initiation Protocol (SIP) goes beyond merely running a SIP stack on a host supporting a dual IP- stack (i.e., IPv4/IPv6). In addition to host-level support for IPv6, a SIP stack itself must exhibit certain behavior if it is to support IPv6. This document describes such behavior in the form of recommendations that SIP implementors can use while constructing IPv6-aware SIP clients and servers. This work is being discussed on the sipping@ietf.org mailing list. "The RC4-HMAC Kerberos encryption type", Karthik Jaganathan, 20-Jul-05, The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES based encryption types. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong crypto (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types "TIPC based TML for the ForCES protocol", Jon Maloy, 11-Jul-05, This document describes a ForCES [ForCES] Transport Mapping layer (TML) based on the Transparent Inter Process Communication service [TIPC]. It is intended to be used when the ForCES protocol is transported over L2 carriers such as Ethernet, RapidIO or PCI- Express. TIPC has been specially designed for efficient and easy-to- use communication over L2 carriers, and is typically used to define clusters of loosely coupled nodes in such environments. "Common RADIUS Implementation Issues and Suggested Fixes", David Nelson, 11-Jul-05, This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, violations of recommendations from RADIUS RFCs are mentioned. "Internet Routing Protocol Standardization Criteria", Bill Fenner, Alex Zinin, 11-Jul-05, This document provides guidance for the advancement of the protocols produced within the IETF Routing Area. It places implementation and interoperability constraints on protocols earlier in the standards process than RFC 2026, based on RFC 2026's provision that the IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. We also discuss the applicability of these rules to protocols and their extensions. "A Solution to the Heterogeneous Error Response Forking Problem (HERFP) in the Session Initiation Protocol (SIP)", Rohan Mahy, 11-Jul-05, The SIP protocol defines a role for proxy servers which can forward requests to multiple contacts associated with a specific resource or person. While each of these contacts is expected to send a response of some kind, responses for each branch are not necessarily sent back to the original requester. The proxy server forwards only the "best" final response back to the original request. This behavior causes a situation known as the Herterogeneous Error Response Forking Problem (HERFP) in which the original requester has no opportunity to see or fix a variety of potentially repairable errors. This document describes a backwards compatible solution to the HERFP problem for INVITE transactions. "Media Server Control Language and Protocol Thoughts", Eric Burger, 11-Jul-05, IP mutli-function Media Server control is a problem that has slowly bubbled up in importance over the past four years. A driver in the IETF is the requirements generated by the XCON framework. Many approaches have been proposed. Some of these proposals are device- controlled-oriented, such as H.248. Others are server-oriented, using SIP and application-oriented markup. Before rushing headlong into a framework for a solution, it is time to step back and try to understand just what the scope of the problem is. Once consensus is reached, we can then move forward with a framework for a solution. This document describes a number of existing approaches and proposals to solve the Application Server - Media Server protocol problem, their characteristics and benefits and drawbacks. "Internet Protocol (IP) Extension for a Real Time Service", Dimitar Aleksandrov, 11-Jul-05, The Real Time Network Service (RTNS) is a process of data transfer (with real time characteristics) between two end systems. It is part of the OSI model of the Network layer, the Internet layer ot the DoD model respectively. It is not a separate protocol, but rather an additional service, of which applications, exchanging data in real time, can take advantage. In the current document this service is defined as an option of the Internet Protocol. "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", Jean-Louis Le Roux, 20-Jul-05, This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. "Recommended Relationships between Different Types of Identifiers.", Henning Schulzrinne, Eunsoo Shim, 11-Jul-05, Evolution of communications technologies brought us various types of identifiers or addresses that identify persons such as SIP URIs, email addresses, and telephone numbers. Proper relationships among different type of identifiers can enable various services, which, otherwise, are difficult to realize. This memo provides guidelines for managing relationships between SIP URIs other personal identifiers. "OAM Requirements for GMPLS Networks", Thomas Nadeau, 11-Jul-05, This document describes requirements for operations and management for Generalized Multi-Protocol Label Switching networks, as well as for applications of Generalized Multi-Protocol Label Switching. "6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)", Soohong Park, 19-Jul-05, 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended for use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified on-demand routing protocol based on AODV. "Simple Service Location Protocol (SSLP) for 6LoWPAN", Soohong Park, 11-Jul-05, The Simple Service Location Protocol (SSLP) provides a framework for the discovery and selection of the services working on 6LoWPAN. The protocol has a simple structure that is easy to be implemented on 6LoWPAN devices that are characterized by short range, low bit rate and low power. The protocol also offers a mechanism for interoperability with the IP networks under SLP. It enables communication between 6LoWPAN and other IP networks. "Interoperability of 6LoWPAN", Soohong Park, 19-Jul-05, This document specifies the gateway architecture for the interoperability between 6LoWPAN and external IPv6 networks. The gateway does the compression and decompression of IPv6 packets and performs the mapping between 16 bit short addresses and the IPv6 addresses for both the external IPv6 networks and 6LowPAN, respectively. "Content-Digest and EDigest Header Fields", William Leibzon, 11-Jul-05, This document defines Content-Digest header field, which can be used for including hash of MIME content body and header fields data and can support several hash algorithms and canonicalization methods. EDigest header field is also defined which allows to specify digest information for external content part or hash of several content parts joined together. "Session Initiation Protocol Exceptional Procedure Examples", Miki Hasebe, 15-Jul-05, This document gives examples of Session Initiation Protocol (SIP) exceptional-procedure call flows. These senarios are confusing and this document shows the best practices to handle them. 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. "Extensions to the OSPF Management Information Base in support of GMPLS", Tomohiro Otani, 12-Jul-05, This memo defines the Management Information Base (MIB) objects in order to manage OSPF routing information with extension in support of Generalized Multi-Protocol Label Switching (GMPLS) for use with network management protocols. "Rationale for Location by Reference", James Winterbottom, 12-Jul-05, This document motivates the provisioning of location by-reference within the GEOPRIV architecture. Location by-reference takes the form of a URI in contrast to provisioning a static location. "Extensible Message Application Interchange Language (EMAIL) -- Part One: Introduction and Overview", Bruce Lilly, 12-Jul-05, The Internet Message Format originally formally specified in RFC 561 has been extended in some ways and for some purposes which have posed difficulties for some desirable operations such as digitally signed messages, have led to clutter in message content which in turn has led user agent implementers to suppress display of some originator message content, leading in some cases to user confusion, surprise, and embarrassment. This memo is part of a multi-document series that specifies an extensible message format which is intended to facilitate operations hampered by extensions to the current format and to reduce clutter in the user-to-user message content. This memo will present a brief history of the Internet Message Format evolution, will identify problems caused by changes that have been made, and will introduce terminology and concepts that will be used in other documents in the series. "Extensible Message Application Interchange Language (EMAIL) -- Part Two: Syntax, Semantics, and Media Types", Bruce Lilly, 12-Jul-05, The Internet Message Format originally formally specified in RFC 561 has been extended in some ways and for some purposes which have posed difficulties for some desirable operations such as digitally signed messages, have led to clutter in message content which in turn has led user agent implementers to suppress display of some originator message content, leading in some cases to user confusion, surprise, and embarrassment. This memo is part of a multi-document series that specifies an extensible message format which is intended to facilitate operations hampered by extensions to the current format and to reduce clutter in the user-to-user message content. This memo defines and provides registration information for media types relevant to the extensible message format. "Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios", Thomas Nadeau, George Swallow, 19-Jul-05, This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching Label Switched Paths that extend beyond a single Autonomous System and/or across multiple Service Provider network boundaries. This document describes extensions to the existing MPLS LSP Ping protocol to achieve these goals. "The _service domain and prefix", Jeroen Massar, 12-Jul-05, This document defines a new domain, _service., which can be used for automatic service configuration and discovery. The associated anycast prefixes can be used to configure a default DNS server, which provides lookups for a local _service. domain but also acts as a (caching) recursive DNS server, thus allowing DNS clients to use this well-known address as their default DNS server as well as to use it to find various well known services, thus avoiding manual configuration. "DomainKeys Identified Mail (DKIM)", Eric Allman, 12-Jul-05, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to prove and protect message sender identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Proof and protection of email identity, including repudiation and non-repudiation, may assist in the global control of "spam" and "phishing". "DKIM Sender Signing Policy", Eric Allman, 12-Jul-05, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [ID- DK-BASE]. This document describes the policy records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results. "Mobile IPv6 Fast Handovers for 3G CDMA Networks", Hidetoshi Yokota, Gopal Dommety, 12-Jul-05, Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node moves between access provider networks. However, this handover procedure requires not only movement detection, but also the acqusition of a new care-of address and the sending of a binding update message to the home agent before the traffic begins to direct to the new location. During this period, packets destined for the mobile node will be lost, which may not be acceptable for real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods and selective bi-casting methods in the 3G context in order to reduce latency and packet loss during handover. "Terms of Appointments for Nomcom-selected IETF Leadership Positions", John Klensin, 12-Jul-05, A consensus is emerging in the IETF that very long tenure in leadership roles is not in the best interests of the community. While, in theory, that advice could simply be given to the Nomcom, there is reason to believe that a different model for consideration of renewal or replacement for members of the leadership would be more efficient for the Nomcom and would impose less hardship on incumbents and the community. This document outlines that alternate method. "Inter-domain Data Exchange Questionnaire", Elisa Boschi, 12-Jul-05, This document has been created to raise the question of inter- domain measurements and data exchange between ISPs. The goal of this questionnaire is to find out what the main concerns are, and whether and how an inter-domain collaboration would be beneficial for the community. "Issues with existing Cryptographic Protection Methods for Routing Protocols", Vishwas Manral, 21-Jul-05, Routing protocols often use cryptographic mechanisms to authenticate data being received from a neighboring router has not been modified in transit, and actually originated from the nrighboring router purporting to have originating the data. Most of the cryptographic mechanisms rely on hash algorithms applied to the data in the routing protocol packet, which means the data is transported, in the clear, along with the has signature based on the data itself. These mechanisms rely on the manual configuration of the keys used to seed, or build, these hash based sigantures. This document outlines some of the problems with manual keying of these cryptographic algorithms. "LDP-based Autodiscovery for L2 Services", Yakov Stein, Simon DeLord, 12-Jul-05, Current L2VPN implementations that use LDP for label binding require another protocol to dynamically detect which PEs belong to a given VPN. We herein propose a simple extension to LDP consisting of a message with which a PE announces its desire to join an existing VPN. The technique is equally applicable to HVPLS, multisegment VPLS and VPWS, and may be especially attractive for access networks employing MPLS. "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", Matthew Bocci, Stewart Bryant, 12-Jul-05, This document describes an architecture for extending pseudo wire emulation across multiple packet switched network segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, and where the emulated service originates and terminates on the same providers PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudo wires, defines terminology, and specifies the various protocol elements and their functions. "Extensible Message Application Interchange Language (EMAIL) -- Part Three: Media Types Registration Guidelines", Bruce Lilly, 12-Jul-05, The Internet Message Format originally formally specified in RFC 561 has been extended in some ways and for some purposes which have posed difficulties for some desirable operations such as digitally signed messages, have led to clutter in message content which in turn has led user agent implementers to suppress display of some originator message content, leading in some cases to user confusion, surprise, and embarrassment. This memo is part of a multi-document series that specifies an extensible message format which is intended to facilitate operations hampered by extensions to the current format and to reduce clutter in the user-to-user message content. This memo defines supplementary guidelines for registration of media types relevant to the extensible message format. "Extensible Message Application Interchange Language (EMAIL) -- Part Four: Message/List Registration", Bruce Lilly, 12-Jul-05, The Internet Message Format originally formally specified in RFC 561 has been extended in some ways and for some purposes which have posed difficulties for some desirable operations such as digitally signed messages, have led to clutter in message content which in turn has led user agent implementers to suppress display of some originator message content, leading in some cases to user confusion, surprise, and embarrassment. This memo is part of a multi-document series that specifies an extensible message format which is intended to facilitate operations hampered by extensions to the current format and to reduce clutter in the user-to-user message content. This memo defines and provides registration information for a media type for conveying mailing list information in the extensible message format. "Response Identity and Authentication in Session Initiation Protocol", Feng Cao, Cullen Jennings, 12-Jul-05, This draft describes some extensions for verifying SIP response identity and enhancing SIP response authentication. Some mechanisms are demonstrated for providing and verifying the identity of SIP responses. In order to prevent several kinds of security attacks through SIP response, SIP response authentication should be provided through a chain of trust of the SIP responses. Some extensions are proposed to enhance the per-hop authentication for handling SIP response. "RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes", Colin Perkins, 12-Jul-05, This memo extends the RTP Payload Format for Uncompressed Video to support additional RGB sampling modes. "RTCP XR - New Parameter Extensions", Alan Clark, 12-Jul-05, This document provides suggested extensions to the extended report (XR) packet type blocks for the RTP control protocol (RTCP) for voice over IP (VoIP) monitoring. Additionally, new block types will be defined for other media types such as video. "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers", Bill Fenner, 12-Jul-05, When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and describes the numbers that have already been reserved by other documents. "Multicast With Minimal Congestion Using Connected Dominating Sets", Charles Perkins, 12-Jul-05, Flooding is useful for many reasons in ad hoc networks, but causes congestion that can block traffic. Selecting multi-point relays (MPRs) reduces congestion due to flooding, but has several disadvantages. It is possible to select a subset of the MPRs to do the same job more effectively. In this document, signaling is specified for identifying a relatively small connected dominating set that can still manage the flooding operation. "NSIS Signaling Protocols in Multihomed Mobile Networks", Suwon Lee, 12-Jul-05, A host that is an initiator or responder of NSIS signaling messages can be not only mobile but also multihomed. Multihomed hosts and scenarios may be common in the future IPv6-based Internet. Benefits of multihoming include increased bandwidth, load balancing, load sharing, ubiquitous access, bi-casting, resilience, and etc. NSIS signaling should be able to support various multihoming scenarios. This draft describes NSIS operations and applicability in multihomed environments. "Benchmarking Terminology for Protection Performance", Scott Poretsky, 12-Jul-05, This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP-Layer, so avoid dependence on specific sub-IP protections mechanisms. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Link Protection (APS) for SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for Multi-Protocol Label Switching (MPLS). "ATIS PTSC Work Program", Martin Dolly, 12-Jul-05, At the 63rd Paris IETF Meeting it is anticipated that a new BoF, possibly called VoIP Peering and Interconnect BoF (voipeer), will be held to discuss the subject of VoIP peering. This Internet Draft has been prepared to share the relevant portions of the PTSC current work program, which may be related to this topic, with the IETF. It is hoped that awareness of the Packet Technologies Systems Committee (PTSC) work program will allow for more informed discussion during this BOF. "NSIS Operation Over IP Tunnels", Charles Shen, 12-Jul-05, In this draft we briefly review various IP Tunnelling mechanisms and discuss the main problems with signaling operation over IP tunnels. We also summarize the existing RSVP operation over IP tunnels mechanism. Then we present the design details and case examples of an NSIS operation over IP tunnels scheme. QoS NSLP is assumed as the NSIS signaling application in our discussion. "Composing Presence Information", Henning Schulzrinne, 12-Jul-05, Composition creates a presence document from multiple components published by one or more sources. This document describes use cases for presence composition and identifies sources of information that a composer might draw on. The composing function can be complex, so we intentionally restrict the discussion to cases that are likely to be common across many users of presence systems. "RADIUS Quality of Service Support", Hannes Tschofenig, 20-Jul-05, This document describes an extension to the RADIUS protocol that performs authentication, authorization, and accounting for Quality- of-Service reservations. The described extensions allow network elements to authenticate the initiator of a reservation request (if desired), to ensure that the reservation is authorized, and to account for established QoS resources. Flexibility is provided by offering support for different authorization models and by decoupling specific QoS attributes carried in the QoS signaling protocol from the AAA protocol. This document is the RADIUS complement to the DIAMETER QoS application. "A Uniform Resource Name (URN) for Services", Henning Schulzrinne, 12-Jul-05, The content of many communication services depend on the context, such as the user's location. We describe a 'service' URN that allows to register such context-dependent services that can be resolved in a distributed manner. "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", Hee-Jin Jang, 12-Jul-05, This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.16e suite of specifications. "IPv6 Tunnel Discovery", Jeroen Massar, 12-Jul-05, This document defines how to discover tunnel services using the _service domain. "Composition of Metrics", Al Morton, 12-Jul-05, This memo intends to define metrics that are applicable to both complete paths and sub-paths, where a corresponding relationship can be specified to compose the complete path metric from the sub-path metrics with sufficient accuracy. The current memo gives some background and proposes wording for a Scope and Application section to define this new work. The description of an example metric and statistic follows. "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", Vijay Devarapalli, Pasi Eronen, 12-Jul-05, Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. "IPv6 Address Allocation to End Sites", Thomas Narten, 12-Jul-05, This document revisits the IAB/IESG recommendations on the assignment of IPv6 address space to end sites. Specifically, it indicates that changing the default end-site assignment for typical home and SOHO sites from /48 to /56 is consistent with the goals of IPv6 and RFC 3177. Although it is for the RIR community to make adjustments to the IPv6 address space allocation and end site assignment policies, the IETF community would be comfortable with RIRs changing the default assignment size to /56 for smaller end sites. This document obsoletes RFC 3177 and reclassifies it as historic. "DHCPv4 Extensions and Option for Fast Handovers", Takeshi Ogawa, 12-Jul-05, When a standard IPv4 node (mobile node: MN) changes its wireless network attachment point (performs a handover), it gets new IP layer configuration information (e.g., its new IP address and the addresses of new routers) from a DHCP server and changes its IP layer configuration. During such a handover process, it cannot send or receive IP packets to/from its corresponding node (CN), so a service disruption is caused. In this document, we introduce new DHCPv4 extensions and an option (Fast Handover Option) for fast handovers. This protocol is ported from "DHCPv6 options for Fast Handovers" [6]. It enables DHCP servers to send new configuration information to MNs before a handover to be used after the handover, so MNs can have shorter handover processing times. It is noted that DHCP servers and MNs implementing this protocol can achieve fast handovers with standard IPv4 routers without any other micro-mobility management protocols. "SIP Offer/Answer and Middlebox Communication with End-to-End Security", Dan Wing, 12-Jul-05, This document provides a mechanism to allow middleboxes to see IP addresses, ports, and bandwidth when the session description is in an S/MIME-encrypted body. "Diameter applicability for AAA-HA Interface in Mobile IPv6", Hannes Tschofenig, 12-Jul-05, In Mobile IPv6 deployment a need for interface between the Home Agent and the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This interface should meet a list of requirements. This document provides an overview description of the functionalities and design of Diameter protocol which could meet the specified goals. "Clarifying Construction