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, 8-Mar-06, 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, 27-Feb-06, 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 Session Initiation Protocol (SIP) Application", Miguel Garcia-Martin, 13-Feb-06, 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 the authentication of users and authorization of SIP resources usage from a Diameter server. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)", Moti Morgenstern, 27-Feb-06, 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 parameters of the "Asymmetric Digital Subscriber Line" family of interface types, especially including ADSL, ADSL2, and ADSL2+. "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, 6-Feb-06, 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 parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing ADSL, ADSL2, and ADSL2+ interfaces. Atom Publishing Format and Protocol (atompub) --------------------------------------------- "The Atom Publishing Protocol", Bill de Hora, Joe Gregorio, 22-Feb-06, The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (RFC4287). To provide feedback on this Internet-Draft, join the atom-protocol mailing list (http://www.imc.org/atom-protocol/index.html) [1]. Audio/Video Transport (avt) --------------------------- "RTP Payload Format for Generic Forward Error Correction", Adam Li, 2-Mar-06, 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 algorithm 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 of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely backward compatible with non-FEC capable hosts. The receivers that do not implement FEC can still work by simply ignoring 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, 8-Mar-06, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. 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 summarized reporting mechanism. "RTP Retransmission Payload Format", Jose Rey, 15-Sep-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, 1-Feb-06, 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, Tom Taylor, 10-Nov-05, This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. It obsoletes RFC 2833. 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. It specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. Aside from clarifications to the original document, this memo 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. "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Joerg Ott, Elisabetta Carrara, 30-Dec-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, 25-Jan-06, 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, 25-Jan-06, 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, 6-Sep-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, 23-Jan-06, 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. The memo also describes the syntax and semantics of the SDP parameters needed to support the H.261 video codec. A media type registration is included for this payload format. "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", Joerg Ott, 20-Dec-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 Profile for TCP Friendly Rate Control", Ladan Gharai, 25-Oct-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 ATRAC Family", Matthew Romaine, 2-Dec-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 Format for H.263 using RFC2190 to Historic status", Roni Even, 20-Dec-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, 6-Mar-06, 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-Oct-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 media 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, Andrew Lochbaum, 1-Feb-06, 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", Tom Taylor, Henning Schulzrinne, 6-Jan-06, This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-10) 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", Tom Taylor, Henning Schulzrinne, 1-Dec-05, This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-12) to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. "Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery", Andrew Leung, 1-Feb-06, This memo describes extended uses for payload header in RFC document: "An RTP Payload Format for JPEG 2000 Video Streams." [1] For better support of JPEG 2000 features such as scalability and includes a main header recovery method. This memo MUST be accompanied with a complete implementation of "An RTP Payload Format for JPEG 2000 Video Streams." [1] The RFC document [1] 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. "Media Type Registration of RTP Payload Formats", Stephen Casner, 2-Mar-06, This document specifies the procedure to register RTP payload formats as audio, video or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. "Protocol Extensions for Header Compression over MPLS", Jerry Ash, 7-Mar-06, 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). Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. Each HC scheme operates over a single pseudowire instance very much like it would over a single point-to-point link. "A general mechanism for RTP Header Extensions", David Singer, 9-Feb-06, 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. "Associating SMPTE time-codes with RTP streams", David Singer, 9-Feb-06, 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. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 26-Jan-06, 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. "RTP Payload Format for the Speex Codec", Greg Herlein, 14-Oct-05, Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). "RTP payload format for the G.729EV audio codec", Aurelien Sollaud, 2-Mar-06, This document specifies a real-time transport protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729EV audio codec. A media type registration is included for this payload format. "Enhancements to RTP Payload Formats for EVRC Family Codecs", Qiaobing Xie, Rohit Kapoor, 24-Feb-06, This document defines several enhancements and extensions to the EVRC RTP payload formats defined in RFC 3558. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B encoded speech transported via RTP. VoIP applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. "RTP Payload Format for E-AC-3 Audio", Brian Link, 16-Feb-06, This document describes an RTP payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US HDTV, DVD, cable and satellite television and other media. E-AC-3 is an optional audio format in US and world-wide digital television and high definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. "RTP Payload Format for Vorbis Encoded Audio", Luca Barbato, 28-Feb-06, This document describes an 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 and other setup information. Also included within the document are the necessary details for the use of Vorbis with MIME and Session Description Protocol (SDP). "Real Time Protocol (RTP) MIB Version 2", Alan Clark, Amy Pendleton, 28-Feb-06, 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 Protocol (RTP) systems (RFC3550) and is a proposed replacement for RFC 2959 - the RTP MIB. "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", Stephen Casner, 2-Mar-06, This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. 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, 8-Mar-06, Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that provides the ability for applications to determine the public IP addresses and ports allocated to them by the NAT and to keep NAT bindings open. These addresses and ports 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, 14-Sep-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, 17-Feb-06, This document describes the behavior of an IGMP Proxy, as implemented in NAT devices, and places requirements on such devices. "NAT Behavioral Requirements for Unicast TCP", Saikat Guha, 24-Feb-06, This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. "Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN)", Jonathan Rosenberg, 1-Mar-06, This specification defines a usage of the Simple Traversal of UDP Through NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This usage is useful for elements behind NATs whose mapping behavior is address and port dependent. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running well general purpose servers from ports obtained from the STUN server. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Bidirectional Forwarding Detection", Dave Katz, David Ward, 24-Oct-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 IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 24-Oct-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, 24-Oct-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, 27-Feb-06, 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, 7-Feb-06, 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. "Terminology for Benchmarking IPsec Devices", Michele Bustos, 6-Mar-06, 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, 7-Mar-06, This dpcument 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, 7-Mar-06, This document describes the terminology for benchmarking IGP Route Convergence as described in Applicability document [1] and Methodology document [2]. The methodology and terminology are to be used for benchmarking Convergence Time 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, 7-Mar-06, This document provides considerations for IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence benchmarking terminology [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 data plane is measured to obtain the convergence benchmarking metrics described in [1]. "Terminology for Accelerated Stress Benchmarking", Scott Poretsky, Shankar Rao, 9-Mar-06, 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, 21-Oct-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, 10-Feb-06, Test engineers take pains to declare all factors that affect a given measurement, including intended 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 IPsec Devices", Merike Kaeo, Tim Van Herck, 6-Mar-06, The purpose of this draft is to describe methodology specific to the benchmarking of IPsec IP forwarding devices. It builds upon the tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts 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. "Methodology for Benchmarking Network-layer Traffic Control Mechanisms", Scott Poretsky, 7-Mar-06, This document describes the methodology for the benchmarking of devices that implement traffic control based on IP precedence or diff-serv code point criteria. The methodology is to be applied to measurements made on the data plane to evaluate the performance of the traffic control mechanisms. The methodology permits the specific traffic control mechanisms and configuration commands to vary between DUTs. The methodology uses much of the Terminology defined in [Pp06]. Better-Than-Nothing Security (btns) ----------------------------------- "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, 21-Feb-06, The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication via IKE of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without full IKE authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or 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. "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, 24-Feb-06, This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No IKE extensions are needed, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). "IPsec Channels: Connection Latching", Nicolas Williams, 27-Feb-06, This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by "latching" connections to certain IPsec Security Association (SA) parameters for their lifetime. This can be used to protect applications against accidental reconfiguration of IPsec that might expose live packet flows to unintended peers, such as might happen with Better Than Nothing Security (BTNS). Latched connections represent IPsec channels, and as such, allow for channel binding to IPsec. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 1-Mar-06, This document, [iMIP], specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model [iCAL] are composed using constructs from [RFC-2822], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 9-Mar-06, This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendar systems. This is done in a general way so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol using specific interoperable methods of communications between systems. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", Bernard Desruisseaux, Chris Stoner, 26-Oct-05, Calendar systems export, transport and sometimes even store calendar information in a standard, interoperable format. This memo defines the common format for openly exchanging calendaring and scheduling information across the Internet, known as the iCalendar object format. An iCalendar object may represent an event, to-do or task, or journal entry (note). Comments are solicited and should be addressed to the working group's mailing list at ietf-calsify@osafoundation.org and/or the editor. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", S Govindan, 29-Sep-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. "Evaluation of Candidate CAPWAP Protocols", Darren Loher, 16-Sep-05, This document is a record of the process and findings of the Configuration and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the four candidate protocols as they were submitted to the working group on the 26th of June, 2005. "CAPWAP Protocol Specification", Pat Calhoun, 2-Mar-06, Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized controller and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF CAPWAP working group protocol requirements. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, including an extension which supports the IEEE 802.11 wireless LAN protocol. Future extensions will enable support of additional wireless technologies. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management", Thomas Nadeau, 14-Oct-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, Adrian Farrel, 3-Mar-06, 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, Adrian Farrel, 3-Mar-06, 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. "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. "Exclude Routes - Extension to RSVP-TE", Adrian Farrel, 29-Aug-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. "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, 12-Sep-05, 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. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. "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, 7-Mar-06, Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, and when TE links are unnumbered. Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. When link level failure detection is 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). The use of Node-ID based Hello session is optimal in the sense that as long as there is IP reachability to the nieghbor (node-id), the signalling adjacency will remain up. "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, 9-Feb-06, This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) LSPs signaled with RSVP-TE. 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. "Extensions to GMPLS RSVP Graceful Restart", Arun Satyanarayana, Reshad Rahman, 25-Oct-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, 6-Mar-06, 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. "Label Switched Path Stitching with Generalized MPLS Traffic Engineering", Arthi Ayyangar, JP Vasseur, 23-Sep-05, In certain scenarios, there may be a need to combine together 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 realized 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 may 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 establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", JP Vasseur, 13-Feb-06, This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. "Evaluation of existing Routing Protocols against ASON routing requirements", Dimitri Papadimitriou, 7-Nov-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, 24-Feb-06, 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 The document recommends a proper approach for the interpretation and 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. Finally, it discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. 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. Finally, it discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", Eric Mannie, Dimitri Papadimitriou, 20-Dec-05, This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", JP Vasseur, 7-Feb-06, The set up of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Path (LSP) among a set of Label Switch Routers (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP routing extensions for ISIS and OSPF so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh. "Routing extensions for discovery of Traffic Engineering Node Capabilities", JP Vasseur, Jean-Louis Le Roux, 30-Nov-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. "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", Kohei Shiomoto, 12-Jan-06, Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. 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. "Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)", Jean-Louis Le Roux, 25-Jan-06, 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. "Link Management Protocol (LMP) Management Information Base (MIB)", Martin Dubuc, 22-Feb-06, This document provides minor corrections to and obsoletes RFC 4327. 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). Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "IRIS - An Address Registry (areg) Type for the Internet Registry Information Service", A Newton, 9-Jan-06, 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, 9-Feb-06, 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, 9-Feb-06, 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. "A Common Schema for Internet Registry Information Service Transfer Protocols", Andrew Newton, 9-Feb-06, 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, 9-Feb-06, 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. "Domain Registry Version 2 for the Internet Registry Information Service", Andrew Newton, Frederico Neves, 28-Feb-06, This document describes version 2 of the domain registration information schema for IRIS. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. 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-Aug-05, This document describes, for the historical record, the motivation behind DCCP (the Datagram Congestion Control Protocol), an unreliable transport protocol incorporating end- to-end congestion control. DCCP implements a congestion- controlled, unreliable flow of datagrams 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)", Eddie Kohler, 7-Dec-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): the Small-Packet (SP) Variant", Sally Floyd, Eddie Kohler, 3-Mar-06, This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC 3448]. 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. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a Min Interval of 10 ms between data packets, to prevent a single flow from sending small packets arbitrarily frequently. "Strategies for Streaming Media Applications Using TCP-Friendly Rate Control", Thomas Phelan, 26-Oct-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). 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, 24-Feb-06, This document specifies a Dynamic Host Configuration Protocol 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, 24-Feb-06, 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 Server Identifier Override Suboption", Richard Johnson, 24-Oct-05, This memo defines a new suboption of the DHCP relay information option which allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs 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 DHCP RENEW messages. "Detecting Network Attachment in IPv4 (DNAv4)", Bernard Aboba, 2-Dec-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 from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses 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. "DHCP Preboot eXecution Environment (PXE) Options", Stig Venaas, Michael Johnston, 27-Oct-05, We define DHCP options being used by PXE and EFI clients to uniquely identify booting client machines and their pre-OS runtime environment so the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. "Configured Tunnel End Point Option for DHCPv6", Soohong Park, a Vijayabhaskar, 25-Oct-05, For the newly deployed IPv6 networks to interoperate with vastly deployed IPv4 networks, various transition mechanisms had been proposed. One such mechanism is configured tunnels. This document provides a tunnel discovery mechanism by which the DHCPv6 servers can provide information about the available configured tunnel end points to reach the IPv6 nodes which are separated by IPv4 networks. "DHCP: IPv4 and IPv6 Dual-Stack Issues", Tim Chown, 27-Oct-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. "The DHCPv6 Client FQDN Option", Bernie Volz, 24-Feb-06, 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. "DHCPv6 Relay agent RADIUS Attribute Option", Wing Lau, 6-Feb-06, 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. "DHCPv6 Relay Agent Subscriber-ID Option", Bernie Volz, 6-Mar-06, 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, 6-Mar-06, 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. "Dual-stack clients and merging of data from DHCPv4 and DHCPv6", Stig Venaas, Tim Chown, 26-Oct-05, A node may have support for communications using both IPv4 and IPv6 protocols. Such a node may wish to obtain both IPv4 and IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). This can be done by using the IPv4 and the IPv6 DHC protocols respectively. This document considers mechanisms that allow such a node to make use of the configuration data from both protocols to obtain the desired common configuration. "DHCP option for PANA Authentication Agents", Suraj Kumar, 6-Mar-06, This document defines new Dynamic Host Configuration Protocol options that contain a list of domain names or IP 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). "Domain Suffix Option for DHCPv6", Renxiang Yan, 13-Mar-06, 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. "DHCP Relay Agent Assignment Notification Option", Ralph Droms, 24-Jan-06, The DHCP Relay Agent Assignment Notification option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. "Time Protocol Servers and Time Offset Options for IPv6 DHCP", Ralph Droms, D Evans, 24-Feb-06, The Time Protocol Servers option for IPv6 DHCP (RFC 3315) carries the IPv6 addresses of servers that a host should use for the Time Protocol (RFC 868). The Time Offset option carries the offset in seconds from Coordinated Universal Time (UTC) that a client may use to determine its local time. Diameter Maintanence and Extensions (dime) ------------------------------------------ "The Diameter API", Pat Calhoun, 6-Mar-06, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. Distributed Management (disman) ------------------------------- "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", Juergen Quittek, Kenneth White, 22-Feb-06, This memo defines Management Information Bases (MIBs) for performing ping, traceroute and lookup operations at a 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 resolution of either an IP address to an DNS name or a 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. Domain Keys Identified Mail (dkim) ---------------------------------- "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", Jim Fenton, 7-Mar-06, This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. "DomainKeys Identified Mail Signatures (DKIM)", Eric Allman, 3-Feb-06, 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 Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting 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". Detecting Network Attachment (dna) ---------------------------------- "Link-layer Event Notifications for Detecting Network Attachments", Alper Yegin, 26-Oct-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, 20-Jan-06, 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 therefore 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. "Detecting Network Attachment in IPv6 - Best Current Practices for hosts.", Sathya Narayanan, 26-Oct-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 ascertain 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, 8-Mar-06, 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. "Fast Router Discovery with L2 support", JinHyeock Choi, 18-Oct-05, For efficient DNA, a host should quickly receive an RA (Router Advertisement) 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. "Detecting Network Attachment in IPv6 Networks (DNAv6)", James Kempf, 27-Feb-06, 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 flexibility 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 receive an RA quickly. In this memo, an integrated solution is presented. Monitoring of prefixes by both hosts and routers is used to achieve link identification while router advertisements are sent rapidly in a deterministic order by combining router solicitation source addresses with hash-based router tokens. "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", Greg Daley, 27-Feb-06, 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. "FMIPv6 Usage with DNA Protocol", Rajeev Koodli, Syam Madanapalli, 1-Mar-06, In this document, we describe how the Fast Mobile IPv6 Handovers (FMIPv6) protocol can work where DNA protocol support is available, but the neighborhood information, which is part of the FMIPv6 operation, is not available. DNS Extensions (dnsext) ----------------------- "A DNS RR for Encoding DHCP Information (DHCID RR)", Mark Stapp, 3-Mar-06, It is possible for DHCP clients to attempt to update the same DNS FQDN or attempt to update a DNS FQDN that has been added to the DNS for another purpose 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, 6-Oct-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, 26-Oct-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. "Elliptic Curve Keys and Signatures in the DNS", R Schroeppel, Donald Eastlake, 26-Oct-05, The standard method for storing elliptic curve cryptographic keys and elliptic curve SHA-1 based signatures in the Domain Name System is specified. "The Role of Wildcards in the Domain Name System", Edward Lewis, 9-Jan-06, 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, 27-Oct-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, 1-Feb-06, Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC MD5 (Message Digest) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. "Requirements related to DNSSEC Signed Proof of Non-Existence", Rip Loomis, Ben Laurie, 26-Oct-05, DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. "An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors", Johan Ihren, 27-Oct-05, The DNS Security Extensions (DNSSEC) works by validating so called chains of authority. The start of these chains of authority are usually public keys that are anchored in the DNS clients. These keys are known as the so called trust anchors. This memo describes a method how these client trust anchors can be replaced using the DNS validation and querying mechanisms (in-band) when the key pairs used for signing by zone owner are rolled. This memo also describes a method to establish the validity of trust anchors for initial configuration, or priming, using out of band mechanisms. "Automated Updates of DNSSEC Trust Anchors", Michael StJohns, 10-Jan-06, This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against single key compromise of a key in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor. This mechanism, if adopted, will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. "DNSSEC Hash Authenticated Denial of Existence", Ben Laurie, 9-Mar-06, The DNS Security Extensions introduces the NSEC resource record for authenticated denial of existence. This document introduces a new resource record as an alternative to NSEC that provides measures against zone enumeration and allows for gradual expansion of delegation-centric zones. "Storing Certificates in the Domain Name System (DNS)", Simon Josefsson, 20-Oct-05, Cryptographic public keys 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 obsoletes RFC 2538. "DNSSEC Experiments", David Blacka, 24-Feb-06, 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, 24-Jan-06, 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", Rob Austein, Samuel Weiler, 12-Jan-06, 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. "Derivation of DNS Name Predecessor and Successor", Geoffrey Sisson, Ben Laurie, 6-Oct-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. "DNS Name Server Identifier Option (NSID)", Rob Austein, 12-Jan-06, 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 responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", Wesley Hardaker, 23-Feb-06, This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to key signing DNSKEY key(s) in a child zone. "Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC", Jelte Jansen, 14-Feb-06, This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). "Requirements related to DNSSEC Trust Anchor Rollover", Steve Crocker, 21-Feb-06, Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. Domain Name System Operations (dnsop) ------------------------------------- "Observed DNS Resolution Misbehavior", Matt Larson, Piet Barber, 13-Feb-06, 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. "Requirements for a Mechanism Identifying a Name Server Instance", David Conrad, Suzanne Woolf, 6-Mar-06, 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 for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. "Operational Considerations and Issues with IPv6 DNS", Alain Durand, 20-Oct-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. "DNSSEC Operational Practices", R Gieben, Olaf Kolkman, 9-Mar-06, 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. This document obsoletes RFC 2541, as it covers more operational ground and gives more up to date requirements with respect to key sizes and the new DNSSEC specification. Extensible Authentication Protocol (eap) ---------------------------------------- "Extensible Authentication Protocol (EAP) Key Management Framework", Bernard Aboba, 7-Mar-06, The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the transport and usage of keying material generated by EAP authentication algorithms, known as "methods". It also specifies the EAP key hierarchy. "Network Discovery and Selection Problem", Jari Arkko, Bernard Aboba, 25-Oct-05, The so called network discovery and selection problem affects network access, particularly in the presence of multiple available wireless accesses and roaming. This problem has been the subject of discussions in various standards bodies. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol (EAP) working group at the IETF. The problem is defined and divided into subproblems, and some constraints for possible solutions are outlined. The document presents also some existing mechanisms which help solve at least parts of the problem, and gives some suggestions on how to proceed for the rest. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Requirements for Emergency Context Resolution with Internet Technologies", Henning Schulzrinne, Roger Marshall, 8-Mar-06, This document enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. "A Uniform Resource Name (URN) for Services", Henning Schulzrinne, 7-Mar-06, 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. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", Terry Harding, Richard Scott, 24-Jan-06, 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. Telephone Number Mapping (enum) ------------------------------- "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 9-Mar-06, 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 advisory, 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, 21-Oct-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". "Carrier/Infrastrucure ENUM Requirements", Steven Lind, 21-Oct-05, This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoI "ENUM Validation Information Mapping for the Extensible Provisioning Protocol", Bernie Hoeneisen, 15-Feb-06, This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. "ENUM Validation Architecture", Alex Mayrhofer, Bernie Hoeneisen, 23-Feb-06, 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. "ENUM Validation Token Format Definition", Otmar Lendl, 27-Feb-06, 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. "IANA Registration for an Enumservice Containing PSTN Signaling Information", Jason Livingood, Richard Shockey, 18-Jan-06, This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. "IANA Registration for Enumservice vCard", Alexander Mayrhofer, David Lindner, 30-Nov-05, This memo registers the Enumservice "vCard" with several subtypes according to the IANA Enumservice registration process described in RFC3671. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. "IANA Registration for IAX Enumservice", Ed Guy, 22-Feb-06, This document registers the IAX2 (Inter-Asterisk eXchange Version 2) Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761. "Guide and Template for IANA Registrations of Enumervices", Jason Livingood, Bernie Hoeneisen, 27-Feb-06, This document provides a guide to and template for the creation of new IANA registration of ENUM services. It is also to be used for updates of existing IANA registrations. "Infrastrucure ENUM Requirements", Steven Lind, Penn Pfautz, 6-Mar-06, This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Forwarding Element Model", Lily Yang, 7-Mar-06, 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, 6-Mar-06, This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol messages, the specification also defines the framework, the mechanisms, and the Transport Mapping Layer (TML) requirements for ForCES protocol. "TCP/IP based TML (Transport Mapping Layer) for ForCES protocol", Jon Maloy, 7-Mar-06, This document defines the 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 [5] document. "ForCES Intra-NE Topology Discovery", Hormuzd Khosravi, 21-Oct-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. "ForCES MIB", Robert HAAS, 26-Jan-06, This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a MIB for the Forwarding and Control Element Separation (ForCES) Network Element (NE). The ForCES working group is defining a protocol to allow a Control Element (CE) to control the behavior of a Forwarding Element (FE). 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, 18-Jan-06, 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, 13-Feb-06, 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 Document Format for Expressing Privacy Preferences", Henning Schulzrinne, 8-Mar-06, This document defines a framework for authorization policies controlling 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, 9-Mar-06, 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, 9-Mar-06, This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office and train station. "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Hannes Tschofenig, 3-Mar-06, 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 recommends a subset of GML that MUST be implemented by applications involved in location based routing. "Revised Civic Location Format for PIDF-LO", Martin Thomson, James Winterbottom, 3-Jan-06, This document defines an XML format for the representation of civic location. This format is designed for use with PIDF Location Object (PIDF-LO) documents. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for DHCP, and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. Global Routing Operations (grow) -------------------------------- "Operation of Anycast Services", Joe Abley, Kurt Lindqvist, 27-Jan-06, 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, 7-Feb-06, 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, 9-Mar-06, 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, 4-Mar-06, This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. 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), it provides integrity protection and optional encryption for upper layer protocols, suchs as TCP and UDP. Discussion related to this document is going on at the IETF HIP Working Group mailing list. "Host Identity Protocol Architecture", Robert Moskowitz, Pekka Nikander, 22-Aug-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, 1-Mar-06, 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, 27-Feb-06, This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP.) This RR allows 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 Names of its rendezvous servers (RVS.) "Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier, Lars Eggert, 10-Oct-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, 4-Mar-06, 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). "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, 16-Dec-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. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Managed Objects of EPON", Lior Khermosh, 13-Feb-06, 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 for generic point to multi-point (P2MP) networks, and in specifically Ethernet Passive Optical Networks (EPON) interfaces, defined in IEEE Std 802.3ah-2004, which amends IEEE Std 802.3-2002. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", Edward Beili, 27-Oct-05, This document defines a Management Information Base (MIB) module 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 modules 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. "Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces", Matt Squire, 8-Mar-06, This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet like interfaces conformant to the Ethernet OAM functionality defined in [802.3ah]. The Ethernet OAM functionality is complementary to SNMP management in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions, and for providing results and status of the OAM functions to management entities. "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", Edward Beili, 27-Oct-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. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. Internet Architecture Board (iab) --------------------------------- "A Survey of Authentication Mechanisms", Eric Rescorla, 22-Feb-06, Authentication is a common security issue for the design of Internet protocols. A wide variety of authentication technologies are avail- able. A common problem is knowing which technology to choose or which of a variety of essentially similar implementations of a given tech- nique to choose. This memo provides a survey of available mechanisms and guidance on selecting one for a given protocol. "Internet Denial of Service Considerations", Eric Rescorla, Mark Handley, 16-Sep-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, 21-Dec-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. "IAB Thoughts on the Role of the Internet Research Task Force (IRTF)", Sally Floyd, 28-Dec-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 relationship 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. "Considerations for Selection of Techniques for NAT Traversal", Jonathan Rosenberg, 11-Oct-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, 9-Dec-05, Since the late 1980s, 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. "Guidelines for Acting as an IETF Liaison to Another Organization", Loa Andersson, 8-Mar-06, Whenever IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052 [RFC4052]. This document gives guidelines on expectations, tasks, responsibilities and mandate of the liaison managers. "Review and Recommendations for Internationalized Domain Names (IDN)", John Klensin, Patrik Faltstrom, 6-Mar-06, This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and those for use of those names for use in the DNS. It recommends that IETF should update the IDN related RFCs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the IDNA standard and its supporting tables, based on experience gained since those standards were completed. Inter-Domain Routing (idr) -------------------------- "Cooperative Route Filtering Capability for BGP-4", Enke Chen, Yakov Rekhter, 10-Mar-06, 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, 11-Nov-05, Currently the Autonomous System number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. "Aspath Based Outbound Route Filter for BGP-4", Keyur Patel, Susan Hares, 21-Feb-06, This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 21-Dec-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, 25-Jan-06, 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, 6-Mar-06, 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, 11-Nov-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. "Autonomous System Confederations for BGP", Paul Traina, 5-Oct-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 Route Reflection - An Alternative to Full Mesh IBGP", Tony Bates, 12-Oct-05, The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed. This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. "Multisession BGP", John Scudder, Chandrashekhar Appanna, 10-Mar-06, This specification augments "Multiprotocol Extensions for BGP-4" [MP- BGP] by proposing a mechanism to allow multiple sessions to be used between a given pair of BGP speakers. Each session is used to transport routes for one or more AFI/SAFI. This provides an alternative to the current [MP-BGP] approach of multiplexing routes for all AFI/SAFI onto a single connection. Use of this approach is expected to increase the robustness of the BGP protocol as it is used to support more and more diverse AFI/SAFI. "Avoid BGP Best Path Transitions from One External to Another", Enke Chen, Srihari Sangli, 27-Dec-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 BGP speaker contribute to the churn. "Address Prefix Based Outbound Route Filter for BGP-4", Enke Chen, 11-Nov-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. "The AS_HOPCOUNT Path Attribute", Tony Li, 29-Dec-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. "The AS_PATHLIMIT Path Attribute", Tony Li, 9-Mar-06, This document describes the 'AS path limit' (AS_PATHLIMIT) 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. 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, 13-Feb-06, The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes a data model to represent information exported by intrusion detection systems, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "The Intrusion Detection Exchange Protocol (IDXP)", Benjamin Feinstein, Gregory Matthews, John White, 23-Oct-02, This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in the Intrusion Detection Message Exchange Format (IDMEF) [2], a companion document of the Intrusion Detection Exchange Format (IDWG) working group of the IETF. Internet Emergency Preparedness (ieprep) ---------------------------------------- "A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain", Ken Carlberg, 13-Dec-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) ------------------------------------------ "DISCUSS Criteria in IESG Review", Jon Peterson, 7-Feb-06, 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, 28-Nov-05, The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. "IMAP4 LIST Command Extensions", Barry Leiba, Alexey Melnikov, 6-Mar-06, 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, 13-Feb-06, Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of 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) 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. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). "Internet Message Access Protocol Internationalization", Chris Newman, 1-Mar-06, 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. Internet and Management Support for Storage (imss) -------------------------------------------------- "Fibre-Channel Name Server MIB", Claudio DeSanti, 20-Dec-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 Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. "Fibre Channel Fabric Address Manager MIB", Claudio DeSanti, 22-Nov-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. "Fibre-Channel Routing Information MIB", Claudio DeSanti, 5-Jan-06, 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. "MIB for Fibre-Channel's Fabric Shortest Path First Protocol", Claudio DeSanti, 21-Oct-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. "The Virtual Fabrics MIB", Scott Kipp, 26-Jan-06, 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. Extended Incident Handling (inch) --------------------------------- "The Incident Object Description Exchange Format Data Model and XML Implementation", Jan Meijer, 15-Nov-05, The purpose of the Incident Object Description Exchange Format (IODEF) is to define a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. The IODEF satisfies the requirements specified in RFCXXX [1] This Internet-Draft describes a data model for representing incident information exported from incident handling systems managed by CSIRTs. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "Requirements for the Format for Incident Information Exchange (FINE)", Yuri Demchenko, 2-Mar-06, This document describes the high-level functional requirements of an abstract format, the Format for Incident information Exchange (FINE), which will facilitate the exchange of incident information among computer security incident response teams (CSIRTs) and involved parties. A common and well-defined format will help in the exchange of incident related information across organizations, regions, and countries. Implementations of FINE will also be useful for reactionary analysis of current threats and support the proactive identification of trends that can lead to incident prevention. "Incident Handling: Real-time Inter-network Defense", Kathleen Moriarty, 17-Oct-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 (NPs) 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 is 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, 8-Nov-05, This document extends the INCH XML incident reporting format for reporting phishing, fraud, other types of electronic crime, and widespread spam attacks and incidents. Although the term "phishing attack" is used, 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, along with simple spam. 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. "IODEF/RID over SOAP", Kathleen Moriarty, 1-Mar-06, Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an inter-operable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP(S) and SOAP over BEEP. IP over Cable Data Network (ipcdn) ---------------------------------- "Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems", Richard Woundy, Kevin Marez, 5-Mar-06, 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, Eduardo Cardona, 27-Oct-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 and obsoletes RFC 2670. Please see section 6 for a description of the changes from RFC 2670. Note to RFC Editor (Remove this paragraph prior to publication) 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. "Network-Based Call Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)", Gordon Beacham, 6-Mar-06, 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 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. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects are consistent with the SNMP framework and existing SNMP standards. "Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices", Eugene Nechamkin, Jean-Francois Mule, 27-Dec-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, 27-Oct-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) ------------------- "Address Resolution for IP Datagrams over MPEG-2 Networks", Gorry Fairhurst, Marie-Jose Montpetit, 9-Feb-06, 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) value 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 the ND protocol, and provides guidance on usage. IP Flow Information Export (ipfix) ---------------------------------- "Architecture for IP Flow Information Export", Ganesh Sadasivan, 15-Aug-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, 28-Sep-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, 7-Sep-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) -------------------------- "Definitions of Managed Objects for InfiniBand Interface Types", Bill Anderson, Sean Harnedy, 13-Sep-05, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet community. In particular, it defines objects for managing IBA defined InfiniBand interfaces. "Definitions of Managed Objects for the InfiniBand Subnet Management Agent (SMA)", Sean Harnedy, 13-Sep-05, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Subnet Management Agents (SMA). "Definitions of Textual Conventions and OBJECT-IDENTITIES for IP Over InfiniBand (IPOVERIB) Management", Sean Harnedy, 9-Sep-05, This memo defines a Management Information Base (MIB) module that contains Textual Conventions and OBJECT-IDENTITIES for use in definitions of management information for IP Over InfiniBand (IPOVERIB) networks. The intent is that these TEXTUAL CONVENTIONs (TCs) will be imported and used in IPOVERIB related MIB modules. "IP over InfiniBand(IPoIB) Architecture", Vivek Kashyap, 4-May-04, InfiniBand is a high speed, channel based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. "Transmission of IP over InfiniBand", H.K. Jerry Chu, Vivek Kashyap, 13-Jan-05, This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link layer address to be used when resolving the IP addresses in 'IP over InfiniBand (IPoIB)' subnets. The document also describes the mapping from IP multicast addresse to InfiniBand multicast addresses. Additionally this document defines the setup and configuration of IPoIB links. "DHCP over InfiniBand", Vivek Kashyap, 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. "Definitions of Managed Objects for InfiniBand Channel Adapters (CA)", Sean Harnedy, 13-Sep-05, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Channel Adapters (CA). "Definitions of Managed Objects for the InfiniBand Baseboard Management Agent (BMA)", Sean Harnedy, 13-Sep-05, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Baseboard Management Agents (BMA). "Definitions of Managed Objects for the InfiniBand Performance Management Agent (PMA)", Sean Harnedy, 13-Sep-05, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand Performance Management Agents (PMA). "IP over InfiniBand: Connected Mode", Vivek Kashyap, 2-Dec-05, This document describes transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. IP over Resilient Packet Rings (iporpr) --------------------------------------- "Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks", Marc Holness, Glenn Parsons, 8-Nov-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, 6-Mar-06, 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. "Packet Reordering Metric for IPPM", Al Morton, 13-Dec-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 assessing 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 relating to IETF work on IP Performance Measurements (IPPM, RFC 2678 - 2681)", Henk Uijterwaal, 3-Jan-06, 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, 11-Nov-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. "A Two-way Active Measurement Protocol (TWAMP)", Jozef Babiarz, 11-Nov-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. "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, 13-Jan-06, 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. "Spatial Composition of Metrics", Al Morton, Emile Stephan, 28-Feb-06, This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. "Framework for Metric Composition", Al Morton, Steven Van den Berghe, 28-Feb-06, This memo describes a framework for composing and aggregating metrics (both in time and in space) defined by RFC 2330 and developed by the IPPM working group. The framework describes the generic composition and aggregation mechanisms. It provides a basis for additional documents that implement this framework for detailed, and practically useful, compositions and aggregations of metrics. Intellectual Property Rights (ipr) ---------------------------------- "RFC 3978 Update", Scott Bradner, 2-Mar-06, This document modifies RFC 3978 "IETF Rights in Contributions" as follows: (1) recognizing that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights, (2) giving IETF Trust the right to permit extraction of material from RFCs, and (3) giving IETF Trust the right to permit others to create derivative works outside the IETF Standards Process. This document does not constrain how the IETF Trust exercises those rights. "Advice to the IAOC on Rights to be Granted in IETF RFCs", Joel Halpern, 4-Mar-06, The IASA is resposible for managing intellectual property rights on behalf of the IETF. This includes the license to copy, implement and otherwise use IETF contributions, among them Internet-Drafts and RFCs. The IASA takes direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding rights granted in IETF contributions. IP Storage (ips) ---------------- "Definitions of Managed Objects for iSCSI", Mark Bakke, 11-Oct-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. "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", Kevin Gibbons, 27-Jan-06, The iSNS protocol [RFC4171] provides storage name service functionality on an IP network that is being used for iSCSI [RFC3720] or iFCP [RFC4172] 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@ietf.org and/or the authors. "Definition of Managed Objects for SCSI Entities", Michele Hallak, 30-Jan-06, 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 Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. "Definitions of Managed Objects for IP Storage User Identity Authorization", Mark Bakke, Jim Muchow, 27-Feb-06, 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, 20-Oct-05, iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol such as the iWARP protocol suite. An RDMA-Capable Protocol 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 provided by an RDMA-Capable Protocol such as the iWARP protocol suite. "iSCSI Implementer's Guide", Mallikarjun Chadalapaka, 3-Mar-06, 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 Policy (ipsp) ------------------------- "IPsec Security Policy Database Configuration MIB", Wesley Hardaker, 3-Mar-06, This document defines an 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 are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards based defined packet filters and actions. "IPsec Security Policy IPsec Action MIB", Wesley Hardaker, 12-Aug-05, This document defines a SMIv2 Management Information Base (MIB) module for configuring IPsec actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IPSec protocol actions on that device. The IPSP IPsec Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. "IPsec Security Policy IKE Action MIB", Wesley Hardaker, 12-Aug-05, This document defines a SMIv2 Management Information Base (MIB) module for configuring IKE actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IKE protocol actions on that device. The IPSP IKE Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. IP Telephony (iptel) -------------------- "A Telephony Gateway REgistration Protocol (TGREP)", Manjunath Bangalore, 22-Feb-06, 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, 23-Feb-06, This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. "Number Portability Parameters for the "tel" URI", James Yu, 24-Jan-06, This document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. "The ENUM Dip Indicator parameter for the "tel" URI", Richard Stastny, 20-Dec-05, This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in VoIP (Voice over Internet Protocol) network elements. A VoIP network element may receive an URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such an URI, it asserts that an ENUM query has been carried out on this number. "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Cullen Jennings, Vijay Gurbani, 14-Feb-06, This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. IP Version 6 Working Group (ipv6) --------------------------------- "IPv6 Node Information Queries", Matt Crawford, Brian Haberman, 14-Feb-06, 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). "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. "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, 28-Dec-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. "Neighbor Discovery for IP version 6 (IPv6)", Thomas Narten, 9-Mar-06, 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, 7-Dec-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, 26-Oct-05, Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. IS-IS for IP Internets (isis) ----------------------------- "Management Information Base for IS-IS", Jeff Parker, 29-Dec-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, 24-Oct-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. "M-ISIS: Multi Topology (MT) Routing in IS-IS", Tony Przygienda, 21-Oct-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. "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, 16-Nov-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, 5-Jan-06, 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. "IS-IS extensions for Traffic Engineering", Tony Li, Henk Smit, 6-Sep-05, This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. Integrated Security Model for SNMP (isms) ----------------------------------------- "Secure Shell Security Model for SNMP", Joseph Salowey, David Harrington, 6-Mar-06, This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)", David Harrington, Juergen Schoenwaelder, 6-Mar-06, This document describes a Transport Mapping Security Model (TMSM) subsystem for the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document identifies and discusses some key aspects that need to be considered for any transport-mapping-based security model for SNMP. This memo also defines a portion of the Management Information Base (MIB) for managing the Transport Mapping Security Model Subsystem. Kerberized Internet Negotiation of Keys (kink) ---------------------------------------------- "Kerberized Internet Negotiation of Keys (KINK)", Shoichi Sakane, 9-Dec-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) ----------------------------------------- "Desired Enhancements to GSSAPI Version 3 Naming", Sam Hartman, 7-Mar-06, 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 for the next version of GSS-API. 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 may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. "GSS-API Domain-Based Service Names and Name Type", Nicolas Williams, 19-Oct-05, This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Domain-based service names are similar to host-based service names, but using a domain name (not necessarily and Internat domain name) instead of or in addition to a hostname. The primary purpose of domain-based service names is to provide a way to name clustered services after the domain which they service, thereby allowing their clients to authorize the service's servers based on authentication of their names. "GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", Nicolas Williams, 21-Oct-05, This document describes the mapping of GSS-API domainname-based service principal names onto Kerberos V principal names. "Generic Security Service API Version 2 : Java Bindings Update", Mayan Upadhyay, Seema Malkani, 31-Jan-06, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in RFC 2853 [JGSS]. This document obsoletes RFC 2853 [JGSS] by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience. The only note-worthy changes are in sections 4.12.1, 6.3.2, and 6.8.1 of RFC 2853 [JGSS], which are replaced by the sections 5.12.1, 7.3.2, and 7.8.1 of this document, where numerical constants were either added or modified. The GSS-API is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are The Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5]. "Guide to the GSS-APIv3", Nicolas Williams, 19-Oct-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, 19-Oct-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. These interfaces include: mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that posses given attributes, and a function for displaying mechanism attributes. "Stackable Generic Security Service Pseudo-Mechanisms", Nicolas Williams, 19-Oct-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. Stackable GSS-API pseudo-mechanisms allow for the composition of new mechanisms that combine features from multiple mechanisms. Stackable mechanisms that add support for Perfect Forward Security (PFS), data compression, additional authentication factors, etc... are facilitated by this document. "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 19-Oct-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, 19-Oct-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, 19-Oct-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, 17-Oct-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. "GSS_API V2: C# Bindings", Juan Carlos Luciani, 21-Nov-05, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the C# language bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [RFC2743]. The GSS-API C# bindings were designed to emulate the Java bindings as defined in RFC 2853 [RFC2853]. Kerberos WG (krb-wg) -------------------- "Public Key Cryptography for Initial Authentication in Kerberos", Brian Tung, Larry Zhu, 9-Feb-06, 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, 7-Mar-06, 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, 19-Oct-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, 24-Oct-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, 26-Oct-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. "ECC Support for PKINIT", Larry Zhu, 5-Mar-06, This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT - the Kerberos Version 5 extension that provides for the use of public key cryptography. Layer 1 Virtual Private Networks (l1vpn) ---------------------------------------- "Framework and Requirements for Layer 1 Virtual Private Networks", Tomonori Takeda, 6-Mar-06, 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. "Applicability analysis of Generalized Multiprotocol Label Switching (GMPLS) protocols to Layer 1 Virtual Private Networks", Tomonori Takeda, 6-Mar-06, 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. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)", Carlos Pignataro, 28-Nov-05, This document describes the use of "version 3" of Layer Two Tunneling Protocol (L2TPv3) to tunnel Point-to-Point Protocol (PPP) packets. This document defines the control protocol and encapsulation specifics for tunneling PPP over L2TPv3, and is a companion document to the L2TPv3 base specification. "PPP over L2TP Tunnel Switching", Vipin Jain, 20-Dec-05, PPP [7] 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 L2tp Endpoint. 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, 9-Sep-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, 12-Oct-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. "Transport of Ethernet Frames over L2TPv3", Rahul Aggarwal, 12-Oct-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, 2-Mar-06, 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, 10-Jan-06, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines an extensible tunneling protocol 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) Pseudowires and provides guidelines for transporting various ATM services over an IP network. "Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur, 10-Oct-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. "Signaling and Encapsulation for the Transport of IP over L2TPv3", Carlos Pignataro, Wei Luo, 16-Feb-06, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document defines the control messaging, signaling procedures and encapsulation specifics of how to tunnel IPv4 and IPv6 packets directly over L2TPv3. "L2TP Proxy Authenticate Extensions for EAP", Manesh Kelkar, 20-Dec-05, L2TP [1] defines Proxy Authentication AVPs that MAY be exchanged during session establishment, to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation. This document defines contents of this PPP authenticate information for the Extensible Authentication Protocol (EAP). 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, 10-Jan-06, This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). 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, 29-Dec-05, Virtual Private LAN (Local Area Network) 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 Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. "Virtual Private LAN Services over MPLS", Marc Lasserre, Vach Kompella, 15-Nov-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 using LDP [RFC3036], 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, Autodiscovery, and Signaling in L2VPNs", Eric Rosen, 3-Mar-06, Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., 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 to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on 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, 24-Oct-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, 26-Oct-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, 7-Mar-06, 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 Packet 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-Oct-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 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. "OAM Procedures for VPWS Interworking", Mustapha Aissaoui, 19-Oct-05, This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, 7-Mar-06, This document provides functional requirements for network solutions that support multicast over 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. "Multicast in VPLS", Rahul Aggarwal, 1-Dec-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. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy De Clercq, 20-Dec-05, This informational document describes 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. "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Eric Rosen, 8-Aug-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-Feb-06, 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, 4-Aug-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", Hamid Ould-Brahim, 6-Mar-06, This document 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). "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. "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, 3-Mar-06, 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, 28-Dec-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. This revision is unchanged from the previous version and does not reflect the discussion that has taken place since initial publication. 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, 26-Oct-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 Security Mechanisms", Rod Harrison, 13-Feb-06, This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation. This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism. This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes. This document, together with other documents in the LDAP Technical Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC 2829 and RFC 2830. "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, 30-Jan-06, 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, 30-Sep-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, 24-Jan-06, The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led 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, 1-Feb-06, 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) --------------------------------------------------------------------------------- "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, 4-Oct-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, 20-Jan-06, 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 optimize submission and to efficiently resynchronize 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 [SUBMIT]. "IMAP4 Extensions for Quick Reconnect", Corby Wilson, Alexey Melnikov, 31-Jan-06, 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 amount of data transfered at login after a dropped connection. "SMTP Submission Service Extension for Future Message Release", Gregory White, Gregory Vaudreuil, 26-Oct-05, This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. 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, 11-Nov-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. "IMAP URL Scheme", Alexey Melnikov, 6-Feb-06, IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. "CONVERT", Stephane Maes, Ray Cromwell, 2-Mar-06, CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. "Realization of OMA Mobile Email (MEM) Architecture using Internet Mail", Stephane Maes, Glenn Parsons, 7-Dec-05, This document specifies a realization of the architecture for the mobile email enabler (MEM) as specified by the OMA, using Internet Mail protocols. "Support for Sieve in Internet Message Access Protocol (IMAP4)", Barry Leiba, 9-Mar-06, Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). "Lemonade notifications and filters", Stephane Maes, 6-Mar-06, This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILEBIS]. "LEMONADE profile bis", Stephane Maes, 6-Mar-06, This document describes LEMONADE profile bis. It contains pointers or mention to all the features that are normatively part of LEMONADE profile bis. 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 optimize submission and to efficiently resynchronize 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 ([18]) extensions and BURL extension to the SUBMIT protocol (SUBMIT). It provides also extensions to provide support for realizationz of OMA mobile email enabler (MEM) ([16] and [9]) using Internet Mail protocols defined by the IETF. "Persistent Virtual Folder extension to the IMAP Protocol", Stephane Maes, 2-Mar-06, Persistent Extensions to the IMAP Protocol (LPSEARCH) defines extension parameters to the [RFC3501] CREATE command to allow virtual mailboxes to be created which are views of other mailboxes narrowed by search criteria. "WITHIN Search extension to the IMAP Protocol", Stephane Maes, Ray Cromwell, 2-Mar-06, WITHIN is an extension to [RFC3501] SEARCH which returns messages whose internal date is on or within a specified interval and differs from SINCE in that an interval in seconds is specified instead of a date. WITHIN is expected to be most useful for persistent searches in combination with mobile devices. "COMPRESSION", Stephane Maes, Ray Cromwell, 2-Mar-06, Lemonade investigates adding mobile optimizations for the next version of the Lemonade Profile. LZIP addresses this task and provides an extension to allow compression of the exchanged text and binary literals, typically message body parts. "Deployment Considerations for lemonade-compliant Mobile Email", Randall Gellens, 2-Mar-06, This document discusses deployment issues and describes implicit requirements for successful deployment of mobile email based on the IETF lemonade documents. "Lemonade bindings to cross firewalls and mobile network intermediaries", Stephane Maes, 2-Mar-06, As part of the LEMONADE work to define extensions to the IMAP and SMTP protocols that provide optimizations in a variety of settings, the this document describes an alternative, optional binding for IMAP and SMTP showing how HTTP can be used to transfer commands and responses. This binding is intended to facilitate the use of IMAP and SMTP in deployments involving a variety of intermediaries. Bindings to SOAP, REST and WebDAV are also provided. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-Term Archive Service Requirements", Carl Wallace, 10-Oct-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-Feb-06, 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, 16-Dec-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, 6-Mar-06, This document describes a service operated as a trusted third party to securely archive electronic document called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. "Using SCVP to Convey Long-term Evidence Records", Carl Wallace, 29-Sep-05, The Simple Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support non-repudiation of existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust can be established in the certificates after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes an application of SCVP to serve this purpose using the WantBack feature of SCVP to convey evidence records. "Infrastructure Support for Retention of PKI Artifacts", Carl Wallace, 18-Jan-06, In most PKIs, directory servers are used to provide current certificates and revocation information to relying parties. In situations where certificates must be validated relative to a time in the past, relying parties often have no means of obtaining the necessary PKI artifacts. This specification defines several directory attributes to support validation using historical PKI artifacts. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 18-Oct-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 of Language Tags", Addison Phillips, Mark Davis, 5-Mar-06, This document describes different mechanisms for comparing and matching language tags. Possible algorithms for language negotiation or content selection, filtering, and lookup are described. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. "Initial Language Subtag Registry", Doug Ewell, 19-Oct-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, 8-Mar-06, 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. 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", Charlie Perkins, Ian Chakeres, 6-Mar-06, 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 on-demand. "Simplified Multicast Forwarding for MANET", Joseph Macker, 6-Mar-06, This document describes the Simplified Multicast Forwarding (SMF) protocol that provides a basic IP multicast forwarding capability within mobile ad-hoc networks (MANET). SMF is designed to have limited applicability as a forwarding mechanism for multicast packets within MANET routing areas. In addition, it provides mechanisms to support interoperability with a connected wired infrastructure. SMF uses packets to all MANET multicast receivers within a MANET routing area. The core design does not use receiver specific group information in favor of reduced complexity and state maintenance within the mobile topology. Such extensions may follow in later specifications. The design accounts for the unique nature and behavior of MANET interfaces and takes advantage of efficient relay set algorithms previously designed and applied in the MANET routing control plane. This document describes the SMF forwarding mechanisms in detail, specifies an optional SMF neighborhood discovery protocol, and describes several efficient relay set algorithms that have been implemented in conjunction with SMF. "The Optimized Link-State Routing Protocol version 2", Thomas Clausen, 9-Mar-06, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link- state information. A secondary optimization is, that OLSRv2 employs partial link-state information: each node maintains information of all destinations, but only a subset of links. This allows that only select nodes diffuse link-state advertisements (i.e. reduces the number of network-wide broadcasts) and that these advertisements contain only a subset of links (i.e. reduces the size of each network-wide broadcast). The partial link-state information thus obtained allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. "Generalized MANET Packet/Message Format", Thomas Clausen, 1-Mar-06, This document describes a generalized multi-message packet format which may be used by mobile ad hoc network routing and other protocols. 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, 21-Oct-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 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. "Multicast Source Discovery protocol MIB", Bill Fenner, Dave Thaler, 21-Oct-05, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. "Overview of the Internet Multicast Addressing Architecture", Pekka Savola, 3-Mar-06, 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, 6-Mar-06, Typically applications developers have requested static IANA assignments for their 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. "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services", Haixiang He, 10-Feb-06, This memo presents requirements in the area of accounting and access control for multicasting. General requirements for accounting capabilities including quality-of-service (QoS) related issues are listed. 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, 3-Mar-06, 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, 7-Mar-06, This memo 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 memo 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 memo recommends for requirements to be defined that would set the groundwork for framework(s) and solutions that sufficiently address 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, 24-Jan-06, 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, 4-Oct-05, Mobile IPv4 describes how a Mobile Node can perform IPv4-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 IPv4 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 IPv4 packets due to the delay in the Mobile IPv4 Registration process. "Mobile IPv4 Challenge/Response Extensions (revised)", Charles Perkins, 1-Feb-06, 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. "IP Mobility Support for IPv4, revised", Charles Perkins, 26-Oct-05, This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", Sami Vaarala, Espen Klovning, 8-Nov-05, This document outlines a 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 protocols, the VPN gateway, or the home agent are required. "Foreign Agent Error Extension for Mobile IPv4", Charles Perkins, 21-Sep-05, This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. "Mobile IPv4 Regional Registration", Eva Gustafsson, 1-Dec-05, Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e. registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce 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. "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", Vijay Devarapalli, Pasi Eronen, 24-Jan-06, 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. "Mobile IPv4 Message String Extension", Venkateshwara Sastry, 24-Jan-06, 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. "Mobile IPv4 RADIUS requirements", Madjid Nakhjiri, 13-Feb-06, This document provides an applicability statement as well as a scope definition for the specification provided in the document ‘‘RADIUS Mobile IPv4 extension’’ and its future revisions hereby collectively referred to as [RADMIP]. The goal is to justify qualification of [RADMIP] as a IETF work item. "Mobile IPv4 Fast Handovers", Rajeev Koodli, Charles Perkins, 27-Feb-06, The Mobile IPv6 fast handover document [2] specifies a protocol to improve latency and packet loss resulting from Mobile IPv6 handover operations. This document adapts the protocol for IPv4 networks to improve performance over Mobile IPv4 operations, including processing of Agent Advertisements, new Care of Address acquisition and Registration Request and Reply. However, operation without Foreign Agent function at a router is also feasible. In addition, the protocol may be used transparently on hosts which do not support Mobile IP, but with limited movement across subnets. Using the concepts outlined in [2], this document also addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration, the document currently proposes that the new CoA is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. 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, 21-Feb-06, This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6. Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", Charles Perkins, 2-Dec-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. "Problem Statement for bootstrapping Mobile IPv6", Gerardo Giaretta, Alpesh Patel, 10-Feb-06, 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 mobile node bootstrapping. "Mobile IPv6 and Firewalls: Problem statement", Franck Le, 26-Jan-06, 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. Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere in the smooth operation of the protocol and can be a detriment to deployment. This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as GPRS/ UMTS and CDMA 2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG. "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", Francis Dupont, Vijay Devarapalli, 6-Mar-06, This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 21-Dec-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 for home address option validation (aka. triangular routing) and protection of mobility signaling for routing optimizations. The configuration details for IPsec and IKE are also provided. "Goals for AAA-HA interface", Gerardo Giaretta, 27-Jan-06, 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 explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping in integrated and split scenarios. "Mobile IPv6 bootstrapping in split scenario", Gerardo Giaretta, 7-Mar-06, 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 bootstrapping 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, 26-Oct-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 the current [MIPv4] and [MIPv6] protocols could be extended so that they can support mobility management for a dual stack node. "Why Authentication Data suboption is needed for MIP6", Basavaraj Patil, Gopal Dommety, 12-Sep-05, Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. "IP Address Location Privacy and Mobile IPv6: Problem Statement", Rajeev Koodli, 3-Mar-06, In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", Hesham Soliman, 7-Mar-06, The current Mobile IPv6 and NEMO specification support only IPv6. Hence, this specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the HA. This specification allows also the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path. "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", Kuntal Chowdhury, Alper Yegin, 20-Oct-05, The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery based on DHCPv6 for the integrated scenario. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Session Description Protocol (SDP) Source Filters", Bob Quinn, Ross Finlayson, 22-Sep-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, 25-Jan-06, 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. "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 2.0 (RTSP)", Henning Schulzrinne, 9-Mar-06, This memorandum defines RTSP version 2.0 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). "How to Enable Real-Time Streaming Protocol (RTSP) Traverse Network Address Translators (NAT) and Interact with Firewalls.", Magnus Westerlund, Thomas Zeng, 26-Oct-05, This document describes several types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations are given. Further a description on how RTSP relates to firewalls is given. "Session Description Protocol Security Descriptions for Media Streams", Flemming Andreasen, 12-Sep-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. "Requirements for Internet Media Guides", Yuji Nomura, 20-Dec-05, 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, 9-Mar-06, This document describes a protocol for Network Address Translator (NAT) traversal for multimedia session signaling protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Simple Traversal of UDP through NAT (STUN), applying its binding discovery, connectivity check and relay usages. "A Framework for the Usage of Internet Media Guides", Yuji Nomura, 20-Dec-05, 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, 6-Mar-06, 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. This revision of the document reflects comments made during IESG review. "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. "An Extension to the Session Description Protocol (SDP) for Media Loopback", Kaynam Hedayat, 8-Nov-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, 1-Dec-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, 21-Oct-05, This document defines a new security precondition for the Session Description Protocol precondition framework described in RFCs 3312 and 4032. 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, 21-Oct-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. "The SDP (Session Description Protocol) Content Attribute", Jani Hautakorpi, Gonzalo Camarillo, 8-Mar-06, 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. "FEC Grouping Semantics in SDP", Adam Li, 8-Dec-05, This document defines the semantics that allows for grouping of forward error correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document is to be used with Grouping of Media Lines in the Session Description Protocol (RFC 3388) to group together "m" lines in the same session. "TCP Candidates with Interactive Connectivity Establishment (ICE)", Jonathan Rosenberg, 1-Mar-06, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Simple Traversal of UDP over NAT (STUN). ICE provides a general framework for describing alternates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. IKEv2 Mobility and Multihoming (mobike) --------------------------------------- "Design of the MOBIKE Protocol", Tero Kivinen, Hannes Tschofenig, 3-Mar-06, The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of 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, 24-Feb-06, This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile VPN client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. Mobile Nodes and Multiple Interfaces in IPv6 (monami6) ------------------------------------------------------ "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, 22-Feb-06, 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. The purpose of this document is to detail all the issues arising through the operation of Mobile IPv6 on multihomed mobile nodes. A taxonmy is used to describe the different situations where a mobile node is multihomed. Issues are explained for each multihomed configuration (number of interfaces, number of Home Addresses or number of Care-of Addresses), and classified into general IPv6 issues, issues pertaining to the specification of Mobile IPv6, and issues related to the implementation of Mobile IPv6. It is not the intention of this document to imply that all issues must be solved in the short term. "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Thierry Ernst, 3-Mar-06, In this document, multihoming is investigated from a node point of view, and not from a site point of view as the term "multihoming" is commonly understood so far. The purpose of this document is to explain the motivations for fixed and mobile nodes (hosts and routers) using multiple interfaces and the scenarios where this may end up using multiple global addresses on their interfaces. Such multihoming configurations can bring a number of benefits once appropriate support mechanisms are put in place. Interestingly, this analysis is generic, i.e. motivations and benefits of node multihoming apply to both fixed end nodes and mobile end nodes. Multiprotocol Label Switching (mpls) ------------------------------------ "ICMP Extensions for MultiProtocol Label Switching", Ronald Bonica, 21-Sep-05, This memo defines an extension to ICMP that permits Label Switching Routers to append MPLS information to ICMP messages. This extension has already been widely deployed and this memo is introduced to describe existing practice. "Graceful Restart Mechanism for BGP with MPLS", Yakov Rekhter, Rahul Aggarwal, 16-Aug-05, A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed an is described in a separate document ("Graceful Restart Mechanism for BGP"). 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...) The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve their forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting a subset of the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. "Definition of an RRO node-id subobject", JP Vasseur, 1-Dec-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 Switching 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 in order 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. The MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. "MPLS Traffic Engineering Soft Preemption", Matthew Meyer, 12-Jan-06, 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. "Label Switching Router Self-Test", George Swallow, 26-Oct-05, This document defines a means for a Label-Switching Router (LSR) to verify that its data plane is functioning for certain key Multi-Protocol Label Switching (MPLS) applications, including unicast forwarding and traffic engineering tunnels. A new Loopback FEC type is defined to allow an upstream neighbor to assist in the testing at very low cost. MPLS Verification Request and MPLS Verification Reply messages are defined to do the actual probing. "LDP Specification", Loa Andersson, 20-Oct-05, The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031 [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. 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, 24-Oct-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. "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Rahul Aggarwal, 27-Oct-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, 13-Dec-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 apply equally to packet switched networks under the control of MPLS protocols and to 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, 27-Feb-06, 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 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. "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", Seisho Yasukawa, 6-Sep-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. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognised and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS TE LSPs. This documents does not replace any of the mechanism of LSP Ping, but clarifies their applicability to P2MP MPLS TE LSPs, and extends the techniques and mechanisms of LSP Ping to the P2MP TE environment. "Component Link Recording and Resource Control for GMPLS Link Bundles", Anca Zamfir, 27-Feb-06, 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. "Experience with the LDP protocol", Loa Andersson, 20-Sep-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. "LDP Implementation Survey Results", Loa Andersson, Bob Thomas, 4-Oct-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. "OAM Requirements for Point-to-Multipoint MPLS Networks", Adrian Farrel, 28-Feb-06, 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 data plane 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 fundamentals of an MPLS network, but also because they may impact service level specification commitments for customers of their network. "MPLS Multicast Encapsulations", Toerless Eckert, 16-Feb-06, 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. RFC3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, 1-Mar-06, This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) 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 for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. "MPLS Upstream Label Assignment and Context Specific Label Space", Rahul Aggarwal, 10-Mar-06, 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". 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. "Group Security Policy Token v1", Hugh Harney, Andrea Colegrove, 24-Jan-06, The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is comprised of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. "The Key ID Information Type for the General Extension Payload in MIKEY", Elisabetta Carrara, 8-Mar-06, 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, 11-Jan-06, TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol is a protocol for providing source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead, which scales to large numbers of receivers, and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published targeting multicast authentication in scenarios, where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms. This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol 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, 3-Feb-06, 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, 1-Feb-06, The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution to setup Secure Real-time Rransport Protocol (SRTP) 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. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). "Multicast Extensions to the Security Architecture for the Internet Protocol", Brian Weis, 3-Mar-06, The Security Architecture for the Internet Protocol [RFC4301] 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. "GKDP: Group Key Distribution Protocol", Lakshminath Dondeti, 9-Mar-06, This document specifies a group key distribution protocol (GKDP) based on IKEv2, the IPsec key management protocol; the new protocol is similar to IKEv2 in message and payload formats, and message semantics to a large extent. The protocol in conformance with MSEC key management architecture contains two components: member registration and group rekeying, and downloads a group security association from the GCKS to a member. This protocol is independent of IKEv2 except in its likeness. Network Mobility (nemo) ----------------------- "Network Mobility Support Goals and Requirements", Thierry Ernst, 27-Oct-05, Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such kind of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. "Network Mobility Support Terminology", Thierry Ernst, Hong Lach, 9-Mar-06, This document defines a terminology for discussing network mobility issues and solution requirements. "NEMO Home Network models", Pascal Thubert, 21-Feb-06, 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. 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, 24-Feb-06, 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). Recommendations are then made as to whether the NEMO Working Group should solve these issues, or a solution should be sought elsewhere. "Network Mobility Route Optimization Problem Statement", Chan-Wah Ng, 28-Dec-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 sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems, and provides for the motivation behind Route Optimization (RO) for NEMO. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, 2-Mar-06, 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. "Network Mobility Route Optimization Solution Space Analysis", Chan-Wah Ng, 10-Feb-06, With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. 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. "IPv4 Network Mobility (NEMO) Basic Support Protocol", Kent Leung, 2-Mar-06, This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. Network Configuration (netconf) ------------------------------- "NETCONF Configuration Protocol", Rob Enns, 6-Mar-06, 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, 9-Mar-06, 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, 5-Mar-06, 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 (Hypertext Transport Protocol) and SOAP over BEEP (Blocks Exchange Extensible Protocol) bindings for NETCONF. "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", Margaret Wasserman, Ted Goddard, 9-Mar-06, This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. "NETCONF Event Notifications", Sharon Chisholm, 11-Jan-06, This memo defines a framework for sending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to application protocols. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "Requirements and Gap Analysis for IP Local Mobility", James Kempf, 2-Feb-06, 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. "Problem Statement for IP Local Mobility", James Kempf, 2-Feb-06, 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. New IETF Standards Track Discussion (newtrk) -------------------------------------------- "Internet Standards Documentation (ISDs)", John Klensin, John Loughney, 9-Mar-06, It has been observed that the current IETF standard designations, STD nnnn and BCP nnnn designation, have not worked well. Problems have been found when one of them is used either as a stable reference for external specifications or as a combined reference for multiple documents linked together into a single document. This document proposes two changes to these designations. The first of these changes would create a new document series and assign a new number and acronym to a specification when it enters the first level of the Standards Track (or is first designated as a BCP). The second would migrate the concept of STDs and BCPs numbering of RFCs into actual documents that detail what they identify, their publication information and their change history. The document also specifies a set of minor standards process changes to accommodate and integrate the new style of doing things that is represented by the new document series. "Getting rid of the cruft: Report from an experiment in identifying and reclassifying obsolete standards documents", Eliot Lear, Harald Alvestrand, 10-Jan-06, This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic. "Formalizing IETF Interoperability Reporting", Larry Masinter, 12-Oct-05, This document suggests another way of reforming IETF standards process by formalizing the mechanism for interoperability reporting, as a way of facilitating standards development. It establishes two kinds of reports: a 'Protocol Feature Set', which lays out the set of features from IETF specifications that constitute a protocol, and a 'Protocol Implementation Report', which is submitted by an individual or group to report on implementation and interoperability testing. "Cleaning the Attic II: Promoting Marketplace-approved Standards", John Klensin, Spencer Dawkins, 23-Feb-06, Historically, Internet Standards have been characterized by three primary criteria: the specifications are stable, implementations of them have been demonstrated to be interoperable, and they have achieved sufficient deployment to be considered useful. The IETF has developed specific rules for determining whether those criteria have been met, but the rules and their implementation have sometimes not adequately reflected those underlying criteria. The result has been that the application of the rules has not resulted in STDs for all protocols that meet the underlying criteria. This document proposes a process experiment to reclassify standards-track documents whose interoperability and utility have been demonstrated by the fact of deployment and use in products being used by Internet users. "Identifying Standards Track Documents", John Klensin, 27-Feb-06, In the present Internet Standards Process, stable identifiers for standards, as distinct from documents (for which RFC numbers are sufficient), has become problematic because proportionately few documents reach Full Standard and are assigned STD numbers. Several proposals have been introduced into NEWTRK to address this problem, but only in the context of trying to resolve a number of other issues. In the hope of making some progress on this dimension, this document proposes a change to the standards-track document identifier system only. 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. "NFS RDMA Problem Statement", Thomas Talpey, Chet Juszczak, 27-Oct-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, 27-Oct-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, 27-Oct-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. "People and Content video streams", Roni Even, 23-Feb-06, This document describes the procedures for using more than one video channel in SIP based systems enabling the other endpoints to understand the semantics of each channel. The document describe how to label individual channels with a "role". The "role" indicates the requirements for processing the channel and the role of the channel content in the SIP call. The procedure address multipoint and point to point scenarios. "NFSv4 pNFS Extensions", Garth Goodson, 10-Oct-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. "NFSv4 Minor Version 1", Spencer Shepler, 9-Mar-06, This Internet-Draft describes the NFSv4 minor version 1 protocol extensions. These most significant of these extensions are commonly called: Sessions, Directory Delegations, and parallel NFS or pNFS "A DNS RR for NFSv4 ID Domains", Rick Mesta, 25-Oct-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. "pNFS Block/Volume Layout", David Black, Stephen Fridella, 4-Jan-06, 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. "Object-based pNFS Operations", Benny Halevy, 24-Jan-06, 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-ietf-nfsv4-pnfs-00.txt "NFS Version 4 ACLs", Sam Falkner, Lisa Week, 17-Feb-06, NFS version 4 (specified in RFC 3530) Access Control Lists (ACLs) provide more fine grained control than previous file permission models, but before the full benefit of the model can be exploited, some changes and clarifications must be made. This document will describe the details that implementors should consider in order to allow implementations to function and interoperate better. 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, 26-Sep-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, 9-Aug-05, This document defines an extension to 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]. "The application/smil and application/smil+xml Media Types", Philipp Hoschka, 27-Feb-06, This document specifies the Media Type for versions 1.0, 2.0 and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. "Load Control of Real-Time Traffic", Lars Westberg, 2-Dec-05, There is an increased interest of simple and scalable resource provisioning solution for Diffserv networks. This is an updated version of the old draft (previous version was submitted in April 2000) describing a concept called Load Control. Load Control addresses the following issues: 1. Admission control for real time data flows in stateless domains 2. Dropping of flows in case of exceptional events, such as severe congestion after re-routing "Additional ECC Groups For IKE and IKEv2", Daniel Brown, 30-Jan-06, This document describes new ECC groups for use in IKE [IKE] and IKEv2 [IKEv2] 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] and IKEv2 [IKEv2]. "IP over MIME", Donald Eastlake 3rd, 2-Dec-05, The MIME encoding of IP packets is specified so they can conveniently be sent via MAIL, HTTP, etc. This may be convenient for transmitting packets for analysis, debugging, monitoring, or creating application level tunnels. "Quick Transaction Protocol - QTP", Allan Cornish, 24-Oct-05, QTP is a simple protocol for multiplexing short-duration connections over an arbitrary transport service such as UDP. QTP is an open standard to allow dial-up Credit Authorization Terminals (CAT) or Point-Of-Sale (POS) terminals to connect into IP hosts. These transactions require fast connection times, efficient concentration of many sessions, fault tolerant operation, and the ability to transfer access network addressing (called and calling numbers) along with transaction data. "Transport of Layer 2 Frames Over MPLS", Luca Martini, 30-Jan-06, 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. "A Protocol for Remotely Managing Sieve Scripts", Tim Martin, Alexey Melnikov, 6-Feb-06, Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "sieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. "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 and IKEv2 Authentication Using ECDSA", Jerome Solinas, David Fu, 20-Oct-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) and Internet Key Exchange version 2 (IKEv2) protocols. 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. "Session Initiation Protocol Private Extension for an OSP Authorization Token", 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. "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. "LDAP Transactions", Kurt Zeilenga, 7-Mar-06, Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. However, It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning and information replication. This document defines an LDAP extension to support transactions. "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. "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS Networks", Luca Martini, 30-Jan-06, 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 network. "Domain Name System Uniform Resource Identifiers", Simon Josefsson, 5-Aug-05, This document define Uniform Resource Identifiers for Domain Name System resources. See for more information. "Explicit Multicast (Xcast) Basic Specification", Richard Boivie, 28-Dec-05, While traditional IP multicast schemes[1112] are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification at this point. "SASL in HTTP/1.1", Magnus Nystrom, Alexey Melnikov, 12-Dec-05, 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. "The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers, 1-Mar-06, 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. An ARK has five components: an optional and mutable Name Mapping Authority Hostport, the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, followed by a single question mark ('?'), returns a brief metadata record that is both human- and machine-readable. When the ARK is followed by dual question marks ('??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. "SMB File Sharing URI Scheme", Christopher Hertel, 9-Jan-06, 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. "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, 2-Feb-06, 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, 2-Feb-06, 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. "Dynamic Service Negotiation Protocol (DSNP)", Jyh-Cheng Chen, 2-Mar-06, This memo presents the specification of Dynamic Service Negotiation Protocol (DSNP). DSNP is a protocol to negotiate the SLS (Service Level Specification) in IP layer. It can be used for service negotiation from host to network, network to host, and network to network. The automated negotiation makes service negotiation efficient in terms of time, cost, and correctness, etc. The dynamic negotiation not only allows users to adapt their needs dynamically, but also let providers better utilize the network. The DSNP messages and packet formats are detailed. DSNP can be used in both wireline and wireless networks. It is, however, particularly useful in mobile environment. To demonstrate the usefulness of DSNP, a reference wireless QoS architecture is presented. Exemplary applications are illustrated. "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. "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, 28-Nov-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. "FTP/TLS Friendly Firewalls", Paul Ford-Hutchinson, 21-Oct-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. "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, 13-Mar-06, 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. This Internet access 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, 3-Feb-06, 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, 12-Sep-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, 28-Dec-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. "SS7 MTP2-User Peer-to-Peer Adaptation Layer Test Specifications M2PA-TEST", Brian Bidulock, 24-Oct-05, This Internet Draft provides information for the Internet community on test cases for testing the SS7 MTP2-User Peer-to-Peer Adaptation Layer [M2PA] based on the conformance test specifications for SS7 MTP Level 2 [Q.781]. This memo describes the test environment and a detailed description of test cases for validation, compatibility and interoperability testing of the M2PA protocol implemented on the foundation of ITU SS7 MTP Signalling Links [Q.703]. "Registration of GSTN SMS Service Qualifier", Erik Wilde, 9-Feb-06, 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). "Application Server Process (ASP) Extension (ASPEXT) Framework for Signalling User Adaptation Layers", Brian Bidulock, 28-Oct-05, This Internet-Draft describes ASP Extensions (ASPEXT) for Signalling User Adaptation Protocols [IUA-BIS..SUA, DUA..TUA], which permits cooperating Signalling Peer Processes (SPPs) to indicate to each other the specific protocol extensions that each supports. "Signalling Gateway (SG) Information (SGINFO) Support for Signalling User Adaptation Layers", Brian Bidulock, 28-Oct-05, This Internet-Draft describes Signalling Gateway (SG) Information (SGINFO) for Signalling User Adaptation Protocols [M2UA..TUA], which permits supporting Signalling Gateways (SG) to convey additional Application Server (AS) support information to Application Server Processes (ASPs) activating for AS on the SG. This additional AS support information consists of information pertaining to the underlying SS7 Signalling Provider that otherwise would have to be statically configured at the Application Server Process (ASP) or exchanged between SG and ASP using a non-IETF defined protocol. "Load Selection (LOADSEL) for Signalling User Adaptation Layers", Brian Bidulock, 28-Oct-05, This Internet-Draft describes Load Selection (LOADSEL) for Signalling User Adaptation Protocols [IUA-BIS..SUA, DUA..TUA], which permits an Application Server Processes (ASP) to indicate its placement within an Application Server and permits an Signalling Gateway (SG) to distribute traffic over ASPs in Application Servers under Application Server Process (ASP) control. "Load Grouping Extension for Signalling User Adaptation Layers", Brian Bidulock, 28-Oct-05, This Internet-Draft describes an extension parameter and procedure to the Signalling User Adaptation Protocols [IUA..TUA, IUA- BIS..GR303UA00], based on the Stream Transmission Control Protocol (SCTP) [RFC 2960] which permits an Application Server Processes (ASP) to indicate its placement within a Load Group and permits an Signalling Gateway (SG) to distribute traffic over Load Groups under Application Server Process (ASP) control. The described procedure provides for Override, Load-share and Broadcast traffic mode operation within a Load Group consisting of one or more Application Server Processes (ASPs) resulting in a mixture of traffic modes within an Application Server (AS). The parameters and procedures described here supplement the UA Load Selection [LOADSEL] extension parameters and procedures for improved distribution of traffic over ASPs and Signalling Gateway Processes (SGPs). "Correlation Id and Hearbeat Procedures (CORID) Supporting Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Layers", Brian Bidulock, 28-Oct-05, This Internet-Draft describes Correlation Id and Heartbeat procedures to support lossless fail-over between SCTP [RFC 2960] associations for SS7 [Q.700] Signalling User Adaptation Protocols [M2UA..ISUA, TUA] supporting the concept of a Routing Context or Interface Identifier. These procedures permit lossless fail-over between Application Server Processes (ASPs) at a Signalling Gateway (SG) and fail-over between Signalling Gateway Processes (SGPs) and Signalling Gateways (SGs) at an Application Server Process (ASP). Lossless fail-over permits these fail-overs to occur without loss or duplication of UA-User messages. "SS7 TCAP-User Adaptation Layer (TUA)", Brian Bidulock, 28-Oct-05, This document defines a protocol for the transport of any SS7 TCAP- User signalling (e.g, INAP, MAP, etc.) over IP using the Stream Control Transport Protocol [RFC 2960]. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway and IP Signalling End-point architecture. Protocol elements are added to allow seamless operation between peers in the SS7 and IP domains. "URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 9-Feb-06, This memo specifies the Universal Resource Identifier (URI) 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, 7-Dec-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 [RFC3989]. 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-Oct-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. "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. "Analysis of IDR requirements and History", Avri Doria, Elwyn Davies, 26-Oct-05, This document analyses the current state of IDR routing with respect to RFC1026 and other IDR requirements and design efforts. It is the companion document to "Requirements for Inter-Domain Routing" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture and future routing protocols. "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, 7-Mar-06, 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. "Preventing SCTP Congestion Window Overgrowth During Changeover", Janardhan Iyengar, 2-Dec-05, SCTP [RFC2960] supports IP multihoming at the transport layer. SCTP allows an association to span multiple local and peer IP addresses, and allows the application to dynamically change the primary destination during an active association. We present a problem in the current SCTP specification that results in unnecessary retransmissions and "TCP-unfriendly" growth of the sender's congestion window during certain changeover conditions. We present the problem and propose an algorithm called the Split Fast Retransmit Changeover Aware Congestion Control algorithm (SFR-CACC) as a solution. We recommend the addition of SFR-CACC to the SCTP specification [RFC2960]. "IMAP ANNOTATEMORE Extension", Cyrus Daboo, 28-Nov-05, The ANNOTATEMORE extension to the Internet Message Access Protocol permits clients and servers to maintain annotations ("metadata") on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. "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. "Enabling Global Service Attributes in the Service Location Protocol", Weibin Zhao, Henning Schulzrinne, 10-Oct-05, This document describes enabling global service attributes in the Service Location Protocol (SLP). A global service attribute describes a service property common to all service types. Its name begins with the "service-" prefix. It is defined via an attribute template, and can be imported into any service template. A single Service Request (SrvRqst) message can use global service attributes to search services across multiple service types. Global service attributes can be associated with certain special characteristics so as to support advanced discovery scenarios, such as URL changes, multi-access-point services, multi-function devices and replicated services. "An IPv4 Flowlabel Option", Thomas Dreibholz, 8-Nov-05, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "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. "Advertisement of Multiple Paths in BGP", Daniel Walton, 2-Mar-06, In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. "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. "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-Jan-06, 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. "URI Fragment Identifiers for the text/plain Media Type", Erik Wilde, 6-Jan-06, 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. "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. "XML Schema for Media Control", Orit Levin, 3-Mar-06, This document defines an XML Schema for Media Control in a tightly controlled environment for managing of video streams only. Implementation of this mechanism for interactive video applications in SIP environments significantly improves user experience. "Secure Ad hoc On-Demand Distance Vector (SAODV) Routing", Manel Guerrero Zapata, 7-Feb-06, 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 and authentication. "EAP-Support in Smartcard", Pascal Urien, 21-Feb-06, 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, 19-Sep-05, 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, 2-Mar-06, 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. "Split Multi-link Trunking (SMLT)", Roger Lapuh, 19-Jan-06, 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. "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, 18-Jan-06, 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, 3-Feb-06, 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, 21-Oct-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. "RTP Payload Format for Vorbis Encoded Audio", Luca Barbato, 26-Oct-05, This document describes an 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 and other setup information. Also included within the document are the necessary details for the use of Vorbis with MIME and Session Description Protocol (SDP). "SS7 ISUP-User Adaptation Layer (ISUA)", Brian Bidulock, 28-Oct-05, This document defines a protocol for the transport of any SS7 ISUP- User signalling (e.g, Call Control) over IP using the Stream Control Transport Protocol [RFC 2960]. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway and IP Signalling End-point architecture. Protocol elements are added to allow seamless operation between peers in the SS7 and IP domains. "Registration Extensions (REGEXT) for Signalling User Adaptation Layers", Brian Bidulock, 28-Oct-05, This memo describes Registration Extensions (REGEXT) that provides the ability for an Application Server Process (ASP) to modify existing Routing (Link) Keys with a Signalling Gateway (SG). Current procedures in the SS7 Signalling User Adaptation Layers (UAs) [M2UA..SUA, ISUA, TUA] do not provide for the modification of Routing (Link) Keys without deactivation of the Application Server (AS). This causes problems in making changes to live systems. The extensions described in this memo permit modification of Signalling Link membership in Application Servers for SS7 MTP2-User Adaptation Layer [M2UA], modification of Circuit Identification Code (CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA-BIS], modification of Circuit Identification Code (CIC) ranges for the SS7 ISUP-User Adaptation Layer [ISUA], modificiation of Destination Local Reference (DLR) ranges for SS7 SCCP-User Adaptation Layer [SUA], and modification of Transaction Identifier (TID) ranges for SS7 TCAP-User Adaptation Layer [TUA]. "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, 22-Nov-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, 7-Mar-06, Out-of-order arrival of packets is a common occurrence on the Internet, and it will become more widespread as link speeds increase. 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. Two metrics for packet reordering are presented, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering. These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Lode Coene, 2-Feb-06, 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. "vCard Extensions for Instant Messaging (IM)", Cullen Jennings, 9-Mar-06, 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. "Instant Message Delivery Notification (IMDN) for Common Presence and Instant Messaging (CPIM)", Eric Burger, 6-Feb-06, 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). "The LDAP No-Op Control", Kurt Zeilenga, 7-Mar-06, 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, 7-Mar-06, 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. "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, 20-Jan-06, 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. "Prepaid extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, 16-Feb-06, This document describes an extension to the Remote Authentication Dial- In User Service (RADIUS) protocol. This extension makes RADIUS support charging for prepaid services. The extension is based on a number of charging models, in particular based on volume, duration and single (atomic) events. "Bundle Protocol Specification", Keith Scott, Scott Burleigh, 7-Dec-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, 3-Mar-06, 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, 1-Mar-06, 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. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 9-Mar-06, 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", Hannes Tschofenig, 15-Feb-06, This document specifies EAP-IKEv2, an EAP authentication method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. These techniques can be combined in a number of ways. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and a "fast reconnect" mode. "Internet Application Protocol Collation Registry", Chris Newman, 9-Mar-06, 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. "Advertising Equal Cost Multipath routes in BGP", Manav Bhatia, 14-Feb-06, This document describes an extensible mechanism that will allow a BGP [BGP4] speaker to advertise ECMP routes for a destination to its peers. It uses an existing, Multi Hop Capability [M-HOP], to advertise multiple paths that it is using to its peers. The mechanism described in this document is only applicable to routers that have the ability to inject multiple routing entries in their forwarding table. "Ad Hoc IP Address Autoconfiguration", Jae-Hoon Jeong, 18-Jan-06, This document specifies the steps which a mobile node in the ad hoc network takes in deciding how to autoconfigure its IPv4 or IPv6 address in its network interface. Because the ad hoc IP address autoconfiguration in this document considers the ad hoc network's partition and mergence, the address duplication caused by the ad hoc network's mergence can be resolved through an 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.1", Silvia Pfeiffer, 6-Mar-06, This specification defines the Continuous Media Markup Language (CMML), version 2.1, 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. "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. "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", Gregory Vaudreuil, 10-Mar-06, This memo defines two extensions to the SMTP service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to obsolete RFC 3030. "Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option", Steven Legg, 30-Jan-06, Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, which can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. "Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options", Steven Legg, 29-Nov-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 introduces a new category of attribute options, called transfer encoding options, which can be used to specify that the associated attribute values are encoded according to one of these other methods. "iSeries Telnet Enhancements", Thomas Murphy, 8-Sep-05, This draft describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, lan- guage support, auto-signon, response codes, session association, etc. These support functions are implemented primarily using the Telnet Environment option negotiation [RFC1572] to define new USERVAR vari- ables that will be recognized by iSeries Telnet server. "Secure Origin BGP (soBGP) Certificates", Brian Weis, 5-Mar-06, 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)", Adnan Saleem, Garland Sharratt, 25-Oct-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, 13-Mar-06, 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, 10-Nov-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, 10-Feb-06, This draft describes the methodology for benchmarking MPLS protection mechanisms using the terminology defined in [TERMID]. 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 mechanisms such as Standby LSP, Fast Reroute Detour Mode, and Fast Reroute Bypass Mode. The methodology can also be used to benchmark LSP rerouting due to a Headend Reroute. 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. "BGPv4 Tunnel Encapsulation Attribute", Ruchi Kapoor, 25-Oct-05, This document defines a new BGP attribute called the Tunnel Encapsulation Attribute. This attribute is used to carry Tunnel encapsulations, capabilities and other relevant information about a Tunnel. "Tunnel SAFI", Gargi Nalawade, 25-Oct-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. "Memorandum for multi-domain Public Key Infrastructure (PKI) Interoperability", Masaki SHIMAOKA, 9-Jan-06, 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 (CP) 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. "GOST Cipher Suites for Transport Layer Security", Grigorij Chudov, Serguei Leontiev, 9-Sep-05, This document is intended to register new cipher suites for the Transport Layer Security (TLS) protocol, according to the procedure specified in section A.5 of [TLS]. These cipher suites are based on Russian national cryptographic standards - GOST R 34.10-94 and GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and GOST R 34.11-94 digest algorithm. "Filters for Mobile IPv6 Bindings (NOMADv6)", Koojana Kuladinithi, 25-Oct-05, Filters for Mobile IPv6 Bindings (NOMADv6) introduces a set of extensions for MIPv6 protocol that allows for intelligent use of multiple points of attachment simultaneously, on a mobile node. It specifies a set of rules (filters) communicated to binding agents using binding updates. In turn, binding agents use this information to determine whether and where to route flows associated with the mobile node. In this manner, it is possible for a mobile node to distribute flows or packets of a flow among its available points of attachment or to request that such flow is dropped before traversing the Internet fabric, with or without notification to their source. These extensions mirror a similar extension defined for Mobile IPv4 (NOMADv4) but has been extended to cater to the behavior of IPv6. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Thomas Schmidt, Matthias Waehlisch, 1-Dec-05, This document extends the Hierarchical Mobile IPv6 Internet Draft to include the reception and transmission of Any Source 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 the M-HMIPv6 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. The mechanisms described in this document do not rely on assumptions of any specific multicast routing protocol in use. The M-HMIPv6 protocol operations utilize the existing HMIPv6, MIPv6 and MLDv2 messages under minor extensions. "IPv6 Router Advertisement Option for DNS Configuration", Jae-Hoon Jeong, 19-Jan-06, This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. "SS7 MTP2-User Adaptation Layer (M2UA) SS7 Test Specifications M2UA-SS7TEST", Brian Bidulock, 28-Oct-05, This Internet-Draft provides information for the Internet community on the implementation of test cases for testing the SS7 MTP2-User Adaptation Layer [M2UA] Signalling Gateway (SG) based on the conformance test specifications for SS7 MTP Level 2 [Q.780..M2PATEST05]. "The XML Enabled Directory", Steven Legg, Daniel Prager, 2-Dec-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. "The XML Enabled Directory: Schema Operational Attributes", Steven Legg, Daniel Prager, 30-Nov-05, This document defines additional subschema operational attributes for the XML Enabled Directory (XED) that allow user-defined directory attribute syntaxes to be imported into a directory server. User defined syntaxes specified in XML Schema, RELAX NG or Abstract Syntax Notation One (ASN.1), or specified as XML document type definition (DTD) element type declarations, are supported. "Abstract Syntax Notation X (ASN.X)", Steven Legg, 11-Nov-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", Paul Jones, 2-Jun-04, This document defines the MIME sub-type audio/t38. The packetization and usage of this MIME type, which is intended for use within SDP, is specified within ITU-T Recommendation T.38. "Requirements for Inter-Domain Routing", Avri Doria, 26-Oct-05, These requirements for routing architectures are the product of two sub-groups with the IRTF Routing Research Group. They represent two individual and separate views of the problem and of what is required to fix the problem. While speaking of requirements, the document is actually a recommendation to anyone who would create a routing architecture for the Internet in the coming years. "Dual Stack IPv6 Dominant Transition Mechanism (DSTM)", Jim Bound, 20-Oct-05, In an IPv6 dominant environment, some applications will still require IPv4 addresses to interoperate. Dual stack may be configured on these hosts, but this will imply the configuration of network equipments (such as routers) to proceed IPv4 packets. 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 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, 12-Jan-06, Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDN) have at least two different forms. The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration. This memo defines some basic concepts and specifies the proposed registration and administration procedure of Chinese domain names based on the more general guidelines of RFC 3743 to avoid the problems that may be caused by the variants. It will be useful for understanding and using the tables defined in [LVT-SC] and [LVT-TC]. "TTL-Based Security Option for the LDP Hello Message", Enke Chen, Albert Tian, 27-Jan-06, To facilitate the deployment of the TTL-based security mechanism for LDP, in this document we propose a new optional parameter for the LDP Hello Message that can be used by a LSR to indicate its support of the TTL-based mechanism. "The XML Enabled Directory: Protocols", Steven Legg, Daniel Prager, 15-Nov-05, This document defines semantically equivalent Extensible Markup Language (XML) renditions of the Lightweight Directory Access Protocol (LDAP) and X.500 directory protocols for use by the XML Enabled Directory (XED). "Private VLANs: Addressing VLAN scalability and security issues in a multi-client environment", Sanjib HomChaudhuri, Marco Foschiano, 13-Feb-06, This document describes the concept of Layer 2 isolation among devices that are members of the same Layer 2 domain. A vlan is a 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, 12-Aug-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, 1-Mar-06, 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. "A Bound End-to-End Tunnel (BEET) mode for ESP", Jan Melen, Pekka Nikander, 28-Feb-06, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "An information model for Kerberos version 5", Leif Johansson, 6-Mar-06, This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, 27-Oct-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. "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", Cullen Jennings, 13-Jan-06, The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, 5-Jan-06, 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. "The Extended LDAP Data Interchange Format (ELDIF)", Steven Legg, Andrew Sciberras, 12-Dec-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. "Remote Call Control in the Session Initiation Protocol (SIP) using the REFER method and the session-oriented dialog package", Cullen Jennings, Rohan Mahy, 7-Mar-06, This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. Specifically it extents the REFER mechinims to allow the specificate of a response that a UA should send in a dialog. This functionality is most useful for collections of loosely coupled User Agents that wish to present a coordinated user experience. It does not require a Third-Party Call Control controller to be involved in any of the manipulated dialogs. "IPv6 Implications for TCP/UDP Port Scanning", Tim Chown, 27-Oct-05, The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP port scanning to discover open or running services on a host will potentially become far less computationally feasible, due to the larger search space in the subnet. This document discusses that property of IPv6 subnets, and describes related issues for site administrators of IPv6 networks to consider, which may be of importance when planning site address allocation and management strategies. "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", Aki Niemi, 9-Mar-06, 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, 20-Dec-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, 8-Mar-06, 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. "The LDAP Change Sequence Number", Howard Chu, Jim Sermersheim, 26-Oct-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, 23-Feb-06, 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 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, 13-Jan-06, 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. "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. "Layer 2 VPNs Over Tunnels", Kireeti Kompella, 5-Jan-06, Virtual Private Networks (VPNs) based on Frame Relay or ATM circuits have been around a long time. While these VPNs work well, the costs of maintaining separate networks for Internet traffic and VPNs and the administrative burden of provisioning these VPNs have led Service Providers to look for alternative solutions. In this document, we present a VPN solution where from the customer's point of view, the VPN is based on Layer 2 circuits, but the Service Provider maintains and manages a single network for IP, IP VPNs, and Layer 2 VPNs. "MAC-Forced Forwarding: A Method for Traffic Separation on an Ethernet Access Network", Torben Melsen, Steven Blake, 3-Feb-06, This document describes a mechanism to ensure layer-2 separation of LAN stations accessing an v4IPv4 gateway over a bridged Ethernet segment. The mechanism - called "MAC-Forced Forwarding" - implements an ARP proxy function that prohibits MAC address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. "6to4 Reverse DNS Delegation Specification", Geoff Huston, 10-Nov-05, This memo describes the service mechanism for entering a description of DNS servers which provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The proposed mechanism is a conventional DNS delegation interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. The client is primarily authenticated by it's source address and is authorised to use the function if it's IPv6 address prefix corresponds to the requested delegation point. "The EAP-PSK Protocol: a Pre-Shared Key EAP Method", Hannes Tschofenig, Florent Bersani, 14-Feb-06, 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. "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, 27-Oct-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, 12-Sep-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, 22-Feb-06, This document describes the addition of the ECN-nonce RFC 3540 [4] to the Stream Control Transmission Protocol (SCTP) RFC 2960 [3]. 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. "Future work addressing issues with the Session Initiation Protocol's non-INVITE Transaction", Robert Sparks, 3-Mar-06, 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, 3-Mar-06, The DHCP authentication extension (RFC 3118) cannot be widely deployed due to lack of a key agreement protocol. This document outlines how EAP-based network access authentication mechanisms can be used to establish bootstrap keying material that can be used to subsequently use RFC 3118 security. "Transporting Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 1-Feb-06, This document defines how to send information encoded in the Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP). "Quarantine Model Overview for IPv6 Network Security", Satoshi Kondo, 10-Mar-06, In the current Internet, a site is often secured by firewall, which filters harmful traffic from outside at the border of the site. This 'Border Defense Model', provides only a single line of defence and hinders the deployment of many next-generation Internet applications and services. This memo surveys the security issues of the 'Border Defense Model', and proposes a network architecture 'Quarantine Model', to provide a better security model and promote various end-to-end Internet usages. In our 'Quarantine Model', nodes shareing an Enterprise network network are connected to separate logical networks according to their security privilege level and community of interest. A different security policy is implemented on each logical network segment using the multiple security-related techniques, such as filtering, authentication, and encryption. This 'Compartmentalized' framework provides a better depth of network defenes and additional flexibility to our 'Quarantine Model'. This memo enumerates requirements and issues for this architecture. However, it is beyond the scope of this document to propose specific implementations or protocols. "Basic Messaging and Presence Interoperability between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE)", Peter Saint-Andre, 15-Feb-06, 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. "Requirements for the Resilience of Control Plane", Young Hwa Kim, 25-Oct-05, The resilience of control plane refers to the ability of control plane to continue its operation even under failure conditions of control components such as control entities, control nodes, and control channels. This document describes requirements for providing the resilience capability of control plane (in other words, control network) in non-(G)MPLS and (G)MPLS. This contribution, as a document that proposes a framework to provide the resilience capability of control plane, include terminologies, basic concepts of control networks, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP for the resilience of control plane. "The Archived-At Message Header Field", Martin Duerst, 8-Mar-06, This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. "OSPFv2 Extensions for Link Capabilities to support U-turn Alternates for IP/LDP Fast-Reroute", Alia Atlas, 7-Mar-06, This document proposes an extension to OSPF Version 2 for advertising link capabilities using the extensions defined for traffic engineering. The link capabilities are defined there for future extensibility. To support the signaling requirements of U-turn alternates for IP Fast-Reroute, this document defines three bits in the proposed link capabilities extension. "ISIS Extensions to support U-turn Alternates for IP/LDP Fast-Reroute", Alia Atlas, 6-Mar-06, This document specifies additional information that can inserted in IS-IS LSPs to convey link capabilities that may be useful in certain applications. In particular, an IS may convey that zero or more of its links are explicit marked and/or implicit U-turn recipient capable, which may be described as capable of identifying traffic as U-turn traffic and redirecting the traffic to a suitable alternate. The immediate applicability for these two link capabilities is in support of local protection, provided by a U-turn alternate, in the event of a link and/or node failure while the IS-IS area is reconverging onto a new topology. "Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia-Martin, 14-Feb-06, 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 messaging (IM) sessions, or chat rooms, using the centralized conferencing model. "Emergency Call Information in the Domain Name System", Brian Rosen, 26-Oct-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. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Florent Parent, Marc Blanchet, 2-Sep-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. "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", Joseph Salowey, 24-Oct-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 peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. "Benefits and Motivation for Session Mode Instant Messaging", Rohan Mahy, 4-Mar-06, 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", Hannes Tschofenig, Pasi Eronen, 27-Oct-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. "MIPv6 Authorization and Configuration based on EAP", Gerardo Giaretta, 8-Mar-06, This draft defines an architecture, and related protocols, for performing dynamic Mobile IPv6 authorization and configuration relying on a AAA infrastructure. The necessary interaction between the AAA server of the home provider and the mobile node is realized using EAP, exploiting the capability of some EAP methods to convey generic information items together with authentication data. This approach has the advantage that the access equipment acts as a simple pass-through for EAP messages and therefore does not play any active role in the Mobile IPv6 negotiation procedure, which makes the solution easier to deploy and maintain. "LDAP Turn Operation", Kurt Zeilenga, 27-Oct-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, 6-Mar-06, 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. P-IMAP is a recommendation for interoperable intermediate implementations awaiting [LEMONADEPROFILEBIS] or the realization of the OMA MEM enabler using it. "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Xiaobao Chen, 5-Jan-06, 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 Third Generation Partnership Project (3GPP) specified General Packet Radio Service/Universal Mobile Tele- communications System (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. The GPRS Gateway Support Node (GGSN) checks the source address or the destination address in the basic IPv6 header of incoming or outgoing IP datagrams against a set of packet filtering information established during the GPRS/UMTS session set-up. The packet filtering information remains stable during the sessions and independent of Mobile IP. When MIPv6 is activated by either end of the IPv6 mobile nodes, the packet filtering will fail to perform properly and subsequently block the traffic due to the mismatch between the packet filters and the current source address or destination address in the basic IPv6 header of the IP datagrams to and from the IPv6 mobile nodes. "A note about 3rd party bombing in Mobile IPv6", Francis Dupont, 21-Dec-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, 26-Oct-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. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Xiaoming Fu, Cornelia Kappler, 17-Oct-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. "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. "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, 2-Mar-06, 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. "eXtensible Binary Encoding (XBE32)", Manuel Urueña, David Larrabeiti, 8-Nov-05, This document defines the eXtensible Binary Encoding (XBE32). It has been designed to represent hierarchical data in a compact and extensible format. Data elements are binary encoded inside Type- Length-Value (TLV) structures, which are 32-bit aligned to be easily processed by computers. XBE32 is NOT a binary encoding for XML documents, but an encoding format for small, lightweight network protocols. "Mobile IPv4 NAI-based Home Address Assignment", Naveen PaulKandasamy, Kent Leung, 23-Jan-06, With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to Mobile Nodes during their initial registration. Though the concept of NAI-based home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for achieving such a NAI-based home address assignment has not been outlined. More particularly, the Home Agent and Mobile Node behaviors including the error recovery mechanisms for various scenarios related to NAI- based home address assignment have not yet been specified. This document specifies a procedure that the Mobile IP entities should follow in order to facilitate NAI-based home address assignment under various circumstances. "Email Submission: Access and Accountability", Carl Hutzler, 27-Oct-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. With the recent advent of email authentication technologies aimed at providing assurances and traceability between internetworked networks, the authors recognized that the initial submission of a message became the weakest link. Consequently, the document offers recommendations for constructive operational policies for the first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. The document seeks BCP status. Comments and discussion of this document should be addressed to the ietf-smtp@imc.org mailing list. "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Jari Arkko, Pasi Eronen, 26-Oct-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, 17-Oct-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. "GMPLS Signaling Extensions for the Transfer of Ownership of Label Switched Paths Between the Management and Control Planes", Diego Caviglia, 3-Oct-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. "User Session Tracking in RADIUS", Avi Lior, Glen Zorn, 7-Mar-06, This document defines a set of new messages and attributes designed to allow RADIUS servers to cleanly track user sessions. "DNS Based Blacklists and Whitelists for E-Mail", John Levine, 30-Nov-05, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become a de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. "RADIUS Error Messages", Glen Zorn, 17-Feb-06, This document describes new RADIUS protocol elements designed to allow the communication of packet and attribute errors between RADIUS servers and clients. "Repeated Authentication in IKEv2", Yoav Nir, 10-Jan-06, This document extends the IKEv2 document [IKEv2]. 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 document describes a mechanism to perform this function. "Licklider Transmission Protocol - Specification", Scott Burleigh, 3-Mar-06, 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. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. 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. "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, 21-Oct-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 establishing a secure connection based on the use of Pre Shared Keys (PSK). The secure connection 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 the peer and the 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, 30-Sep-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 a framework for digitally signing email on a per-domain basis. 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". "Transport Layer Security Session Resumption without Server-Side State", Joseph Salowey, 26-Jan-06, 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. "Web Distributed Authoring and Versioning (WebDAV) Locking Protocol", Julian Reschke, 5-Oct-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. "DISCOVER: Supporting Multicast DNS Queries", Bill Manning, Paul Vixie, 17-Nov-05, This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. "DHCP Option for Home Agent Discovery in MIPv6", Alper Yegin, 2-Mar-06, 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. "Dialstring parameter for the Session Initiation Protocol URI", Brian Rosen, 7-Mar-06, 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 or SIPS URI. "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. "Structural object class 'untypedObject' for LDAP/X.500", Alexey Melnikov, Hallvard Furuseth, 20-Jan-06, This document defines an 'untypedObject' structural object class for the Lightweight Directory Access Protocol (LDAP) and X.500. This is useful for entries with no 'natural' choice of structural object class, e.g. if an entry must exist even though its contents are uninteresting. "MTU and Fragmentation Issues with In-the-Network Tunneling", Pekka Savola, 5-Oct-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 GMPLS Traffic Engineering Networks", Anca Zamfir, Zafar Ali, 7-Mar-06, GMPLS-TE Graceful shutdown is a method for explicitly notifying the nodes in a TE network that the TE protocol on a link or on an entire TE node is going to be disabled. GMPLS-TE graceful shutdown 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. These operations are equally applicable for both classical MPLS and its GMPLS extensions. "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, 17-Feb-06, 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, 28-Feb-06, 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. "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. "TCP's Reaction to Soft Errors", Fernando Gont, 23-Sep-05, This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including that in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionaly, it describes a modification to TCP's reaction to soft errors that has been implemented in a variety of TCP/IP stacks to help overcome this problem. "U-turn Alternates for IP/LDP Fast-Reroute", Alia Atlas, 7-Mar-06, 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. "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. "Mobile IPv6 - NSIS Interaction for Firewall traversal", Hannes Tschofenig, 27-Oct-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. "Setup and Maintenance of Pseudowires using RSVP-TE", Rahul Aggarwal, 26-Oct-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. "IMAP and SMTP HTTP Binding", Stéphane Maes, 23-Jan-06, As part of the LEMONADE work to define extensions to the IMAPv4 Rev1 protocol [RFC3501] and SMTP that provide optimizations in a variety of settings, the this document describes an alternative, optional binding for IMAPv4 and SMTP showing how HTTP can be used to transfer commands and responses. This binding is intended to facilitate the use of IMAP and SMTP in deployments involving a variety of intermediaries. A binding to SOAP is also provided. "Payment for Services in Session Initiation Protocol (SIP)", Cullen Jennings, 26-Oct-05, Service usage might require some form of compensation and this is also true for many communication systems where an entity receiving a call should be able to charge the caller. This is necessary for allowing fair communication between two communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for doing this in SIP using the Security Assertion Markup Language (SAML). It relies on a third party to act as a payment provider and is designed for low value transactions. It does not aim to provide the same capability as other authentication, authorization and accounting systems. This draft is in a fairly early state and has many details that are missing. Earlier versions of this document did not use SAML. This version offers a sketch of what the SAML based solution would look like but still lacks many details that would be needed for an actual implementation. "Computational Puzzles for SPAM Reduction in SIP", Cullen Jennings, 6-Mar-06, 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. This draft currently outlines enough information to evaluate and consider this approach or even run experiments. It would need finalization around the forking topics discussed in the open issues before it would be implementable in production system. "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, 21-Oct-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, 25-Oct-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. "Datagram Congestion Control Protocol Mobility and Multihoming", Eddie Kohler, 30-Jan-06, This document lays out requirements and a preliminary design for transport-level mobility and multihoming support in the Datagram Congestion Control Protocol (DCCP) [DCCP]. "SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06, This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. "SIP SAML Profile and Binding", Hannes Tschofenig, 8-Mar-06, This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". "SIP Event Notification for Internet Media Guides", Yuji Nomura, 28-Dec-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. "IPv6 Campus Transition Scenario Description and Analysis", Tim Chown, 9-Mar-06, In this document we consider and analyse the specific scenario of IPv6 transition and deployment in a large department of a university campus network. The department is large enough to operate its own instances of all the conventional university services including (for example) web, DNS, email, filestore, interactive logins, and remote and wireless access. The scenario is a dual-stack one, i.e. transition to IPv6 means deploying IPv6 in the first instance alongside IPv4. This analysis will both identify the available (and still missing) components for IPv6 transition, and also test the applicability of the recently completed IPv6 Enterprise Network Scenarios document. "The PROTO Process: Working Group Chair Document Shepherding", Henrik Levkowetz, 8-Mar-06, The methodologies described in this document have been designed to improve and facilitate IETF document flow processing. A set of procedures, known as the PROTO process (because it was created by the PROcess and TOols or PROTO team), 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. "GMPLS Inter-domain Traffic Engineering Requirements", Tomohiro Otani, 2-Feb-06, 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, 26-Oct-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 nine 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, 17-Jan-06, 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, identity protection, and authenticated data exchange. "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. "Scope Modifiers in Intellectual Property Declarations", I Maturana, I Robredo, 16-Aug-05, The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environnments, such as the Internet. "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets", Daniel Petrie, 26-Oct-05, This document defines the requirements and a format for SIP user agent profile data. An overall schema is specified for the definition of profile data sets. The schema also provides for expressing constraints for how multiple sources of profile data are to be combined. This document provides a guide to considerations, policies and syntax for defining data sets to be included in profile data. It also explores some specific data sets to test the requirements, assumptions and syntax. "Fast End-to-End Restoration Mechanism with SRLG using Centralized Control", Jun Choi, 27-Oct-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. "Server/Application State Protocol v1", Alan Bivens, 19-Aug-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. "Sieve Extensions: MIME Bodypart Iteration, MIME Tests, Replacement and Enclosure", Cyrus Daboo, Tony Hansen, 26-Oct-05, The current Sieve language has no looping mechanism, a way to look at individual MIME parts, or any way to manipulate those individual parts. This document defines extensions for each of these needs. "Framework for Netconf Content", Sandeep Admankar, Sharon Chisholm, 25-Oct-05, This memo defines a framework for defining content for Netconf. It defines requirements to enable interoperability, extensibility, easy parsing, usability and predictable modelling. "Goals and Benefits of Multihoming", Thierry Ernst, 27-Oct-05, This document attempts to define the goals and benefits of multihoming for fixed and mobile nodes (hosts and routers), i.e. from a node point of view, as investigated in the Monami6 WG, and not from a site point of view as investigated in the Shim6 WG. Those goals and benefits are illustrated with a set of scenarios. This document is generic in the sense that the benefits of node multihoming can be shared by both fixed end nodes and mobile end nodes. It is intended to satisfy the first item as specified on the Monami6 charter and as such, working group approval as a working group document will be sought. "ICMP attacks against TCP", Fernando Gont, 27-Oct-05, This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks. "Simple Path Control Protocol Specification", David Lillethun, 3-Mar-06, The Simple Path Control Protocol (SPC) defined in this document is a new protocol defined to enable processes external to networks to establish, delete and monitor paths, including lightpaths. The architecture of this protocol establishes a method of providing messages, and procedures that allow such external processes to use those messages to directly request network resources related to path provisioning. "Guidelines for Writing an IANA Considerations Section in RFCs", Thomas Narten, Harald Alvestrand, 7-Mar-06, 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). "A Proposed Media Delivery Index", James Welch, James Clark, 30-Aug-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. The Media Delivery Index measurement defined in this memo is intended for Information only. "IPsec transport mode in Mobike environments", Francis Dupont, 25-Oct-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. "IPvLX - IP with virtual Link eXtension", Fred Templin, 3-Mar-06, The IPv6 128-bit addressing architecture was designed as a successor for IPv4. But, IPv4 deployment in the global Internet continues via private addressing domains behind Network Address Translators (NATs) such that long-term coexistence with IPv6 addressing and minimal perturbation of IPv4 networks is emerging as the dominant strategy. This document proposes a long-term IPv6/IPv4 coexistence scheme called: IPvLX - IP with virtual Link Extension. "Internet Security Glossary, Version 2", Rob Shirey, 21-Feb-06, This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 297 pages of entries 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. "Guidelines for an Arabic Domain Name System (ADNS)", Mansour Farah, 10-Mar-06, There have been several attempts aimed at developing an Arabic Domain Name System (ADNS) using Arabic characters in an Arabic-language coherent fashion. In the beginning of the second quarter of 2003, an Arabic Domain Name Task Force (ADNTF) was formed under the auspices of United Nations Economic and Social Commission for Western Asia (ESCWA), and the guidance of Multilingual Internet Names Consortium (MINC); one of its main objectives was to help define standards for ADNS through a Request For Comments (RFC) document. This document resolves many technical and linguistic issues, including the adoption of the client-side DNS-based approach to name resolution; syntax of the proposed Arabic Domain Names together with the character set and many Arabic language-specific issues were clearly resolved. This Internet-Draft proposes guidelines that are compatible with the Internet Consortium for Assigned Names and Numbers (ICANN) and the Internet Engineering Task Force (IETF) as far as Domain Names System (DNS) and Internationalized Domain Names (IDN) standards are concerned. Technical, management, operational, and language-specific issues are discussed and recommendations are made. "RIPv2 Cryptographic Authentication", M Fanto, Randall Atkinson, 8-Nov-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. "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, 9-Feb-06, 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, 3-Mar-06, 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. "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force Force", Susan Harris, Paul Hoffman, 24-Feb-06, This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. "A string encoding of Presentation Address", Steve Kille, Alexey Melnikov, 1-Dec-05, There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This is a revision of RFC 1278. This document also defines a string representation for IPv6 network addresses as defined in RFC 1888 and draft-melnikov-nsap-ipv6-XX.txt. "Network Address to support OSI over IPv6", Alexey Melnikov, 20-Jan-06, This document defines a format for OSI NSAP Addresses for use where TCP or UDP is used to provide the OSI Network Service over IPv6, as in RFC 2126 (ISO Transport Service on top of TCP (ITOT)). This requires encoding of an IPv6 address and a port number in the NSAP. RFC 1277 defines an NSAP format for use with IPv4 addresses, and this document updates RFC 1277 to allow for IPv6 addresses. "Bounce Address Tag Validation (BATV)", John Levine, 3-Mar-06, The envelope of Internet mail contains an RFC2821.MailFrom command, which may supply an address to be used as the recipient of transmission and delivery notices about the original message. Existing Internet mail permits unauthorized use of addresses in the MailFrom command, causing notices to be sent to unwitting and unwilling recipients. Bounce Address Tag Validation (BATV) defines an extensible mechanism for validating the MailFrom address. It also defines an initial use of that mechanism which requires no administrative overhead and no global implementation. "Message Header for Indicating Sender Authentication Status", Murray Kucherawy, 27-Feb-06, 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, 21-Oct-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. "EAP Smart Card Protocol (EAP-SC)", Pascal Urien, 20-Oct-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. "Distributing Keys for DNSSEC", Ben Laurie, 30-Nov-05, Until DNSSEC is fully deployed, so-called "islands of trust" will exist. This will lead to a large number of keys with no method within DNSSEC to manage the keys. This proposal seeks to address that issue using existing mechanisms to allow cross-signing of root (i.e. roots of islands) keys. This cross-signing of keys creates a non-hierarchical web of trust which permits the efficient gathering and validation of trust anchors. "Global HA to HA protocol", Pascal Thubert, 21-Oct-05, This HAHA protocol extends MIPv6 [15] and NEMO [16] to remove their link layer dependencies on the Home Link and distribute the HAs at IP layer. Global HAHA considers the distribution at the scale of the Internet, and introduces the MIP proxy for Local Mobility Management and Route Optimization in the Infrastructure. "Quality of Service for Ad hoc Optimized Link State Routing Protocol (QOLSR)", Hakim Badis, 11-Oct-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. OLSR provides optimal routes in terms of number of hops. In order to provide and fulfill quality of service (QoS) requirements, extensions can be added to OLSR functioning and control messages format (HELLO and TC). These extensions specify metrics like available bandwidth, delay, jitter, loss probability, power consumption, etc., which must be used for Multipoint relay (MPR) selection and routing table calculation. This memo describes the QOLSR protocol, which is an enhancement of OLSR to support multiple-metric. "Requirements for Manageability Sections in Routing Area Drafts", Adrian Farrel, 27-Oct-05, It has often been the case that manageability considerations have been retrofitted to protocols. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the requirement for all new Routing Area Internet-Drafts to include an "Manageability Considerations" section, and gives guidance on what that section should contain. "Application Master Session Key (AMSK) for Mobile IPv6", Gerardo Giaretta, 10-Mar-06, The Extensible Authentication Protocol (EAP) defines an extensible framework for performing network access authentication. Most EAP authentication algorithms, also known as "methods", export keying material that can be used with lower layer ciphersuites. It has been proposed [11] to leverage the EAP keying framework to derive Application Master Session Keys (AMSKs) for specific applications or services. This document defines how to generate Application Master Session Keys (AMSKs) specific to Mobile IPv6. These AMSKs can be used by Mobile Node and Home Agent to bootstrap Mobile IPv6 protocol operation. "Service Location Protocol Extensions for Mobile IPv6", Bilhanan Silverajan, 12-Oct-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. "The IMG Envelope", Rod Walsh, 20-Dec-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 object and as a distinct object to associate with a distinct IMG metadata object. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 7-Mar-06, This document summarizes the work and experiences of the Host Identity Protocol IRTF Research Group (HIP-RG). The HIP-RG was chartered to explore the possible benefits and consequences of deploying the Host Identity Protocol architecture in the Internet. "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", Wassim Haddad, 26-Oct-05, This memo describes the privacy in mobility and multi-homing problem statement. "Media Policy Templates for XCON", Chris Boulton, Umesh Chandra, 25-Oct-05, The xcon framework[1] specifies the object model for centralized conferencing. The Conference Object, which is defined in the framework data model, comprises of two distinct components - the Common Conference Information and Conference Templates. This memo specifies the Conference Templates that describe various common conference scenarios. The templates define controls (and media properties like type of media supported, what streams are supported etc) through which participants of the conference can manipulate the media they receive from the conference server. This document provides a minimum set of media templates that can be instantiated during conference creation and manipulated during the life cycle of a conference instance. This draft is currently under major revision and should be considered a work in progress as it aligns with current technical direction of the Working Group. A revision of this draft will be submitted very soon. This work is being discussed on the xcon@ietf.org mailing list. "Network Access Control Protocol (NACP)", Susan Thomson, 7-Mar-06, 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, 7-Mar-06, 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. It is anticipated that TLS/IA will be used with and without subsequent protected data communication within the tunnel established by the handshake. For example, TLS/IA may be used to secure an HTTP data connection, allowing more robust password-based user authentication to occur than would otherwise be possible using mechanisms available in HTTP. TLS/IA may also be used for its handshake portion alone; for example, EAP-TTLSv1 encapsulates a TLS/IA handshake in EAP as a means to mutually authenticate a client and server and establish keys for a separate data connection. "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, 26-Oct-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, 28-Oct-05, Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. 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, 5-Oct-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. "NSLP for Metering Configuration Signaling", Falko Dressler, 27-Oct-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 for a path-coupled configuration protocol for Metetering Entities and discusses the applicability of NSIS for this purpose. This document defines a Metering NSLP protocol design and messages, outlines protocol operation. "Network-Layer Signaling: Transport Layer", Melinda Shore, 22-Nov-05, The RSVP model for communicating requests to network devices along a datapath has proven useful for a variety of applications beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ. We are developing a modernized version that, among other things, is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol. "Centralized Conference Control Protocol", Orit Levin, 3-Jan-06, This document defines a Centralized Conferencing Control Protocol (CCCP) as a part of the XCON Working Group protocols suite. CCCP uses a client-server model for creation, querying, and manipulation of XCON entities, conference objects and sub-objects. An XCON entity, which implements a CCCP server, provides a means for authorized CCCP clients (e.g. conference participants) to affect the behavior of a conference in the XCON system. "A Framework for Loop-free Convergence", Stewart Bryant, Mike Shand, 3-Mar-06, 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. "Traversing HIP-aware NATs and Firewalls: Problem Statement and Requirements", Hannes Tschofenig, Murugaraj Shanmugam, 9-Mar-06, The Host Identity Protocol (HIP) is a signaling protocol, which supports mobility and multihoming by adding a new layer to the TCP/IP stack. By carring relevant parameters in the signaling messages, HIP can be used to establish IPsec encapsulating security payload (ESP) security associations between two hosts. Middleboxes (e.g. firewalls and network address translators) cannot inspect transport layer headers of data traffic if that traffic is sent over an IPsec ESP tunnel. However, HIP is designed to be middlebox friendly; it enables the middleboxes to inspect the signaling messages. The information that they can derive from that messages enables the middleboxes to uniquely identify the subsequent data flows, e.g. for the purposes of multiplexing and demultiplexing . A middlebox that implements the relevant mechanisms is called "HIP-aware". This document presents a problem statement and lists some requirements that are necessary for a HIP-aware middlebox traversal technique. These include authentication and authorization of signaling end-hosts by the middleboxes. Such authorization will help the middleboxes to decide whether or not an end host is allowed to traverse, and can potentially limit unwanted traffic. "Specification for the Explicit Control Protocol (XCP)", Aaron Falk, 20-Oct-05, This document contains an initial specification for the Explicit Control Protocol (XCP), an experimental congestion control protocol. XCP is designed to deliver the highest possible end-to-end throughput over a broad range of network infrastructure, including links with very large bandwidth-delay products, which are not well served by the current control algorithms. XCP is potentially applicable to any transport protocol, although initial testing has applied it to TCP in particular. XCP routers are required to perform a small calculation on congestion state carried in each data packet. XCP routers also periodically recalculate the local parameters required to provide fairness. On the other hand, there is no per-flow congestion state in XCP routers. This version specification (-01) includes protocol changes that move per-packet divisions from the router to the sender. "Interaction between SIP and HIP", Hannes Tschofenig, 8-Mar-06, 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, 25-Oct-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, 27-Oct-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", Dipnarayan Guha, Jun Choi, 8-Mar-06, 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, 9-Mar-06, 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. "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 19-Jan-06, 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. "Inter Home Agents Protocol Specification", Ryuji Wakikawa, 7-Mar-06, This document provides the protocol specification of the inter Home Agent protocol designed for both Mobile IPv6 and the NEMO Basic Support protocol. This document describes Home Agent configurations, message formats and Mobile Host, Mobile Router, and Home Agent operations. "Path type support for NSIS signaling", Takako Sanda, 26-Oct-05, NSIS state management needs to track data path changes and update the states along the affected data paths. However, in certain scenarios, there are multiple concurrent paths involved in the communication. In this case, the normal NSIS scheme does not provide sufficient support for the state manipulation. Therefore, extra functionality for data path identification and distinction is necessary. In current Internet, with the increasing use of multi-homing devices and the employment of Mobile IP, the above issue is getting more prominent. This draft discusses in detail the problems and issues involved in the NSIS state management relevant to the data path differentiation. Specific scenarios for multi-homing and Mobile IP route optimization are studied. Potential solution and its impacts on current NSIS protocol design are discussed as well. "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. "QoS NSLP State Machine", Xiaoming Fu, 10-Mar-06, 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, 11-Nov-05, This document is proposed to use version 2 of the Internet Key Exchange (IKEv2) to replace current HIP protocol's base exchange. IKE-H is an extension of IKE used for performing mutual authentication, establishing and maintaining security associations. It provides continuity of communications between not only hosts but also security gateways. It supports HIP identity authentication method and the establishment of keying material, consequently being used by IPsec Encapsulated Security payload (ESP) to establish a two- way secure communication channel between the hosts or security gateways. "Formats for IPv6 Scope Zone Identifiers in Literal Address Formats", Bill Fenner, Martin Duerst, 24-Oct-05, This document specifies the format to be used when specifying a zone identifier with a literal IPv6 address in URIs and IRIs, and in SMTP and Internet Mail Messages. While this combination is expected to be needed rarely, it is useful to specify the exact syntax. "MPLS and GMPLS Change Process", Loa Andersson, 7-Dec-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 responsibility 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. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 15-Feb-06, 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. "NAT/FW NSLP State Machine", Constantin Werner, 9-Mar-06, 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. "SXDF - Simple Extensible Data Format", Norbert Bollow, 1-Dec-05, The Simple Extensible Data Format (SXDF) defined in this document aims to combine the nice properties of XML (of providing a universal, text-based data format which allows adding additional data fields without breaking existing application programs) with a simple syntax which can be parsed efficiently by computer programs. This data format is intended for over-the-wire use in webservice protocols, where there is generally no interest in being able to directly modify the representation of the data with a standard text editor. "QQP - Quick Queues Protocol", Norbert Bollow, 1-Dec-05, The QQP protocol specifies a method for using a single reliable, stream-oriented connection (i.e. a TCP connection which may optionally be encrypted by means of SSL or TLS) for transmitting multiple webservice requests and responses. QQP plays the role of transport protocol for the QRPC webservice protocol, similar to how XML-RPC and SOAP often use HTTP as transport protocol. "QRPC - Queueable Remote Procedure Calls", Norbert Bollow, 1-Dec-05, The QRPC (Queueable Remote Procedure Calls) protocol is a fast and versatile general-purpose webservice protocol. QRPC can be used as a faster replacement for XML-RPC or SOAP, or it can be used for more general kinds of webservices which integrate technical and business processes across trusted or untrusted networks. QRPC brings the flexibility of the UNIX inter-process communication mechanism with pipes, signals and redirection of "standard input", "standard output" and "standard error" to the realm of webservices. "Licklider Transmission Protocol - Motivation", Scott Burleigh, 3-Mar-06, 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. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "Licklider Transmission Protocol - Extensions", Stephen Farrell, 3-Mar-06, 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. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "A File Aggregation Scheme for FLUTE", Christoph Neumann, 20-Oct-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. "State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)", Pyda Srisuresh, 7-Mar-06, This memo documents the various methods known to be in use by the peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. "Basic Internet Calendaring and Scheduling Core Object Specification (iCalendar Basic)", Doug Royer, 28-Dec-05, This is simplified iCalendar definistion. 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, 15-Sep-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. "The OpenPGP mail and news header", Atom Smasher, Simon Josefsson, 23-Sep-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. "Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont, Jean-Michel Combes, 21-Dec-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. "TLS Sign", Ibrahim Hajjeh, 24-Oct-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. "Mobile IPv4 Message String Extension", Venkateshwara Sastry, 20-Oct-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. "Network Address Translation - Protocol Translation (NAT-PT)", Soohong Park, 25-Oct-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, 20-Oct-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. "A P2P Approach to SIP Registration and Resource Location", David Bryan, 7-Mar-06, 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 p2psip@cs.columbia.edu mailing list. "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. "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, 6-Oct-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, 20-Dec-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 compound meta-flow record. Subsets of flows eligible for aggregation, as well as 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 for 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, 27-Feb-06, This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "NAT Behavioral Requirements for TCP", Senthil Sivakumar, 21-Oct-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 other companion BEHAVE documents like [BEH-UDP], which outlines the requirements for processing UDP and some generic requirements. "SIP, P2P, and Internet Communications", Henry Sinnreich, Alan Johnston, 7-Mar-06, 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 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 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. "RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol", David Auerbach, 10-Nov-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.). "IKEv2 Clarifications and Implementation Guidelines", Paul Hoffman, Pasi Eronen, 22-Feb-06, 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. "RADIUS Mobile IPv4 extensions", Madjid Nakhjiri, 26-Oct-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 registration process of the mobile node with MN-AAA authentication extension. Although Diameter Mobile IP application is being specified to support the needs of Mobile IPv4 from the point of view of the AAA infrastructure, such support does not exist within RADIUS framework. This document defines the RADIUS attributes that provide support for Mobile IPv4 operation. "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", Jean-Louis Le Roux, JP Vasseur, 20-Sep-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 IGP (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 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. "Binomial Congestion Control At Receivers for Multicast (BARM)", Bing Zhang, Zengji Liu, 24-Jan-06, 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. "HTTP Enabled Location Delivery (HELD)", James Winterbottom, 26-Oct-05, This document describes a means by which a Target may request location from a Location Server using HTTP as a GEOPRIV 'using protocol'. The protocol uses standard HTTP request methods with parameters encoded as form data. Methods for discovering accessible servers are also described. "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, 9-Feb-06, 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. "Encoding Instructions for the Robust XML Encoding Rules (RXER)", Steven Legg, 20-Oct-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 Abstract Syntax Notation X (ASN.X) document. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. "IPv6 Support on Mobile Ad-hoc Network", Ryuji Wakikawa, 13-Mar-06, 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. "IMAP4 extension to SEARCH command for controlling what kind of information is returned", Alexey Melnikov, Dave Cridland, 21-Oct-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 untagged response ESEARCH is also specified. "Generic Aggregate RSVP Reservations", Francois Le Faucheur, 21-Oct-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, [RSVP-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, 21-Oct-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. "Information Currency Documents and Operations", J. Bedell, 12-Jan-06, Information currency is the name given to tradeable economic instruments representing underlying information. The document formats for information currency and the operations defined for information currency are described in this note. "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", Cullen Jennings, Nagendra Modadugu, 7-Mar-06, This specification defines how to use Datagram Transport Layer Security (DTLS) as a transport for Session Initiation Protocol (SIP). DTLS is a protocol for providing Transport Layer Security (TLS) security over a datagram protocol. This specification also specifies the IANA registrations for using SIP with Datagram Congestion Control Protocol (DCCP). "Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative", Dan Wing, Cullen Jennings, 7-Mar-06, 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. "Routing extensions for discovery of Traffic Engineering Node Capabilities", JP Vasseur, Jean-Louis Le Roux, 4-Oct-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, 26-Oct-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, 6-Mar-06, 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. "Transmitting Confidential Data in RADIUS", Glen Zorn, 17-Feb-06, 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", Sri Gundavelli, Brian Haley, 26-Oct-05, This document describes an extension to the Mobile IPv6 base protocol [2] by defining a new Mobility Header message type that can be used for sending notification messages between a mobile node, its correspondent nodes, and its home agent. The purpose of this extension is to provide an extensible framework by which Mobile IPv6 entities can exchange notification messages indicating that certain events have occurred. "How to store traceroute measurements and related metrics", Saverio Niccolini, 10-Mar-06, This memo describes a standard way to store traceroute measurements and 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). Moreover an additional element is defined to relate configuration elements and results ones by means of a common unique identifier. On the basis of the information model a data model is then proposed in order to actually store the traceroute measurements. Finally considerations on how to extract relevant metrics related to traceroute measurements are given. "Regulating Publication of Event State Information", Jacco Brok, 8-Mar-06, 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 the presence event package. However, for a UAC on a mobile device, this can be very costly in terms of battery, computing, and network resources. Although some mechnisms exist for a UAC to deduce whether event state publication is needed and at what rate publish messages may be sent, 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, whether urgent and with what delta. "Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)", Jean-Louis Le Roux, 25-Oct-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. "Considerations on the IPv6 Host density Metric", Geoff Huston, 10-Nov-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. "Lemonade and the challenges of Intermediaries", Stephane Maes, 10-Nov-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, 25-Oct-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. "IRIS - A Routing Registry (rreg) Type for the Internet Registry Information Service", Kengo Nagahashi, 26-Oct-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. "A Simple Privacy Extension for Mobile IPv6", Francis Dupont, 17-Jan-06, 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, 3-Mar-06, 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 Re-Association At Confederation Edge", Susan Hares, Pratik Bose, 19-Oct-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. "Conference State Change Protocol (CSCP)", Cullen Jennings, 14-Dec-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, 27-Oct-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, 25-Oct-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, 7-Mar-06, 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. "Using HIP with Legacy Applications", Tom Henderson, Pekka Nikander, 1-Mar-06, 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. "The XML Enabled Directory: Matching Rules", Steven Legg, Daniel Prager, 2-Dec-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 XML document type definition (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, 3-Mar-06, 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. "EAP Tunneled TLS Authentication Protocol Version 1 (EAP-TTLSv1)", Paul Funk, Simon Blake-Wilson, 8-Mar-06, 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. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks. EAP-TTLS also allows client and server to exchange other information in addition to authentication-related information. This document describes EAP-TTLSv1; that is, version 1 of the EAP- TTLS protocol. It represents a significant enhancement to the original version 0 of the protocol. EAP-TTLSv1 utilizes an extended version of TLS, called TLS/IA (TLS/InnerApplication) as its underlying protocol [TLS/IA]. "Additional Values for the NAS-Port-Type Attribute", Glen Zorn, 6-Mar-06, This document defines a set of new values for the NAS-Port-Type RADIUS Attribute. "Address autoconfiguration for MANETs: definition and problem statement", Shubhranshu Singh, 9-Mar-06, A Mobile Ad Hoc NETwork (MANET) is formed by the association of mobile devices, usually wireless and capable of multi-hop communication among themselves even if there is no networking infrastructure available. MANET properties such as multi-hop, autonomous, etc requires separate address autoconfiguration mechanism. This document provides definition, problem statement and goals for ad hoc networks address autoconfiguration. "Considerations of point-to-multipoint route optimization using PCEMP", Jun Choi, 26-Oct-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. "PWE3 Applications & OAM Scenarios", Simon DeLord, 25-Oct-05, This document provides requirements and a framework for PWE3 Operation Administration and Maintenance (OAM). It extends the PWE3 architecture reference model by including multi-segment Pseudo Wires (PWs) and also a detailed model of the access portion of the network. This document targets to provide applicability guidelines for the on going OAM work by describing different implementation solutions and detailing the Pros and Cons of each solution. "Policy Decisions for Users with Access to Multiple Services", Jari Arkko, 27-Oct-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. This draft discusses how to use existing AAA and authentication protocols and extensions to determine what service was provided, agree about this among all the participating parties, and use this information as a basis for policy decisions. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, 7-Mar-06, 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. "To publish, or not to publish, that is the question", Alain Durand, Tim Chown, 27-Oct-05, This document aims at restarting the discussion on what a site network administrator should publish in the global DNS and what they should not. The latest attempt was documented in a previous draft [4] was was ultimately an unsuccessful effort to clarify what to do with IPv4 private addresses RFC1918 [1] in the DNS. Since then, a number of similar issues coming from the IPv6 world have arisen and there is a sense that the situation needs to be clarified by a BCP document. "Application Design Guidelines for Traversal through Network Address Translators", Bryan Ford, 9-Mar-06, This document defines guidelines by which application designers can create applications that communicate reliably and efficiently in the presence of Network Address Translators (NATs), particularly when the application has a need for "peer-to-peer" (P2P) style communication. The guidelines allow a P2P application to work reliably over a majority of existing NATs, as well as all future NATs that conform to the behave requirements specified in companion documents. The NAT traversal techniques described in the document 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 modifications to IP or transport-layer protocols on the end hosts. "Mobile IPv6-based Global Anycasting", Shingo Ata, 20-Jan-06, 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. "Framework for Metering NSLP", Ali Fessi, 27-Oct-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: 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, 9-Mar-06, This document defines the format of Uniform Resource Identifiers (URI) for references to electronic mail addresses. It updates the syntax of 'mailto' URIs from [RFC2368] for better compatibility with IRIs ([RFC3987]). "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Per Frojdh, Magnus Westerlund, 8-Mar-06, 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 RTSP and SDP extensions with IANA. "Complications from Network Address Translator Deployment Topologies", Bryan Ford, Pyda Srisuresh, 6-Mar-06, This document identifies two problems that have arisen from the the unconventional network topologies that are often constructed with the deployment of network address translator devices (NATs). This document also specifies best current practice recommendations for dealing with the issues identified with the two problems. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level hierarchies of inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in the corporates and the wide spread use of remote access virtual private networks (VPNs) can lead to conflict of private IP address space between the remote network where the VPN client is located and the corporate network. "Application Programming Interface to a Trigger Database for MOBIKE", Hannes Tschofenig, 7-Mar-06, MOBIKE is a protocol which adds mobility and multihome support for IKEv2. MOBIKE peers continuously exchange a list of available IP addresses each other. 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 one address or interface to another. This information, which will be referred as trigger, is distributed over a number of protocol daemons at an end host. To make this information available to a 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, 7-Mar-06, This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. We propose a set of extensions to the PF_KEY framework which allows smooth and solid operation of IKE in a Mobile IPv6 environment. The first extension is called PF_KEY MIGRATE and is for migrating the endpoint addresses of a IPsec Security Association pair in tunnel mode. The second extension is named SADB_X_EXT_PACKET and allows IKE to make the right choice for address selection in bootstrapping process. Both extensions are helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE and achieving performance optimization. "Problem Statement: Configuration of IP services for IPDVB", Martin Stiemerling, 26-Oct-05, Future IPDVB networks will require a more powerful configuration management of IP addresses and related networking parameters 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 management are not yet clearly defined. This memo identifies the problem space for dynamic configuration of IP networking parameters in IPDVB networks. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", Gonzalo Camarillo, 8-Mar-06, This documents describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). Although the goal of this document is to describe all the functions of SBCs, a special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. It also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required. "Preferred Alternatives for Tunnelling HIP (PATH)", Pekka Nikander, 9-Mar-06, 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, 25-Oct-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. This document describes a mechanism to enable mobile and correspondent nodes to send the signaling packets directly to their care-of addresses. "The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)", Gonzalo Camarillo, German Blanco, 12-Dec-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, 2-Dec-05, This document describes a general EAP method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for 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, 14-Sep-05, This document describes 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 recent such events, taking account of the creation of the IETF Administrative Support Activity (IASA). "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. "Internet Code Point Assignments for NSAP Addresses", Eric Gray, 2-Dec-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. "Operational, Deployment and Interworking Considerations for GMPLS", Kenji Kumaki, 25-Jan-06, 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. "Dynamic AS Re-Association", Susan Hares, Pratik Bose, 7-Mar-06, 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, 5-Jan-06, 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]. This document defines requirements for a Firewall Configuration Protocol. It has been produced by a number of 3GPP2 member companies and endorsed by 3GPP2. It contains 3GPP2 requirements to a next generation firewall configuration protocol. With the number of threats that keep increasing on the Internet, many networks have decided to deploy firewalls to reduce the possible risks and protect their users as well as their network resources. Firewalls can however present many issues with new protocols, applications and scenarios to be supported. Data packets may be discarded at the firewalls. In addition, the clients may often be the only parties that know the requirements and details of the data communications. This document therefore explains why a protocol allowing clients to configure firewalls would be useful, and attempts to identify the requirements and features to be supported by such a protocol. "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", Jari Urpalainen, 14-Sep-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 with the aid of which a set of patches can be applied to an existing XML document. "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, 16-Sep-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: DKIM. "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. "Collected extensions to IMAP4 ABNF", Cyrus Daboo, Alexey Melnikov, 18-Jan-06, 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 also suggest a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions. This document updates ABNF in RFC 3501, RFC 2342, RFC 2088, RFC 3502 and RFC 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. "IP Fast Reroute Using Not-via Addresses", Stewart Bryant, 3-Mar-06, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" 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. "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. "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, 25-Oct-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, 17-Nov-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. "Firewall Traversal for Mobile IPv6", Yang Shen, 7-Dec-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. This internet draft intends to show some ideas to solve the problems on mobile IPv6 firewall traversal. The solutions proposed are not an overall solution to fix all the traversal problems. "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 IP Handover Support", Seok Koh, 6-Oct-05, This document discusses how to use of SCTP for IP handover support. With the help of the dynamic address reconfiguration, the SCTP with the ADDIP extension (called mSCTP) would provide soft handover for the mobile terminals without any additional support of routers/agents in the networks. For location management, the mSCTP could be used along with Mobile IP, Session Initiation Protocol or Reliable Server Pooling. We also discuss the use of mSCTP along with Mobile IP for Internet mobility support. "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. "The Atom Publishing Protocol (Basic)", Robert Sayre, 25-Jan-06, This memo presents a protocol that uses XML and HTTP to publish and edit Web resources. "A Description of the Rabbit Stream Cipher Algorithm", Erik Zenner, 28-Nov-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. "Extensions of Session Description Protocol (SDP) for Seamless Session Mobility", Xu Mingqiang, 26-Oct-05, Session mobility allows a user to transfer an ongoing communication session from one device to another device. Seamless session mobility is important for real time multimedia applications. This document describes requirements for seamless session mobility, which will guide development of seamless session transfer mechanisms and associated Session Description Protocol (SDP) extensions. "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. "COSINE LDAP/X.500 Schema", Kurt Zeilenga, 7-Feb-06, 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 updates RFC 2247 and RFC 2798. "SCTP NAT Traversal Considerations", Qiaobing Xie, 25-Oct-05, This document defines and classifies scenarios for the usage of SCTP in networks with NATs and similar middleboxes. "Diameter/RADIUS Vendor Specific AVP Translation", David Mitton, 13-Feb-06, 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, 11-Oct-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. RFC3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. "Enhancements to RTP Format for EVRC Family Codecs", Rohit Kapoor, Qiaobing Xie, 26-Sep-05, This document defines several enhancements and extensions to RFC3558 EVRC RTP payload format. In particular, it defines the support for a compact bundled format and EVRC-B codec, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B encoded speech transported via RTP sessions. Some VoIP applications, such as Push- to-Talk and VoIP over low bandwidth dial-up and wireless networks, require such enhancements for efficient use of the bandwidth. "TLS support in ITOT", Alexey Melnikov, 20-Jan-06, 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. "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)", Steven Legg, 14-Nov-05, Abstract Syntax Notation X (ASN.X) is 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 XML Encoding Rules (XER). "ECP Groups For IKE and IKEv2", Jerome Solinas, David Fu, 20-Oct-05, This document describes new ECC groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols 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 and IKEv2 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. "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. "MPLS Upstream Label Assignment and Context Specific Label Space", Rahul Aggarwal, 26-Oct-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". "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, 21-Oct-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. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point traversal scenario described in NATCONS [1]. Furthermore both algorithms are compared. "Receiver-Driven Extensions to SMTP", Zhenhai Duan, 3-Jan-06, 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. "Support of LDP Multicast Label Switched Paths over Point-to-Multipoint Label Switched Path Tunnels and on Multi-Access Links", Seisho Yasukawa, Adrian Farrel, 25-Oct-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 LDP traffic across a provider network within P2MP MPLS tunnels, and introduces solution models that meet those requirements. Note that the requirements and solutions discussed in this document are also applicable to the use of multicast LDP on multi-access networks. "IPv6 Multicast Filtering Rules", Arun Thulasi, 9-Dec-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. "NSIS Flow ID and packet classification issues", Hong Cheng, 26-Oct-05, In current NSIS signaling, there are two main functions depending on Flow ID, i.e. signaling message routing, data packet classification. Specifically, the same information carried by the MRI is also used to derive the packet classification at NSLP layer. This arrangement assumes that identical information is required by the two functions at two different layers, and thus has limitations. With the introduction of NSIS applications in more complicated scenarios, such assumption can no longer hold. Therefore, keeping the dependency between the two functions hinders the development of NSIS. Efforts have been made in different NSLP layer applications to extend the relationship, e.g. QoS NSLP. This draft studied the possibility of disjoining the information for the two functions. Problems faced by the current system and different remedy options are discussed. With these details, it is intended to help the reader to evaluate the feasibility of redefining the packet classification information signaling in NSIS. "An IRIS schema for Emergency Service contact URIs", Ted Hardie, 26-Oct-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. "NSIS Extensibility Model", John Loughney, 9-Mar-06, 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. This document will serve as guidence on how the NSIS architecture can be extended. "3GPP QoS Model for Networks Using 3GPP QoS Classes", Seong-Ho Jeong, 27-Oct-05, This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS classes and bearer service attributes. Specifically, this draft describes additional optional parameters for QSPEC which carries 3GPP QOSM specific information and how the QSPEC information should be processed in QNEs. "A Problem Statement for Partly-Decoupled Signalling in NSIS", Robert Hancock, 8-Mar-06, The NSIS working group is currently developing a protocol suite for signalling which manipulates network state related to data flows. The protocol design 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 a particular deployment mode for GIST (the common lower layer of the NSIS protocol suite) which relaxes this constraint, allowing the signalling and data paths to be partially decoupled, without sacrificing the integration with routing (e.g. sensitivity to route changes) which is intrinsic to the path-coupled case. "The AES-CMAC-96 Algorithm and its use with IPsec", Junhyuk Song, 7-Feb-06, 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. "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-Sep-05, This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a 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", Roland Jesske, 6-Oct-05, This document describes a set of requirements to the Session Initiation Protocol (SIP) [2] 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", Jicheol Lee, 12-Dec-05, National Institute of Standards and Technology (NIST) has newly specified the Cipher-based Message Authentication Code (CMAC) which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies the authentication algorithm based on CMAC with 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. "TCP SYN Flooding Attacks and Common Mitigations", Wesley Eddy, 8-Dec-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 and users may better evaluate them. "CAPWAP Handover Protocol (CAPWAPHP)", Behcet Sarikaya, 2-Mar-06, 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 Termination Points (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 handles local MAC and Split MAC with separate procedures. CAPWAPHP can be transported using CAPWAP protocol. "Multicast in Virtual Router-based IP VPNs", Hong-Ke Zhang, 20-Oct-05, This document specifies the procedures required to be implemented for IP multicast traffic to travel from one VPN site to another within a Virtual Router-based IP VPN [VR-VPN]. It details the solution according to process in local customer sites and in SP backbone networks. 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 that have been implemented and deployed. "The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", Junhyuk Song, 6-Feb-06, 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. "NAT Behavioral Requirements for Unicast TCP", Saikat Guha, 24-Feb-06, This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. "The AS_HOPCOUNT Path Attribute", Tony Li, 3-Oct-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, 3-Mar-06, 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 Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", David McGrew, John Viega, 10-Mar-06, This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). 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. "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 1-Dec-05, This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). "Automatic configuration of IPv6 addresses for MANET with multiple gateways", Simone Ruffino, Patrick Stupar, 9-Mar-06, This document describes a mechanism for stateless autoconfiguration of IPv6 addresses for Mobile Ad-hoc Networks (MANETs), connected to the Internet by means of one or more gateways. Network prefixes are disseminated by Internet gateways and are used by nodes to configure a set of global IPv6 addresses. An algorithm is specified, by which nodes can choose the optimal address for data traffic. Configured global addresses are also advertised to other MANET nodes, to minimize latencies in case of gateway failures, partitions and mergers. The specified mechanism aims to be independent from any particular MANET routing protocol and to effectively exploit multiple gateways. "Distributing Default Address Selection Policy using DHCPv6", Tomohiro Fujisaki, 2-Dec-05, This document describes a new DHCPv6 option for distributing default address selection policy information to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior. "Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand, 1-Mar-06, 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, 6-Mar-06, This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is 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 examples of networks where the Delay-Tolerant Network architecture[1] is applicable. The document presents an architectural overview followed by the protocol specification. "Object-based pNFS Operations", Jim Zelenka, 26-Oct-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-ietf-nfsv4-pnfs-00.txt "Guidance for AAA Key Management", Russ Housley, Bernard Aboba, 8-Nov-05, This document provides guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include 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 IETF RFCs, as well as to use of AAA key management by any other standards development organizations (SDOs). "US Secure Hash Algorithms (SHA and HMAC-SHA)", Donald Eastlake 3rd, Tony Hansen, 30-Jan-06, 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 open source 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 input strings of arbitrary length. Most of the text herein was adapted by the authors from FIPS 180-2. Code to perform SHA based HMACs is also included. "pNFS Block/Volume Layout", David Black, Stephen Fridella, 24-Oct-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, 24-Feb-06, This document describes work in progress in the MFA Forum on ATM and Frame Relay to MPLS Control Plane Interworking. Two specifications are being defined, one for client-server 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 client-server 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 "Expert Review" range are requested. The need for these codepoints and proposed usage is described. "DHCP Option for CLF/NASS", Li Jun, 17-Oct-05, This document defines a new dhcp option for Access Network Information discovery. The network terminal can get the Access Network Information,which it is attached, through this option. And the Access Network Information can be used for different purpose, such as in TISPAN NGN network the Access Network Information can be used to discover the CLF(Connectivity Session Location and Repository Function) of the NASS (Network Attachment Subsystem).This document defines the related dhcp option and option codes. "Centralized Conferencing (XCON) Using the Message Session Relay Protocol (MSRP)", Chris Boulton, Mary Barnes, 23-Sep-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, 26-Oct-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. This document describes the message formats, while a companion document describes the overall system architecture. "Mobile IPv6 Multicast with Dynamic Multicast Agent", Hong-Ke Zhang, 13-Sep-05, This document addresses the problem of delivering IPv6 multicast traffic to MNs (Mobile Nodes). An approach named Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed. The approach is a combination of Movement Based Method [2] and Distance Based Method [3]. Such a design allows MNs to optimize multicast routes, and meanwhile reduces 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 without the restriction on network topologies. "Use of IPFIX for Export of Per-Packet Information", Elisa Boschi, Lutz Mark, 27-Oct-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. "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, 26-Jan-06, 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. "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, 7-Mar-06, This document describes a private Session Initiation Protocol(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, 14-Sep-05, This document defines the semantics that allows for grouping of forward error correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document is to be used with Grouping of Media Lines in the Session Description Protocol (RFC 3388) to group together "m" lines in the same session. "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, 15-Sep-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. "Using non-ASCII Characters in RFCs", Paul Hoffman, 2-Dec-05, This document specifies a change to the IETF process in which RFCs are allowed to have non-ASCII characters. The proposed change is to change the encoding of RFCs to UTF-8. "H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths", Doug Leith, Robert Shorten, 20-Dec-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 Incremental Syndication", Mark Nottingham, 28-Feb-06, This specification describes a technique for feed publishers to give hints about the completeness of a feed, and a means of retrieving "missed" entries from a incremental feed. "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. "Use of the SIP Preconditions Framework for Media Privacy", Ron Shacham, 23-Nov-05, Recording of a conversation presents a possible breach of privacy. This document presents a use of the SIP Preconditions Framework to negotiate the recording guidelines for the session. One party may assert either their desire to record or their restriction of the other party's recording. In order to establish the session, the other party must respond that it agrees to the conditions. While this does not have the power to limit the physical recording by the user on the end system, it provides evidence of the expressed wishes of one party and the agreement of the other. "Requirements for a Handover Information Service", Stefano Faccin, 8-Mar-06, Handover Information Services may be used to assist handovers between one network to another network or within a network, based on stored network knowledge. Information Services can be used to provide essential network related information e.g. topology and channel information which may allow a moving host to select an appropriate link-layer connection to make, amongst available networks, whether using the same technology or heterogeneous technologies. This document is an effort to describe use cases and transport requirements for handover information services, when they are transported over IP networks. "Media-Independent Pre-Authentication (MPA) Implementation Results", Yoshihiro Ohba, 6-Mar-06, 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. "An Anonymity and Unlinkability Extension for OMIPv6", Wassim Haddad, 7-Mar-06, The "Optimized Mobile IPv6 with CBA" (OMIPv6) protocol specifies a new route optimization (RO) mechanism, which offers better security, less signaling messages and reduces the handoff latency. This document describes a new extension to be added to the OMIPv6 protocol in order to provide the anonymity and the unlinkability aspects at the IP layer. "Handover Keys Using AAA", Vidya Narayanan, 24-Oct-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 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. The protocol is loosely based on the Mobile IP-AAA model [11] where the MN-HA security association is derived using a AAA server. "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. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2-Feb-06, 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. "Local HA to HA protocol", Vijay Devarapalli, 6-Mar-06, 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. "RADIUS Attributes for WLAN", Bernard Aboba, 8-Mar-06, Although AAA support is optional within IEEE 802.11, it is expected that many IEEE 802.11 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. "ASBR VRF context for BGP/MPLS IP VPN", Marko Kulmala, 7-Feb-06, This document describes an additional option to the 'Multi-AS Backbones' section of [RFC4364]. This option combines per VPN VRFs at the Autonomous System Border Router (ASBR) as described in 'Option A' with the redistribution of labeled VPN-IPv4 routes as described in 'Option B'. In addition, this option allows for a data plane consisting of two methods of traffic forwarding between attached ASBR pairs. In this Multi-AS option, the ASBR installs VPN-IPv4 routes into VRFs in the same manner as described in [RFC4364] e.g. VPN-IPv4 routes are converted back to IPv4 routes and imported into VRFs via Route Target (RT) based filtering policies. Once installed in a VRF, selected IPv4 routes are converted to VPN-IPv4 routes by the addition of Route Distinguisher (RD) values, along with one or more associated RTs as configured per VRF at the ASBR. Dependant on service provider preference, traffic forwarding between attached ASBRs is either via per VRF attachment circuits or a 'global' (non-VRF attachment circuit associated) IP interface. In both traffic forwarding cases, packets may be MPLS-labeled or non-labeled. If attached ASBR pairs belonging to separate Autonomous Systems (AS) make use of this Multi-AS option, then VRF based route filtering policies via RTs is achieved directly between ASBR pairs, independent of PE based RT filtering within an AS. "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)", Steven Legg, 11-Nov-05, Abstract Syntax Notation X (ASN.X) is 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). "Requirements for IPsec Negotiation in the SIP Framework", Makoto Saito, Shingo Fujimoto, 10-Mar-06, As the Internet grows, it becomes inevitable even for the general users to take measures against the security risks such as tapping, unauthorized access, and so on. For example, we can consider the use case of networked home appliances which cannot have the rich calculation resources and may use the dedicated transport protocol for the media session. In such a case, it is effective to connect such devices securely using IPsec [1] because it does not require the rich resources, and is independent of the upper layer protocol. Also from the viewpoint of implementation, IPsec is not only widespread in IPv4, but also mandatory in IPv6 which is expected in the networked home appliances region(this use case is just the one of examples, and this document does not focus only on home appliances but also on the general applications which use the dedicated media protocols, where IPsec is suitable as the security protocol). "Synchronisation of Loop Free Timer Values", Stewart Bryant, 6-Mar-06, 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, 24-Oct-05, This document describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service usage (e.g. DNS). "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, 12-Oct-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. "Encoding Instructions for the Generic String Encoding Rules (GSER)", Steven Legg, 26-Oct-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. "TCP and UDP based ForCES Protocol TML over IP Networks", Weiming Wang, 3-Mar-06, This document defines ForCES Transport Mapping Layer (TML) over IP networks, the framework and the specifications to meet the ForCES TML requirements. "Entire Route Reflect capability", Renhai Zhang, 24-Feb-06, 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. "TTL Partition Security Mechanism", Miao Fuyou, 26-Sep-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. "Failover for Multiple Mobile Routers in a Mobile Network", Jiho Ryu, 8-Mar-06, This draft proposed the use of multiple mobile routers in a single NEMO. A failed mobile router is taken over 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, 19-Sep-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, 23-Feb-06, 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 mechanism can also be used in the case of link-state change of a set of links attached to one common node, e.g. a linecard removal. The solution can also be used in conjunction with a FRR mechanism which turns a sudden link failure into a non-urgent change, by ensuring a local protection of the link, if protection is ensured for all the prefixes that are reached via this link. After a non-urgent topology change, each router 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, 9-Mar-06, This memo describes a framework for the Host Identity Protocol that provides location privacy and mobility to end hosts. It discusses the introduction of a new functional entity that prevents HIP enabled nodes from revealing their location. "The Use of TESLA in the ALC and NORM Protocols", Sebastien Faurite, 27-Feb-06, This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. This document only considers the authentication/integrity of the packets generated by the session's sender. "IPFIX templates for common ISP usages", Emile Stephan, Eric Moreau, 21-Oct-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, 24-Oct-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 bandwidth, flow priority values, etc. to user plane network elements. "Combined User and Carrier ENUM in the e164.arpa tree", Michael Haberler, Richard Stastny, 8-Mar-06, ENUM as defined in RFC3761 [1] 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. "LDP extensions for Inter-Area LSP", Bruno Decraene, 24-Oct-05, To facilitate the establishment of Label Switched Paths (LSP) that would span multiple IGP areas in a given Autonomous System (AS), 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. "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, 8-Mar-06, 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. "Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris Cross, 7-Feb-06, 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. "Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)", Vijay Gurbani, 9-Feb-06, This informational document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the IPv6 portions of a SIP implementation. This work is being discussed on the sipping@ietf.org mailing list. "The RC4-HMAC Kerberos encryption type", Karthik Jaganathan, 3-Mar-06, 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. "Common RADIUS Implementation Issues and Suggested Fixes", David Nelson, 15-Feb-06, 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, 25-Oct-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, 7-Mar-06, 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. "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", Jean-Louis Le Roux, 21-Feb-06, 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. "6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)", Soohong Park, 6-Mar-06, 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. "Session Initiation Protocol Exceptional Procedure Examples", Miki Hasebe, 4-Mar-06, This document gives examples of Session Initiation Protocol (SIP) call flows in race condition. Call flows in race conditions are confusing and this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxies. Call flow diagrams and message details are shown. "Extensions to the OSPF Management Information Base in support of GMPLS", Tomohiro Otani, 6-Mar-06, This memo defines the Management Information Base (MIB) objects in order to manage OSPF routing information with extension in support of Multi-protocol label switching (MPLS) as well as Generalized MPLS (GMPLS) for use with network management protocols. "Rationale for Location by Reference", James Winterbottom, 30-Jan-06, An analysis is performed on the advantages and disadvantages for provision of Location Information (LI) by-reference in the GEOPRIV architecture. The concept of a Location URI, that is, a URI that references LI, is introduced. A number of usage patterns for Location URIs are discussed, particularly with regard to addressing mobility. Security concerns that are introduced by Location URIs are also considered. "DomainKeys Identified Mail (DKIM)", Eric Allman, 26-Oct-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 Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting 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, 26-Oct-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- DKIM-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, 2-Mar-06, 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 acquisition 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. "Inter-domain Data Exchange Questionnaire", Elisa Boschi, 27-Oct-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 ISP community itself. "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", Matthew Bocci, Stewart Bryant, 17-Oct-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. "Response Authentication in Session Initiation Protocol", Feng Cao, 10-Jan-06, This draft describes some extensions for enhancing SIP response authentication. In the real-world SIP deployment, TLS may be not available on some hops. Due to the lack of other response authentication mechanisms in SIP, several kinds of security attacks could be conducted on those hops through SIP response. This draft suggests some approaches for complementary enhancement on SIP response authentication. With the new per-hop response authentication proposed in this draft, the security gaps on the hops without TLS can be bridged. "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers", Bill Fenner, 23-Jan-06, 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. "Benchmarking Terminology for Protection Performance", Scott Poretsky, 10-Feb-06, 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, 9-Mar-06, At the 65th Dallas IETF Meeting it is anticipated that the Real-time Applications and Infrastructure Area will meet for the first time and its work program will be an item for discussion. This Internet Draft has been prepared to share the relevant portions of the PTSC current work program with the IETF. It is hoped that awareness of the Packet Technologies Systems Committee (PTSC) work program will allow for more informed discussion. "NSIS Operation Over IP Tunnels", Charles Shen, 8-Mar-06, This draft presents an NSIS operation over IP tunnels scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated reservation modes are discussed. The scheme proposes the use of separate signaling sessions inside the tunnel for the end-to-end sessions. Packets belonging to qualified tunnel sessions are assigned special flow IDs to be distinguished from the rest of the tunnel traffic. The end-to-end session and its corresponding tunnel session are associated with each other when necessary; so that adjustment in one session may be reflected in the other. "Composing Presence Information", Henning Schulzrinne, 7-Mar-06, Composition creates a presence document from multiple components published by one or more sources. This document identifies sources of information that a composer might draw upon and describes steps for composition. 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. We present an XML format for specifying a composition policy, based on our discussion. "RADIUS Quality of Service Support", Hannes Tschofenig, 25-Oct-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, 26-Oct-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, 4-Mar-06, This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.16e suite of specifications. "Spatial Composition of Metrics", Emile Stephan, Al Morton, 25-Oct-05, This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The current version of the memo gives some background and proposes wording for a Scope and Application section to define this new work. The description of several example metrics and statistics follow. "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", Vijay Devarapalli, Pasi Eronen, 20-Oct-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, 9-Mar-06, RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted those recommendations in 2002 and they have been in effect ever since. This document revisits and updates the IAB/IESG recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is a policy issue under the purview of the RIRs, subject to IPv6 architectural considerations. This document reviews those architectural considerations and reiterates that changing the /48 recommendation is one of policy, and has minimal impact on the IPv6 architecture and on IETF Standards. This document obsoletes RFC 3177 and reclassifies it as historic. "Mobile IPv6 Bootstrapping using Diameter", Hannes Tschofenig, 25-Oct-05, Both Mobile IPv6 bootstrapping solutions require use of a AAA interface. In the split scenario, this interface is between the Home Agent and the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA). The first interface should meet a list of requirements. This document provides an overview of the capabilities and design of the Diameter protocol that could meet the specified goals. In the integrated scenario, in addition to this interface, the impact of the MIPv6 bootstrapping on the AAA interface for network access authentication must be considered. Basically, this interface is also used to carry Home Agent information. This document defines the necessary AVP and how Diameter can be used in the integrated scenario. "Construction of the Route Header Field in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 9-Mar-06, The Route header field in the Session Initiation Protocol (SIP) is used to cause a request to visit a set of hops on its way towards the final destination. Several specifications have defined rules for how a user agent obtains and then uses a set of Route header fields in the transmission of a request. These include the SIP specification itself, the Service-Route header field specification, the SIP server option in the Dynamic Host Configuration Protocol (DHCP), and others. Unfortunately, these specifications are not consistent and the resulting behavior at clients and servers is not clear or complete. This document resolves this problem by defining a consistent set of logic. "Security Considerations for Softwire", Shu Yamamoto, 9-Mar-06, This document discusses the security requirements of softwire. Authentication, integrity and confidentiality of the softwire control and data packets are discussed. Both hub and spokes and mesh solutions are discussed. "GIST NAT Traversal", Andreas Pashalidis, Hannes Tschofenig, 8-Mar-06, This document describes a number of mechanisms for the implementation of the General Internet Signalling Transport (GIST) protocol [1] on different types of Network Address Translator (NAT). The focus of these mechanisms is the interaction of GIST with the address translation function of the NAT, and their purpose is to enable GIST hosts that are located on either side of the NAT to correctly interpret signalling messages with respect to the data traffic they refer to. The purpose of this document is to provide guidance to people that implement GIST and NSLPs on both NAT and non-NAT nodes. "Reporting Schema for NetConf Protocol", Sandeep Adwankar, Sharon Chisholm, 21-Oct-05, This memo defines XML Schema for reporting information about the NetConf system. "IETF Meeting Venue Selection Criteria", Jordi Palet, 18-Jan-06, This document provides the IAD with technical and logistic criteria for selecting venues for IETF meetings. "Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6", Jari Arkko, 8-Mar-06, This memo suggests a new and enhanced route optimization security mechanism for Mobile IPv6. 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 most of the per-movement signaling can be done when payload traffic flow has already been moved. "Netconf Event Messages", Sharon Chisholm, 27-Oct-05, This memo defines a framework for sending asynchronous messages, or event messages in Netconf. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to application protocols. "Adjacency Reduction in OSPF using SPT Reachability", Abhay Roy, 28-Nov-05, There is significant overhead in OSPF when a router has to establish adjacencies with every peer with whom it can verify 2-way connectivity. OSPF supports the broadcast network type for these scenarios, where you only have to peer with the designated router (DR). However,a full mesh of connectivity is required for proper operation and this doesn't help in networks with overlapping partial meshes of connectivity. This draft proposes a technique to reduce the number of adjacencies based on shortest path tree (SPT) reachability information. "Extensions to OSPFv2 for Advertising Optional Route/Link Attributes", Sina Mirtorabi, 6-Mar-06, There are applications which require additional attributes to be advertised with an OSPF link or route. The existing OSPF LSA formats do not allow for backward compatible extension to advertise these attributes. This draft proposes an extension to OSPF for advertising additional attributes which will be associated with a link or route. It also introduces the support of administrative tags for any link type in the router-LSA and any route in summary-LSAs, NSSA-LSAs, or AS-external-LSAs. "SIP Identity Usage in Enterprise Scenarios", Steffen Fries, Hannes Tschofenig, 23-Feb-06, This document describes a use case for the SIP Identity document involving certificate management with the focus on enterprise environments. It provides a best current practice document for binding an identity to a certificate for the duration of a session. The certificate may then be used to bootstrap further security parameters, e.g., for securing media data. A discussion of possible enhancements is included in the appendix. "IMAP CREATE/RENAME parameters", Alexey Melnikov, 22-Sep-05, When creating (or renaming) a mailbox in [IMAP4] it is desirable to be able to specify additional creation time parameters that can't be changed after the mailbox is created. Some examples of the creation time parameters are: mailbox type, mailbox location on a server or a cluster of servers, mailbox flag state. This document extends IMAP CREATE and RENAME commands to allow for such parameters. A server which supports this extension indicates this with a capability name of "X-DRAFT-I01-CREATEPARAM". "Using SRTP transport format with HIP", Hannes Tschofenig, 25-Oct-05, The Host Identity Protocol (HIP) is a signaling protocol which adds a new layer between the traditional Transport and Network layer. HIP is an end-to-end authentication and key exchange protocol, which supports security and mobility in a commendable manner. The HIP base specification is genralized and purported to support different key exchange mechanisms in order to provide confidentiality protection for the subsequent data traffic. In some cases it might not be desirable to establish IPsec security associations for protection of media traffic. This draft explains how keying material and parameters for usage with the Secure Real Time Protocol (SRTP) can be established using HIP. "Trust Path Discovery", Kumiko Ono, Henning Schulzrinne, 27-Oct-05, Chained or transitive trust can be used to determine whether incoming communication is likely to be desirable or not. We can build a chained trust relationship by introducing friends to out friends, for example. We propose mechanisms for discovering trust paths and binary responsive trustworthiness. The trust paths are based on a chain of trust relationships between users, a user and a domain, and domains. We apply this model to relatively low-value trust establishment, suitable for deciding whether to accept communication requests such as emails, calls, or instant messages from strangers. "Route Optimization and Location Privacy using Tunneling Agents (ROTA)", Kilian Weniger, Takashi Aramaki, 21-Oct-05, Mobile IPv6 in route optimization mode reveals mobile node's care-of address to the correspondent node and hence cannot provide location privacy. In contrast, Mobile IPv6 in bi-directional tunneling mode can provide location privacy, but the resulting route may be far from optimal, especially when correspondent node is mobile as well. This may be an issue for conversational mobile-to-mobile communication scenarios, e.g., using VoIP. The draft discusses the problem of providing both location privacy and route optimization with Mobile IPv6 and describes a solution in terms of an optional extension to Mobile IPv6. The basic idea is that mobile nodes switch the reverse tunnel endpoint in bi-directional tunneling mode from their home agent to a so-called tunneling agent in an on-demand manner. To ensure location privacy, the tunneling agent selection is done by the home agents. The solution does not require the mobile node to change its home address and does not rely on visited network support. "Secure SCTP", Carsten Hohendorf, 3-Feb-06, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC2960, it is designed to integrate cryptographic functions into SCTP. "Pre-Congestion Notification marking", Bob Briscoe, 8-Mar-06, Pre-Congestion Notification (PCN) builds on the concepts of RFC 3168, "The addition of Explicit Congestion Notification to IP". However, Pre-Congestion Notification aims at providing notification before any congestion actually occurs. Pre-Congestion Notification is applied to real-time flows (such as voice, video and multimedia streaming) in DiffServ networks. As described in [CL-ARCH], it enables "pre" congestion control through two procedures, flow admission control and flow pre-emption. The draft proposes algorithms that determine when a PCN-enabled router writes Admission Marking and Pre-emption Marking in a packet header, depending on the traffic level. The draft also proposes how to encode these markings. We present simulation results with PCN working in an edge-to-edge scenario using the marking algorithms described. Other marking algorithms will be investigated in the future. "A Framework for Admission Control over DiffServ using Pre-Congestion Notification", Bob Briscoe, 8-Mar-06, This document describes a framework to achieve an end-to-end Controlled Load (CL) service without the scalability problems of previous approaches. Flow admission control and if necessary flow pre-emption preserve the CL service to admitted flows. But interior routers within a large DiffServ-based region of the Internet do not require flow state or signalling. They only have to give early warning of their own congestion by bulk packet marking using new pre- congestion notification marking. Gateways around the edges of the region convert measurements of this packet granularity marking into admission control and pre-emption functions at flow granularity. "A Single-Stage Standards Process", John Loughney, Spencer Dawkins, 6-Mar-06, This document proposes several changes of principle to the Internet standards process, specifically a reduction from three stages to a single stage in the standards track. This does not effect the Informational, Experimental or BCP designations. "Design Guidelines for RADIUS Attributes", Greg Weber, 7-Mar-06, This memo explores various issues related to the data model used by the Remote Authentication Dial In User Service (RADIUS) protocol. Recommendations are made to facilitate internal alignment and uniformity. Attribute design guidelines are also provided. "An Extensible Authentication Protocol (EAP) Enrollment Method", Rohan Mahy, 7-Mar-06, This document introduces a new EAP Method intended to automatically enroll clients with minimal user interaction in a wireless LAN environment. The enrollment process involves the client providing weak possibly temporary credentials and the server providing stronger persistent credentials, both stages over a TLS-protected channel. "Experience with the General Area Review Team", Avri Doria, 26-Oct-05, The General Area Review team has been doing Late Reviews of Internet Drafts since 2004. This draft discusses the experience and the lessons learned in the first 18 months of this process. "Codec Control Messages in the Audio-Visual Profile with Feedback (AVPF)", Stephan Wenger, 8-Mar-06, This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are Full Intra Request, Temporary Maximum Media Bit-rate and Temporal Spatial Trade-off. "Requirements for Pseudo Wires carrying Timing and Synchronization", Tim Frost, 10-Mar-06, This document describes the requirements for the transmission of network timing and synchronization across packet-switched networks using pseudo-wires. Such services enable the function of real-time, synchronous applications across the asynchronous packet switched network. In particular, it complements the emulation of TDM bit streams over the packet switched network. "Gateway Selection in Multi-homed Ad Hoc Networks", Kaouthar Sethom, 10-Jan-06, When an ad hoc network is connected to the Internet, it is important for the mobile nodes to detect available gateways providing access to the Internet. Therefore, a gateway discovery and selection mechanism is required. Current ad hoc routing protocols have been extended to support gateway discovery. However, the selection process is based on the default gateway configuration. We here describe an extension to MANET protocols to enable the gateway selection according to users’ requirements, especially in the case where multiple gateways co- exist. "A Congestion Status Precondition for the Session Initiation Protocol (SIP)", Corey Alexander, John Rutledge, 25-Oct-05, This document defines the Congestion Status precondition for SIP, utilizing the framework defined in RFC 3312 and updated in RFC 4032. The Congestion Status precondition requires that the participant verify that congestion thresholds along the network path for the session media have not been exceeded before continuing with session establishment or modification. This verification is performed via an RTP probe utilizing draft "Congestion Notification Process for Real- Time Traffic" and draft "RTP Payload Format for ECN Probing". "LDELIVER", Stephane Maes, 27-Sep-05, This draft introduces LDELIVER and LCOMPOSE as a LEMONADE extensions to the IMAPv4 Rev1 protocol [RFC3501] to enable sending email as an IMAP command. It provides simple ways to provide reply and forward without download with a gateway to the email and submit servers as well we as support to send only edit differences to the server. It is complementary to the trio BURL/URLAUTH/CATENATE described in [LEMONADEPROFILE]. "LZIP", Stephane Maes, 26-Sep-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. LZIP provides an extension to allow compression of the exchanged messages to and from the mobile client. "Dynamic router selection", Kaouthar Sethom, 10-Jan-06, In a network topology where the host has multiple routers on its Default Router List, it is important to select the most suitable one according to node’s application requirements. This document describes an extension to router advertisement message [RFC 1256, RFC 2461] for dynamic router selection. This new functionality is implemented in routers with additional capabilities. "Piggybacking Key Material with Security Encapsulated Data: Inband Key Updates", Lakshminath Dondeti, 26-Oct-05, IPsec and SRTP use out-of-band key management. Synchronization of group security associations is an issue when out-of-band key management protocols are used. In case of rapid or unplanned rekeying, some members may not receive the key updates in time to decrypt the IPsec or SRTP traffic. To address that problem, this document describes a strawman proposal to carry group key updates as part of IPsec and SRTP. "Data Types for Netconf Data Models", Dan Romascanu, 21-Oct-05, This memo defines initial set of reusable NetConf data types. "Session Initiation Protocol Event Packages for Calendaring", Aki Niemi, 8-Mar-06, Calendar sharing and scheduling enable a user to subscribe to receiving calendar information from other users' calendars as well as scheduling of various calendar events among a set of users. This memo defines Session Initiation Protocol (SIP) event packages for calendar sharing and scheduling. "L3Shim state management using Vertical layered Communication", Taewan You, 27-Oct-05, This draft proposed vertical layered communication method; especially it is mechanism to notify locator changing from L3Shim to TCP layer. In this draft, it is called indirect TCP congestion control. This mechanism make TCP congestion situation using behavior of L3Shim layer without correcting conventional TCP. And then we describe L3Shim state through the event. These kinds of events and progress state are presented in a single system view. And it will be help to implement L3Shim functionality through understanding L3Shim process. "Flushing Mechanism to Notify Binding Update in MIPv6", Jaehwoon Lee, Sanghyun Ahn, 21-Oct-05, The Mobile IPv6 (MIPv6) is a protocol that allows a mobile node (MN) to maintain connectivity with a correspondent node (CN) via the Internet while changing its point of attachment. In MIPv6, a MN cannot know which packet is the last packet with the previous CoA (PCoA) as the destination address. In this draft, we define the format and the usage of the Flush message, in order for the MN to know the last packet with the PCoA as the destination address sent by the home agent (HA) and/or a CN. "Another Aspects of Address Selection in Multi6", Indong Jang, 27-Oct-05, The address selection mechanisms have been suggested under the circumstance occurring link failure already. But this draft proposes various considerations to address selection such as load sharing without presenting address selection mechanism clearly. The goal of this document is merely referred various situation that have to consider when we make out address selection mechanism in the context of load sharing. "AII Types for Aggregation", Chris Metz, 21-Oct-05, [PWE3 Control] defines the signaling mechanisms for establishing point-to-point pseudowires between two provider edge (PE) nodes. The Generalized ID FEC element contained in PWE3 signaling protocols include TLV fields that identify pseudowire endpoints called attachment individual identifiers (AII). This document defines an AII structure in the form of new AII type-length-value fields that supports AII aggregation for improved scalability. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote PE nodes based on customer need. "SMTP Service Extension for Priority Message Handling", Michael Schmeing, Jan-Wilhelm Brendecke, 6-Mar-06, This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are sent with a priority to achieve a certain order in which the messages are transferred by an MTA (Message Transfer Agent). This priority or precedence order is used instead of the first-come-first-serve rule. This extension is not to be confused with "Importance of a Message" which is widely deployed using an email header such as Importance or even Priority or Precedence with common values of HIGH, NORMAL and LOW. Importance of a Message does not affect the priority of the transport itself in any way. Nevertheless, there may be policy defined relations between priorities and importance indicators. This extension uses the term priority in the meaning of expedited treatment of a message by the server according to its priority. "BGP Anycast Node for Authotitative Name Server Requirements", Yasuhiro Morishita, 24-Jan-06, IP anycast [1] is a technology to share an IP address of an Internet service with multiple servers. It is now being deployed for the authoritative name servers, especially for the root servers. RFC 3258 [2] describes a set of practices to provide IP anycast technology for the authoritative name servers. And "Operation of Anycast Services" Internet-Draft [3] (hereafter, called "Abley's Draft") describes a series of recommendations for distribution of services using anycast. Operators of authoritative name servers can also refer to RFC 2182 [4] and 2870 [5] for general guidances on appropriate practices for authoritative name servers. This memo describes the details of requirements and preconditions for making authoritative name servers in IP anycast technology, with the consideration of the practices in RFC 2182, 2870, 3258 and Abley's Draft. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 8-Mar-06, This memo describes a batch of Presence Information Data Format (PIDF) and its extension schemas written with the RELAX NG schema language. Unlike with the current W3C XML Schema language it is possible to write reasonable forwards and backwards compatible presence combination schemas. These RELAX NG schemas are stricter than the W3C Schemas and thus the instance documents that validate with these schemas follow the intended content model more closely. Especially, these schemas are targeted to actual implementations in order to decrease interoperability problems. "L2tp Proxy Authenticate Extensions for EAP", Manesh Kelkar, 28-Nov-05, L2TP [1] defines Proxy Authentication AVPs that MAY be exchanged during session establishment, to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation. This document defines contents of this PPP authenticate information for the Extensible Authentication Protocol (EAP). "XML structure for Set of RFC Descriptors", John Leslie, Douglas Otis, 12-Oct-05, This document introduces a new document series called Set of RFC Documents (SRDs). SRDs will be distinguished by names and serial numbers. SRDs contain Extensible Markup Language (XML) which can automatically produce HTML and plaintext versions for human consumption With many RFC being updated, this creates difficulty when determining which RFCs are necessary as references when implementing or using protocols. Grouping RFC into sets that embody a specific endeavour would permit stable references for those interested in discovering related details. The SRD name may also serve as a reference for topical information stored in a database that is made available. "Trust Anchor Key Renewal Method Applied to X.509 Self-signed Certificates (TAKREM-X.509)", Thierry Moreau, 9-Sep-05, In the Internet PKI, trust anchor keys are distributed as self- signed X.509 security certificates. This document specifies a trust anchor key renewal mechanism that leverages the confidence in the initial certificate distribution. A non-critical X.509 certificate extension holds a sequence of opaque octet strings. The trust anchor renewal operation occurs upon receipt of a message that hashes to one of those octet strings. "A Design Rationale for Providing IP Services Over DVB-S2 Links", Juan Cantillo, 29-Nov-05, This document describes a framework for the transmission of IP datagrams over DVB-S2, the second generation standard for Digital Video Broadcasting over Satellite. The new standard features an improved and adaptive physical layer, as well as a new framing structure at link level, the Generic Streams. Combined use of adaptability and Generic Streams is expected to offer throughputs never achieved for IP services up to now, but no standard way to carry IP data using the specific features of DVB-S2 has been defined yet. The present document analyzes these issues, and it identifies the requirements for the definition of a standard interface between the DVB-S2 link layer and an IP subnetwork. "The Core Session Initiation Protocol User Agent Profile Data Set", Daniel Petrie, 26-Oct-05, This document defines the properties and format for the core SIP user agent profile data set. The properties defined in this document are expected to be common to most SIP user agents regardless of whether the user agent support audio, video, text or any combination of media. These core SIP properties are considered to to be a data set. Several datasets may be combined into documents or profiles that are provided to SIP user agents so that they can operate with the desired behavior. "Feed Rank", James Snell, 22-Feb-06, This document defines a mechanism for numerically ranking entries within a syndication feed. "iCalendar in XML Format (xCal-Basic)", Doug Royer, 25-Oct-05, The mailing list for discussion of this memo is "xCal@ INET-Consulting.com" and signup page at "http://INET-Conusulting.com/mailman/listinfo/xcal. This is a rerelease of an expired draft with updates and a much more simplivied approach. This approach uses an exact 1 to 1 mapping between iCalendar and xml objects. "IPv4 Mobile Host/Network support for NEMO Basic Support Protocol", Keiichi Shima, 26-Oct-05, This memo describes the IPv4 Mobile Network Prefix Option which carries IPv4 network prefix information behind a NEMO router. This option makes it possible to support IPv4 mobile networks over the IPv6 network infrastructure. "Media Server Control Protocol (MSCP)", Scott McGlashan, 26-Jan-06, This document specifies MSCP (Media Server Control Protocol), a protocol to control interactive dialog and conferencing functions on a media server. The protocol messages - requests, responses and notifications - are modeled on dialog and conferencing elements defined in CCXML (Voice Browser Call Control), and interactive dialogs can be specified in VoiceXML (Voice Extensible Markup Language). MSCP messages have self-contained XML representation and transaction models, so the protocol is independent of the underlying transport channel. Messages may be transported using SIP or, preferably, using a dedicated transport channel. "Update to OSPF Graceful Restart procedure", Ashok Holla, 10-Mar-06, This document suggests improvements to OSPF v2 Graceful Restart. The basic protocol working remains as specified in [OSPFGR]. The draft describes a two pronged approach for improving the current graceful restart mechanism. It improves the restarting router’s ability to detect and react to topology changes. It also reduces the conservative behavior of the helper router in reacting to topology changes. "UniDirectional Link Detection (UDLD) Protocol", Marco Foschiano, 14-Feb-06, This document describes a protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused for instance by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. Please note that this document is not meant to be used as an implementation reference for inter-vendor interoperability purposes. Its objective instead is to be an informative reference for users who wish to deploy services based on the protocol herein described. "Mounting WebDAV (Web Distributed Authoring and Versioning) servers", Julian Reschke, 30-Nov-05, In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a WebDAV server. For example, it is frequently desirable to be able to click on a link, and have this link open a window that can handle drag and drop interaction with the resources of a WebDAV server. This document specifies a mechanism and a document format that enables Web Distributed Authoring and Versioning (WebDAV) servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. "Feed License Link Relation", James Snell, 27-Jan-06, This memo presents a mechanism that allows feed publishers to associate copyright licenses with feeds and entries. "Feed Thread: Enabling Threaded Entries in Atom", James Snell, 22-Feb-06, This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. "IODEF/RID over SOAP", Kathleen Moriarty, Brian Trammell, 28-Nov-05, Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an inter-operable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP(S) and SOAP over BEEP. "Atom Metadata Expiration: Specifying Expiration Timestamps for Atom Feed and Entry metadata", James Snell, 9-Dec-05, This memo presents a mechanism that allows feed publishers to express maximum age and expiration properties for information content within an Atom entry. "Link Adaptation for IPv6-in-IPv4 Tunnels", Fred Templin, 3-Mar-06, IPv6-in-IPv4 tunnel endpoints support an MTU of 1280 bytes or larger via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document proposes a new MTU determination mechanism for IPv6-in-IPv4 tunnels that supports larger MTUs using a link adaptation scheme with tunnel endpoint-based segmentation/ reassembly and dynamic segment size probing. "Revised Civic Location Format for PIDF-LO", Martin Thomson, James Winterbottom, 4-Oct-05, This document defines an XML format for the representation of civic location. This format is designed for use with PIDF Location Object (PIDF-LO) documents. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for DHCP. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. "Lawful Intercept procedure via the Session Initiation Protocol (SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular (PoC)", S Sriram, 21-Sep-05, This document describes the Lawful Intercept Procedure using Session Initiation Protocol (SIP) used by the Open Mobile Alliance (OMA), for Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application. "Distributed Security Threat Model", Pekka Savola, 27-Oct-05, The distributed security framework document describes an approach where hosts take greater responsibility for protecting against attacks on security vulnerabilities targeted at themselves. This memo analyzes the threat model of the distributed security approach, in particular pointing out areas which the mechanism cannot protect against. XXX: generic comment from JariA: "The main issue that I could see is that its still rather simple presentation of the issues, e.g. does not necessarily go as deep as some other ongoing work goes." XXX: generic comment from EKR: "I found the organization rather confusing. It seems to me like a lot of the material in the framework document would make more sense in the threat model. Without that context, it's fairly hard to understand what you're trying to accomplish." (Similar comment from others: addressing this would require significant(?) text duplication from the framework doc..) "The IETF Process: a Roadmap", Brian Carpenter, 22-Feb-06, This document describes a roadmap for various IETF process documents, intended both to assist IETF participants and to support discussions about process reform. "Using Spurious Retransmissions to Adapt the Retransmission Timeout", Mark Allman, 15-Feb-06, This document describes a method for using spurious retransmission timeouts as the trigger for slightly changing the way TCP's retransmission time is computed in an effort to avoid subsequent unnecessary retransmissions. "Metrics for the Evaluation of Congestion Control Mechanisms", Sally Floyd, 17-Oct-05, This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. This includes metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. 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. "Dynamic Feedback Protocol", Curt Kersey, 9-Mar-06, This memo presents a protocol for allowing servers in a load sharing pool to provide feedback status to the entity making decisions on how to distribute the work load to the pool. "Stream Control Transmission Protocol (SCTP) Stream Reset", Randall Stewart, 8-Feb-06, Many applications that desire to use SCTP have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". This documents presents also a method for resetting the transport sequence numbers and all stream sequence numbers. "Inserting Advertisements in IP multicast", Ajeet Khunger, 2-Sep-05, Providing a Standard method for Addition of regional Advertisements in the IP Multicast Video Streaming is very important , because the equipment deployed would most likely be from different vendors across a multicast network. The idea is to introduce a special kind of Enhanced IGMP Ad-Insert control packet, which is passed from the multicast source to intermediate routers and which indicates that the source is going to stop sending multicast traffic for a particular group for specified time and the Regional center can utilize this time to insert its regional advertisement. "Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 16-Nov-05, This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. If approved, this document will obsolete RFC 3730. "Time Protocol Servers and Time Offset Options for IPv6 DHCP", Ralph Droms, D Evans, 13-Oct-05, The Time Protocol Servers option for IPv6 DHCP (RFC 3315) carries the IPv6 addresses of servers that a host should use for the Time Protocol (RFC 868). The Time Offset option carries the offset in seconds from Coordinated Universal Time (UTC) that a client may use to determine its local time. "Fibre-Channel Zone Server MIB", Keith McCloghrie, 7-Mar-06, 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 Zone Server. At present, this memo is being proposed to T11.5 (http://www.t11.org). The plan is that it will later become a work item of IETF's IMSS working group. "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", Pekka Nikander, 3-Mar-06, This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as end- point identifiers at applications and APIs and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. "A solution for the HERFP caused by forked SIP INVITE requests", Jeroen van Bemmel, 2-Sep-05, This document describes a solution to the Heterogeneous Error Response Forking Problem (HERFP), a situation in which a UAC remains unaware of elements that are responding to its INVITE with a 'repairable' error response, because a forking proxy in the signalling path only forwards what it considers the 'best' final response. This issue may cause communication establishment to be delayed or even fail. To address this issue this document proposes a new method [preliminarily called 'FIX'] to be used by a forking proxy that detects a HERFP to notify the UAC of a repairable error. "XHTML Microformats for the Atom Publishing Protocol", Robert Sayre, 6-Sep-05, This memo presents a number of XHTML microformats for use with the Atom Publishing Protocol. "Security Threats and Requirements for Emergency Call Marking and Mapping", Henning Schulzrinne, 5-Mar-06, This document reviews the security threats associated with the two current work items of the ECRIT Working Group. The first is the marking of signalling messages to indicate that they are related to an emergency. The second is the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. "Secure Shell Security Model for SNMP", David Harrington, 19-Sep-05, This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. "Extensible Provisioning Protocol (EPP) Host Mapping", Scott Hollenbeck, 21-Nov-05, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732 if approved. "Extensible Provisioning Protocol (EPP) Contact Mapping", Scott Hollenbeck, 21-Nov-05, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733 if approved. "Extensible Provisioning Protocol (EPP) Transport Over TCP", Scott Hollenbeck, 21-Nov-05, This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734 if approved. "Emergency Context Routing of Internet Technologies Architecture Considerations", James Polk, Andrew Newton, 7-Mar-06, This document discusses architectural considerations for emergency context routing of Internet technologies. The purpose of this document is to provide a systemic view of emergency context routing, discuss unresolved issues, and explain the relationship of some of the proposals to these issues, while discussing potential directions that might be still be necessary for the working group to investigate. "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, 8-Sep-05, This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No IKE extensions are needed, but a Peer Authorization Database (PAD) extension in the form of an ID selector wildcard, 'UNKNOWN', specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). "A Uniform Resource Name (URN) Namespace for the Coral Consortium Corporation", Knox Carey, 9-Sep-05, This document describes a Uniform Resource Name (URN) namespace that will identify various objects in Coral system implementations to facilitate interoperability of digital rights management systems. "Use of PKIX Certificates in DKIM", Phillip Hallam-Baker, 9-Sep-05, This document describes a mechanism for using X.509v3 certificates that comply with the PKIX profile with Domain Keys Identified Mail (DKIM). An email signer MAY inform potential relying parties that a key described in a DKIM key record has a corresponding PKIX certificate or certificate path by means of an attribute in the key record that provides the URL of the certificate data. An email verifier MAY choose to make use of this information in deciding the disposition of the signed email message. "Atom Link No Follow", James Snell, 9-Dec-05, This memo presents a mechanism that allows feed publishers to express preferences over how a consumer processes Atom links and Content-By- Reference. "The Proposal for Internationalizing ccTLD Names", Howard Li, 9-Sep-05, There are great demands on using someone's native language to surf the Internet around the world. Internationalized domain name system has been introduced to meet the demand. However, due to many technical and policy issues, IDN may provide malicious rogues the opportunities to mislead users to unintended third party website, thus cause security issues and threat the stabilization of the Internet. CDNC recognize the complexity of the issue and make advises to avoid the threat. To simplify the issue, CDNC suggest internationalize the ccTLD before any moves on gTLD. Also, the approval on internationalize a ccTLD should based on the readiness of the respective registry and the support from the respective government. The following document fully demonstrated the principles and procedure to internationalize ccTLD that recommended by CDNC. "Extensible Provisioning Protocol (EPP) Domain Name Mapping", Scott Hollenbeck, 21-Nov-05, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731 if approved. "A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers", James Polk, 7-Mar-06, This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP message from the server. "Unrouted Data Handling in PIM-SM", A.S. Musthafa, 12-Sep-05, A shared-media LAN like Ethernet may have multiple PIM-SM routers connected to it. In a scenario where two or more routers are connected to the same LAN and if only one of the PIM-SM Routers has members joined for a particular group, all the other routers will receive the same traffic. Since no members are joined for this group in the routers, each time when data is received, the PIM-SM has the overhead of processing all these data packets in the control plane to decide where to route the packet. To avoid this, an (S, G) or (*, G) Entry with NULL Oif list is created so that discarding of the packets will be handled efficiently in the data plane as opposed to searching the route entry in the control plane and then dropping the packet. "A method for overlap signalling in SIP", Pengsheng Zhang, 8-Mar-06, Overlap signalling is a traditional feature in telecom network. RFC 3578 addresses how to implement it in a SIP network. It mainly introduce the method to carry subsequent dialed number in INVITE. But there are still some issues for it. This document gives a detailed discussion on another method based on INFO. It can be treated as a supplementary for RFC 3578. "CAPWAP Comparative Analysis", Richard Gwee, 12-Sep-05, The purpose of this document is to present a comparative evaluation of the Control and Provisioning of Wireless Access Points (CAPWAP) protocol proposals. To the date of this document, the following four protocols have been proposed, namely CAPWAP Tunneling Protocol (CTP), Light Weight Access Point Protocol (LWAPP), Secure Light Access Point Protocol (SLAPP), Wireless LAN Control Protocol (WiCoP). Each of these protocols has its own unique strengths in fulfilling the CAPWAP Objectives through their own mechanisms and functionalities. The final CAPWAP protocol should comprise all of these strengths. This document gives a comparative study of the four proposed protocols based on the CAPWAP Objectives and makes recommendations on the combination of their strengths for the final CAPWAP protocol. "Diameter Compression", H Zhangtao, R Rajith, 14-Sep-05, This document describes the negotiation of compression algorithm between two Diameter peers and the indication of data compression using a new AVP [Attribute Value Pair] flag. "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Haitham Cruickshank, 14-Sep-05, This document provides a threat analysis and derives security requirements for MPEG-2 transmission links using the Unidirectional Lightweight Encapsulation (ULE). It also provides the motivation for ULE link level security. "Link Layer Hashed Based Addresses (LL-HBA) for Secure Neighbor Discovery (SEND)", Julien Laganier, Gabriel Montenegro, 14-Sep-05, The current mechanisms used by Secure Neighbor Discovery (SEND) to secure the Neighbor Discovery Protocol (NDP) relies almost solely on public key cryptography (i.e. Certificates and/or Cryptographically Generated Addresses). While these approaches provide very strong guarantees on the authenticity of an IP address to link layer address mapping, they are computationally expensive, which might be a problem on resource-constrained devices. It is also recognized in the SEND specification that it does not compensate for an insecure link layer; more specifically, no protections are offered against spoofing, link disruption, or bombing DoS attacks launched at the link layer. Accordingly, this note suggests an alternative to the current specification of SEND which leverage on the deemed required link layer security to secure NDP. This technique is based on the use of a specific kind of IPv6 addresses, the so-called Link Layer Hashed Based Addresses (LL-HBA), and of link layer address reachability tests. When the link layer security prevents attacker to redirect frames at the link layer layer, this technique allows to provide some level of security to NDP while relying solely on symmetric (i.e., computationally inexpensive) cryptography. "Mobile IPv4 Fast Handovers for 802.16e networks", Junghoon Jee, 14-Oct-05, This document describes how a Mobile IPv4 Fast Handover can operate on link layers confirming to the IEEE 802.16e suite of specification. "Tools for the Evaluation of Simulation and Testbed Scenarios", Sally Floyd, Eddie Kohler, 17-Oct-05, This document describes tools for the evaluation of simulation and testbed scenarios used in research on Internet congestion control mechanisms. We believe that research in congestion control mechanisms has been seriously hampered by the lack of good models underpinning analysis, simulation, and testbed experiments, and that tools for the evaluation of simulation and testbed scenarios can help in the construction of better scenarios, based on better underlying models. One use of the tools described in this document is in comparing key characteristics of test scenarios with known characteristics from the diverse and ever-changing real world. Tools characterizing the aggregate traffic on a link include the distribution of per-packet round-trip times, the distribution of packet sequence numbers, and the like. Tools characterizing end-to- end paths include drop rates as a function of packet size and of burst size, the synchronization ratio between two end-to-end TCP flows, and the like. For each characteristic, we describe what aspects of the scenario determine this characteristic, how the characteristic can affect the results of simulations and experiments for the evaluation of congestion control mechanisms, and what is known about this characteristic in the real world. We also explain why the use of such tools can add considerable power to our understanding and evaluation of simulation and testbed scenarios. "A solution for the HERFP caused by forked SIP INVITE requests", Jeroen van Bemmel, 15-Sep-05, This document describes a solution to the Heterogeneous Error Response Forking Problem (HERFP), a situation in which a UAC remains unaware of elements that are responding to its INVITE with a 'repairable' error response, because a forking proxy in the signalling path only forwards what it considers the 'best' final response. This issue may cause communication establishment to be delayed or even fail. To address this issue this document proposes a new method [preliminarily called 'FIX'] to be used by a forking proxy that detects a HERFP to notify the UAC of a repairable error. "IPv6 Routing Policies Guidelines", Marc Blanchet, 7-Mar-06, Guidelines on how to handle IPv6 routes are needed for operators of networks, either providers or enterprises. This document is a followup on RFC2772 work but for the production IPv6 Internet. RFC2772 becomes historic. "An Encapsulation for Transmission of IP Datagrams over a DVB-S2 Generic Stream (GULE)", Gorry Fairhurst, 18-Jan-06, This document describes a Generic stream Unidirectional Lightweight Encapsulation (GULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the DVB S2 Generic Stream. This specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. Internet-Drafts can be and are used to describe technical issues and protocols that are of interest to the Internet community but that are not finally standardised within the IETF. This is such a document. It is intended for open discussion, but there is no current plan to publish this as an Internet RFC. "TRIP Attribute for Resource Priority", Piers O'Hanlon, Ken Carlberg, 16-Sep-05, This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. "Use of the Gnerealized Multi-Protocol Label Switching control plane for point-to-point Ethernet Label Switching", Loa Andersson, Dimitri Papadimitriou, 21-Oct-05, This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. "Authentication for TCP-based Routing and Management Protocols", Ronald Bonica, 31-Jan-06, This memo describes a TCP extension that enhances security for BGP, LDP and other TCP-based protocols. It is intended for applications where secure administrative access to both the end-points of the TCP connection is normally available. TCP peers can use this extension to authenticate messages passed between one another. The strategy described herein improves upon current practice, which is described in RFC 2385. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages. "Obtaining and Using Temporarily Routable User Agent (UA) URIs (TRUU) in the Session Initiation Protocol (SIP)", Jeroen van Bemmel, 19-Sep-05, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct a URI which can only be used to route messages to that specific UA instance for the duration of a particular call. A URI whose lifetime is controlled by the UA instance to which it indirectly routes is called a Temporarily Routable UA URI (TRUU). This document describes an extension to SIP for obtaining a TRUU from a proxy, and for using this TRUU when communicating with a peer in the context of a dialog. "Extending the Internet Control Message Protocol (ICMP)", Ronald Bonica, 27-Jan-06, This document defines a syntax that can be used to extend ICMPv4. The syntax is characterized by an extension structure that is appended to selected ICMP messages. The extension structure contains an header followed by one or more objects. Each object contains a header and a payload. All object headers share a common format. "Internet Message Store Events", Chris Newman, 20-Sep-05, One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. "BGP support for 4-Byte AS Numbers - Implementation Survey Report", Geoff Huston, 20-Sep-05, This document provides a survey of BGP-4 4-Byte AS Number support implementations. "Enhanced Fast Handover for Mobile IPv6 based on IEEE 802.11 Network", Youngsong Mun, 21-Oct-05, In MIPv6 [1], whenever a mobile node changes its attached point, handover process should be followed to inform its home agent and correspondent of a MN's current location. The handover process is decomposed into layer 2 and layer 3 handovers again, and these two handovers are accomplished sequentially, which causes long latency problem. This problem is a critical issue in MIPv6. To make up for this, we propose an enhanced Fast Handover scheme to reduce the overall latency on handover, revising the Fast Handover [2]. Especially, several messages in layer 3 are sent in one frame during layer 2 handover. "IP Multicast MIB", David McWalter, 16-Dec-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 multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. "A Method to deliver Resource Information List for Presence Information", Xiao Wang, Peili Xu, 14-Feb-06, Presence Information Data Format(PIDF) [1] and Rich Presence Extensions to the Presence Information Data Format(RPID) [2] have definition for a lot of presence information. Notifier can filter the presence information to subscriber according to local policy . But the notifier may not support all the presence information. It is a matter how to inform the subscriber the allowed, forbidden and unsupported presence information. This document provides a method to solve this problem by introducing the concept of Resource Information List(RIL). "Configuration Issues Facing Full Service DNS Resolvers In The Presence of Private Network Addressing", Mark Andrews, 24-Feb-06, Practice has shown that there are a number of zones all full service resolvers should, unless configured otherwise, automatically serve. RFC4193 already specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC1918 address space and other well known zones with similar usage constraints. "Delay-Tolerant Networking Security Overview", Stephen Farrell, 3-Mar-06, This document provides an overview of the security requirements and mechanisms considered for delay tolerant networking security. It discusses the options for protecting such networks and describes reasons why specific security mechanisms were (or were not) chosen for the relevant protocols. The entire document is informative, given it's purpose is mainly to document design decisions. "RADIUS Delegated-IPv6-Prefix Attribute", Joseph Salowey, Ralph Droms, 24-Oct-05, The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is to be delegated to the user. "Simple Firewall Traversal Mechanisms and Their Pitfalls", Eliot Lear, 20-Oct-05, Many devices make use of so-called "Call Home" functionality in order to be managed or updated, or to otherwise establish outbound communication in the face of NATs, firewalls, and mobility. This memo defines call home functionality, discusses the requirement for firewall traversal, some mechanisms used, and security considerations of those mechanisms. Several existing examples will be shown. This memo also contains examples of how one would make SNMP over SSH, NETCONF over SSH, and interactive terminal access call-home protocols. "IMAP URL Scheme", Chris Newman, Alexey Melnikov, 22-Sep-05, IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. "Service Lookup System (SLS) Mapping for the Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 22-Sep-05, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Service Lookup System (SLS) data stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to SLS data elements. "Ingress filtering compatibility for IPv6 multihomed sites", Christian Huitema, 22-Sep-05, The note presents a set of mechanisms to provide ingress filtering compatibility for legacy hosts in IPv6 multihomed sites. "A Common Conference Information Data Model for Centralized Conferencing (XCON)", Oscar Novo, 9-Mar-06, This document collects, organizes, and describes the conference variables that have been introduced in various protocol drafts of the XCON and SIPPING working groups. The goal of this document is to allow the conference control protocols to use a unified common conference information data model for XCON. This document formally defines an Extensible Markup Language (XML) Schema that represents the common conference information in a conferencing server. The information is modeled as a series of elements, each of which contains a set of children and attributes. "UDP enhanced tunnel for traversing NAT", Xiangyang Wu, 10-Oct-05, This protocol specification describes a more generic method to encapsulate and decapsulate packets inside a UDP enhanced tunnel for traversing Network Address Translators (NATs). UDP enhanced tunnel header (UTH) encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. "Atom Publishing Protocol - Blog Publishing Controls", James Snell, Elias Torres, 26-Sep-05, This document introduces weblog specific publishing control extensions for use with the Atom Publishing Protocol pub:control mechanism. "OCSP Extensions to IKEv2", Michael Myers, Hannes Tschofenig, 3-Feb-06, 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. When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. "Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful", Francis Dupont, 21-Oct-05, Dynamic Home Agent Address Discovery (DHAAD) mechanism of Mobile IPv6 is nearly impossible to make secure. As the service itself is useful, this document shows the security problems of the current mechanism and promotes an alternative solution. "16ng Problem Statement", Junghoon Jee, 19-Oct-05, This document describes the IPv6 over IEEE 802.16(e) networks (16ng) problem statement. "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", Jim Fenton, 20-Dec-05, This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. "Scenarios and Considerations of IPv6 in IEEE 802.16 Networks", Myung-Ki Shin, 28-Feb-06, As the deployment of IEEE 802.16 networks progresses, IPv6 will be introduced in IEEE 802.16 networks. The characteristics of IEEE 802.16 networks put special considerations on how IPv6 is used. This document describes scenarios and considerations on IPv6 adoption in IEEE 802.16 networks. "Passive Duplicate Address Detection for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4)", Andrea Forte, 5-Mar-06, In a Layer 3 (L3) handoff procedure, one of the biggest components in terms of delay is introduced by the DHCP address acquisition time required for obtaining a valid IP address for the new subnet. Duplicate Address Detection (DAD) is the most time consuming part of the whole DHCP procedure. In this document we propose a new DAD scheme which has been proven to be effective without introducing any significant delay. By using such a scheme we can avoid duplicate address and at the same time keep the address acquisition time in the order of a few milliseconds. Using the new procedure will also permit to detect an unauthorized use of a particular IP address even if no duplicate IP has yet occurred. "Requirements for Link Adaptation over IP-in-IPv4 Tunnels", Fred Templin, 30-Sep-05, IP-in-IPv4 tunnel endpoints present a Maximum Transmission Unit (MTU) to layer 3 via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations that can cause degraded performance and communications failures. A new method for providing link adaptation over IP-in-IPv4 tunnels is needed. "Requirements for IETF Technical Publication Service", Allison Mankin, Stephen Hayes, 6-Mar-06, The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. "Great Real-Time Problem Statement", Yakov Stein, 30-Sep-05, VoIP is commonly perceived to be a low quality, but low cost, alternative to standard telephony. This poor perception is often well deserved, being fueled by implementations designed without regard to characteristics of IP networks. This problem statement attempts to catalog the shortcomings of current implementations, in order to explore the IETF community's interest in working to improve this situation. "Enhanced Communications Transport Protocol for One-to-Many Multicast Applications with Unicast Reverse Data Channels", Seok Koh, Dae Young Kim, 30-Sep-05, This document is a part of the ITU-T Recommendation and ISO/IEC International Standard, named the Enhanced Communications Transport Protocol (ECTP), which is a multicast transport protocol designed to support Internet multicast applications. This third part of ECTP (ECTP-3) describes the protocol specification for the duplex multicast transport. In a duplex connection, a single multicast sender, named TC-Owner (TO), transmits multicast data to the other group members, while some of the participating TS-users may send unicast data to the TO over the reverse data channel. "SMTP extension for internationalized email address", XiaoDong Lee, Jiankang Yao, 28-Feb-06, Internationalized eMail Address (IMA) includes two parts, the local part and the domain part. The way email addresses are used by protocols are different from the way domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. So IMA is different from the internationalized domain name (IDN). IMA can be solved by exploiting the negotiation mechanism while IDN can not use the negotiation mechanism. So IMA should be solved in the mail transport-level using the negotiation mechanism, which is an architecturally desirable approach. This document specifies the use of SMTP extension for IMA delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol proposed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. "Address selection in multihomed environments", Marcelo Bagnulo, 3-Oct-05, This note describes mechanisms for address selection in hosts within a multihomed site. The goal of these mechanisms is to allow hosts within the multihomed site to establish new communications after an outage. The presented mechanisms are not by themselves a complete multihoming solution but rather a component of such solution. "Overview and Framework for Internationalized Email", John Klensin, YangWoo Ko, 22-Feb-06, Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications and operational suggestions that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also will include discussion of key assumptions and issues in deploying fully internationalized email. "Requirements for IP-in-IP Tunnel MTU Assurance", Fred Templin, 4-Oct-05, IP-in-IP tunnels present a Maximum Transmission Unit (MTU) to layer 3 via static prearrangements and/or dynamic MTU determination based on layer 2 ICMP messages, but these methods have known operational limitations that can fail to enforce an assured MTU resulting in degraded performance and communications failures. A method for providing an assured MTU to layer 3 over IP-in-IP tunnels is needed. "Guidelines for Acting as an IETF Liaison to Another Organization", Loa Andersson, 4-Oct-05, Whenever IETF decides to enter into a liaison relationhsip with another organization, e.g. a Standards Development Organization, a consortium, or an industrial forum, a liaison manger is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052 [RFC4052]. This document give guidelines on expectations, tasks, responsibilities and mandate of the liaisons managers. "NTP Timestamp Extension for ALC", Martin Jansky, Topi Pohjolainen, 4-Oct-05, This document defines a variable length ALC PI specific LCT Header Extension, NTP Timestamp Header (EXT_NTP). This extension can be used within an ALC session for multiple purposes, for example, to signal the last moment of time there was a change in the session. "GMPLS Requirements for MS-SPRing support", Diego Caviglia, 4-Oct-05, GMPLS [1] provides ideally a robust and flexible control plane protocols set designed for application over generalized transport network. A typical application of GMPLS is, among others, the control of transport networks based on SDH/SONET [2] technology. In this scenario, the introduction of GMPLS based control plane should ensure support of and/or compatibility with the most important and widely exploited SDH/SONET features, making possible a seamless interworking with inherent data plane requirements. In this document we focus on one of the most attractive SDH/SONET protection mechanism, implemented through MS-SPRing (G.841 [3]), a widely deployed ITU standard for ring-shared protection. "Rationale for the Service Lookup System (SLS)", Scott Hollenbeck, 4-Oct-05, Developing technology to support truly internationalized Internet identifiers is proving difficult within the framework of the existing Domain Name System (DNS). At the same time, the DNS continues to do an excellent job at serving its original mandate for providing efficient mappings between machine-readable labels and network resources. However, it is clear that the existing DNS cannot be transformed into a service that can handle the more human-oriented identification services it is now being asked to provide. This document describes the rationale for a directory layer above the existing DNS that can better solve these problems. "IANA Registration for Enumservice vCard", Alex Mayrhofer, David Lindner, 5-Oct-05, This memo registers the Enumservice "vCard" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC3671. This Enumservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call. "IS-IS Multi-instance Multi-topology", Stefano Previdi, 5-Oct-05, This draft describes a mechanism that allows a single router to share one or more links among multiple IS-IS routing protocol instances. Multiple instances allow the deployment of multiple address-families as well as multiple instances of the same address-family and it is an alternative to Multi-Topology IS-IS. Routers supporting the same instance will form adjacencies, exchange routing updates and compute paths. Each PDU will contain a new TLV identifying the instance to which the PDU belongs. This allows a network operator to deploy multiple IS-IS topologies in parallel, using the same set of links when required and still have the capability of computing topology specific paths. This draft does not address the forwarding paradigm that needs to be used in order to ensure data PDUs are forwarded according to the topology to which they belong. "Guidelines for Implementing the Dialog Event Package in User Agents", Dale Worley, 5-Oct-05, This document sets out guidelines for how user agents should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. It is in addition to the basic requirements for dialog event package implementation in RFC 3265 and draft-ietf-sipping-dialog-package. "PIDFConn: Extension to the Presence Information Data Format (PIDF) for Expressing Connectivity Features", Jussi Ala-Kurikka, 9-Mar-06, The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The optional contact element in PIDF contains a URI that ultimately resolves to a network interface on some device. Currently, the ways of expressing features related to that interface are limited. PIDFConn defines an extension to PIDF for describing features of connectivities and the cost of using services. "PIM Bootstrap Router MIB", David McWalter, 5-Oct-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 Bootstrap Router (BSR) mechanism for PIM. "Guidelines for Implementing the GRUU Support in User Agents", Dale Worley, 6-Mar-06, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). An Internet-Draft is progressing toward standardization that gives a method by which proxies can construct and delver GRUUs to UAs that request them. This document distills that Internet-Draft into a guide for UA implementors. "Registration of MIME media type audio/sp-midi", Timo Kosonen, Tom White, 5-Oct-05, The MIDI Manufacturers Association (MMA) and the Association of Music Electronics industry (AMEI) have produced the Scalable Polyphony MIDI (SP-MIDI) standard [n1]. SP-MIDI has been approved for 3GPP standardization and a dedicated SP-MIDI profile has been defined for 3GPP SP-MIDI devices [n2]. Since MIDI information is a very compact media type, 3GPP is initially focusing on the application of SP-MIDI for music downloading and messaging applications that require MIME registration. "Registration of MIME media type audio/mobile-xmf", Timo Kosonen, Tom White, 5-Oct-05, The MIDI Manufacturers Association (MMA) and the Association of Music Electronics industry (AMEI) have produced the Mobile XMF standard [1]. The Mobile XMF standard has been developed particularly for mobile MIDI [7] applications. Mobile XMF is a very compact media type providing high quality synthetic audio content for music downloading and messaging applications that require MIME registration. "Indicating Service Retargeting in the Session Initiation Protocol (SIP)", John Elwell, Francois Audet, 6-Oct-05, This contains motivation, requirements and a proposed solution for indicating service retargeting information in SIP requests and responses. Retargeting of a request can be considered to be service retargeting when it goes beyond "normal" routing and might be of interest to applications at the UAS or UAC. "SSH File Transfer Protocol", Joseph Galbraith, Oskari Saarenmaa, 6-Oct-05, The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. "GRE Key Extension for Mobile IPv4", Parviz Yegani, 7-Mar-06, The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to setup the necessary protocol interfaces prior to receiving the mobile's traffic. The new extension option allows a foreign agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile Ipv4. GRE tunneling provides an advantage that allows operator's private home networks to be overlaid and allows the HA to provide overlapping home addresses to different subscribers. When the tuple < Care of Address, Home Address and Home Agent Address > is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling. "Next Steps for NFSv4 Migration/Replication", David Noveck, Rodney Burnett, 6-Oct-05, The fs_locations attribute in NFSv4 provides support for fs migration, replication and referral. Given the current work on supporting these features, and the new needs such as support for global namespace, it is time to look at this area and see what further development of this protocol area may be required. This document makes suggestions for the further development of these features in NFSv4.1 and also presents ideas for work that might be done as part of future minor versions. "Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG", David Harrington, 2-Mar-06, This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge WG to the IEEE 802.1 WG, which develops the bridging technology the MIB modules are designed to manage. "SIP-based Network Mobility (SIP-NEMO) Route Optimization", Chao-Hsien Lee, 7-Oct-05, The Network Mobility (NEMO) Basic Support protocol enables a mobile network to change its point of attachment and keeps nodes in the mobile network reachable when the mobile network moves in the Internet. However, using the NEMO Basic Support protocol, all traffic must pass through the bi-directional tunnel between a mobile router and its home agent when the mobile router leaves its home network. It results in sub-optimal routing and long transmission delay. This document describes the SIP-based Network Mobility (SIP- NEMO) Route Optimization (RO) that achieves optimal routing and reduces the limitation due to the bi-direction tunnel using Session Initiation Protocol (SIP). "Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)", Shinji Shibata, 8-Mar-06, Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. RFC 3471 [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of a new generation of lambda switch-capable equipment, this document explains new models that require standardization of the label. It highlights new operator requirements and describes signaling and routing extensions to satisfy those requirements. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. "Middlebox Traversal Issues of Host Identity Protocol (HIP) Communication", Martin Stiemerling, 31-Jan-06, 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. "Persistent Search Extensions and Virtual Folder to the IMAP Protocol", Stephane Maes, 23-Jan-06, Persistent Extensions to the IMAP Protocol (LPSEARCH) defines extension parameters to the [RFC3501] CREATE command to allow virtual mailboxes to be created which are views of other mailboxes narrowed by search criteria. "RTP Payload Format for SVC Video", Stephan Wenger, 8-Mar-06, This memo describes an RTP Payload format for the scalable extension of the ITU-T Recommendation H.264 video codec which is the technically identical to ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by the video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. "ENUM Requirement for EDNS0 Support", Lawrence Conroy, Jim Reid, 25-Oct-05, This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support ENUM query resolution (as defined in RFC3761). This requirement is needed as DNS responses to ENUM-related questions return larger sets of Resource Records than typical DNS messages. Without EDNS0 support in all the involved entities, a fallback to TCP transport for ENUM queries and responses would typically occur. That has a severe impact on DNS Server load, and on latency of ENUM queries. This document updates RFC3761 only in adding this requirement. "Lemonade notifications and filters: how to", Stephane Maes, 27-Oct-05, This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILE]. "Operation and Maintenance for Multi-segment Pseudo Wire", Yang Yang, Jixiong Dong, 27-Feb-06, This draft proposes a method for operation and maintenance on the multi-segment pseudo wires (MS-PWs). It extends and is compatible with the existing single-segment pseudo wire OAM mechanism [VCCV]. "Policy-Enabled Path Computation Framework", Igor Bryskin, 5-Mar-06, The PCE architecture [PCE-ARCH] introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides configuration scenarios for the support of PCE Policy. "RADIUS Support for New Header Compression Schemes", Kuntal Chowdhury, Arun Seshadri, 11-Oct-05, The definition of RADIUS attribute "Framed-Compression" in RFC 2865 does not include values for new Header Compression schemes like ROHC, ROHC-TCP. This document defines the new values to the "Framed- Compression" attribute. "DNS Start of Authority Discovery", Mark Andrews, 21-Oct-05, Sometimes it is necessary to discover the Start of Authority points in the DNS, otherwise known as zone cuts, without causing negative entries to be recorded in caches. This document describes how to achieve this. "Automatic Tunneling Setup for/with IPv6", Jordi Palet, Miguel Diaz, 18-Jan-06, This document presents the basis for a procedure that enables a host or router to automatically setup an IPvX in IPvY tunnel. Basically, the document considers several scenarios, from the most common today "dominant IPv4" networks to new "dominant IPv6" networks, which can even support the use of multicast. A basic requirement is that the host or router is a dual stack node and it will have either native IPv4-only access (dominant IPv4 network) or native IPv6-only access (dominant IPv6 network). Consequently, either IPv6 will be transported in the existing IPv4- only infrastructure, or IPv4 will be transported in the existing IPv6-only infrastructure. Other combinations are possible, such as IPv6 in IPv6 (for example to support IPv6 multicast in an IPv6- unicast-only infrastructure). The procedure follows the work from [1], [2], [3], [4] and mainly [5], trying to be compliant with the requirements enumerated in those documents. "TLS Multiplexing", Mohamad Badra, Ibrahim Hajjeh, 11-Oct-05, TLS is the famous protocol that provides authentication and data protection for communication between two entities. However, missing from the protocol is a way to multiplex application data over the same TLS session. This document defines a new TLS sub-protocol called MTLS running over TLS (or DTLS) Record protocol. The MTLS design provides application multiplexing over a single TLS session. Instead of associating a TLS connection with each application, MTLS allows several applications to protect their exchanges over a single TLS session. "Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration", Kohei Shiomoto, 2-Mar-06, The migration from Multiprotocol Label Switching (MPLS) to Generalized MPLS (GMPLS) is the process of evolving an MPLS traffic engineered (TE) control plane to a GMPLS control plane. An appropriate migration strategy can be selected based on various factors including the service provider's network deployment plan, customer demand, available network equipment implementation, operational policy, etc. In the course of migration, several interworking cases may exist where MPLS and GMPLS devices or networks must coexist. During the migration process, standard interworking functions are needed to allow graceful deployment of GMPLS technologies while keeping existing IP/MPLS networks unaffected. Since GMPLS signaling and routing protocols are different from the MPLS control protocols, in order for MPLS and GMPLS to interwork, we need mechanisms to compensate for the differences between MPLS and GMPLS. This document provides a landscape of techniques, practices and an overview of interworking between MPLS and GMPLS in support of IP/MPLS to GMPLS migration, which is also beneficial for graceful deployment of GMPLS technologies into existing IP/MPLS networks. We discuss issues, models, migration scenarios, operation, and requirements. "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", Eiji Oki, 12-Oct-05, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. "Internationalized Email Headers", Jeff Yeh, 28-Feb-06, Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use international characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header fields. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. "Multicast in BGP/MPLS VPN", Xiaohu Xu, 19-Oct-05, This document describes a set of procedures and protocols that allow IP multicast traffic in Border Gateway Protocol (BGP4)/ Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) to travel from one VPN site to another in MPLS Label Switching Path (LSP) tunnel. "Bidirectional RSVP-TE Tunnel", Xiaohu Xu, Le Zhang, 19-Oct-05, Through the binding of two unidirectional RSVP-TE tunnels established between a pair of LSRs destined to each other, a bidirectional RSVP- TE tunnel is formed. The bidirectional RSVP-TE tunnel can be used to establish L3VPN with virtual router technology. "Dynamic Multicast Tree Construction for NEMO", Kiyong Park, 12-Oct-05, Multicast Supporting is one of the most important issues in Network Mobility Environment, because some killer applications related to multicast service need to be provided on Next Generation Network. However, current NEMO technique based on basic support protocol have got many problems to support the service such as route optimization, pinball route, mass of multicast problem, etc. the most signficant problem of the service in NEMO environment is that Mobile Network cannot be sure that multicasting from parent mobile networks is possible when the network is nested, Moreover, even though the best case that all mobile networks have its own multicast router is supposed and multicasting is working well, the multicast route tree can not be optimized due to different MNPs of the multicast routers in each nested network. This document defines additional functions of each component to enable dynamic multicast tree construction for multicast service in Mobile Network. "Using URIs for the PIDF-LO 'provided-by' element", Martin Thomson, James Polk, 12-Oct-05, The "provided-by" element in PIDF-LO is a container designed to carry information about the source of location information. This document defines an XML structure that can be used within the "provided-by" element to convey basic information about the information provider in the form of a URI. "Quantum Key Destribution within Point to Point Protocol (Q3P)", Mohamed Ali Sfaxi, Solange Ghernaouti, 12-Oct-05, The aim of this paper is to analyse the use of quantum cryptography within PPP. We propose a solution that integrates quantum key distribution into PPP. "Extend IGMPv3 To Support Router Annoucing Information For Host", Chen Wumao, 13-Oct-05, IGMP is used by IPv4 system to report their multicast group memberships to multicast routers. This document adds support for router annoucing information, that is, the ability for a multicast router to annouce information about a group to host. For example, some hosts may send reports to join a group that do not exist, so the router would send some message to inform the hosts. "Routing Control Plane Security Capabilities", Zhao Ye, Miao Fuyou, 13-Oct-05, The document lists the security capabilities needed for routing control planeof IP infrastructure to support the practices defined in [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. "RFC 3978 Update", Simon Josefsson, 13-Dec-05, Two problems with BCP 78 regarding the outbound rights granted to third parties are identified. A proposal to solve the problems is proposed. The first problem is that rights granted to third parties in BCP 78 are more restrictive then what was permitted through the license in RFC 2026. The rights granted by the new license is too limited for some uses of Contributions. The uses include adapting portions of Contributions for online help, reference manuals, and source code. The second problem is that rights to publish and distribute documents are not granted to third parties. We also discuss an issue that has been expressed regarding fake RFCs, that might have been permitted through our earlier license, and we also attempt to solve that problem. "SIMCO over SCTP", Sebastian Kiesel, 13-Oct-05, This document specifies how to use SCTP for the transport of the SIMCO (Version 3.0) protocol. SIMCO (SImple Middlebox COnfiguration) is a protocol that implements the MIDCOM semantics. It can be used for controlling middleboxes such as firewalls and network address translators. SCTP (Stream Control Transmission Protocol) is a transport layer protocol that is expected to have advantages for this type of application, compared to TCP, which is the default transport layer protocol for SIMCO. The specific requirements for SIMCO when using SCTP instead of TCP are specified in this document. "Experience With Multicast VPN", Yiqun Cai, 13-Oct-05, Multicast VPN based on early standards has been in operation in production networks for several years now. This document describes some of the experience gained from implementation and deployment and as such is informational only. "Network Management Access Security Capabilities", Ronald Bonica, Syed Ahmed, 14-Oct-05, This document describes how network management stations can communicate with the devices that they manage using either the in- band network, an out-of-band network, or a virtual out-of-band network. This document also evaluates each access method in terms of its security capabilities and lists the device capabilities needed to support each method. "Label Switched Ethernet (LSE) Architecture", Jaihyung Cho, 14-Oct-05, A solution for GMPLS implementation over Ethernet based on label encoding method using 48bits of Ethernet address is proposed. Ethernet switches supporting this approach control L2-LSP using source & destination MAC addresses. The format of GMPLS label encoding on Ethernet header is described. GMPLS bridge model and three implementation models over bridged core network are presented. The purpose of this draft is not to define new bridge architecture but to help understanding some aspects of this approach, and identify requirements for potential extension to current GMPLS protocols and bridge. "MBS zone Management Protocol(MzMP) for the Multicast", Yongtae Shin, 14-Oct-05, This document presents consideration item and guide line of multicast service environment construction as technology research for efficient multicast service support in common use carrying along internet topology is changed through the result in 2.3GHz carrying along internet topology that become major of mobile internet. "Appling PKI for The Initial Exchange in IKE", Yongtae Shin, 14-Oct-05, This document is describes version 1 of the Internet Key Exchange Protocol. IKE is a component of IPSec used for performing mutual authentication and establishing and maintaining security associations (SAs). Initial exchange information during IKE Processing must be protected with PKI. "Home Agent Configuration Option for DHCPv6", Ma Yuzhi, 14-Oct-05, This document defines a new home agent option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). To assist with rapid handovers the option allows a mobile node (DHCPv6 client) to acquire a list of home agent addresses from a DHCPv6 server. "Improve communication between Mobile Nodes", Ma Yuzhi, 14-Oct-05, Any node communicating with a mobile node in Mobile IPv6 is referred to as a "correspondent node" of the mobile node, and may itself be either a stationary node or a mobile node. Communication between mobile nodes has additional complexity. This document specifies a solution to improve communication procedure between mobile nodes. "IPv6 measurement header", Jian Zhang, HongFei Chen, 14-Oct-05, The purpose of this document is to introduce a measurement header. Measurement header is a new type of IPv6 extended header used for network measurement. The information needed by measurement carried in measurement header. The parameters can be calculated based on these information. "IPv6 Deployment Scenario over Mobile Broadband Wireless Networks", Minji Nam, 14-Oct-05, This document introduces a network structure for IEEE 802.16e, and IPv6 deployment scenario over IEEE 802.16e network with three phases. It lists considerations about mobility management aspect and network aspect that Internet Service Providers (ISPs) should consider when they start to provide IPv6 services. "A header to deliver the calling party category", Rocky Wang, Youzhu Shi, 21-Oct-05, SS7 ISUP [3] defines a Calling Party's Category (CPC) parameter that characterizes the station used to originate a call and carries other important state that can describe the originating party. Based on the CPC parameter from the calling network, the called network can do some special processes related to the calling party category, just like override the calee's DND and some other barring services. This document specifies a way to deliver the calling party category to implement some supplementary services derived from the PSTN network. "Connected Identity in the Session Initiation Protocol (SIP)", John Elwell, 22-Feb-06, Because of retargeting of a dialog-forming request, the UAS can have a different identity from that in the To header. This document provides a means for that UA to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an authentication service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in a PSTN behind a gateway. This work is being discussed on the sip@ietf.org mailing list. "Hash-Based Key Derivation", Quynh Dang, Tim Polk, 14-Oct-05, This draft specifies a Key Derivation Function (KDF) used to derive secret symmetric keying material for participating parties from a secret value and application specific information. The KDF is based on concatenation and a secure hash function. The length in bits of secret keying material that can be generated by the KDF is limited to (2**32 - 1) times the length in bits of the output block of the hash function. The derived keying material is a concatenation of the outputs of the hashing operations. Inputs to the hash function are incremented counter values, one for each separate hashing operation; the secret value; an optional algorithm identifier; identifiers for the participating parties, and optional protocol specific information. "Four-octet AS Specific BGP Extended Community", Yakov Rekhter, 14-Oct-05, This document defines a new type of a BGP extended community - four- octet AS specific extended community. This community allows to carry 4 octet autonomous system numbers. "A new object to specify a Traffic Engineering (TE) Label Switch Path (LSP) cost", Andrew Dolganow, JP Vasseur, 17-Oct-05, This document proposes a new object (named the COST object) used to specify the cost of a Traffic Engineering (TE) Label Switched Path (LSP). The COST object can be carried within an RSVP message so as to record a TE LSP cost during LSP establishment or within a Path Computation Element (PCE) path computation protocol message so as to provide the cost of a computed path to a Path Computation Client (PCC). "Mobile Node-Access Router Authentication Option", Narayanan Venkitaraman, Vidya Narayanan, 17-Oct-05, FMIPv6 [4] requires signalling messages to be exchanged between a mobile node and its access router. For secure interaction, these messages must be authenticated using a security association between the access router and the mobile node. To enable the mobile node and the access router unambiguously identify the correct security association this document extends the mobility header authentication option by defining a subtype to indicate a mobile node - access router SPI. Also, this option can be used in signaling messages used to derive handover keys between the MN and AR, as described in HK_AAA [5]. The idea here is to re-use the existing mobility option for authentication and only define an additional sub-type for MN-AR authentication. "ForCES Intra-NE Routing Mechanism", Xiaoyi Guo, 10-Mar-06, This document describes a routing mechanism for intra-NE packet transfer path and routing table maintenance. The routing mechanism only operates during post-association phase of ForCES protocol. "The Trust Anchor Key Renewal Method Applied to DNS Security (TAKREM-DNSSEC)", Thierry Moreau, 20-Dec-05, This document provides additional security protocol elements to the DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034], [RFC4035]), in the area of DNSSEC key management support functions. It specifies an automated key rollover mechanism for trust anchor keys. This mechanism has implications on the trust anchor key generation procedures, because it is an integrated scheme that supports the security of trust anchor signature key pairs used in consecutive cryptoperiods. "The SEP DNSKEY Direct Authenticator DNS Resource Record (SDDA-RR)", Thierry Moreau, 20-Dec-05, This document specifies a generic DNS resource record format for "direct authentication" of DSNKEY records with the SEP bit (Secure Entry Point) set to "1". Although a generic record format is specified with type fields allowing standardized or proprietary extensions, the only use of SDDA RR in DNSSEC operations is the support of trust anchor key management operations. Schemes using the SDDA-RR format are to be specified in other documents. "Requirements and Framework for SIP User Agent Auto-Configuration", Marcus Brunner, 17-Oct-05, The problem of today's VoIP user agents (hardware terminals, SIP soft phones) is the need for quite a bit of manual configuration at the initialization time as well as when moving from one environment to another. The information to be configured is typically not known by the end-user. Automatic configuration of SIP user agents would release the user of these configuration tasks. This memo describes the challenges of auto-configuration of SIP user agents and gives some requirements for further discussions. "PCE Communication Protocol (PCECP) specific requirements for Inter-Area (G)MPLS Traffic Engineering", Jean-Louis Le Roux, 17-Oct-05, For scalability purposes a network may comprise multiple IGP areas. An inter-area TE-LSP is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end LSR cannot compute alone an inter-area shortest constrained path. One key application of the Path Computation Element (PCE) architecture is the computation of inter- area TE-LSP paths. In this context, this document lists a detailed set of PCE Communication Protocol (PCECP) specific requirements for support of inter-area TE-LSP path computation. It complements generic requirements for a PCE Communication Protocol. "Best Current Practice for SIP (Session Initiation Protocol) Usage of Offer/Answer Model", Takuya Sawada, Paul Kyzivat, 17-Oct-05, SIP utilizes offer/answer model to establish and update multimedia sessions. The descriptions on how to use offer/answer in SIP are dispersed in the multiple RFCs. This document summarizes all the current usage of offer/answer model in SIP communication. "Multiple Authentication Exchanges in IKEv2", Pasi Eronen, Jouni Korhonen, 8-Mar-06, IKEv2 supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, either using different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. "Extending the Session Initiation Protocol Reason Header with Warning Codes", Jani Hautakorpi, Gonzalo Camarillo, 17-Oct-05, This document specifies a new protocol value, called 'SIP-Warning', for the Session Initiation Protocol (SIP) Reason header. The values for the name space of 'SIP-Warning' are taken from the Warning codes (warn-codes) of SIP. In addition, this document also defines one new SIP Warning code to be used in situations where User Agent Server (UAS) does not accept calls from an anonymous source. "Cryptographically Generated Addresses (CGA) Extension Field Format", Marcelo Bagnulo, Jari Arkko, 21-Oct-05, This document define a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. "Low Infrastructure Mutual Authentication Using SPKM-3", William Adamson, Olga Kornievskaia, 17-Oct-05, This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a secure channel between a user on a client and a server, authenticating both the user and server with public key certificates [RFC3280], without the need for an external Public Key Infrastructure for certificate verification. The method leverages the existing Simple Public Key Mechanism Version 3 (SPKM-3) [RFC2847]. In addition to describing the use of SPKM-3 for mutual authentication, this memorandum updates RFC2847, reflecting implementation experience. "RSVP Extensions for Emergency Services", Francois Le Faucheur, 6-Mar-06, An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of call completion to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be achieved through an admission control solution which supports admission priority capabilities and possibly session preemption capabilities (depending on policies and deployed implementations). Admission priority involves setting aside some resources (e.g. bandwidth) out of the engineered capacity limits for the emergency services only, or alternatively involves allowing the emergency sessions to seize additional resources beyond the engineered capacity limits applied to normal calls. This document specifies RSVP extensions necessary for supporting such admission priority capabilities. "Miscellaneous Capabilities for IP Network Infrastructure", Ross Callon, George Jones, 17-Oct-05, The Framework for Operational Security Capabilities [11] outlines the proposed effort of the IETF OPSEC working group. This includes producing a series of drafts to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. Current plans include separate capabilities documents for Packet Filtering; Event Logging; In-Band and Out-of-Band Management; Configuration and Management Interfaces; AAA; and Documentation and Assurance. This document describes some additional miscellaneous capabilities which do not fit into any of these specific catagories, and whose descriptions are brief enough that it does not seem appropriate to create a separate document for each. Operational Security Current Practices [12] lists current operator practices related to securing networks. This document lists miscellaneous 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 may be cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, tradeoffs, etc. "Network-based Fast Handovers for Local Mobility (NFLM)", Mohan Parthasarathy, 17-Oct-05, Local Mobility is IP mobility over a restricted geographical and administrative domain. This document describes a network based localized mobility management protocol which does not require host involvement while moving within such a local mobility domain. "Link Characteristic Information for IP Mobility Problem Statement", Jouni Korhonen, 17-Oct-05, This document discusses the problems related to the link characteristic information delivery from the mobile node to other relevant network nodes. The purpose of this document is to set the scope and goals for possible future work on generic link characteristic information delivery for optimizing IP mobility performance. "Mobile IPv4 Fast Handovers", Rajeev Koodli, Charles Perkins, 17-Oct-05, The Mobile IPv6 fast handover document [2] specifies a protocol to improve latency and packet loss resulting from Mobile IPv6 handover operations. This document adapts the protocol for IPv4 networks to improve performance over Mobile IPv4 operations, including processing of Agent Advertisements, new Care of Address acquisition and Registration Request and Reply. However, operation without Foreign Agent function at a router is also feasible. In addition, the protocol may be used transparently on hosts which do not support Mobile IP, but with limited movement across subnets. Using the concepts outlined in [2], this document also addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration, the document currently proposes that the new CoA is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. "draft-koodli-mipshop-rfc4068bis", Rajeev Koodli, 17-Oct-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. During handover, there is a period when the Mobile Node is unable to send or receive packets due to both link switching delay and IP protocol operations. This ``handover latency'' resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. "Terminology for Describing VoIP Peering and Interconnect", Dave Meyer, 24-Oct-05, This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. "Network-based localized mobility management (NETLMM) with distributed anchor route", Gerardo Giaretta, 17-Oct-05, This document describes a network-based local mobility management protocol that implies minimal host involvement in mobility management procedures and fulfills the requirements provided in draft-kempf-netlmm-nohost-req-00. "NFS Version 4 ACLs", Sam Falkner, Lisa Week, 17-Oct-05, NFS version 4 (specified in RFC 3530) Access Control Lists (ACLs) provide more fine grained control than previous file permission models, but before the full benefit of the model can be exploited, some changes and clarifications must be made. This document will describe the details that implementors should consider in order to allow implementations to function and interoperate better. "IGP protocol extensions for Path Computation Element (PCE) Discovery", Jean-Louis Le Roux, 17-Oct-05, In various situations it would be highly useful for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information relevant for PCE selection. When the PCE is an LSR participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery, consists of relying on IGP flooding. For that purpose this document defines simple OSPF and ISIS extensions for the advertisement of PCE Discovery information within and across IGP areas. "BGP Encodings for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, 3-Mar-06, This document describes the BGP encodings for signaling the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. "A Fast Handover Scheme for Mobile IPv6 Based Wireless Networks", Pyung-Soo Kim, 17-Oct-05, This draft proposes a new fast handover scheme for Mobile IPv6 based wireless networks. To implement the proposed scheme, the beacon message used in L2 is defined newly by adding a specific subfield to the capability information field. In addition, Router Information Request/Reply messages used in L3 are defined newly. The proposed scheme provides the faster acquisition of new access router's network information than the existing one, which might be advantageous for the low handover latency. In addition, the proposed scheme might reduce amount of traffic in comparison with the existing one, which might be remarkable when there are many mobile nodes that are now connecting to current access router. Moreover, in the proposed scheme, a mobile node can know whether it changes access router or access point, which can remove redundant traffic of the existing one. "Client SMTP Authorization (CSA)", David Crocker, 17-Oct-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. "Routing Requirements in Support of R-Bridges", Eric Gray, 18-Oct-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 supports VLANs, allows forwarding tables to be based on RBridge destinations (rather than endnode destinations, allowing internal forwarding tables to be smaller than in conventional bridge systems) and re-uses existing routing protocols (for - at least - distribution of reachability of destinations and shortest path computation within a campus). In order to accomplish this, the design may impose requirements for extensions to existing routing protocols necessary to accomplish the distribution and computation processes, as well as specific limits on interactions between bridge, R-Bridge and Router instances. "Anonymity Support for Kerberos", Larry Zhu, 9-Mar-06, This document defines the use of anonymous Kerberos tickets for the purpose of authenticating the servers and enabling secure communication between a client and a server, without identifying the client to the server. "NDP over IEEE 802.16 Networks", Joo-Chul Lee, 7-Mar-06, IEEE 802.16 issued the new standards for PHY and MAC providing broadband wireless access network. Currently, it is being developed under the assumption that IPv4 is used over it and the use of IPv6 over IEEE 802.16 networks has not been considered yet. Hence, this draft describes several problems in running NDP over IEEE 802.16 networks and presents some proposed solutions for those problems. "Mobile IPv6 Bootstrapping with IKEv1", Vijay Devarapalli, Mohan Parthasarathy, 6-Mar-06, The current Mobile IPv6 bootstrapping mechanisms require the use of IKEv2 between the mobile node and the home agent. If the Mobile IPv6 signaling messages are protected by IKEv1 and IPsec as described in RFC 3776, then the bootstrapping mechanism based on IKEv2 cannot be used. This document describes a bootstrapping mechanism for Mobile IPv6 when RFC 3776 is used. "Problems with Max-Forwards Processing (and Potential Solutions)", Scott Lawrence, 18-Oct-05, This document describes an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. The document analysis ways to limit the impact of this kind of attack, and proposes changes to the SIP protocol to help mitigate the risk. The document also proposes ways to improve diagnosis of failures caused by the hop limit being reached. The purpose of this document is to stimulate discussion of the identified problem and proposed solutions. Much of the proposed solution language appears normative, but implementors should not treat the current document as such. Comments are solicited, and should be directed to the SIPPING working group list at 'sipping@ietf.org'. "General Internet Signaling Transport (GIST) over SCTP", Xiaoming Fu, 22-Feb-06, The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take the advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for some extensions of SCTP is also discussed, namely its Partial Reliability Extension and the usage of TLS over SCTP. "Target Choice of FEC Type", Luca Martini, George Swallow, 18-Oct-05, The Generalized PWid FEC permits a procedure know as single-sided signaling as documented. In this procedure, one end of the pseudowire always initiates the pseudowire setup and the target of that label mapping message only signals in response. For certain applications of pseudowires it is advantages to configure the pseudowire type (PW type) at the target of the initial label mapping message. This document specifies a means of doing this. "Host Identity Tags (HIT) in Presence Information Data Format (PIDF)", Nick Papadoglou, Haris Zisimopoulos, 18-Oct-05, This document describes a new way of exchanging Host Identities (or Host Identity Tags) by means of the Presence Information Data Format [6] using the Host Identity Protocol (HIP). A new presence information element is proposed as an extension to the Presence Information Data Format (PIDF), to include and convey the Host Identity that corresponds to the different SIP URI's the node may have registered. This automatically creates a list of associations between the SIP URI and the Host identity for the different UA instances on the same or different node. "Security Descriptions Extension for Early Media", Rob Raymond, Dan Wing, 18-Oct-05, This document extends security descriptions to allow early media to be received and decrypted. This extension is useful when security preconditionss isn't used. "Password Authenticated Diffie-Hellman Exchange (PAK)", Alec Brusilovsky, 9-Mar-06, This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password Authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. The use of Diffie-Hellman exchange ensures Forward Secrecy. "Network File System (NFS) version 4 byte range delegations", Trond Myklebust, 18-Oct-05, This document describes a set of extensions to the NFS version 4 protocol that enable the client to cache file data when caching conflicts prevent the server from handing out a file delegation. The proposed extensions enable the caching of only those specific byte ranges of data which the user application is reading or writing. As in the case of full delegations, a callback mechanism enables the server to request that the client flush cached data when a caching conflict occurs. "Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links", Kohei Shiomoto, 7-Mar-06, This document addresses topics related to hierarchical and stitched Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that a bi-directional LSP will be used as a dynamically signaled Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the document also addresses the issue of how to indicate that an LSP should be advertised as a traffic engineering (TE) link into a different instance of the IGP and how to identify the instance that should be used. "Temporal Aggregation of Metrics", Steven Van den Berghe, 18-Oct-05, This memo intends to define metrics that allow to aggregate metric samples over a time interval. Metrics that are identical in type and scope but collected at different times, or in different time windows, can be aggregated into a new metric that characterizes the full time interval. The document additionally introduces some comments on terminology and motivation that could be the basis for a more general framework for metric composition. "6in4 versus 6over4 terminology", Jordi Palet, 16-Nov-05, This document clarifies the existing terminology confusion among references to IPv6/IPv4 encapsulations and IPv4/IPv6 transition mechanisms. "Moving Forwards with IETF Process Evolution", Elwyn Davies, 13-Jan-06, This document provides a summary of previously identified problems with the Internet Engineering Task Force (IETF) process for developing standards and other specifications; and then identifies a set of goals to aim at, and guidelines that should be followed during any activity seeking to revise and update this process. It does not propose specific changes to the process, which should be the subject of future documents. "vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 18-Oct-05, This document specifies a set of methods, headers and resource types that define an extension to the WebDAV protocol to support vCard data stored as address books on the server. The new protocol elements are intended to make WebDAV-based address book management an intereropable standard that supports address book access, address book sharing, and address book publishing. "A base Library for use with the ForCES Protocol and Model", Joel Halpern, 7-Mar-06, The Forwarding and Control Element Separation (ForCES) working group is defining a protocol to allow a Control Element (CE) to control the behavior of a Forwarding Element (FE). The manipulations used by this protocol operate in terms of adjustments to Logical Function Blocks (LFBs) whose structure is defined my a model RFC produced by the working group. In order to build an actual solution using this protocol, there needs to be a set of Logical Function Block definitions that can be instantiated by FEs and controlled by CEs. This document provides an initial set of such definitions. It is anticipated that additional defining documents will be produced over time. "Media Control Protocol Framework", Martin Dolly, 24-Feb-06, This document provides requirements for a protocol, that will enable one physical entity that includes the media policy server, notification server and the focus to interact with one or more physical entities that serves as mixer or media server. It will address all phases and aspects of media handling in a conferencing service including announcements and IVR functionality. "Improved Binding Management for Make Before Break Handoffs in Mobile IPv6", Henrik Petander, Eranga Perera, 18-Oct-05, Mobile IPv6 binding management has been designed for break-before- make handoffs, which can be performed by hosts equipped with a single interface. However, a Mobile Node may be equipped with multiple interfaces, allowing it to perform Make-Before-Break handoffs by connecting simultaneously to two overlapping access networks during the handoff. In theory these handoffs can be lossless, provided that there is sufficient overlap between the two networks. However, unless Mobile IPv6 bindings are managed carefully Mobile Node and Correspondent Node will have inconsistent binding state during the handoff, which will lead to packet loss. In this draft we propose changes to binding management for lossless make-before-break handoffs. The proposed changes do not affect the interoperability with Mobile IPv6 nodes not implementing these changes. "Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne, 18-Oct-05, This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. The architecture does not depend on using a specific protocol, but does require that protocols can summarize the coverage region of a node. "Link State Routing Protocols Extensions for ASON Routing", Dimitri Papadimitriou, 8-Mar-06, 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 the extensions of the IETF Link State Routing Protocols to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. "Problem Statement and Requirements for Event and Command Services in Media Independent Handovers", Srinivas Sreemanthula, 8-Mar-06, This document discusses the usage scenarios and usage models of event services and command services involving inter-system IP mobility, specifically media independent handovers. The discussion is intended to aid the MIPSHOP WG in understanding the problem domain and requirements of the event and command services in the Internet. "Reserved Top Level DNS Names", Donald Eastlake 3rd, 18-Oct-05, To reduce the likelihood of conflict and confusion, a few top level and a number of other domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a number of other domain names labels reserved to avoid confusing names or other purposes. "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.", Volker Hilt, Gonzalo Camarillo, 7-Mar-06, This specification defines a Session Initiation Protocol (SIP) event package for session-specific session policies. This event package enables users to subscribe to the policies for a SIP session and to receive notifications if the policies change. The package is part of the Framework for SIP Session Policies. "Automatic Control Channel Protection Protocol for Resilience of Control Channels", Young Hwa Kim, 19-Oct-05, The configuration of control channels with a higher reliability would be an important factor for the more stable provision of communication environment in non-(G)MPLS and (G)MPLS networks. This document specifies an automatic control channel protection (ACCP) protocol that runs between a pair of nodes and is used to support the resilience capability of control channels. The ACCP protocol is based on the concept of common channel signaling in ITU-T and the current control channel management function of LMP in IETF. This ACCP protocol provides functions such as identification of direct and indirect control channels, automatic and forced switchover of those channels, and so on for the resilience of control channels. "A delta format for XML documents", Adrian Mouat, 19-Oct-05, This document specifies an implementation independent format for expressing a set of changes between 2 XML documents. This set of changes is commonly referred to as a "delta" in computing terminology. The delta can be used to automatically transform (or "patch") one XML document into another. "Dynamic Placement of Multi Segment Pseudo Wires", Florin Balus, 19-Oct-05, There is a requirement for service providers to be able to extend the reach of pseudo wires ( PW ) across multiple Public Switched Network 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. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge Routers. "A Framework for Session Initiation Protocol (SIP) Session Policies", Volker Hilt, 7-Mar-06, Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. However, there is currently no standard mechanism by which a proxy can influence session policies such as the codecs or media types to be used. This document specifies a framework for SIP session policies. It defines two types of session policies, session-specific and session- independent policies and introduces a model, an overall architecture and the protocol components needed for session policies. "SNMP Agent Discovery under SSH Transport", Miao Fuyou, 19-Oct-05, This document discusses several possible mechanisms of SNMP engine discovery when SSH is deployed as transport mapping for SNMP. The document proposes a discovery mechanism using UDP transport and User Based Security Model(USM) with a feature of SSH host key distribution. The mechanism tries to reduce discovery cost and in the same time improve SSH host key distribution efficiency. The draft is in "discussion" nature. Maybe there is text that is implementation-related, but the author believes it was not specific to a certain implementation. "Layer 1 VPN Basic Mode", Yakov Rekhter, Don Fedyk, 7-Mar-06, This draft describes the basic mode of Layer 1 VPNs (L1VPN BM) that is port based VPNs. In L1VPN BM, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port-topology. This draft defines the operational model using either provisioning or a VPN auto-discovery mechanism and the signaling extensions for the L1VPN BM. "PCE Policy Architecture", Lou Berger, 19-Oct-05, The PCE architecture [PCE-ARCH] introduces the concept of path computation related policy at a high level. This document provides additional details on policy as applied to the PCE architecture. "Routing Optimization in the same nested mobile network", Sungmin Baek, 19-Oct-05, This document describes a nested NEMO Route Opimization (NNRO) protocol for the communications between any two nodes in the same nested mobile network. A nested NEMO Route Opimization message is used to exchange the routing information between two mobile network nodes in the same nested mobile network. The protocol is designed in a way such that the mobility of the entire nested mobile network is transparent to the nodes therein. "The Miscellaneous Transcoding Error Case and the Multi-Transcoding Scenario", Taegyu Kang, 5-Mar-06, This document presents miscellaneous transcoding error cases and multi-transcoding scenarios. The miscellaneous transcoding errors can occur where there is a codec mismatch between two parties during SIP/SDP codec negotiation in a multi-transcoding environment. The multi-transcoding scenarios are useful for network environments with a signaling/media path separation and multi-transcoding. "A Strawman Architecture for Diffserv Control Plane Elements", Kathleen Nichols, 19-Oct-05, Diffserv (RFC 2474, 2475, and 3086) made explicit that IP QoS can be separated into the differentiated treatment given to packets in the forwarding path and the task of configuring these forwarding path components to allocate QoS according to policy and availability. The IETF Diffserv WG described the forwarding path architecture in detail and specified some specific forwarding path elements. This draft attempts a similar approach of specifying the elements of a diffserv control plane, gives a general architecture and example solution that fits into this architecture, and lays out some issues. An example of a diffserv control plane architecture is presented, derived from the control plane described in RFC2638, and an example implementation of that approach is briefly described. The authors hope to stimulate a discussion of the architectural model and its elements and to elicit more example solutions that may fit, change, or extend the model. A control plane must be configurable, secure, and monitorable. The authors believe the operations and management issues of a diffserv control plane must be made explicit and the approach to solving them properly constrained. Resolving operational and management issues is key to moving to availability of IP QoS. A pdf version of this document is available at: www.pollere.com at Resources: Current Work. "TRILL using Pseudo-Wire Emulation (PWE) Encapsulation", Stewart Bryant, 19-Oct-05, A new layer of encapsulation is required with RBridges. This layer must contain at least a time-to-live and an RBridge identifier field. This document proposes that the reuse of the encapsulation defined by PWE3 for encapsulation of Ethernet frames over an MPLS packet switched network. "AES Counter Mode Cipher Suites for TLS and DTLS", Nagendra Modadugu, Eric Rescorla, 19-Oct-05, This document describes the use of the Advanced Encryption Standard (AES) Counter Mode for use as a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) confidentiality mechanism. "Signaling Tunnel Identifiers and Capabilities in BGP", Rahul Aggarwal, 19-Oct-05, This document proposes a mechanism that allows a router to signal the identifiers of IP/MPLS Tunnels, for which it is the headend, using Border Gateway Protocol (BGP). One application of this mechanism is multicast in BGP - Multi-Protocol-Label Switching (MPLS) Virtual Private Networks (VPNs). This document also proposes a mechanism that allows a router to signal its tunnel enapsulation/decapsulation capabilities using BGP. One application of this is signaling MPLS upstream label assignment capability when BGP is used to advertise MPLS upstream assigned labels. "MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 19-Oct-05, This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. "A Document Format for Filtering and Reporting Location Notications in PIDF-LO", Rohan Mahy, 7-Mar-06, This document describes filters which limit asynchronous location notifications to compelling events. 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. "LABEL-EXP-Inferred-Label Switched Paths", Le Zhang, 19-Oct-05, Solutions have been specified in Multi-Protocol Label Switching (MPLS) Support of Differentiated Services(Diff-Serv) defined in RFC3270. This document describes a new type of Differentiated Services(Diff- Serv) LSP: LABEL-EXP-Inferred-LSP(L-E-LSP).It uses both Label and EXP bits for Differentiated Services. "An Identification of QoS Mechanism for Preconditions", James Polk, 8-Mar-06, The offer/answer model for SDP assumes that endpoints establish, somehow, the QoS (Quality of Service) required for the media streams they establish. Endpoints in closed environments typically agree out of band (e.g., using configuration information) which QoS mechanism to use. However, in the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. "MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux, 19-Oct-05, This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. "Extensions to the Session Initiation Protocol (SIP) Event Package for Conference State", Orit Levin, 19-Oct-05, This document introduces global elements into the SIP Conference Event Package XML schema to make the conference objects and sub- objects easily accessible by schemas external to the event package, such as the XCON conference control protocols. This document also defines the way to introduce XCON extensions into the SIP Conference Event Package in a backwards compatible manner. This document also defines a set of extensions to the SIP Conference Event Package XML schema being used in the XCON conferencing architecture. "Context Transfer Using GIST", Xiaoming Fu, 9-Mar-06, The CXTP specification uses basic SCTP as transport for CXTP message exchanges between a mobile node's previous and new access routers. It also relies on a pre-established IPsec ESP transport mode tunnel. This document discusses two alternative approaches based on "persistent" associations using either SCTP streams feature or GIST protocol. While both approaches reduce context transfer latency during handovers, GIST also offers more flexible transport and richer security properties. "Use of the SHA-256 algorithm in S/MIME", Blake Ramsdell, 19-Oct-05, This document describes the integration of the SHA-256 cryptographic digest algorithm with S/MIME. "SPAM for Internet Telephony (SPIT) Prevention using the Security Assertion Markup Language (SAML)", Daniel Schwartz, 19-Oct-05, Limiting and preventing SPAM for Internet Telephony (SPIT) is seen as an important task for future security work in the Voice over IP environment. This document addresses the problem by utilizing the concept introduced by the SIP Identity Framework in combination with the Security Assertion Markup Language (SAML) to warrant certain security relevant attributes from one administrative domain to another. This approach allows the destination domain to make intelligent filtering decisions when receiving voice calls. "Media Type Registrations for Downloadable Sounds for MIDI", Per Frojdh, 14-Feb-06, This document serves to register a media type for Downloadable Sounds. "Biflow implementation support in IPFIX", Elisa Boschi, Brian Trammell, 27-Oct-05, This document describes how bidirectional flows (biflows) can be implemented in the IP Flow Information Export (IPFIX) protocol. We propose a variety of methods for biflow export, including an extension to the IPFIX Information Model that allows the specification of biflow semantics and a set of counters needed for biflow processing. "BGP Connector Attribute", Gargi Nalawade, 19-Oct-05, In the case of BGP AFIs such as IPv6 unicast or VPNv4 unicast, it is possible for the data traffic intended for the NLRIs of that AFI/SAFI, to be forwarded over an underlying tunnel. The tunnel may be to a PE or to a Tunnel Concentrator or a Tunnel Broker. Both will be referred to as Tunnel endpoints. In this document an egress router refers to the egress point of the Tunnel and an ingress router refers to the ingress point of the tunnel. The discovery of the Tunnel endpoint and the corresponding tunnel encapsulation information may be done out of band, either by static configuration, or through a number of different mechanisms. There is a need to be able to indicate with the BGP update for a given NLRI, the Tunnel endpoint to be used for forwarding data traffic to that NLRI destination. This document defines a new BGP attribute called the 'Connector Attribute' which would convey the information about the Tunnel endpoint - the Tunnel Identifier, the Tunnel endpoint address. "Traversal Using Relay NAT (TURN) Extension for IPv4/IPv6 transition", Gonzalo Camarillo, Oscar Novo, 19-Oct-05, This document defines the Traversal Using Relay NAT (TURN) REQUESTED- ADDRESS-TYPE attribute, which allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). This document also registers the IPv6 address type. "Improving DNS Service Availability by Using Long TTLs", Vasileios Pappas, 3-Mar-06, Due to the hierarchical tree structure of the Domain Name System [RFC1034][RFC1035], losing all of the authoritative servers that serve a zone can disrupt services to not only that zone but all of its descendants. This problem is particularly severe if all the authoritative servers of the root zone, or of a top level domain's zone, fail. Although proper placement of secondary servers, as discussed in [RFC2182], can be an effective means against isolated failures, it is insufficient to protect the DNS service against a distributed denial of service attack (DDoS). This document proposes to mitigate the impact of DDoS attacks against top level DNS servers by setting long TTL values for NS records and their associated A records. Our proposed changes are purely operational and can be deployed incrementally. Our analysis shows that this simple operational tuning has a small impact on DNS performance but can significantly reduce the impact felt by client resolvers as a result of a successful DDoS attacks on the DNS service. "Prolonging Network Lifetime via Intra-Cluster Routing", Jaehwa Lee, 19-Oct-05, An important challenge in wireless sensor network (WSN) is that how to route data packets from sources to base station energy efficiently. Inspiring data fusion feature and multi-hop routing, in this document, we introduce a clustering approach called PLIR (Prolonging Network Lifetime via Intra-Cluster Routing) for saving energy and distributing data dissipation evenly by improving BS cluster formation algorithm of LEACH-Centralized and providing 3-hop routing algorithm within clusters. Hence, it prolongs the lifetime of WSN. PLIR consumes less energy and reduces communication overhead, and extends the network lifetime compared with other approaches. "IPFIX Implementation Guidelines", Elisa Boschi, 9-Mar-06, The IP Flow Information eXport (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. A set of these guidelines refers to the implementation on middleboxes, such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc. "Multi-Interface Routing for Mobile Terminals (MIR)", K Srinivasa, 19-Oct-05, This document defines protocol enhancements that allow a Mobile IP enabled mobile terminal, when away from home, to simultaneously use multiple connected network interfaces for the routed traffic between the home agent and the mobile terminal so as to obtain higher aggregated bandwidth. "Prep-Binding of Fast Handovers for Mobile IPv6", HongFei Chen, Jian Zhang, 26-Oct-05, Fast Handovers are specified in RFC4068, Fast Handovers for Mobile IPv6. This document discusses the issues which happen after the MN moves to the NAR but before it finishes the binding update. "AAA Framework for Multicasting", Hiroshi Ohta, 8-Mar-06, This memo provides a generalized framework for solution standards to meet the requirements presented in draft-ietf-mboned-maccnt-req- 04.txt, "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services". In this framework a user sends a request for multicast data to a network service provider. The network service provider selects the appropriate content provider to which it then sends on the request transparently in a way so that the network service provider and content provider do not need to know the corresponding user id for the same user in the other provider's domain. The content provider then responds with an indication of "success" or "failure" to the network provider and in the case of "success", the network provider may delivery the requested data to the user. The network service may base its decision to deliver such data to the user based on its bandwidth management policy. The framework is designed to be flexible and extendible, so it will be possible to implement partially enabled versions as well as fully enabled versions of the model. Also an additional entity may provide transit of requests between network service providers and content providers, either through relaying or tunneling. "A TCP for Heterogeneous Networks", Choong Seon Hong, 19-Oct-05, Based on incorporating the ECN - Explicit Congestion Notification [RFC3168] and the end-to-end Available Bandwidth Estimation, TCP for heterogeneous networks accommodates a way for TCP sender to be ability of distinguishing the wireless packet losses from the congestion packet losses, as well as estimating of the available bandwidth to adjust transmission rate when the neworks become congested. "Downgrading mechanism for Internationalized eMail Address (IMA)", Yoshiro Yoneya, Kazunori Fujiwara, 9-Mar-06, Traditional mail system handles only US-ASCII characters in SMTP envelope and mail headers. The Internationalized eMail Address (IMA) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver IMA through IMA incompliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP session downgrade, header downgrade and implementation consideration. "The Session Initiation Protocol User Agent Identity Profile Data Set", Daniel Petrie, 19-Oct-05, This document defines the properties and data format for the SIP user agent identity profile data set. The properties in this data set define identities or SIP address of records (AORs) related to incoming or outgoing SIP signaling on a user agent. The identities may be those that are registered via the SIP REGISTER method or identities which are provisioned on the user agent. These identities may be used or referenced when defining identity specific handling related to SIP features on the user agent. "Conflict Detection in MANET Autoconf", Cedric Adjih, Kenichi Mase, 20-Oct-05, Several wireless ad-hoc routing protocols have been and are being developped for MANET. However, autoconfiguration of MANET networks is still an unsettled area, and several methods have been proposed to perform such a task. One of the mecanisms that may be required for address autoconfiguration, is the detection of address conflicts. This is specially true for one of scenarios for MANET autoconf, the This document specifies a general protocol for the detecting address conflicts in a MANET network, and hence addresses a subset of the requirements of a full MANET address autoconfiguration solution. It is specified as an independent protocol from the MANET routing protocol, and the address configuration method, and may be used with any of them. It aims at conceptual simplicity: essentially, a tree of the nodes is built, from which all the information from all the existing nodes is known. Conflicts are detected by the node at root of the tree, or as inconsistent information on the root of the tree. "Media Independent Handovers: Problem Statement", Eleanor Hepworth, 8-Mar-06, There are on-going activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem which is within the scope of the IETF. This draft presents a problem statement for this core problem. "PANA Mobility Optimizations Analysis", Julien Bournelle, 20-Oct-05, The PANA protocol offers a way to authenticate clients in IP based access networks. It carries EAP over UDP which permits ISPs to use multiple authentication methods. However, in roaming environments IP clients might change of gateways and new EAP authentication from scratch may occur. This can considerably degrade performance. To solve this problem, the PANA WG is currently working on a solution based on context transfer between PANA Authentication Agents. The aim of this document is to analyze how this proposal works in a WLAN environment considering various deployment scenarios. "Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing", Ki-Hyung Kim, 20-Oct-05, This document specifies how to use the Dynamic MANET On-demand Routing Protocol over IEEE802.15.4 networks. "The Session Initiation Protocol User Agent VoIP Features Data Set", Daniel Petrie, 20-Oct-05, This document defines the properties and format for the SIP user agent VoIP Features data set. The properties defined in this document are expected to be common to most SIP user agents that provide VoIP capabilities. These VoIP Feature properties are considered to be a data set. Several types of datasets may be combined into documents that are provided to SIP user agents so that they can operate with the desired behavior. "Issues of HIP in an Operators Networks", Thomas Dietz, 20-Oct-05, This document discuss the potential issues that arise when the Host Identity Protocol (HIP) will be introduced in a operator network, especially in the IP Multimedia Subsystem (IMS) of the 3GPP systems. It discusses mobile network specific issues like charging, lawful interception as well as common issues like where to associate the HIP ID or privacy issues. The document tries to make the HIP community aware of those issues and wants to stimulate discussion on those topics. "Generic Notification Message for Mobile IPv4", Hui Deng, 7-Mar-06, This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notfication messages using a generic message header defined in this specification. "Inter-AS PCE Requirements", Nabil Bitar, 27-Oct-05, This document discusses requirements for the support of the Path Computation Element (PCE) in inter-AS applications. Its main objective is to present a set of requirements which would result in guidelines for the definition, selection and specification development for any technical solution(s) meeting these requirements. "Default Well-known DNS Resolver IPv6 Address Using Anycast", Seunghoon Lee, 20-Oct-05, A host needs to configure itself with its own global unicast IP addresses, default gateway IP addresses, and DNS resolver IP addresses. For the IPv6 address of DNS resolver, there is need to define alternative automatic configuration mechanism that enables for an IPv6 host to configure its own DNS resolver IPv6 addresses by itself, even when there is no other additional autoconfiguration mechanism applied. "Analysis of Options for Securing the Generic Internet Signaling Transport (GIST)", Hannes Tschofenig, Pasi Eronen, 20-Oct-05, This document investigates the different options for securing the Generic Internet Signaling Transport (GIST) protocol with the goal of using existing credentials, user and policy databases and other security infrastructure. We examine, among other options, Transport Layer Security (TLS) with X.509 PKI, Extensible Authentication Protocol (EAP), and 3GPP Generic Bootstrapping Architecture (GBA). "Codec specific parameters in SDP", Peili Xu, 8-Mar-06, From time to time, there are discussions to describe some session parameters specific to the codecs in a media in the application of SDP [1]. Codec specific ptime and transport address are two examples. This document analyses those requirements, and provides the evaluation for possible solutions. "IPv6 NDP for Common Prefix Allocation in IEEE 802.16", HongSeok Jeon, Junghoon Jee, 8-Mar-06, IPv6 Neighbor Discovery Protocol [RFC 2461] assumes that the underlying link layer support native multicast while IEEE 802.16 is a point-to-multipoint network without bi-directional native multicast support. Such a discordance between IPv6 Neighbor Discovery Protocol and IEEE 802.16 network results in the on-link and multicast issues. This document defines a mechanism, IPv6 NDP Relay and Multicast Emulation, to solve these issues. "Reed Solomon Error Correction Scheme", Jerome Lacan, 20-Oct-05, This document describes a Fully-Specified FEC scheme for the Reed- Solomon forward error correction code and its application to reliable delivery of data objects on the packet erasure channel. The Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e, they enable a receiver to recover the k source symbols from any set of k received symbols. The implementation described here is compatible with the IPR-free implementation described in [5]. "Secure Route Discovery in Low-Rate WPAN", Dongjin Kwak, 20-Oct-05, A low-rate wireless personal area network (LR-WPAN) is a network designed for low-cost and very low-power short-range wireless communications. It is hard to employ static routes. Route discovery is the procedure whereby network devices cooperate to find and establish routes through the network and is always performed with regard to a particular source and destination device. However, Route discovery in LR-WPAN has lack of authentication mechanism. Also, dynamic network topology makes it arduous to detect malicious nodes. We proposed a secure route discovery authentication mechanism using the ¥ìSRD. ¥ìSRD uses RREQ ID, destination address and the unique value as input string to generate authentication code (AC). It is used as the authentication between source node and destination node. "Network initiated handovers problem statement", Telemaco Melia, 7-Mar-06, This is a first document describing the rational about network support for decision making and execution of handovers. Starting from existing technologies and considering new trends from mobile operators, we draw potential deployment scenarios and derive a set of associated functionalities. These functionalities and associated assumptions are listed in the document. Application areas for network initiated handovers are then illustrated specifying a set of goals and non-goals to be addressed in a future version. "Role Definitions for Centralized Conferencing", David Morgan, Oscar Novo, 20-Oct-05, This document defines the set of possible conferencing roles that are used to represent participants withing a Conference Object (as defined in the XCON Conference Framework [1]). The document also provides a set of semantics associated with each role. Additional roles may be defined in the future, as necessary, with their corresponding schema extensions, as appropriate. "DHCP Relay agent Request from Multi Address Pool", Zi Kang, 20-Oct-05, This document modifies the Subnet selection option and defines a new sub-option of the relay-agent-information option. Each of these options is used by the relay agent to tell the DHCP Server to allocation address from more than one address pool. "Link Aggregation Member Interface Status Signal", Zi Kang, Liu Jun, 20-Oct-05, Link Aggregation can be used as Attachment Circuit (AC) of the PWE3 service. Link Aggregation is treated as a single interface. But changes in the the member interface may affect use of the aggregated link. This draft suggests a method to signal the status of the member interface of Link Aggregation AC to remote Provider Edge (PE) device. With this status information, the remote PE can decide to discard traffic over bandwidth, avoid congestion at local PE and avoid wasted bandwidth of the Packet Switched Network (PSN). This mechanism is required in PWE3 applications because pseudo-wires provide layer 1/layer 2 services, carrying traffic that may not respond to loss events by executing congestion avoidance "Handling Path Constraints in Generalized RSVP-TE signaling", Dimitri Papadimitriou, Jean-Louis Le Roux, 26-Oct-05, In various situations, it would be useful to include aggregated path parameters such as, e.g., delay, hop-count or optical power, within Generalized MPLS signaling. For that purpose, this draft extends GMPLS RSVP-TE, for signaling end-to-end path constraint, and aggregating path parameters along the path. This draft only defines generic encoding rules and procedures. Specific encoding and procedures for each path parameter will be addressed in separate documents. "Update to RFC 3455: (Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage, 20-Oct-05, RFC3455 [3] describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. Since RFC3455 [3] was approved in 2003, a number of minor corrections and extensions have arisen whose documentation would be convenient to 3GPP. This proposed update to RFC3455 [3] provides those minor corrections and extensions. "Multicast Link State For Rbidges", Susan Hares, 20-Oct-05, Rbridges are transparent Layer 2 bridges that provide the ability to have an entire campus, with multiple physical links look like a single subnet. The Rbridge technology utilizes Rbridges to link together Layer 2 areas using spanning trees to calculate paths. The Rbridges run a link state protocol to determine the least cost paths Rbridges and exchange information about the location of MAC addresses. The Rbridges will run a level 1 or a single area routing protocol. To forward multicast packets, the Rbirdges may treat these as broadcast (sending the packets to all Rbridges) or use methods to snoop the Multicast MAC addresses (GARP, MAC learning) or IP/MAC address packets (IGMP/PIM snooping). Multicast Link State Rbridge connections suggest a Hybrid Multicast Link state extensions to ISIS and OSPF for Rbridges. "Problem Statement for Heterogeneous Handover", Ashutosh Dutta, 1-Mar-06, This document describes the problem statement and a set of issues and requirement specific to heterogeneous handover. Careful consideration needs to be given to these set of requirements while designing an optimized handover framework in a heterogeneous mobility scenario. These problem statements help determine the key functions that are responsible for delay during handover involving interdomain and heterogeneous access technology. Analysis of these issues and requirements can be applied to any existing mobility optimization framework. "Analysis of Multiple Mobile Routers Cooperation", Manabu Tsukada, 20-Oct-05, This document is an analysis of multiple Mobile Routers Cooperation in the context of network mobility support (NEMO) in IPv6. Our objective is to identify when cooperation between MRs is needed and what information must be exchanged. "Load Balance-based Reorganizing Protocol for SOS in Active Network", Jaehwa Lee, 20-Oct-05, Secure overlay services (SOS) architecture has been proposed to provide reliable communication between clients and a target under DDoS attacks. The SOS architecture employs a set of overlay nodes arranged in three hierarchical layers that controls access to the target. Although the architecture is novel and works well under simple congestion based attacks, we observe that it is flimsy after it resisted the DDoS for a period of time and it didn't pay attention to the endurance of the Nodes. We propose an Algorithm to improve the secure overlay services (SOS) both on load balance and resilient. "draft-tuexen-sctp-udp-encaps", Michael Tuexen, Randall Stewart, 20-Oct-05, This document describes a simple method of encapsulating SCTP Packets. This makes it possible to use SCTP in networks with legacy NAT not supporting SCTP. "GMPLS control of Ethernet IVL Switches", Don Fedyk, David Allan, 20-Oct-05, This memo describes how GMPLS signaling may be applied to appropriately configured Ethernet Independent VLAN Learning capable switches in order to configure Ethernet switched paths. "GMPLS Inter-domain routing problem statement and requirements", Satori Okamoto, Tomohiro Otani, 20-Oct-05, This draft provides problem statement and requirements of inter- domain routing in a generalized multi-protocol label switching (GMPLS) network. The reachability information exchange must be supported for appropriate signaling operation in a GMPLS network, as the same with the IP/MPLS inter-domain case. "Network Controlled Handover Problem Statement", Yong Cui, 20-Oct-05, This document describes why network controlled handover is necessary to future IPv6 deployment, and also outlines some of its features. "Widget Description Exchange Service (WIDEX) Requirements", Vlad Stirbu, Dave Raggett, 20-Oct-05, This document defines functional requirements for a framework and a protocol used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update/mutation operations. "IANA Registration for IAX Enumservice", Ed Guy, 20-Oct-05, This document registers the IAX2 Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761. "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification", Francois Le Faucheur, 20-Oct-05, This document specifies the extensions to RSVP for support of the Controlled Load (CL) service over a Diffserv cloud using Pre- Congestion Notification as defined in [CL-ARCH]. "Transport of IP over 802.16", Jeff Mandin, 20-Oct-05, In this memo we describe a simple scheme for configuration and provisioning of an 802.16 network so that it emulates a broadcast network that uses the 802.3 packet format. We briefly describe how this network supports IPv4 and IPv6 services in a manner similar to other broadcast media (eg. ethernet). Finally, we review some architectural issues behind the choice of broadcast network emulation and examine alternative approaches to supporting IP over 802.16. We additionally describe some possible system optimizations to reduce consumption of air resources. "Privacy Terminology", Wassim Haddad, Erik Nordmark, 20-Oct-05, This memo introduces the terminology for the main privacy aspects. The prime goal is to avoid situations where different interpretations of the same key privacy aspects result in different requirements when designing specific solutions, thus leading to an unnecessary confusion. "Detecting Network Attachment in IPv6 Networks (DNAv6)", Brett Pentland, 20-Oct-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. In this memo, an integrated solution is presented. Monitoring of prefixes by both hosts and routers is used to achieve link identification while router advertisements are sent rapidly in a deterministic order by combining router solicitation source addresses with hash-based router tokens. "TCP Alternatives with Interactive Connectivity Establishment (ICE", Jonathan Rosenberg, 20-Oct-05, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Simple Traversal of UDP over NAT (STUN). ICE provides a general framework for describing alternates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. "Address Resolution for GMPLS controlled PSC Ethernet Interfaces", Zafar Ali, Tomohiro Otani, 7-Mar-06, This document outlines some issues with the use of ARP over GMPLS controlled Ethernet router-to-router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC GMPLS core. The document also proposes solutions accordingly. "Requirements and Possible Mechanisms for File Transfer Services Within the Context of SIP Based Communication", Markus Isomaki, 8-Mar-06, This document describes use cases and defines requirements for how different types of file transfer services could be integrated into the general Session Initiation Protocol (SIP) based communication framework. It also explores some of the possible solutions to meet those requirements, either based on existing protocol mechanisms or defining minor extensions to them. The purpose of the document is to start the discussion on whether some new standardization work is needed in this area. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, 9-Mar-06, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol arranges an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. Then the upstream party at any trust boundary in the internetwork can be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability and policing mechanisms for incoming traffic from end-customers or from neighbouring network domains. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end-points will be to set the extended ECN field honestly. "PIM Snooping over VPLS", Venu Hemige, 20-Oct-05, "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 9-Mar-06, The Real-time Transport Protocl (RTP) is a widely used transport for real-time media on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. "Considerations for Having a Successful BOF", Thomas Narten, 8-Feb-06, This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. "FAIS Line Interface Protocol Architecture & Requirements", Roger Cummings, 10-Mar-06, FAIS Line Interface Protocol (FLIP) describes mechanisms that allow a set of functions that have been defined for an internal API related to storage virtualization to be extended to operate over a TCP/IP infrastructure. Significant deployment and configuration flexibility is gained by taking such an approach. "Radio Network Protocol", Susan Hares, Nehru Bhandaru, 20-Oct-05, The CAPWAP problem statement 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. RNP is a protocol that supports the management of WTP's Radio information, Session Parameters, Data Forwarding and interaction with the Wireless Portal. The RNP protocol consists of five sub- protocols: RNP-DT (Data Tunneling), RNP-SM (Session Management), RNP-RC (Radio Control), RNP-DF (Data Forwarding), and RNP-WP (Wireless Portal). The RTP protocol with it's family of protocol provides a complete control situation for the CAPWAP environment. In many ways, RNP provides a super set of the RNP requiremetns. "Energy Efficient Routing for Highly Dense Sensor Network Based on Residual Energy and Distance", Dongjin Kwak, 20-Oct-05, Efficient energy utilization and prolonged lifetime are two most covetable targets for sensor network. For increased lifetime,each node must conserve energy as much as possible. In this paper we propose a protocol in which energy is conserved by amortizing the energy cost of superfluous packets and idle state energy consumption To achieve our goal we have exercised well-known periodic sleep protocol and reduce redundant transmission by creating broadcast tree based on residual energy and distance based communication cost. Wasteful energy consumption of sensor nodes (e.g. idle listening, retransmission due to packet collision, overhearing etc) can be minimized by selecting minimum number of forwarding nodes. Our proposed algorithm selects minimum number of forwarding while creating broadcast tree. All intermediate nodes acts as forwarding node (non-leaf) while all the other nodes acts as a non-forwarding (child) reduces wasteful energy consumption by keeping radio transceiver off. Simulation shows our algorithm is better in terms Dense Sensor Network Based on Residual Energy and Distance of energy conservation and network lifetime "Load Balancing in MANET with Multiple Internet Gateways", Sanghyun Ahn, 20-Oct-05, In MANET, nodes wishing to communicate with nodes in the wired Internet, the global Internet connectivity is required and this functionality can be achieved with the help of the Internet gateway (IGW). For the support of reliability and flexibility, multiple IGWs can be provisioned for a MANET. In this case, load-balancing becomes one of the important issues since the network performance such as the network throughput can be improved if the load of the IGW is well-balanced. In this draft, we categorize the load-balancing mechanisms for the IPv6-based MANET with multiple IGWs and define a new load-balancing metric computed from the hop distance and the number of routing table entries. "DHCP cluster", Francois Bourdais, 20-Oct-05, This document describes a design of DHCP server that relies upon the use of an external storage entity. Such solution provides an alternative solution to the DHCP failover protocol for the deployment of multiple DHCP servers. "IPv4 Network Mobility (NEMO) Basic Support Protocol", Kent Leung, 20-Oct-05, This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. "Multicast State Distribution between VPLS PE routers Using LDP", Ray Qiu, 9-Mar-06, In Virtual Private LAN Service (VPLS), as also in IEEE Bridged Networks, the switches simply flood multicast traffic on all ports in the LAN by default. Multicast Snooping can be used to avoid the unnecessary flooding as defined in [MAGMA-SNOOP] and [PIM-SNOOP]. When the number of Pseudo Wires (PWs) and refresh messages increases dramatically, it is desirable to reduce the messages exchanged between VPLS PE routers to improve scalability. This document describes the procedures and recommendations for using LDP for distributing Multicast state information between VPLS PE routers. "An Extension to Avoid the Occurance of HERFP", Adam Roach, 20-Oct-05, The processing of SIP reqeusts by certain types of proxies can lead to situations in which multiple non-sucessful responses are generated, only one of which is ultimately reported to the originator of the response. In many cases, these non-successful responses indicate conditions that can be addressed by the requestor, and then retried; therefore, the elision of them by proxies can lead to a decrease in the rechability of certain network entites. This document defines a mechanism that can be employed to avoid the dropping of such requests with minimal implementation complexity. "Discussion on Requesting a mobile nodes binding information from a Home Agent", Robert Jaksa, 20-Oct-05, This draft documents an idea whereby a Mobile IPv6 node may request binding information from its respective Home Agent about other Mobile IPv6 nodes all using the same home agent. "Extensible MANET Auto-configuration Protocol (EMAP)", Pedro Ruiz, Francisco Ros, 7-Mar-06, Mobile Ad Hoc Networks need an auto-configuration protocol being able to satisfy their self-deployment requirements while remaining flexible enough to accommodate special features for different devices. The Extensible Manet Auto-configuration Protocol (EMAP) tries to fullfil these requirements both for IPv4 and IPv6 mobile ad hoc networks. It provides auto-configuration mechanisms for isolated as well as hybrid MANETs, and is envisioned to be integrated within unicast routing protocols (like DYMO [1] or OLSRv2 [2]). EMAP allows nodes to create a (highly likely) unique IP address which can be used locally inside the MANET. In a similar way, nodes can auto-configure globally routable IP addresses when one (or more) gateways to the Internet are present in the network. The general framework provided by the protocol may be used as a service discovery protocol for MANETs. As an example, this document also specifies an optional feature which consists on the discovery of DNS servers reachable from the MANET. However, the approach is extensible to other services like SIP proxies, authentication entities, etc. Therefore, EMAP has been designed taking into consideration the possibility of extending it later on with new features, uses, and optimizations. "DNS Glue RR Survey and Terminology Clarification", Peter Koch, 8-Mar-06, This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different TLDs. "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", HeeYoung Jung, 20-Oct-05, This document proposes a scheme to support Fast Handover over HMIPv6 networks. The HMIPv6 was developed to reduce the signaling overhead and delay concerned with Binding Update in Mobile IPv6. Therefore HMIPv6 still need a further handover enhancement for supporting the real-time applications. Currently FMIPv6 is the typical protocol to reduce the handover latency. Accordingly it may be straightforward to simply introduce FMIPv6 into HMIPv6 networks. However, it is noted that such simple approach may induce unnecessary processing overhead. F-HMIPv6, described in this document, considers how to integrate these two protocols and provides a scheme for effective integration. "IPv6 VPN Based Address Format", Bin Lee, HongFei Chen, 20-Oct-05, This text introduces a kind of method to carry out VPN based on IPv6 addresses, defines VPN unicast and multicast address structure and the method to construct VPN topology, and depicts unicast and multicast routing and forwarding process between VPN sites. Moreover, this text discusses VPN security. "PANA Mobility Optimizations with Session Keys Context (SKC)", Dan Forsberg, 21-Oct-05, This specification describes an extension to the PANA protocol that enables usage of a AAA Proxy acting as a Key Distribution Center (KDC) for multiple local PANA Authentication Agents. The AAA Proxy acts as the contact point towards the AAA home server (single SA) and a AAA server and KDC towards the PAAs. This document assumes that the local network has multiple PAAs. To avoid signalling between PAAs and the KDC, a Session Key Context is also defined which permits to the KDC to proactively provide a set of keys to a PAA. Session Keys can then be fetched using CXTP. "Improved Assert in PIM-SM", Venu Hemige, 21-Oct-05, In [PIM-SM], assert procedures are triggered by data-plane interaction with the control-plane when traffic arrives on an outgoing interface. There are several disadvantages with this in that duplicate traffic is forwarded downstream until an assert winner is elected and seen by all routers on the LAN; such dependence on the data-plane to build control-plane state does not scale well. When [PIM-SM] is used to setup P2MP LSP trees as in [SURESH-P2MP], it is not always possible to determine if traffic arrived on an outbound interface . This draft proposes mechanisms to trigger assert completely in the control plane by reacting to Joins sent to another router on a LAN. These procedures are essential when it is not possible to determine if traffic arrived on an outbound interface. It also helps completely remove the dependency on data-plane to trigger asserts and eliminates duplicate traffic resulting from assert scenarios. "Alert Filtration and Fusion(AFF) in Intrusion Management System", Yixian Yang, 21-Oct-05, Alert Filtration and Fusion (AFF) is proposed to solve the problems of existing IMS(Intrusion Management System). The Alert Filtration is used to filtrate original alerts and reduce the alerts which are obviously unavailable. The Alert Fusion is used to reduce redundant alerts and find the relationships of alerts. The false positive rate and false negative rate can be reduced by Alert Filtration and Fusion. "Analysis of multiple interfaces in a Mobile Node", Yong-Geun Hong, 21-Oct-05, This document is an analysis of multiple interfaces in a mobile node using Mobile IPv6 or a mobile router using NEMO Basic Support. The current Mobile IPv6 and NEMO Basic Support are suitable for a single network interface. When a mobile node or a mobile router has multiple interfaces, the current Mobile IPv6 and NEMO Basic Support cannot directly be used for them. In this document, we describe some problems for a mobile node which has multiple network interfaces when the mobile node is using Mobile IPv6 as an aspect of a node. "Virtual network interface for multiple interfaces in a Mobile node using Mobile IPv6", Yong-Geun Hong, 21-Oct-05, The use of Mobile IPv6 in a mobile node and NEMO Basic Support in a mobile router with multiple network interfaces may have some problems. This document discusses how to solve the problems of multiple interfaces in a mobile node and proposes a virtual network interface model which describes the use of Mobile IPv6 to support multiple network interfaces in a mobile node. "Call Pickup Examples in SIP", Dale Worley, 2-Mar-06, This document walks through various examples and call flows for implementing "call pickup" operations in SIP telephony. It focuses on distributing as much processing as possible in the user agents in accordance with the philosophy of end-point controlled call-control (EPCC). Various difficulties in implementing call pickup are discussed, and further suggestions and discussion are solicited. "Name-Based Autoconfiguration for MANET", Namhoon Kim, 21-Oct-05, In a mobile ad hoc network, difficulties exist in supporting address autoconfiguration and naming resolution due to the lack of centralized servers. This document presents a novel approach, called Name-Based Autoconfiguration (NBA), which uses host names to determine IP addresses and provides address autoconfiguration and name resolution as a single protocol. "AROD: An address autoconfiguration with Address Reservation and Optimistic Duplicated address detection for mobile ad hoc networks", Namhoon Kim, 21-Oct-05, Every node must configure its network interface with a unique address in order to communicate with other nodes. Having a centralized DHCP server that provides addresses to nodes, we can easily and automatically obtain addresses. However, in a mobile ad hoc network, difficulties exist in supporting address autoconfiguration due to the lack of the centralized servers. We therefore propose a distributed address autoconfiguration approach for a mobile ad hoc network using address reservation and optimistic Duplicated Address Detection. The reserved address helps to reduce the allocation latency, and the optimistic DAD guarantees the uniqueness of addresses with smaller communication overhead. "Multi-layer Intrusion Tolerance Based On Threshold(MIT)", Yixian Yang, 21-Oct-05, Multi-layer Intrusion Tolerance Based On Threshold(MITT) is proposed to solve the problems of maintaining acceptable service, despite existing intrusions. MITT integrates redundancy and variety architectures, and utilizes the threshold secret share schemes to implement the survivability of system and to protect confidential data from compromised service in the presence of intrusions. "Key Technologies of Intrusion Prevention Systems(IPSs)", Yixian Yang, 21-Oct-05, Intrusion prevention systems(IPSs) are a kind of systems that can keep away and interdict intrusions actively. This document puts forward some relevant solutions to the existing problems in IPSs at present. Zero-copy technology is adopted to reduce the system expenses, in order to optimize communication performance; Load balancing technology guarantees the flow distributed at each IPSs engine even; Protocol analysis technology improves detection efficiency to a certain degree. The structure of detection engine designed can be either a node of Large-scale Distributed Intrusion Prevention Systems or an independent IPS. "An Algorithm for Intrusion Prevention System based on Fuzzy Connectedness Clustering", Yixian Yang, 21-Oct-05, In this document, an algorithm for intrusion prevention systems based on fuzzy connectedness clustering was presented in order to measure the similarity. Fuzzy connectedness that was first applied in image segmentation was extended to clustering algorithm, and used as the similarity metric between objects to be clustered. By a little expert knowledge, starting with at least one seed data in each cluster, the similarity between each data in dataset and each seed data in each cluster was measured. According to the highest fuzzy connectedness of each data, clustering was finished. This algorithm was applied in intrusion prevention systems as a tool of detecting intrusion, overcoming some shortcomings of previous clustering algorithm. "A Framework for Large-scale Distributed Intrusion Management System(LDIMS)", Yixian Yang, 21-Oct-05, Network is now developing into large-scale and speedup, meanwhile, intrusion methods become more and more complicated. In this network environment, traditional IDSs can¡¯t insure the security of the protected systems. IMS is the trend of IDSs evolution. IMS is a system that combines intrusion detection with urgent response. In IMS, IDSs associate with other security components, such as Firewalls, Vulnerability Scanning Systems, Virus Prevention Systems and network Management Systems. This document describes a hierarchy framework for Large-scale Distributed Intrusion Management System (LDIMS), with which a Large-scale Distributed IMS can be flexibly deployed. layered nodes constitute this framework. Each node is a simple IMS. This document gives a four-layer structure for the simple IMS, the four-layer structure can also be the structure of an independent IMS. "P2MP LSP Setup using PIM-SSM and LDP", Suresh Boddapati, Venu Hemige, 21-Oct-05, There is emerging interest in the use of MPLS LSPs for the delivery of multicast traffic. Efficient delivery of multicast traffic using MPLS requires P2MP LSPs. This document describes a mechanism to setup P2MP LSPs using PIM-SSM and LDP. PIM-SSM is a widely deployed multicast routing protocol and has well defined procedures for signalling multicast traffic. LDP is a well defined mechanism for distribution of MPLS labels. Utilizing both PIM-SSM and LDP for setting up P2MP LSPs keeps the clear separation between signalling and label distribution, and minimizes changes to both protocols. PIM-SSM signals when to receive multicast traffic and LDP distributes label information regarding how to receive multicast traffic. "BGP-based Auto-Discovery for L1VPNs", Hamid Ould-Brahim, 9-Mar-06, The purpose of this draft is to define a BGP-based auto- discovery mechanism for layer-1 VPNs. The auto-discovery mechanism for l1vpns allows the provider network devices to dynamically discover the set of PEs having ports attached to CEs member of the same VPN. That information is necessary for completing the signaling phase. One main objective of l1vpn auto-discovery mechanism is to support "single-end provisioning" model, where addition of a new port to a given l1vpn would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. "Review of Threats Associated with Email and DomainKeys Identified Mail (DKIM)", Douglas Otis, 27-Oct-05, This document is intended to provide an alternative perspective to the document prepared by Jim Fenton for DomainKeys Identified Mail (DKIM), although it borrows from his substantial effort. This review removes emphasis on email-address domains, as DKIM allows signatures to be independent of the email-address. This document also considers the impact of adding an opaque-identifier and implementing abusive message replay abatement. This document considers threats against Internet mail and threats created when employing a signature-based method for establishing an accountable domain for a message, in particular DKIM. This document also ranks threat levels, modes of access, Bad Actors and their capabilities, and possible motivations for various attack scenarios. "Softwire Problem Statement", Alain Durand, 21-Oct-05, This document defines problem statements for the Softwire Working Group to solve. At the highest level, the softwire WG is tasked to identify, and extend where necessary, standard protocols to support a selected set of IPv4 in IPv6 and IPv6 in IPv4 transition problems. This document describes the distinct problems that will be solved as part of a solution phase following the completion of this document. Some individual requirements (and non-requirements) are also identified in this document at times in order to better describe the specific scope for a given problem definition. "Securing LWAPP with DTLS", Scott Kelly, Eric Rescorla, 13-Dec-05, The LWAPP protocol defines interactions between wireless termination points and wireless access controllers. Communications between these components must be secured, and the current specification provides for transport security using proprietary mechanisms which are embedded in the protocol. This document describes an alternative approach which eliminates the embedded security, and instead uses DTLS as a secure, tightly-integrated wrapper. "Using HTTP for IMG Transport", Joerg Ott, Kevin Loos, 21-Oct-05, The IMG framework document defines a set of abstract operations to distribute and retrieve Internet Media Guides (IMG). This document specifies the mapping of the abstract operations QUERY and RESOLVE to HTTP which includes mapping IMG URIs are parameters to HTTP URIs. IMG envelopes are used to encapsulate IMG contents. This is an initial strawman intended to provoke discussion. "Edge Mobility Protocol (EMP)", Jonathan Wood, Katsutoshi Nishida, 21-Oct-05, This document specifies a protocol for localized mobility management which allows the mobile node to keep using the same IP address while it is in the same localized mobility management domain. The protocol enables the edge mobility anchor point to manage the routing path for the mobile node in the domain, so that the packet form the correspondent node can be delivered to the access router of MN currently connecting. For routing path management, the protocol also specifies the functionality of the access router to provide the MN's IP address, MN identifier to edge mobility anchor point. The protocol does not require the mobile node to involve in the mobility management if link layer technology can provide MN related information necessary for this protocol. "RADIUS Mobile IPv6 Support", Kuntal Chowdhury, 9-Mar-06, A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document defines the new attributes to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. This information exchange may take place as part of the initial network access authentication procedure or as part of a separate protocol exchange between the mobile node, the home agent and the AAA infrastructure. "POTS, GETS,MLPP call comparison", Stuart Goldman, 21-Oct-05, This document provides a high level conceptual discussion on the significant modeling differences affecting the treatment of a POTS (Plain Old Telephone Service) call, a GETS (Government Emergency Telephone Service) call, and an MLPP (Multilevel Priority and Preemption) call in the traditional voice PSTN (Public Switched Telephone Network). The genesis for this discussion on these services is primarily from experience with the United States capabilities and it is appreciated that these types of calls may be very different or non-existent in other regions of the world. Still, it may be useful to provide this discussion as a background, which may be useful in understanding the legacy operations as the chartered ieprep work progresses. It should be made clear from the onset that this document suggests no requirements or solutions, but is merely informative about the tradition voice network treatments. "NAT Behavioral Requirements for ICMP protocol", Pyda Srisuresh, 6-Mar-06, This document identifies the behavioral properties required of the Network Address Translator devices (NATs) in conjunction with the ICMP protocol. The objective of this memo is to make NAT middleboxes more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP and UDP. "Combining Cryptographically Generated Address and Crypto-Based Identifiers to Secure HMIPv6 (HMIPv6sec)", Wassim Haddad, 7-Mar-06, This memo describes a method for establishing a security association between the mobile node and the selected mobility anchor point in an hierarchical mobile IPv6 domain. The suggested solution is based on combining the cryptographically generated address (CGA) and crypto- based identifiers (CBID) technologies. "Protocol Requirements for mobility in LoWPAN", Dipnarayan Guha, Thambipillai Srikanthan, 21-Oct-05, In this draft, we propose some protocol requirements for mobility in LowPAN networks within the context of the IETF LowPAN working group (IPv6 over IEEE 802.15.4). To achieve mobility in LowPAN networks, there may be inter-domain movement of network elements across different LowPAN domains or across domains that do not comprise LowPAN autonomous systems. To address routing issues in inter-domain LowPAN networks that conform to fitting within a single IEEE 802.15.4 frame, there are needs for collaborative and distributed methodologies for route computation, information storage and retrieval, and security issues in protocols targeted to LowPAN mobility. This draft proposes some requirements of mobility in LowPAN protocols from the perspective of protocol-independent metrics, algorithm complexities, scalability and security criteria. "NETLMM Protocol", Ippei Akiyoshi, Marco Liebsch, 21-Oct-05, This document specifies a network-based protocol which allows mobile nodes to remain reachable while moving around a certain administrative network called Edge Mobility Domain. This protocol also allows mobile nodes to keep their IP address when the mobile nodes move from one access router to another within the Edge Mobility Domain. "Multicast PE to PE Signaling Using BGP", Gargi Nalawade, 24-Oct-05, Multicast PE to PE Signaling is a key component of the L3MVPN architecture defined in MVPN [1]. This draft considers the option of using BGP with extensions for Multicast VPNs and describes the tradeoffs involved in using BGP. "An XML Format for Representing XML Configuration Access Protocol (XCAP) Change Logs", Jonathan Rosenberg, 25-Oct-05, The XML Configuration Access Protocol (XCAP) Diff Format defines a simple XML format for indicating that an XML document has changed. This format does not indicate the actual change in the document; just that it changed. However, the XCAP Diff Format is extensible, to allow inclusion of the actual document changes. This specification defines an XML schema that can be used to represent a set of changes in an XCAP document. "Benefits of multiple care-of addresses and home addresses for low power multimode mobiles", Shiao-Li Tsao, 25-Oct-05, It is expected that future mobile devices will equip multiple wireless interfaces in order to access the Internet ubiquitously. For such a multimode mobile node (MMN) that might have multiple home addresses to associate with its interfaces, the MMN has to keep its interfaces awake to listen the packets to these home addresses (HoAs). Therefore, the MMN consumes a considerable energy to maintain the reachablilities of these HoAs/interfaces. The draft presents the benefits to use multiple care-of addresses and/or home addresses to save the idle-mode power consumption of an MMN, and also discusses the impacts and the requirements of the existing IETF protocols to support the proposed low power operations. "Managements for using multiple home addresses as care-of addresses", Taewan You, 26-Oct-05, This draft proposes a simple method that multiple HoAs obtained by each of heterogeneous interfaces should be registered to home agents as like CoAs to support benefits of multihoming, such as ubiquitous accessibility, redundancy, and inter interface handover. However, a protocol for using HoA as CoA was already referred by [ID.Multi_PB]. In this draft, we should extend situation that HoAs are used as like CoAs, and modify registration protocol for multiple CoAs [ID.MCoA] [ID.MMI] to support reliable and robust network connectivity. "Quality of Service Extension to Dynamic MANET OnDemand Routing Protocol", Namhi Kang, Younghan Kim, 5-Mar-06, This document describes extensions to the Dynamic MANET On-demand (DYMO) routing protocol in order to enable mobile nodes to discover and maintain QoS routes. DYMO is a reactive (on-demand) routing protocol designed for use by mobile nodes in multi-hop wireless ad hoc networks. Extensions of this document include the necessary additions to the routing table and the DYMO message element. "A Scheme for the Security between Mobile Node and Mobility Anchor Point in Hierarchical Mobile IPv6", F Bao, 26-Oct-05, The document proposes the solution for the security between mobile nodes and MAPs. According to the requirements of the security statement in the working group, two modes for two scenarios are considered in the draft: authentication-only mode and authentication and authorization mode. "Extension MIB for ENUM management", Yongtae Shin, 26-Oct-05, It is service that ENUM replaces existent IP by telephone number and a user does various kinds devices so that is available by one peculiar number. As this ENUM's DNS becomes bulky, we need monitoring for ENUM. There is MIB to monitoring method that is used present. We propose standard for efficient ENUM DNS administration applying extension MIB that is this MIB's extension to ENUM. "CableLabs-IETF Standardization Collaboration", Mark Townsley, Jean-Francois Mule, 3-Mar-06, This document describes the collaboration between the Cable Television Laboratories, Inc. (CableLabs) and the Internet Engineering Task Force (IETF). "IP location update for Network Controlled Mobility Management: Problem Statement", Eric Njedjou, 27-Oct-05, Mobile IP is good at addressing IP session continuity (hide of the IP address change from transport layer perspective, as well as from the correspondent perspective) but certainly not optimal for mobility management as would perform 3GPP systems providers that want to extend their services to IP access systems. This document only describes the problem and is not meant to provide any solution nor any requirement thereof. "Multicast Mobility in MIPv6: Problem Statement", Thomas Schmidt, Matthias Waehlisch, 27-Oct-05, In this document we discuss mobility extensions to current IP layer multicast solutions. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented subsequently. The principal approaches to multicast mobility are introduced in brief. "BGP Aggregate Withdraw", Robert Raszuk, 28-Oct-05, This document proposes a scheme that allows a BGP speaker to withdraw multiple NLRIs that share a set of properties more efficiently by just specifying the shared properties among them. "A profile of the XML Configuration Access Protocol (XCAP) for manipulating resource lists and authorization lists", Rohan Mahy, 7-Mar-06, This document describes a profile of XCAP (XML Configuration Access Protocol) for manipulating SIMPLE resource lists and common policy rule sets. While XCAP allows access to arbitrary XML document subtrees, most XCAP implementations only need access to documents at the specific points in the XML schema described by this profile. "MMD CAVE Support Requirements", Bifeng Yan, 31-Oct-05, This document describes why there is a need to support CAVE authentication in Multi-Media Domain, and outlines the requirements of the potential solution to this problem. "Key rollover schemes for TCP connections employing a shared key model.", Anantha Ramaiah, 2-Nov-05, This document describes mechanisms to achieve Key rollover for TCP connections that are using the TCP MD5 digest as described in RFC 2385. The mechanisms presented here do not require TCP protocol changes. The mechanisms are not just limited to TCP MD5 digest Key rollover but can be used for any shared Key based TCP security option. "Requirements for SIP-based Peer-to-Peer Internet Telephony", Salman Baset, 7-Nov-05, This document defines requirements for designing peer-to-peer voice, text, and real-time multimedia communication system protocols. "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Vijay Gurbani, Cullen Jennings, 8-Dec-05, This document creates an Internet Assigned Number Authority (IANA) registry for the tel Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. "IANA Considerations for PPP over Ethernet (PPPoE)", Peter Arberg, Vince Mammoliti, 7-Nov-05, This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. "Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network", Emmanuel Lochin, Laurent Dairaine, 7-Nov-05, This memo introduces gTFRC, a TCP-Friendly Rate Control providing throughput guarantee over the DiffServ/AF class. gTFRC is largely based on TFRC [2]. It provides a mean to take into account the quality of service negotiated with the network. As a result, the mechanism is able to reach a minimum throughput guarantee whatever the flow's RTT and target rate. "A URN Namespace for ASD Specification 1000D", Sean Rushing, 7-Nov-05, This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by ASD Specification 1000D. "Establishing Host Identity Protocol Opportunistic Mode with TCP Option", Janne Lindqvist, 6-Mar-06, This document specifies an alternative opportunistic mode for the Host Identity Protocol (HIP). The opportunistic mode is initialized by adding a 128 bit Host Identity Tag (HIT) as a TCP option to a TCP SYN packet. The mode allows a TCP connection to be established directly without a timeout delay in the case the peer does not support HIP. "APP Service Description Format", Robert Sayre, 11-Nov-05, This memo presents an XML format used to describe Atom Publishing Protocol services. These services typically expose one or more groupings of resources. On a blogging service, for example, each grouping might represent a distinct blog and associated resources. "SOA-Reliability (SOA-Rity) for HTTP", Yaron Goland, 8-Nov-05, SOAR-ity is intended to allow for "reliable" (this term is almost always a misnomer) messaging over HTTP. It achieves this goal by introducing two new request headers, Message-ID which provides a unique ID for a message and MsgCreate which contains the date and time on which the first instance of the message with the associated Message-ID was sent. The purpose of the Message-ID/MsgCreate pair is to allow any HTTP request (e.g. any HTTP method can be used) to be repeated multiple times with a guarantee that the message will be processed no more than one time. In essence it makes any HTTP method call idempotent. "Feed Seek for the Atom Publishing Protocol", Robert Sayre, 8-Nov-05, This memo presents a set of URI parameters used identify segments of an Atom Publishing Protocol feed. It also presents a syntax for declaring the placement of those parameters in a URI. "DHCP Relay Agent Assignment Notification Option", Ralph Droms, 8-Nov-05, The DHCP Relay Agent Assignment Notification option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. "Design Options of NSIS Diagnostics NSLP", Xiaoming Fu, 9-Mar-06, The Next Steps in Signaling protocol suite aims to provide a way to communicate with network intermediaries. As such, it is desirable to offer generic diagnostics function for NSIS users and system administrators to make the functionality provided by the network more transparent (e.g., to identify particular NSLPs, to determine to which degree the network supports NSIS, GIST state or specific NSLP session information along a given path). Instead of suggesting one specific solution we highlight the different design options of some simple, stateless diagnostics functions from a querying node to a responding node. These preliminary thoughts should help the working group to have a more structure discussion in this problem space. "Localized Mobility Management using Proxy Mobile IPv6", Sri Gundavelli, Kent Leung, 10-Nov-05, Localized Mobility Management (LMM) requires mobility support for a mobile station within a restricted and topologically localized portion of the network. Mobile IPv6 is a standardized mobility protocol for IPv6 that can be extended to address the local mobility management requirements. This document describes a solution based on Proxy Mobile IPv6 scheme by introducing new functional entities and extensions to the protocol and by restricting the mobility signaling to only certain entities in the network. "Requirements for Service Discovery in the Personal Area Network(PAN)", Xu Mingqiang, 10-Nov-05, Several protocols exist in the industry for device/service discovery. Each of these protocols addresses the aspects of device/service discovery in different network environments. A Service Discovery in a PAN Personal Area Network (PAN) is dynamic in its nature where devices may join and leave the network very frequently. A PAN, being an ad- hoc network, also differs from fixed networks in many other ways. The current generation of service protocols such as SLP were not designed for such an environment. This document specifies the requirements of a service discovery protocol for PANs, which specifically can be used for applications such as multimedia session transfer between devices within a PAN. "Issues Discussed in Revising BGP-4", Andrew Lange, 11-Nov-05, This document records the issues discussed and the consensus reached in the Interdoming Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol. "The RObust Header Compression (ROHC) Framework", Lars-Erik Jonsson, 11-Nov-05, The RObust Header Compression (ROHC) protocol provides an efficient, flexible and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. RFC 3095 defined the ROHC framework along with an initial set of compression profiles. To improve and simplify the specification, it has been agreed that the framework and the profiles parts of RFC 3095 be split into separate documents. This document explicitly defines the ROHC framework, and thus replaces the framework specification of RFC 3095. "Registration of media type audio/mobile-xmf", Timo Kosonen, Tom White, 11-Nov-05, The MIDI Manufacturers Association (MMA) and the Association of Music Electronics industry (AMEI) have produced the Mobile XMF standard [1]. The Mobile XMF standard has been developed particularly for mobile MIDI [7] applications. Mobile XMF is a very compact media type providing high quality synthetic audio content for music downloading and messaging applications that require MIME registration. "Registration of media type audio/sp-midi", Timo Kosonen, Tom White, 11-Nov-05, The MIDI Manufacturers Association (MMA) and the Association of Music Electronics industry (AMEI) have produced the Scalable Polyphony MIDI (SP-MIDI) standard [n1]. SP-MIDI has been approved for 3GPP standardization and a dedicated SP-MIDI profile has been defined for 3GPP SP-MIDI devices [n2]. Since MIDI information is a very compact media type, 3GPP is initially focusing on the application of SP-MIDI for music downloading and messaging applications that require MIME registration. "Web Distributed Authoring and Versioning (WebDAV) URL constraints", Julian Reschke, 14-Nov-05, Both WebDAV servers and clients frequently map URI-escaped characters inside a path segment to non-ASCII characters. These mappings can only be interoperable if there is a consensus about the appropriate character encoding. This document specifies a default encoding that is compatible with both the recommendations for URIs in HTML content and the "Internationalized Resource Identifiers" (IRI) specification. Furthermore, servers that implement a mapping to locally constrained names frequently do not support specific names, or silently map "similar" names to the same resource (for instance when content is stored in a filesystem that is case-preserving, but not case- sensitive). For these cases, discovery and error signalling features are defined. "Revision of the Recall Initiation Model", John Klensin, 14-Nov-05, The procedures for initiating a recall specified in RFC 3777 restrict signatories to those who are "nomcom qualified". Perhaps inadvertently, this prohibits members of the IESG and IAB from initiating these procedures. This document suggests that limitation was an unanticipated and undesirable side-effect and proposes to remove it. This document is intended to update RFC 3777. "The Base16, Base32, and Base64 Data Encodings", Simon Josefsson, 14-Nov-05, This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. "Kerberos 5 TCP/IP Expansion Mechanism", Simon Josefsson, 14-Nov-05, An expansion mechanism for the Kerberos 5 TCP/IP Transport is described. "Atom Publishing Protocol - Introspection", James Snell, 14-Nov-05, This specification defines an introspection format for the Atom Publishing Protocol. "Administration of the IANA Special Purpose Address Block", Geoff Huston, 28-Dec-05, This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. "Carrying Attached Addresses in IS-IS", David Ward, 15-Dec-05, This draft specifies the IS-IS extensions necessary to support multi- link IPv4 and IPv6 networks, as well as to provide true link state routing to any protocols running directly over layer 2. While supporing this concept involves several pieces, this document only describes extensions to IS-IS. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. "IKEv2-based Home Agent Assignment in Mobile IPv6/NEMO Bootstrapping", Kilian Weniger, Francis Dupont, 7-Mar-06, This document specifies how to use IKEv2 for Home Agent assignment in Mobile IPv6 or NEMO bootstrapping. It uses IPv6 anycast addresses and should not introduce new security issues. "Virtual AP for 802.11 Seamless Handoff", Song Yubo, 16-Nov-05, This memo documents the concept of virtual AP which refers to using multi physical APs to simulate only one virtual AP, method and process used for seamless handoff between APs upon IEEE802.11 network. It defines the stages to actualize smooth handoff, mentions the concepts, theories and requirements in these stages. "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon Josefsson, 17-Nov-05, This document describes how to use a Generic Security Service Application Program Interface mechanism in the the Simple Authentication and Security Layer framework. See for more information. "RFC3065bis Implementation Report", Danny McPherson, 17-Nov-05, This document provides an implementation report for Autonomous System Confederations for BGP as defined in draft-ietf-idr- rfc3065bis-05.txt. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. "Congruency for VPLS Multicast and Unicast Paths", Ali Sajassi, 17-Nov-05, The current VPLS multicast proposals based on multicast tree has several issues that are outlined in [BRIDGE-INTEROP]. These issues stems from the divergence of the multicast and unicast paths for a given VPLS instance in the MPLS/IP network. This draft describes a mechanism for building multicast and unicast paths that are congruent in order to address these issues. "IAX: Inter-Asterisk eXchange Version 2", Brian Capouch, 9-Mar-06, This document describes the Inter-Asterisk eXchange protocol, Version 2, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX is targeted primarily at the control of Voice over Internet Protocol (VoIP) calls, but can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in Internet Protocol (IP) networks. It combines both control and media services in the same protocol. IAX's compact encoding decreases bandwidth usage and since IAX uses a single, static, UDP port, it facilitates native support for Network Address Translation (NAT) transparency. IAX is well suited for Internet telephony service, but, is open enough to support additional services. "Identifiers for Internet Media Guides (IMG)", Janico Greifenberg, 15-Dec-05, This document defines a Uniform Resource Name (URN) namespace for identifying Internet Media Guides (IMGs). IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", Joseph Touch, 21-Nov-05, Current Ethernet (802.1) link layers use custom routing protocols that have a number of challenges. The routing protocols need to strictly avoid loops, even temporary loops during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non- overlapping pairwise paths (in the case of spanning trees). The convergence of these routing protocols and stability under link changes and failures is also of concern. This document addresses these concerns and suggests that they are related to the need to be able to apply network layer routing (e.g., link state or distance vector) protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing bridged (802.1D) links, but that a solution would be backward compatible with 802.1D, including hubs, bridges, and their existing plug-and-play capabilities. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/rbridge "The Architecture of an RBridge Solution to TRILL", Joseph Touch, Radia Perlman, 8-Mar-06, RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine the link layer ability to allow hosts to reattach without renumbering with network layer routing benefits. RBridges use existing link state routing to provide higher RBridge to RBridge cross-section bandwidth, fast convergence on reconfiguration, and more robust under link interruption than an equivalent set of conventional bridges using existing spanning tree forwarding. They are intended to apply to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also attempt to retain as much 'plug and play' as is already available in existing bridges. This document proposes an RBridge system as a solution to the TRILL problem. It also defines the RBridge architecture, defines its terminology, and describes basic components and desired behavior. One or more separate documents specify the protocols and mechanisms that satisfy the architecture presented herein. "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls", Dimitri Papadimitriou, Adrian Farrel, 28-Nov-05, In certain networking topologies it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent connections may be made. In Generalized MPLS (GMPLS) such connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. 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. "Fibre-Channel Fabric Configuration Server MIB", Claudio DeSanti, 7-Mar-06, 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 Fabric Configuration Server function of a Fibre Channel network. 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. "Fibre Channel Registered State Change Notification (RSCN) MIB", Claudio DeSanti, 7-Mar-06, 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 management of Fibre Channel's Registered State Change Notifications (RSCNs). "ExtCommunity map and carry TOS value of IP header", Zhifeng Zhang, 28-Nov-05, This document defines a new BGP Extended Community, which can map the value of IP TOS. Then, the Extended Community can classified the route information at the same time can carry the value of TOS which will apply into the IP packet. Then BGP and QoS have corre -lation when we apply the QoS policy based on BGP,it will be simple. "Review: Quick-Start for TCP and IP", Bob Briscoe, 28-Nov-05, This review thoroughly analyses draft 01 of the Quick-Start proposal, focusing mostly on security issues. It is argued that the recent new QS nonce proposal gives insufficient protection against misbehaving receivers, and a new approach is suggested. But it would be perverse to strengthen protection against malicious receivers too much when the protocol only works if all senders can be trusted to comply. The review argues this is an inevitable result of choosing to have routers allocate rate to senders without keeping per-flow state. The paper also questions whether Quick-Start's under-utilisation assumption defines a distinct range of operation where fairness can be ignored. Because traffic variance will always blur the boundary, we argue that under-utilisation should be treated as the extreme of a spectrum where fairness is always an issue to some extent. If we are to avoid per-flow state on routers, the review points to an alternative direction where endpoints allocate rate to themselves. Counter-intuitively, this allows scalable security and a spectrum of fairness to be built in from the start, but rate allocation is less deterministic. Issues not related to security are also raised, including the possibility of a catastrophic overload if path delays are atypical. A solution to this is offered, as well as solutions to scalability issues with the range and precision of the Rate Request field. Many other more minor review comments are given. "SIPPING TISPAN Ad Hoc Summary", Erick Sasaki, 28-Nov-05, This draft summarizes the discussion and outcome from the sipping working group ad hoc meeting to discuss TISPAN requirements held on November 9, 2005. The sipping working group held an ad hoc meeting on November 9, 2005 to address TISPAN's requirements as outlined in [TISPAN-Reqts] and [TISPAN-Anal]. During the meeting, the requirements were discussed and following are the comments made to address the requirements. "M3UA Deployment Considerations", Tolga Asveren, 28-Nov-05, This document provides some considerations regarding the deployment of M3UA protocol, which were originally brought up at the SIGTRAN mailing list. Certain parts of the discussions in this document are applicable to other SIGTRAN protocols as well. "DTCP: Dynamic Tasking Control Protocol", David Cavuto, 29-Nov-05, Dynamic Tasking Control Protocol is a UDP/IP interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. "A common framework for autoconfiguration of stand-alone ad hoc networks", Kenichi Mase, 9-Feb-06, We consider the unique local address autoconfiguration problem for stand-alone ad hoc networks (MANETs). Specifically, we consider two cases. First, a node without a pre-assigned and valid local address acquires a new local address and becomes a member of a new or existing MANET. Second, two or more MANETs merge. In the first case, a mechanism of IP address generation based on a stateful or stateless method is needed. We also should have MANET-wide duplicate address detection (MANET-DAD) on newly generated address (tentative address) for suppressing occurrence of duplicate addresses regardless of whether stateful or stateless method is employed for address generation (pre-service MANET-DAD). In the second case, duplicate address may occur as the result of a merger of two formerly independent networks. We should have MANET-DAD on addresses in use for resolving duplicate addresses and suppressing routing information contamination due to existence of duplicate addresses (in-service MANET-DAD). To realize pre-service MANET-DAD and in-service MANET- DAD, we define autoconfiguration states that are common for both proactive and reactive routing protocol. Each node exists in one of the autoconfiguration states at any time. The specific MANET-DAD algorithm is beyond the scope of this document. "Use of Hash Algorithms in IKE and IPsec", Paul Hoffman, 6-Mar-06, This document describes how the IKEv1, IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. "Mechanism of multiple adjacent nodes RSVP graceful restart Simultaneously", Jiang Weilian, 30-Nov-05, Based on the RSVP graceful restart defined in the RFC3473, RFC3209, Node ID RSVP Hello:A Clarification Statement (draft-ietf-ccamp-rsvp -node-id-based-hello-02) and the Extensions to GMPLS RSVP Graceful Restart (draft-ietf-ccamp-rsvp-restart-ext-05), this document puts forward extension to solve the problem for the restart node to actively inform RSVP graceful restart to the neighbor, and further provides the relevant mechanism to support recovery processing of RSVP graceful restart at simultaneous restart of multiple adjacent nodes. "OSPF Version 3 Trap MIB", Nitin Kakkar, 30-Nov-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 Traps for managing version 3 of the Open Shortest Path First Routing Protocol. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo is intended to complement draft-ietf-ospf-ospfv3-mib-09.txt and uses many definitions provided in this MIB. "Generalized MPLS (GMPLS) architecture's extensions for Optical Burst Switch network", Keping Long, 30-Nov-05, The Generalized MPLS[RFC 3031] suite of protocols has been defined to control different switching technologies, such as TDM, Optical Circuit Switching, and even Optical Fibre Switching. However, Optical Burst Switching(OBS)[Qiao] is a promising optical switching technology, which is expected to be deployed in optical network in the very near future. Therefore, this document focuses mainly on how to extend the architecture of Generalized MPLS (GMPLS)[RFC 3945] to support Optical Burst Switching. Herein, the extensions consist in the following issues, i.e., signaling, routing and link management. What more, the extended GMPLS architecture will be much more scalable than before. Note that the extensions are not limited a certain OBS signaling type, such as Just-In-Time or Just-Enough-Time, Wavelength- Routed OBS or traditional OBS. "Updating RFC 3484 for multihoming support", Marcelo Bagnulo, 1-Dec-05, This note describes the limitations of RFC 3484 in multihomed environments and proposes possible updates to the default address selection mechanisms in order to cope with the identified limitations. "IPv6 Neighbor Discovery over 802.16: Problems and Goals", Syam Madanapalli, 1-Dec-05, This draft provides overview of 802.16 Network characteristics and Convergence Sublayers, and specifies the problems in running the IPv6 Neighbor Discovery over 802.16 Networks. This document also presents the goals that point at relevant work to be done either at IETF or some other standards body. "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, 9-Jan-06, IPv6 fragmentation allows fragments to be sent only by the source of a packet. The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. Firewalls generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document specifies where tiny fragments can be issues. "Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP)", David Bryan, 1-Dec-05, This document attempts to identify and classify use cases of P2P based SIP. It does not attempt to exhaustively enumerate these cases, and is focused exclusively on cases related to real-time IP communication. "Cryptographically Generated Addresses (CGA) Extension Field Format", Marcelo Bagnulo, Jari Arkko, 8-Mar-06, This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. "TCP Burst Mitigation Through Congestion Window Limiting", Janardhan Iyengar, 11-Jan-06, This document describes Congestion Window Limiting (CWL), a method for mitigating micro-bursts in TCP by limiting the congestion window during interruptions in TCP's acknowledgment clock. "M3UA SG-SG Communication", Tolga Asveren, 2-Dec-05, This document describes a protocol to support the communication between M3UA SGs in IP domain. The functionality needed by SGs to act as relay points between SS7 nodes is also addressed. "Practical Usages of Default Address Selection Policy Distribution", Arifumi Matsumoto, 2-Dec-05, This document describes some practical usages of default address selection policy distribution mechanism defined in another document. Default address selection policies are originated by ISPs or by network administrators and are delivered to each end node. These policies are stored at end nodes in the form of default address selection policy table. This mechanism is effective in many cases, such as IPv4 and IPv6 dual-stack environment and other multiple address environment. Every end node is guided by the policy in selecting an appropriate destination and source addresses. "Unicast Address Sub-Option", Stefaan De Cnodder, Patrick Mensch, 2-Dec-05, In some network topologies, it is preferred to have a trusted network element between the DHCP client and the DHCP relay agent that adds the DHCP relay-agent-information option but does not set the giaddr field. This document defines a new sub-option for the relay-agent- information option. With this sub-option, the DHCP relay agent will always unicast the messages towards the trusted layer 2 DHCP relay agent with a MAC address that is known in the network. The new sub- option is called the "unicast-address" sub-option. "Integrity Transform Carrying Roll-over Counter", Vesa Lehtovirta, 14-Feb-06, This document defines an integrity transform for SRTP [RFC3711], which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session, and needs to quickly and robustly get into synchronization. The mechanism also enhances SRTP operation in cases where there is a risk of loosing sender-receiver synchronization. "TCP Message Authentication Code Option", Brian Weis, 7-Dec-05, This memo describes a TCP [RFC0793] extension to enhance security for BGP [I-D.ietf-idr-bgp4] and other TCP-based protocols requiring message authentication. It provides message authentication using a Message Authentication Code (MAC), which is a superior authentication method to the keyed MD5 method previously used. The option also includes provision for automatic generation and distribution of MAC keys. A set of MAC algorithms are specified, as well as guidance when to use each one. "Atom Syndication Format Link Extensions", James Snell, 25-Jan-06, This specification defines extensions to the Atom Syndication Format link and content elements that may be used to express additional metadata about linked resources. "A STUN-Based Signaling (SBS) Framework", Melinda Shore, 7-Dec-05, STUN has proven to be a popular mechanism for providing basic NAT traversal capabilities for UDP traffic. As it has matured it has become an attractive target for extensions that move away from STUN's discovery function towards explicit communication with middleboxes -- in other words, as an on-path signaling protocol. This document describes a more generalized framework for using STUN for solving on- path signaling problems. "Hardware and Network Address Options for TFTP", Shengyou Zeng, D Evans, 8-Dec-05, The Hardware Address and Network Address options carry the hardware address and network address respectively of a client device that performs a Trivial File Transfer Protocol (TFTP) request. "IPv6 over Low Power WPAN Security Analysis", Soohong Park, 8-Dec-05, This document describes IPv6 over Low Power WPAN security analysis. "Sieve Notifications via the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, Alexey Melnikov, 8-Dec-05, This document describes a profile of the Sieve extension for instant notifications to be used with the Extensible Messaging and Presence Protocol (XMPP). "Transitional Atom Format", James Snell, 9-Dec-05, This specification defines a transitional form of the Atom 1.0 Entry Document that may be used during the production lifecycle of Atom 1.0 Entry Documents. "Abridges as Rbridges: Transparent Routing with Simplified Multiple Spanning Trees", Guillermo Ibanez, 9-Dec-05, Rbridges are link layer devices that use routing protocols as a control plane but do not target to scale up to large campus networks. This document contains an alternative proposal to link-state Rbridges, named Abridges. Abridges overcome Rbridges L2 network size restrictions allowing applicability to very large Ethernet campus networks while maintaining zero configuration and high performance, by assuming a topological restriction that is automatically performed. The proposal includes a two-layered network architecture with two hierarchical independent spanning tree layers. Expected convergence is fast, probably below two seconds. Abridges use multiple simplified spanning trees rooted at core edge bridges to achieve results comparable to Rbridges with lower computational complexity. Two implementation variants of simplified multiple spanning trees are proposed: The first one is a fundamental simplification of the standard Multiple Spanning Tree protocol and the second one (still in a very preliminary stage) consists of an N-multiple simultaneous execution of the Rapid Spanning Tree protocol at each Rbridge. An optional mechanism of ARP/Abridge servers/registrars (with load splitting) is proposed to limit ARP traffic in large scale Ethernet networks and to enhance scalability and security. This mechanism can also be used for host-Designated Rbridge resolution as an alternative to the interchange of Hosts Lists between Rbridges. "IMAP4 IDLE command", Barry Leiba, 9-Dec-05, The Internet Message Access Protocol requires a client to poll the server for changes to the selected mailbox (new mail, deletions). It's often more desirable to have the server transmit updates to the client in real time. This allows a user to see new mail immediately. It also helps some real-time applications based on IMAP, which might otherwise need to poll extremely often (such as every few seconds). (While the spec actually does allow a server to push EXISTS responses asynchronously, a client can't expect this behaviour and must poll.) This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. "AAA based Keying for Wireless Handovers: Problem Statement", Madjid Nakhjiri, 27-Jan-06, The Extensible Authentication Protocol (EAP) provides a framework for performing authentication and key management using the AAA infrastructure. The framework deals with a model which includes a peer, a pass-through authenticator and a backend authentication server. Some of the emerging mobile networks use EAP in handover scenarios in ways that go beyond currently defined EAP keying framework. This document provides a problem statement for the usage of EAP in these emerging mobile networks. "Routing Security in Sensor Network: HELLO Flood Attack and Defense", Suho Park, 9-Dec-05, In this document, We consider Wireless Sensor Network (WSN) security and focus our attention to tolerate damage caused by an adversary who has compromised deployed sensor node to modify, block, or inject packets. We adopt a probabilistic secret sharing protocol where secrets shared between two sensor nodes are not exposed to any other nodes. Adapting to WSN characteristics, we incorporate these secrets with bidirectional verification and multipath routing to multiple base stations to defend against HELLO flood attacks. We then analytically show that our defense mechanisms against HELLO flood attack can tolerate damage caused by an intruder "Atom Syndication Format Tombstones", James Snell, 22-Feb-06, This specification defines mechanisms by which Atom Feed publishers may explicitly indicate that specific Atom Entries have been explicitly removed from an Atom feed. "Generalized OLSRv2 Packet/Message Format", Thomas Clausen, 9-Dec-05, This document describes a generalized multi-message packet format for version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The packet and multi-message format may also be useful for other protocols. "SNMP Traffic Measurements", Juergen Schoenwaelder, 9-Dec-05, The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and configure network elements. Even though the SNMP technology is well documented, it remains unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document proposes to carry out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. "SIP Interface to VoiceXML Media Services", Dave Burke, 12-Dec-05, This document describes a SIP interface to VoiceXML media services, which is commonly employed between application servers and media servers offering VoiceXML processing capabilities. "Packet Filter Configuration Protocol", Michael Paddon, Philip Hawkes, 12-Dec-05, The Packet Filter Configuration Protocol (PFCP) is a client-server protocol which provides a mechanism for trusted clients to dynamically request updates to a packet filtering policy managed by a server. Typically, a server is either a packet filter or an entity which controls one or more packet filters. Since clients may specify permitted flows as and when they are required, packet filters configured via PFCP may operate an extremely restrictive default policy. "ICMP Extensions for Unnumbered Interfaces", Alia Atlas, 7-Mar-06, This memo defines extensions to ICMP that permit identification of unnumbered interfaces. The interface the triggering IPv4 packet was received upon can be identified by appending an ifIndex and/or a string describing the interface. These extensions are defined to facilitate troubleshooting in network with unnumbered interfaces. Additionally, to facilitate debugging of numbered interfaces, the IPv4 address of the interface the triggering IPv4 packet was received upon can be identified by appending the IPv4 address. "Mutual OATH: HOTP Extensions for mutual authentication", David M'Raihi, 15-Dec-05, This document describes Mutual OATH, a mechanism for mutual authentication based on the HOTP algorithm [HOTP] introduced recently by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF last year. The security and strength of Mutual OATH depends on the properties of the underlying building block HOTP, which is a construction based on HMAC [RFC2104] using SHA-1 as the hash function. "A Document Format for Expressing XML Support (EXS)", Martin Thomson, 13-Dec-05, This document defines a simple XML format for expressing support for, or understanding of sections of XML documents. This format is designed for use in negotiating a common level of support in protocols. XPath expressions are used to define which XML nodes within any particular instance document are understood. "Key Management through Key Continuity", Peter Gutmann, 15-Dec-05, This memo provides advice and Best Current Practice for implementors and deployers of security applications that wish to use the key continuity method of key management. "M3UA IPSP Procedures", Tolga Asveren, Javier Pastor-Balbas, 20-Dec-05, This document defines M3UA IPSP procedures. It is based on IPSP concepts and procedures defined by M3UA specification. Its purpose is to describe M3UA IPSP procedures in an easy-to-follow single document and to provide clarifications for M3UA IPSP procedures. "Media Type Registration for SMPTE Material Exchange Format (MXF)", Thomas Edwards, 5-Mar-06, This document serves to register a media type for the SMPTE Material Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. "On the Formatting and Content of IETF Working Group Agendas and Minutes", Dave Meyer, Olaf Kolkman, 20-Dec-05, RFC 2418 outlines the procedures for IETF Session operation. However, it contains little information about post-IETF meeting working group chair responsibilities. In particular, it provides little guidance with respect to either form or submission deadlines for the artifacts of the meeting, namely, session minutes and presentation materials. This document addresses the form and content of Working Group agendas and minutes. "Extensions to RSVP-TE Fast Reroute", Jiang Weilian, 21-Dec-05, This document defines extensions to the Fast Reroute (FRR) mechanism of Facility Backup defined in RFC4090. Through the extensions, the node that has set up FRR relation is capable of notifying the tail node of backup tunnel to act as Merge Point (MP) of the protected and backup tunnels. In addition, after the FRR switchover, PLR and MP nodes can refresh the protocol state of protected tunnel through the Refresh message of backup tunnel, so that the protocol message of protected tunnel will not be refreshed along the path of backup tunnel, the middle nodes and tail node of backup tunnel will not assign many unused labels. "Network Endpoint Assessment (NEA) Problem Statement", Susan Thomson, 6-Mar-06, Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy on access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. This document describes the problem these architectures are intending to address, defines common terminology and concepts, and identifies interfaces that are candidates for standardization. "MPLS l2vpn mangement information base", Jiang Weilian, 10-Mar-06, This draft not only describes the management model which is universal to all PSN types supported by PWE3 architecture, but olso defines an experimental part of MIB on Internet community network management protocol,The MIB supports MPLS-TE PSN, non TE MPLS PSN (external layer tunnel created by LDP or by hand) and MPLS PW labels. Particularly , the draft describes the managed objects of L2VPN service on MPLS switching network, including VPLS and VPWS services. Different from PW MIB, the MIB provides the management models for L2VPN service based on MPLS signaling, including the management models of L2VPN service instance, PW, interface and traffic statistics. The MIB supports MPLS PW labels, MPLS-TE PSN, MPLS PSN, VPLS and VPWS services. "Avoid EBGP Best Path Transitions - Implementation Report", Enke Chen, 27-Dec-05, This document provides an implementation report for "Avoid BGP Best Path Transitions from One External to Another". "Extended Options for DomainKeys Identified Mail (DKIM)", Douglas Otis, 27-Dec-05, This document describes options that extend protections offered by DKIM. These options include Binding-Advice & Role-Assertion, Opaque- Identifier, and an In-Channel check. The Binding-Advice & Role- Assertion offers guidance in isolating the source of a message, in addition to establishing message signature expectations. The Opaque- Identifier (O-ID) offers protection from replay abuse and intra- domain spoofing, even when email-addresses are not associated with the signing-domain. The In-Channel check provides a means to mitigate DNS lookups for avoiding possible message replay abuse. "OSPF Multiple Interface Optimizations", Nitin Kakkar, K Srinivasa, 27-Dec-05, OSPF is a link state IGP routing protocol, but it does not utilizes multiple links between adjacent routers efficiently. This Memo tries to utilize multiple links between adjacent routers to make initial adjacency establishment & flooding more optimized, such that these procedures become faster and consumes lesser bandwidth. "Update to OSPF Hello procedure", Zengjie Kou, 28-Dec-05, This memo documents an extension of the OSPF protocol to reach ¡°ExStart¡± state more quickly. Currently, the OSPF behavior requires the Hello Packet to be sent between the neighbors every HelloInterval. This document proposes to generalize the use of Immediately Replying Hello which could reduce the time required to reach the OSPF ¡°ExStart¡± state and expedite the routing table convergence. "An Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol(SIP)", Chris Boulton, 28-Dec-05, This document defines a Session Initiation (SIP) Control Package for Interactive Voice Response (IVR) interaction. The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks. This Control Package aims to fulfill IVR requirements using the SIP Control Framework [7]. "A Control Framework for the Session Initiation Protocol (SIP)", Chris Boulton, 28-Dec-05, This document describes a Framework and protocol for application deployment where the application logic and processing are distributed. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between Application Servers and tightly associated external Servers e.g. Media Server. The motivation for the creation of this Framework 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. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. "Publishing SIP Peering Policy", Otmar Lendl, 28-Dec-05, This documents proposes the use of DNS entries to publish a SIP proxy's policy for accepting incoming calls. Such published policies can be used to selectively establish peering relationships between VoIP service providers. "Methodology for benchmarking fast failover time with local protection", Samir Vapiwala, 28-Dec-05, This draft provides the methodology for benchmarking the failover time of local protection (aka Fast Reroute). The failover to a backup tunnel could happen at the headend of the primary tunnel or a midpoint and the backup could offer link or node protection. It becomes vital to benchmark the failover time for all the cases and combinations. The failover time could also greatly differ based on the design and implementation and by factors like the number of prefixes carried by the tunnel, the number of primary tunnels affected by the event that caused the failover, number of primary tunnels the backup protects and type of failure etc. All the required benchmarking criteria and benchmarking topology required for measuring failover time of local protection is described Conventions used in this document "TS2 --- A Modified TCP Timestamps Mechanism", Noritoshi Demizu, 3-Mar-06, This memo proposes a modified TCP Timestamps mechanism called "TS2". It uses the existing "TCP Timestamps option" specified in RFC1323 and a new TCP option called "the TCP Old Timestamps option", which is specified in this memo. As a fallback, an RFC1323-compatible mode called "TS1" is also available. The base mechanism of TS2 includes the definitions of those two TCP Timestamps options, mode negotiation to enable TS1 or TS2, and a rule for updating internal states. The applied mechanisms of TS2 include an accurate RTT measurement mechanism that is correct even for duplicate ACK segments (RTTM/TS2), a reordering-robust mechanism to detect wrapped sequence numbers (PAWS/TS2), a lightweight mechanism to detect spoofed segments (PASA/TS2), a loss inference mechanism applicable to both original and retransmitted data segments (DLI/TS2), and a spurious loss inference detection mechanism that operates without waiting for one RTT by sending arbitrary in-window data (SLID/TS2). "Internet Key Exchange Protocol: IKEv2.1", Paul Hoffman, 29-Dec-05, This document describes version 2.1 of the Internet Key Exchange (IKE) protocol. IKEv2.1 is heavily based on IKEv2 from RFC 4306 (edited by Charlie Kaufman), and includes all of the clarifications from the "IKEv2 Clarifications" document (edited by Pasi Eronen and Paul Hoffman). IKEv2.1 makes additional changes to those two documents in places where IKEv2 was unclear and the clarifications document did not commit to a particular protocol interpretation. "Authentic Address Resolution Protocol", Dinh Nguyen, Cam Tu Nguyen, 30-Dec-05, This document describes additions to Address Resolution Protocol that will allow a host to authentically resolve the hardware address from the protocol address of given host. Using authentication data based on X.509 digital signatures to evaluate the authenticity of ARP packets, hosts can prevent ARP spoofing efficiently. "Proposed Experiment: Normative Format in Addition to ASCII Text", Jerry Ash, 31-Jan-06, Following RFC 3933, the authors propose an experiment allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. "SORT extension to IMAP Conditional STORE", Alexey Melnikov, 3-Jan-06, This document specifies SORT extension to the IMAP Conditional STORE extension, which allows a client to request a sorted list of metadata (flag) changes. "Centralized Conferencing Manipulation Protocol", Chris Boulton, Mary Barnes, 3-Jan-06, "A Framework and Data Model for Centralized Conferencing" defines a model whereby client intereaction is required for creation, deletion, and manipulation of a conference, as well as querying the state of a conference. The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the appropriate mechanisms for these protocol interactions. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL). "Firewall State Update Process for Mobile IPv6", Yang Shen, 3-Jan-06, A mobile IPv6 node remains reachable when it moves in a IPv6 Internet. However, if such a node, i.e. MN, moves to a network which is protected by firewalls, the communication that is already existed before its moving may be blocked by firewall. The document presents a mechanism to update the corresponding access control entry of firewall to avoid the communication interrupted. "TLS User Mapping Extension", Stefan Santesson, 24-Feb-06, This document specifies a TLS extension that enables clients to send generic user mapping data in a new handshake message. One such mapping is defined, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mappings may be defined in other documents in the future. "COMP: Conference Object Manipulation Protocol", Henning Schulzrinne, 3-Jan-06, The Conference Object Manipulation Protocol (COMP) allows to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services and SIP event notification as its infrastructure, but can control conferences that use any signaling protocol to invite users. "Locating Media Resource Control Protocol Version 2 (MRCPv2) Servers", Tim Melanchuk, Chris Boulton, 3-Jan-06, This specification defines and registers a set of Media Feature Tags for the Media Resource Control Protocol Version 2 (MRCPv2). Clients and servers can use these tags in conjunction with the Session Initiation Protocol (SIP) capabilities framework so that client requests can be routed to the server best able to satisfy the clients requirements. "RTCP XR - IP Video Metrics Report Blocks", Alan Clark, Amy Pendleton, 2-Mar-06, This document defines extensions to the RTCP XR extended report packet type blocks to support video over IP (VoIP) monitoring for IPTV and video conferencing endpoint reporting. "Issues with existing Cryptographic Protection Methods for Routing Protocols", Vishwas Manral, 22-Feb-06, 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. "RTCP HR - High Resolution VoIP Metrics Report Blocks", Alan Clark, 10-Mar-06, This document defines extensions to the RTCP XR extended report packet type blocks to support Voice over IP (VoIP) monitoring for services that require higher resolution or more detailed metrics than those supported by RFC3611. "EAP based Proxy Mobile IP key bootstrapping: A WiMAX applicability example", Madjid Nakhjiri, Narayanan Venkitaraman, 1-Feb-06, The specification for a EAP based keying methodology for Proxy Mobile IP security is a topic of interest within some standard bodies such as WiMAX and is still under consideration. In this document, the authors intend to provide an first pass illustration on how the EAP keying framework may be used for bootstrapping keys between two agents performing a network service such as Proxy Mobile IP function. Care is taken so that the solution is aligned as closely as possible to the guidelines provided by the EAP Keying framework [EAPKEY]. The solution is, however, fitted to the constraints of the existing SDO scenarios and may not fully fit a future generic application keying solutions defined by HOAKEY. "Response Identity in Session Initiation Protocol", Feng Cao, 10-Jan-06, The mechanism for securely providing responder's identity in response message is missing in the current Session Initiation Protocol. Due to different call scenarios, the exact response identity is hard to guess through the existing response message. This draft describes some extensions for providing SIP response identity and two security mechanisms for verifying the integrity of response identity. It does so by defining new header fields as well as one new response code. Furthermore, the issue of how to require the presence of response identity in one SIP dialog is also discussed with one solution. "Welcomed Correspondence Extensions to IMAP4", David Szego, 12-Jan-06, This document describes in detail the WCOR ("Welcomed Correspondence", or WC/WCor for short) extension to IMAP. "Welcomed Correspondence" is explained in detail in Internet-Draft draft-szego-wcor-overview-00.txt [WCor-Overview]. This extension is based on the standard IMAP "Client Commands - Experimental / Expansion" described in RFC 3501 [RFC3501] section 6.5. Welcomed Correspondence capabilities are identified by the WCOR keyword in the IMAP capabilities list presented by a WC-Compliant IMAP server implementation. "Overview of Welcomed Correspondence Extensions to Mail Delivery and Mail Transfer Protocols", David Szego, 12-Jan-06, The goal of Welcomed Correspondence Extensions is to provide, in the simplest and least intrusive way possible (both programmatically and to the user), a method of avoiding unsolicited and unwanted email without drastically changing the infrastructure of the Internet's existing mail transports. This document describes a two-phase evolutionary approach in order to maintain compatibility with existing standard POP3/IMAP4 retrieval/delivery servers, SMTP mail transfer agents, and end-user mail clients. "Welcomed Correspondence Extensions to POP3", David Szego, 12-Jan-06, This document describes in detail the WCOR ("Welcomed Correspondence", or WCor/WC for short) extension to POP3. "Welcomed Correspondence" is explained in detail in Internet-Draft draft-szego-wcor-overview-00.txt [WCor-Overview]. This extension is based on the standard "POP3 Extension Mechanism" described in RFC 2449 [RFC2449]. Welcomed Correspondence capabilities are identified by the WCOR keyword (POP3 extensions disallow "X-" prefixes) in the POP3 capabilities list presented by a WC-Compliant POP3 server implementation. "Welcomed Correspondence Extensions to ESMTP", David Szego, 12-Jan-06, This document describes in detail the WCOR ("Welcomed Correspondence", or WCor/WC for short) extension to ESMTP. "Welcomed Correspondence" is explained in detail in Internet-Draft draft-szego-wcor-overview-00.txt [WCor-Overview]. This extension is based on the standard SMTP "Service Extensions" described in RFC 1869 [RFC1869]. ESMTP extensions themselves are not formally described here. Welcomed Correspondence capabilities are identified by the X-WCOR (while this document is in draft state) and eventually the WCOR keyword (when and if accepted to standards state) in the ESMTP commands list presented by a compliant ESMTP server implementation in response to an EHLO greeting. "IANA Registration for an Enumservice and “tel” Parameter for Calling Name Delivery(CNAM) Information", Richard Shockey, Jason Livingood, 13-Jan-06, This document registers the Enumservice “cnam” and subtype “tel” using the URI scheme ‘tel:’, as per the IANA registration process defined in the ENUM specification, RFC 3761. In addition this document registers the parameter “cnam” in the IANA “tel” Parameter Registry defined in RFCXXX. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the PSTN that may be displayed on VoIP or other Real-time Client User Agents (CUA). "DiffServ Control Plane: Problem Statement and Scope", Steven Van den Berghe, 17-Jan-06, This document provides a problem statement and scope boundaries to be used as input to the proposed Diffserv Control Plane Elements (DCPEL) BOF. The goal of DCPEL is to provide a standard framework for the DiffServ Control Plane (DCP), service definition information models This document provides a problem statement and scope boundaries to be used as input to the proposed Diffserv Control Plane Elements (DCPEL) BOF. The goal of DCPEL is to provide a standard framework for the DiffServ Control Plane (DCP), service definition information models "Requirements for DiffServ Control Plane Elements", Paulo Mendes, Kathleen Nichols, 17-Jan-06, This document describes a set of requirements for a DiffServ Control plane. It defines requirements for operations within and between network domains, as well as a set of assumptions. "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", Michaela Vanderveen, Hesham Soliman, 17-Jan-06, This document specifies an Extensible Authentication Protocol (EAP) mechanism for shared-secret authentication and key establishment (SAKE). "An Extension to Cache-Control, HTTP/1.1 for group caching", G Manoj, 17-Jan-06, The Cache-Control general-header field of HTTP/1.1 [1] is used to specify directives that must be obeyed by all caching mechanisms along the request/response chain. This document details an extension to the cache-control header to enable caching of resources for dynamic sets of users who are grouped under certain attributes. Also this document specifies user-defined header extensions of HTTP/1.1 [1], which allow these clients to be served from the group caches. "Safe GET & Safe PUT options for FTP", Dilip Kumar Nanecha, Chetan Aswathanarayana, 17-Jan-06, This draft presents a mechanism to overcome one of the cumbersome aspects of file transfer. Ftp fails to transfer the data as there is not enough disk space on the remote machine, but it fails only after it does the substantial data transfer and discovers that there is no more disk space left on the remote machine. The basic intention is to provide FTP Extension for checking the availability of the disk space before starting the actual file transfer operation on remote machines. "A Formal Model for Media Negotiation between SIP User Agents", Alberto Cuda, Enrico Marocco, 17-Jan-06, This document provides a formal description of the interactions between two SIP User Agents establishing a multimedia session, describing the negotiation of the two parties as an exchange of signals between two instances of networks of Finite State Machines (FSMs). The goal is to provide a common reference model for both SIP extensions and User Agent implementations: two flows that can be implemented by using the external interface of the FSMs are guaranteed not to conflict to each other. On the other hand a reference model for User Agents is expected to improve interoperability between different implementations and help implementors to model their software in a way that makes SIP extensions conforming to this document easier to implement. "Extension of OSPF-MDR to Allow Option of Using MPRs", Richard Ogier, 17-Jan-06, This document describes an extension of OSPF-MDR which allows the option of using multipoint relays (MPRs) to select the MANET Designated Routers (MDRs), which form a CDS used for flooding LSAs. This extension allows each router to decide independently whether or not to select MPRs, so it provides additional flexibility without having to specify OSPF-MDR so that it either requires or prohibits MPRs. The use of MPRs in OSPF-MDR may provide some advantages (e.g., a CDS with a smaller stretch factor), although this may come with some costs in terms of overhead and/or response time. Simulations are planned to compare the performance of OSPF-MDR with and without MPRs. "Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)", Markus Kuhn, 18-Jan-06, Coordinated Universal Time (UTC) is the international standard timescale used in many Internet protocols. UTC features occasional single-second adjustments, known as "leap seconds". These happen at the end of announced UTC days, in the form of either an extra second 23:59:60 or a missing second 23:59:59. Both events need special consideration in UTC-synchronized systems that represent time as a scalar value. This specification defines UTC-SLS, a minor variation of UTC that lacks leap seconds. Instead, UTC-SLS performs an equivalent "smooth" adjustment, during which the rate of the clock temporarily changes by 0.1% for 1000 seconds. UTC-SLS is a drop-in replacement for UTC. UTC-SLS can be generated from the same information as UTC. It can be used with any specification that refers to UTC but lacks provisions for leap seconds. UTC-SLS provides a robust and interoperable way for networked UTC- synchronized clocks to handle leap seconds. By providing UTC-SLS instead of UTC to applications, operating systems can free most application and protocol designers from any need to even know about UTC leap seconds. "CORE Subgroup Problem Statement", John Buford, 18-Jan-06, New research in the design of peer-to-peer overlay networks offers the possibility of addressing limitations of existing service, resource and content discovery methods. We identify the research goals to be pursued in investigating new designs for global scale service discovery. The purpose of this document is to attract participation from other researchers interested in these problems and to lead to a coordinated research approach within the P2PRG CORE subgroup. "Proposed initial version of LEMONADE profile phase 2", Stephane Maes, 20-Jan-06, This document proposes an initial draft for LEMONADE profile phase 2. It is based on a combination of the content of LEMONADE profile [4] and the OMA MEM realization internet draft [21] initially considered for internet draft publication as information or standard track by LEMONADE. This also provides an initial proposal on how to divide the specification work between OMA MEM and LEMONADE for a LEMONADE realization of the OMA MEM enabler. "Widget Description Exchange Service (WIDEX) Framework", Vlad Stirbu, Dave Raggett, 20-Jan-06, This document defines a framework used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update operations. "SIP Interface for Media Servers with BAU", Darshan Bildikar, 20-Jan-06, This document defines a mechanism that helps SIP entities leverage the BAU packet cable specification to support simple IVR applications. It builds upon [1] to add BAU [2] support in addition to the VXML support that is already provided. "GSMP extensions for layer2 control (L2C) Topology Discovery and Line Configuration", Sanjay Wadhwa, 23-Jan-06, This document describes proposed extensions to the GSMP protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. BRAS). This document focuses on specific use cases, topology discovery and line configuration. It is intended to be complemented by other Internet-drafts focusing on additional use cases. "Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 24-Jan-06, In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server need to set some indication in SIP message to indicate next application server, what are allowed and what are not allowed. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network. "Clearing attributes on non-referenced material", Alan Buxey, 24-Jan-06, RFC 822 [RFC0822] defines many headers which can be applied to email messages and RFC 2076 [RFC2076] provides a simple summary of the commonly occurring headers in headings of e-mail messages. Both of these RFCs define the 'In-Reply-To' and 'References' fields - which have since had their definitions improved in RFC 2822 [RFC2822] and RFC 1036 [RFC1036] respectively. These fields are used by 'thread capable' email clients to display messages grouped together in organised parent/child relationships that enable the reader to follow a train of thought or a process of information dissemination. However, if a reply to such a threaded message does not contain relevant follow-up information or is used as a platform to deliver a new message with new subject, then that reply is put within the already existing thread. This is known as 'Thread-Jacking'. This draft proposes a couple of techniques which can be undertaken to resolve this issue within the scope of email. "Experimental Procedure for Long Term Suspensions from Mailing Lists", Sam Hartman, 6-Feb-06, Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing IETF mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. "Guidelines for Creating Generally Useful Authentication Mechanisms (GUAM)", Joseph Salowey, 25-Jan-06, Generic Security Services API (GSS-API), the Simple Authentication and Security Layer (SASL), and the Extensible Authentication Protocol (EAP) are three authentication and frameworks used within the IETF that have similar goals. This document describes guidelines for creating authentication mechanisms that are generally usable in any of these frameworks. "Label Switching Ethernet (LSE) Architecture", Jaihyung Cho, Dae Young Kim, 25-Jan-06, A solution for GMPLS implementation using 48bits of Ethernet multicast address as label is proposed. It is claimed that Ethernet bridges supporting IEEE 802.1D-2004 and IEEE 802.1Q-2003 may implement GMPLS according to this proposal without requiring modification to data plane, hence this solution is an appropriate candidate solution for GELS (GMPLS Ethernet Label Switching) group. The LSP established in this method is intrinsically bi-directional. Ethernet bridges of this implementation provide traffic engineered frame delivery path. Any point-to-point LSP can be transformed to multi-point LSP, and vice versa. It is interoperable with 802.1D/Q bridges. This proposal allows automated setup of VLAN using GMPLS in small scale network. IEEE 802.1 controlled spanning tree path may co- exist with GMPLS controlled LSP path when VLAN is used for segregating GMPLS flows and normal Ethernet flows. Clear advantage of this proposal compared to all-router based backbone network is cost- effectiveness that it helps reducing CAPEX/OPEX of operators. With the aid of well-established IP technology, it also helps enhancing scalability and manageability of bridged backbone network. "SIP Interface for Media Servers with BAU", Darshan Bildikar, 26-Jan-06, This document defines a mechanism that helps SIP entities leverage the BAU packet cable specification to support simple IVR applications. It builds upon [1] to add BAU [2] support in addition to the VXML support that is already provided. "A method to override the barring services", Rocky Wang, 26-Jan-06, The document collects some approaches used to implement the functionalities of Override Barring Services in Session Initial Protocol (SIP), and gives detailed description of service flows for each type of the functionalities. Some methods such as SAML, CPC, which is used to implement service, are also dealt with in the document. "An Extension to Session Initiation Protocol (SIP) Events for Issuing Conditional Subscriptions", Aki Niemi, 26-Jan-06, The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they do not allow state to persist over a subscription refresh, or between two consecutive polls. This inablity to suppress notifications of state already known to the subscriber results in superfluous traffic. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition fails, the event state is not sent in a notification. "SIP Subscription Mobility using SUBSCRIBE with Replaces Header", Bradley Jentz, 26-Jan-06, A device using the Session Initiation Protocol (SIP) may need to perform a handover between networks that results in a corresponding change to the mobile's SIP edge proxy. Alternatively, there may be the need to transfer a SIP dialog from one device to another. In both of these scenarios, the device needs a procedure to allow it to take an existing SIP dialog and logically replace it with a new SIP dialog. An important subset of these dialogs consists of the device's subscription dialogs. This document proposes to extend the SIP SUBSCRIBE method to include the Replaces header field for the purpose of enabling a more robust solution to SIP subscription mobility. "Channel Binding Mechanism based on Parameter Binding in Key Derivation", Yoshihiro Ohba, 26-Jan-06, This document describes a channel binding mechanism based on parameter binding in the key derivation procedure. The method cryptographically binds service information to a key without need to carry the service information in EAP methods. "2-Way RSS", Robert Sayre, 17-Feb-06, This memo presents a protocol that uses XML and HTTP to publish and edit Web resources. "The Point6Box Approach", Laurent Toutain, 27-Jan-06, The Point6Box is an add-on equipment which brings IPv6 connectivity to home and SME in a non-intrusive way. It is a deployment tool which will be replaced by IPv6 native service in term. "Location Configuration Protocol", Marc Linsner, John Schnizlein, 27-Jan-06, Location Configuration Protocol provides a host with physical location based on its IP address. This document describes the communication protocol and mechanism for an IP host to discovery the physical location associated with its own IP address by communicating with a Location Information Server. This document describes the overall protocol and communication architecture. "A Timezone Option for DHCP", Paul Eggert, Eliot Lear, 6-Mar-06, DHCP defines an option for a server to deliver to a client offset from UTC. This information in and of itself is not sufficient for devices to portray local time both accurately and consistently. This memo specifies a new option for both DHCPv4 and DHCPv6 to do so. "DHCPv4 Option for Discovering IEEE 802.21 Information Service Location", Soohong Park, 10-Feb-06, In IEEE 802 Standard, the Media Independent Handover (MIH) Services are under work through IEEE 802.21 Working Group. It is consist of three services, Media Independent Event Service (MIES), Media Independent Command Service (MICS) and Media Independent Information Service (MIIS). This document provides a mechanism by which the DHCP can provide information about the MIIS Location. "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", Eric Levy-Abegnoli, 30-Jan-06, [6PE] specifies a mechanism to interconnect IPv6 islands over an MPLS-enabled IPv4 cloud using the IPv6 Provider Edge routers (6PE) approach. The present document reports the results of an implementation survey for this mechanism. After a brief summary of the results, each survey response is listed. The document contains responses from the five implementers that completed the survey (Cisco Systems, Juniper Networks, Ixia, Agilent, Spirent). The document also reports some basic interoperability testing of 6PE implementations carried out by ISOCORE. No ambiguities or errors in the [6PE] specification which could compromise interoperability have been reported. "draft-kelly-saag-des-implications", Scott Kelly, 30-Jan-06, The Data Encryption Standard [DES] is susceptible to brute force attacks which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard [AES]. Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to provide support for it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications, so that designers and implementers can make judicious decisions regarding its use. "The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 1-Feb-06, A "package" is a single addressable resource, logically containing embedded addressable resources, referred to as "parts". Given the URI for a complete package, the "pack" URI scheme provides for the construction and use of URIs referring to individual parts within the package. It also provides for the use of part's URIs as base URIs for resolving relative references between the parts in a single package. "Media Session Authorization", Dan Wing, 1-Feb-06, In many VoIP networks today, firewalls and session border controllers are used at the edge of an administrative domain to allow authorized UDP media flows to enter or leave the network. This document introduces a new mechanism to authorize a UDP media flow. This mechanism works with encrypted hop-by-hop signaling, end-to-end authenticated signaling, and multihomed networks. The media authorization is performed using an Interactive Connectivity Establishment-capable endpoint and a calling signaling device that authorizes a firewall to permit a flow. "JavaScript Object Notation (JSON)", Douglas Crockford, 3-Mar-06, JavaScript Object Notation (JSON) is a light-weight, text-based, language-independent, data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. "Distributed Security Framework", Merike Kaeo, Pekka Savola, 2-Feb-06, Security policy enforcement is becoming increasingly challenging as the trend to utilize mobile and nomadic nodes in networked communications continues to grow. This document will enumerate the problem statement and threat model and will describe how a distributed security framework can address the threats related to these problems. "Requirements for Multi Autonomous System VPN Services", Martin Halstead, 13-Feb-06, This document complements [RFC4031] and defines requirements that are specific to the delivery of BGP/MPLS-based [RFC-2547bis] VPN services across multiple administrative domains. These requirements are independent of underlying technologies or the number of Autonomous Systems such VPNs may span. It lists the requirements of the different parties that are involved in the administration of these Autonomous Systems and may therefore be involved in the delivery of the VPN service offerings. "DIX: Digital Identity Exchange Protocol", John Merrells, 2-Feb-06, DIX is an Internet scale protocol for exchanging identity information between endpoints. The protocol architecture maintains a separation of control between all parties of the exchange and supports both compartmentalized and anonymous identities. "RTP Payload Format for E-AC-3 Audio", Brian Link, 2-Feb-06, This document describes an RTP payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US HDTV, DVD, cable and satellite television and other media. E-AC-3 is an optional audio format in US and world-wide digital television and high definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. "Declarative Public Extension Key to Enhance iSCSI Supportability", David Wysochanski, 6-Feb-06, RFC 3270 defines the iSCSI protocol and allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. "MEF Ethernet Traffic Parameters", Dimitri Papadimitriou, 6-Feb-06, This document described the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF.10 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. "Problem Statement for the AMSK", Kuntal Chowdhury, 6-Feb-06, Network operators offer multiple services ranging from basic network access level service to application level service. Each of these services require independent authentication and authorization steps. Depending on the number of services and the scale of these networks, the need for multiple levels of authentication and authorization phases not only makes the operation complex, but it increases network load and session setup latency. This document summarizes the related problem scenarios. The goal is to address these problem scenarios with a solution based on the EAP keying framework. "Secure Dynamic MANET On-Demand (SDYMO) Routing Protocol", Manel Guerrero Zapata, 7-Feb-06, The Secure Dynamic MANET On-Demand (SDYMO) Routing Protocol is an extension of the DYMO routing protocol that can be used to protect the route discovery mechanism providing security features like integrity and authentication. "Extensions to NFSv4 for Checksums", Alok Aggarwal, 7-Feb-06, This document provides motivation for enhancing the NFSv4 protocol to enable checksumming of data and describes extensions to NFSv4 in order to enable such a capability. Discussion and suggestions for improvements are requested. "A Link-Type sub-TLV to convey the number of unconstrained Traffic Engineering Label Switch Paths signalled across a link", JP Vasseur, 7-Feb-06, Several Link-type sub-TLVs have been defined for OSPF and ISIS in the context of MPLS Traffic Engineering in order to convery some link characteristics such as the available bandwidth, traffic enginering metric, adminstrative group and so on. There are various circumstances where it would be useful to also know the number of unconstrained Traffic Engineering Label Switched Path(s) (TE LSP). This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a specific link. "Simple Ad hoc Key Management (SAKM)", Manel Guerrero Zapata, 7-Feb-06, The Simple Ad hoc Key Management (SAKM) is a key management system that allows to the nodes of an ad hoc network to use asymmetric cryptography with zero configuration. It is intended to be applied to MANET routing protocols that provide security features that require the use of asymmetric cryptography (like SAODV and SDYMO). "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path", JP Vasseur, 7-Feb-06, This document specifies a Path Computation Element (PCE)-based procedure to compute inter-domain Traffic Engineering (TE) Multiprotocol Label Switched (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) constrained shortest 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. "Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ Housley, 8-Feb-06, This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extension types are carried in the client and server hello messages to confirm that both parties support the authorization messages. The syntax and semantics of the authorization messages are described in detail. "GMPLS Control of Ethernet VLAN Cross Connect Switches", Nurit Sprecher, 9-Feb-06, This document complements the 'GELS framework for GMPLS-controlled Ethernet Label Switching' paper ([GELS-FRAMEWORK]). It is based on the architecture and the control plane operations which are defined in the framework. Specifically, this document explains how Ethernet switches employing the VLAN Cross Connect method use the link local labels defined in the GELS framework document to establish Connection Oriented point-to-point Ethernet services. An additional document will be written to describe the natural extension to support multipoint services. "Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB)", Steve Silverman, 9-Feb-06, 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. "PCE Applicability for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, 9-Feb-06, A network may comprise of multiple layers. It is important to globally optimize network resources utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes the applicability of the PCE-based path computation architecture to inter-layer MPLS and GMPLS traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). "A URN Namespace for the Latvian National Government Integration Project", Jurijs Kornijenko, 9-Feb-06, This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor - Olimps Ltd and subcontractors - ABC software LTD, Microsoft Latvia LTD, RIX Technologies LTD and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (latvian abbreviation - IVIS). "SPEERMINT Requirements and Terminology", Dave Meyer, 9-Feb-06, This document outlines the solutions space requirements and defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. "DNSKEY Trust Anchor Key Requirements", Thierry Moreau, 10-Feb-06, This draft attempts to fill a portion of the gap between DNSSEC deployment expectations and the lack of DNSSEC trust anchor key management solutions, protocol and procedural aspects. Specific requirements are stated at a level of abstraction that should accommodate solution alternatives to the issues of providing trust anchor keys to DNSSEC-aware resolvers, and rolling those keys. Nonetheless, the characteristics the DNSSEC protocols and the DNS operation contingencies do shape many of the requirements. "Advertising Multiple Nexthop Routes in BGP", Manav Bhatia, 10-Feb-06, This document describes an extensible mechanism that allows a BGP speaker to advertise multiple BGP paths for a destination to its peers, by describing a new BGP capability, termed "Multiple-Hop Capability". The mechanisms described in this document are applicable to all routers, both those with the ability to inject multiple routing entries in their forwarding table and those without. "Trusted Transactions for Network-Enabled Devices", Jeff Stapleton, Phillip Griffin, 10-Feb-06, This document specifies a cryptographically protected message format and transaction protocol for managing network-enabled devices. The message format consists of a header, content and trailers. The message header uniquely identifies the message type. The message content is afforded (i) authentication by means of a digital signature trailer and (ii) confidentiality by means of encryption trailer; and the whole message (header, content, trailers) is afforded integrity by means of a trusted time stamp trailer. All message structures are defined using ASN.1 and all cryptographic structures use CMS. The transaction protocol consists of request messages, response messages, acknowledgement messages, and notification messages. "A Framework for GMPLS-controlled Ethernet Label Switching", Dimitri Papadimitriou, 10-Feb-06, This framework introduces the service models that should be supported. It describes the architecture and the information exchange between the different elements that sustain the reference models. It defines the Ethernet label. The framework also specifies the changes/ extensions that are required to the GMPLS in order to support the service models. "Accounting on Softwires", Bruno Stevant, 13-Feb-06, For access network operators, accounting information are crucial: they provide information for billing and give an overview of the traffic usage. This document defines the requirements for accounting information needed on Softwires. "A Keying hierarchy for managing Wireless Handover security", Madjid Nakhjiri, 3-Mar-06, The Problem of AAA-based key management for facilitating secure handovers in a wireless mobile environment has been described in [I-D.nakhjiri-aaa-hokey-ps]. The intention with this document is to provide a starting point for developing a solution for that problem by introducing a key hierarchy using EAP generated keys. An example of how the channel binding problem can be solved is also added in an appendix. "Pre-Shared Key (PSK) Based Addresses (PBA)", Narayanan Venkitaraman, Vidya Narayanan, 13-Feb-06, Cryptographically generated addresses (CGAs) provide a means of generating an IP address that is tied to a public key of a node. Using this means, the address ownership of the node can be verified by using the public key of the node to decrypt data signed by the node using its private key. In AAA-based systems, there is currently no means of performing such absolute address ownership checks, since address authorization is traditionally outside the scope of AAA. However, in some key generation protocols, it may be critical to perform address ownership verification or authorization before the generated key can be used. When such key generation protocols are AAA-based, there is no known method of address authorization to allow this operation. This draft provides a means of IPv6 address generation using a shared secret so that the IP address of a node can be verified by the entity with which the node shares the secret. "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, 13-Feb-06, One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guideliness on handling this aspect of network design could slow down the integration of IPv6. This draft aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The draft also provides IPv6 addressing case studies for both an enterprise and an ISP network. In this first version of the draft we aim to provoke discussion on this important topic; more detailed case study texts will follow. "A method to Batch Subscriptions Refreshments", Xiao Wang, 14-Feb-06, This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for refreshing batch subscriptions by a message. Subscriber send a message to refresh many subscriptions, and these subscriptions may be in a dialog or in several different dialogs. "Rbridges: Base Protocol Specification", Radia Perlman, Joseph Touch, 15-Feb-06, 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. "Requirements for delivering MPLS Services Over L3VPN", Kenji Kumaki, 15-Feb-06, This document describes Service Provider requirements for providing end-to-end MPLS TE LSPs over L3VPN. The main objective is to present a set of requirements which result in general guidelines for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is out of scope in this document. "IP Flow Information Exchange (IPFIX) Testing", Carsten Schmoll, Paul Aitken, 15-Feb-06, This document presents a list of tests which implementers of IP Flow Information Export (IPFIX) compliant systems are encouraged to perform on their IPFIX system. This document has been created to help implementers test the functionality of their IPFIX exporter and/or collector component. The goal of these tests is to ensure that all important functions are covered by tests and thereby to gain a level of confidence in the system which allows the implementer to perform interoperabilty or plug tests with other IPFIX systems. "IANA Registration for Enumservice foaf", Kurt Reichinger, 15-Feb-06, This memo registers the Enumservice "foaf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process defined in RFC3671. The Enumservice "foaf" is to be used to refer from an ENUM domain name to the location of a FOAF RDF file using the corresponding E.164 telephone number. Clients may use data retrieved from a FOAF RDF file to provide caller or callee with information available within the Friend-Of-A-Friend (FOAF) Semantic Web application. For example, the caller might be presented with personal information on the callee (e.g. name, gender and various online attributes) as well as information on the callee's social context (e.g. relations to friends or colleagues). "Security Threats to Network-based Localized Mobillity Management", James Kempf, Christian Vogt, 15-Feb-06, This document discusses security threats to NETLMM-based mobility management with a focus on threats on the interface between mobile nodes and access routers. Threats to the NETLMM protocol itself, which runs between the access routers and mobility anchor points, are similar to those faced by other protocols between network entities like routers. These threats are handled in the NETLMM protocol specification. In contrast, threats on the interface between mobile nodes and access routers are different, because the access routers are presenting the NETLMM domain as a single subnet, in order to allow mobile nodes to continue using the same IP address as they move from one access router to another. "Credit-Based Authorization for Concurrent Reachability Verification", Christian Vogt, Jari Arkko, 15-Feb-06, Mobility and multi-homing protocols enable multi-addressed nodes to redirect ongoing communication sessions from one IP address to another. Most of these protocols verify a multi-addressed node's reachability at a claimed new IP address in order to prevent redirection-based flooding attacks. In view of reduced protocol latencies, such verification is preferably performed concurrently, i.e., while packets are already being sent to the new IP address. This document defines Credit-Based Authorization, a technique that facilitates concurrent reachability verification without compromise of security. "Methodologies for Scaling Server Load Balancing Environments", Zeeshan Naseh, 16-Feb-06, This document defines details of several design methodologies and current best practices for scaling server load balancing (a.k.a. content switching) environments in today’s enterprise data centers. The scenarios covered in this document covers utilization of protocols and technologies ranging from IPv4 routing to DNS for scalability of server load balancing. "Portable Symmetric Key Container", Apostol Vassilev, 16-Feb-06, This document specifies a shared secret token format for transport and provisioning of shared secrets (One Time Password (OTP) keys or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "IPv6 Benchmarking Methodology", Chip Popoviciu, 16-Feb-06, The Benchmarking Methodologies define in RFC2544 [4] are IP version independent however, they do not address some of the specificities of IPv6. This document provides additional benchmarking guidelines which in conjunction with RFC2544 will lead to a more complete and realistic evaluation of the IPv6 performance of network elements. "DSL Forum Vendor-Specific RADIUS Attributes", Vince Mammoliti, 3-Mar-06, This document describes the set of Remote Authentication Dial in User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum. "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media", Richard Ejzak, 16-Feb-06, This document describes a private Session Initiation Protocol (SIP) header (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. "Bi-directional Multicast Protocol", Edison Albuquerque, 17-Feb-06, This document addresses the problem of providing a bi-directional multicast protocol in an Intranet environment. A protocol named Switched Bi-directional Multicast Protocol (XMP) is proposed. Participants(Sender, S, or Receivers, Rs)signal their will to join the group sending a START(G) packet toward a Focal Point Router(FP). To take control of transmission a receiver application receives permission from the master application (the master transmitter)and sends a START(G) packet re-labeling the involved routers interfaces from R to S. The master Sender resumes transmission by means of his application commanding the receiver's application to go back to the receiver mode and emitting a START(G)packet to FP. ns-2 has been used to simulate it. "LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark, 8-Mar-06, IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. "The EAP TLS Authentication Protocol", Dan Simon, Bernard Aboba, 28-Feb-06, The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. "The Jabber-ID Email Header", Peter Saint-Andre, 17-Feb-06, This document defines an electronic mail header that enables a sender to include a Jabber Identifier in the header block of an email message for the purpose of associating the email message or sender with a particular address on an Extensible Messaging and Presence Protocol (XMPP) network. "Pre-Shared Key (PSK) Based Addresses (PBA)", Narayanan Venkitaraman, Vidya Narayanan, 17-Feb-06, Cryptographically generated addresses (CGAs) provide a means of generating an IP address that is tied to a public key of a node. Using this means, the address ownership of the node can be verified by using the public key of the node to decrypt data signed by the node using its private key. In AAA-based systems, there is currently no means of performing such absolute address ownership checks, since address authorization is traditionally outside the scope of AAA. However, in some key generation protocols, it may be critical to perform address ownership verification or authorization before the generated key can be used. When such key generation protocols are AAA-based, there is no known method of address authorization to allow this operation. This draft provides a means of IPv6 address generation using a shared secret so that the IP address of a node can be verified by the entity with which the node shares the secret. "Pseudowire Group ID Application", Zhang Haiyan, 17-Feb-06, The Pseudowire Group ID is introduced and simply defined in [PWE3- CTRL], but how to use Pseudowire Group ID has not been definitely expounded. This document details the applications of Pseudowire Group ID. "Authorization Policies for Preventing SPIT", Thomas Froment, 21-Feb-06, SPAM, defined as sending unsolicited messages to someone in bulk, might be a problem on SIP open-wide deployed networks. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various factors. This document discusses mechanisms to establish policies to react on potentially unwanted communication attempts. These policies match a particular SIP communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by the Session Initiation Protocol, SIP identity mechanism, SIP-SAML and SPIT-SAML. An important topic for investigation is to decide whether the problem is worth analyzing, the choice of a policy language for describing authorization policies and to provide a mechanisms to create and modify authorization policies that are stored in XML documents. "IETF Process and Operations Documentss", Harald Alvestrand, 21-Feb-06, This document describes a new document series intended for use as a repository for IETF process and operations documents, which should be more ephemeral than RFCs, but more referenceable than internet- drafts, and with more clear handling procedures than a random Web page. It proposes to establish this series as an RFC 3933 process experiment. Comments should be sent to the author, or to the IETF list: ietf@ietf.org. "PDAD-OLSR: Passive Duplicate Address Detection for OLSR", Kilian Weniger, 21-Feb-06, This draft proposes PDAD-OLSR, a solution for configured address uniqueness maintenance in MANETs running the OLSR protocol. It utilizes the Passive Duplicate Address Detection (PDAD) concept, which enables nodes to passively detect duplicate addresses in the network (e.g., occurring after network merging) by analyzing received routing protocol messages. Due to its passive nature, PDAD-OLSR is very efficient in terms of bandwidth consumption. Moreover, it can prevent the contamination of routing tables with wrong routing information resulting from an address conflict. "Optimizing Mobile IPv6 (OMIPv6)", Francis Dupont, Wassim Haddad, 21-Feb-06, This document describes an optimization to the Mobile IPv6 (MIPv6) protocol, which uses the crypto-based identifier (CBID) technology to securely establish a long lifetime bidirectional security association (SA) between the mobile node (MN) and the correspondent node (CN) and to reduce the IP handoff latency as well as the amount of signaling messages. "OSPF Based L1VPN Auto-Discovery", Igor Bryskin, Lou Berger, 21-Feb-06, This document defines an OSPF based layer-1 VPN auto-discovery mechanism. This mechanism enables PEs using the OSPF IGP to dynamically learn about existence of each other, and attributes of currently configured CE-PE links and their associations with L1VPNs. This document builds on [L1VPN-FRMWK] and provides an auto-discovery mechanism as discussed in [L1VPN-BM]. "Updates to the Group Domain of Interpretation (GDOI)", Brian Weis, Sheela Rowles, 21-Feb-06, This memo describes additional updates to the Group Domain of Interpretation (GDOI) [RFC3547] . It provides clarification where the original text is unclear. It also includes a discussion of algorithm agility within GDOI, and proposes several new algorithm attribute values. "The SIP PING Method", Frank Miller, 5-Mar-06, The Session Initiation Protocol (SIP) has the potential for long periods of time to elapse when no signaling traffic is sent between a User Agent Client (UAC) and a User Agent Server (UAS). There are situations when it is advantageous to have some signaling traffic flow periodically between these endpoints or to have a quick, lightweight check whether a UAS is alive. The PING method is proposed that can be used for these purposes. "BR Organization Mapping for the Extensible Provisioning Protocol (EPP)", Frederico Neves, Hugo Koji Kobayashi, 27-Feb-06, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of .br organizational social information stored in a shared central repository. Specified in XML, this mapping extends the EPP contact mapping to provide additional features required for the provisioning of .br organizational social information. "BR Domain Mapping for the Extensible Provisioning Protocol (EPP)", Frederico Neves, Hugo Koji Kobayashi, 27-Feb-06, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of .br Internet 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 .br domain names. "Semi-Proactive QoS Re-establishment", Franco Tommasi, 22-Feb-06, Re-establishment of QoS after a Mobile Node handover must be done as quickly as possible in order to reduce degradation or interruption of QoS. It is specifically useful if real-time applications are used. We propose a Semi-Proactive procedure for QoS re-establisment that also avoids waste of resources. Moreover, we propose a new point of buffering for the packets destined to the Mobile Node during the handover. This is useful when QoS is required for these packets. "A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services", Rohan Mahy, 22-Feb-06, This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning im: URIs in ENUM. "HTTP Enabled Location Delivery (HELD) - Sighting", James Winterbottom, 22-Feb-06, A Geopriv sighting protocol is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol supports mobile and nomadic devices through Location URIs and location update URIs, which enables generation of location information at the Device. The protocol is an application-layer protocol that is independent of session-layer; an HTTP, web services binding is specified. "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", Martin Thomson, 22-Feb-06, This document defines a set of shapes for the representation of uncertainty for PIDF-LO geodetic location information. This includes a GML profile and a schema that defines additional geometries. Further recommendations are made to restrict the use of geographic Coordinate Reference Systems (CRS) and units of measure restrictions that improve interoperability. "Encrypted Key Transport for Secure RTP", David McGrew, 23-Feb-06, SRTP Encrypted Key Transport (EKT) is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by SIP forking and early media. "Serial forwarding approach to connecting TinyOS-based sensors to IPv6 Internet", Behcet Sarikaya, 23-Feb-06, This document describes a simple approach to interconnect IEEE 802.15.4 sensor nodes to IPv6 Internet. The technique requires a gateway node that is connected to both the sensor network and the IPv6 Internet. The gateway node runs the serial forwarder over IPv6. Sensor nodes run the open-source TinyOS operating system and generate TinyOS packets. The sensor network can be accessed from IPv6 Internet using a Web interface and the serial forwarder that runs in the applets enables reception/transmission of TinyOS packets over IPv6. "XKMS Provisioning of OATH Shared Secret Keys", Phillip Hallam-Baker, 23-Feb-06, A means of provisioning OATH shared secret OTP parameters based on the XKMS protocol is described. The techniques used may be extended to support XKMS registration of symmetric keys for other cryptographic protocols. It is hoped that publication of this note will allow others to make use of the same architectural approach as a starting point for future proposals. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability commercial and open-source implementations. "A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services", Rohan Mahy, 23-Feb-06, This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning mailto: (iMIP) and http: (CalDAV) URIs in ENUM. "Pseudowire for Supporting Multicast traffic", Haiyan Zhang, 23-Feb-06, This document describes the solution for supporting the efficient transport of multicast-based services and the corresponding Label Distribution Protocol (LDP) protocol extensions and procedures. "4over6 Transit using Encapsulation and BGP-MP Extension", Jianping Wu, 23-Feb-06, Due to the rapid deployment of IPv6 networks, especially IPv6 backbones, the existing long-live IPv4 networks are connected to these IPv6 networks. In the environment that ISP hopes to use IPv6 backbones while still provides end users IPv4 access to support existing IPv4 applications, IPv4 traffic needs to be transported over IPv6 backbones. Along with the growth of IPv6 backbones, the number of IPv4 access networks becomes large and the IPv4/v6 interconnection topology becomes complex. Therefore, the manual configuration to a large number of these end-2-end tunnels will be an insufferable burden. This draft addresses this problem and presents a mechanism of automatic 4over6 tunnel-end discovery with BGP extensions. "Telephone Number Mapping and Domain Keys as a Distributed Identity Infrastructure", Alexander Mayrhofer, 23-Feb-06, This document creates a decentralized indentity infrastructure by combining technology from E.164 Number Mapping (ENUM) and DomainKeys Identified Mail (DKIM). This infrastructure uses E.164 numbers as identities, ENUM DNS for key distribution, and leverages the trust relations from ENUM validation to actual messages signed by the number holder. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, 24-Feb-06, The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. DNS SRV can be used to join these organization-wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. "Instant Message Delivery and Read Receipts", Hisham Khartabil, 24-Feb-06, 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 receipt as well as a read receipt for a page-mode as well as session mode instant messages. This document also describes how SIP and MSRP entities behave using this extension. "TRILL Routing Requirements in Support of RBridges", Eric Gray, 24-Feb-06, 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 an RBridge campus, optimal pair-wise routing, safe forwarding even during periods of temporary loops, and the potential ability to cut down on Address Resolution Protocol (ARP) and/or Neighbor Discovery (ND) traffic. The design supports VLANs, allows forwarding tables to be based on destinations within the RBridge campus (rather than endnode destinations, allowing internal forwarding tables to be smaller than in conventional bridge systems) and re-uses existing routing protocols (for distribution of reachability of destinations and shortest path computation within an RBridge campus, and potentially for peer/topology discovery). In order to accomplish this, the design may impose requirements for extensions to one or more existing routing protocols necessary to accomplish the distribution and computation processes, as well as specific limits on interactions between bridge, R-Bridge and Router instances. "Atom Syndication Format Person Extensions", James Snell, 24-Feb-06, This specification defines extensions to the Atom Syndication Format Person Construct. "Connectivity Scenarios for MANET", Simone Ruffino, 24-Feb-06, This Internet Draft aims at describing a wide spread set of possible connectivity scenarios involving mobile ad-hoc networks, in order to provide a reference for the AUTOCONF Working Group. 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. "The Architecture of an RBridge Solution to TRILL", Eric Gray, 24-Feb-06, RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine the link layer ability to allow hosts to reattach without renumbering with network layer routing benefits. RBridges use existing link state routing to provide higher RBridge to RBridge cross-section bandwidth, fast convergence on reconfiguration, and more robust under link interruption than an equivalent set of conventional bridges using existing spanning tree forwarding. They are intended to apply to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also attempt to retain as much 'plug and play' as is already available in existing bridges. This document proposes an RBridge system as a solution to the TRILL problem. It also defines the RBridge architecture, defines its terminology, and describes basic components and desired behavior. One or more separate documents specify the protocols and mechanisms that satisfy the architecture presented herein. "Generic EAP Encapsulation (GEE)", Peter Barany, 24-Feb-06, The Extensible Authentication Protocol (EAP) is a general authentication protocol that supports multiple authentication methods and typically runs directly over data link layers without requiring IP. EAP can be used for both access and service authentication, where the access network provider may or may not be the same as the service network provider. However, EAP itself does not have the ability to differentiate between access and service authentication. Furthermore, when the service network provider is a mobility service provider, Mobile IP-AAA signaling is/can be used for service authentication; thereby making EAP service authentication redundant. However, EAP itself does not have the ability to instruct the peer that it should use Mobile IP-AAA signaling for service authentication instead of EAP. This document specifies a general encapsulation protocol, called Generic EAP Encapsulation (GEE), for differentiating between access and service authentication and for communicating to the peer that it should use Mobile IP-AAA signaling for service authentication instead of EAP. "Transmission of IPv6 Packets over IEEE 802.16", Myung-Ki Shin, Hee-Jin Jang, 24-Feb-06, This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.16 networks. It also specifies how to send IPv6 unicast and multicast packets over IEEE 802.16 networks. "The Domain Policy DDDS Application", Otmar Lendl, 27-Feb-06, This documents proposes the use of the DNS to publish a domain's policy regarding incoming communication. The algorithm used is defined as a new application of the Dynamic Delegation Discovery System (DDDS). Such policy announcements can be used to facilitate selective SIP peering. "Consideration about Location Privacy of CoA in MIP6", Zhongqi Xia, 27-Feb-06, In this document, we discuss the problem about location privacy of CoA in Mobile IPv6. And some possible policies and solutions are discussed in order to protect location privacy of CoA in route optimization mode. "Reroute Extensions to LDP for P2MP LSP", Shuying Liu, 27-Feb-06, This document describes some extensions to the Label Distribution Protocol (LDP) for the reroute of point to multi-point (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP only and has no requirement of a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for rerouting a P2MP LSP in the following cases:1)network failure (link or node); 2)a better path emerges (e.g. new link available, metric change);3)planned maintenance. The rerouting mechanism described in this document can minimize the time of traffic disruption when network failure happens. It will also minimize the data duplication and guarantee the traffic continuity during the procedure of rerouting in the last two cases mentioned above. "mpegra URN Definition", Fx Nuttal, 27-Feb-06, ISO JTC1/SC29/WG11 has published the MPEG-21 Digital Item Identification (DII) standard (ISO/IEC 21000-3:2003). This part of the standard defines Digital Items Identifiers as URIs. A registration Authority has been appointed to guarantee uniqueness of the registered identfiers. This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for DIIs. "InterDomain-QOSM: The NSIS QOS Model for Inter-domain Signaling to Enable End-to-End QoS Provisioning Over Heterogeneous Network Domains", Jian Zhang, Edmundo Monteiro, 27-Feb-06, This document describes a NSIS QoS Model for inter-domain signaling (InterDomain-QOSM) between adjacent domains to enable end-to-end QoS provisioning over heterogeneous network domains. Specifically, it assumes a distinct separation between the intra-domain control plane and the inter-domain control plane of an administrative domain and is intended to implement a common inter-domain interface that allows the QoS negotiation and setup of inter-domain traffic streams while hiding the heterogeneity of intra-domain control mechanisms in use in a chain of heterogeneous network domains. The InterDomain-QoSM in this document first describes its operation mode and then the additional QSPEC parameters for fulfulling the common inter-domain interface are specified, followed by the illustrations of how the InterDomain-QOSM cooperates with some typical intra-domain QOSMs. "How to Write an RTP Payload Format", Magnus Westerlund, 27-Feb-06, This document contains information on how to best write an RTP payload format. Reading tips, design practices, and practical tips on how to quickly and with good results produce an RTP payload format specification. A template is also included with instructions that can be used when writing an RTP payload format. "Multiple Forwarding Destinations Notification", Benjamin Koh, Keigo Aso, 27-Feb-06, This document considers a mobile terminal with multiple interfaces which uses Mobile IPv6[1]. With multiple interfaces, the mobile terminal may use them simultaneously for communication with a peer device. Hence enabling the mobile terminal to achieve fault tolerance, load balancing and so on. This document deals with the mobile terminal with multiple interfaces, so it is possible that each kind/type of interface may have its own characteristics or differences. "The Session Initiation Protocol (SIP) Same-Session Header Field", Salvatore Loreto, Gonzalo Camarillo, 27-Feb-06, This document defines a new header field for use with SIP. The Same- Session header field is used to logically correlate an existing SIP dialog with a new SIP dialog when the media sessions established by both dialogs can be considered a single logical session. This mechanism can be used to share the user interface and other resources between all the media streams from both sessions. "Privacy Analysis for the SHIM6 protocol", Marcelo Bagnulo, 27-Feb-06, This note presents a privacy analysis for the SHIM6 protocol for IPv6 site multihoming support and the failure detection extensions for the SHIM6 protocol.This note does not attempt to provide a solution for providing SHIM6 protocol privacy. "Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment", Kenji Kumaki, 27-Feb-06, This document describes Service Provider requirements for IP/MPLS- GMPLS interworking in support of GMPLS deployment. The main objective is to present a set of requirements and scenarios which result in general guidelines for the definition, selection and specification of a technical solution addressing these requirements and supporting the scenarios. Specification for this solution itself is out of scope in this document. "Diameter Interoperability Test Suite", Victor Fajardo, 27-Feb-06, This document describes a collection of test cases to be used for Diameter base protocol and Diameter applications interoperability testing. "A Personal critique of RFC 2026", Brian Carpenter, 27-Feb-06, This document is a personal critique of RFC 2026, the current description of the IETF standards process, based on the author's experience in various IETF roles. "Localized RSVP", Jukka Manner, 27-Feb-06, Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. Even if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources at the access network, e.g., wireless link resources. Additionally, for mobile nodes the continuity of QoS is disturbed due to end-to-end signaling or slow re-reservations of resources after each handover. This draft proposes a simple enhancement to RSVP, so that initial resource reservations and re-reservations, e.g., due to host mobility can be done locally in an access network. "Alternatives to Achieving HCoIPsec", Rohan Jasani, 27-Feb-06, Header Compression over IPsec [HCOIPSEC], documents the work items needed to integrate hop-by-hop header compression algorithms with IPsec security associations. However, as a result of various discussions within the IETF, two alternative approaches to achieving HCoIPsec have emerged. This draft is intended to document the two alternatives, and help those involved with HCoIPsec development converge on one common approach for realizing HCoIPsec. "RTCP feedback messages for packet delay adjustments", HariKishan Desineni, Nikolai Leung, 27-Feb-06, This document specifies two RTCP feedback messages which fall under the codec control category of messages defined in "Codec Control Messages in the Audio-Visual Profile with Feedback(AVPF)". They are helpful primarily in point-to-point topology. However they are also usable in smaller multicast and point to multipoint topologies. The extensions discussed are the Packet Delay Adjust Request (PDAR) and Packet Delay Adjust Acknowledgement(PDAA) messages in point-to-point topology. "ISIS extensions for ordered FIB updates", Olivier Bonaventure, 27-Feb-06, This document proposes extensions to allow IS-IS to support the ordered convergence defined in [RTG-OFIB] that allows to avoid transient forwarding loops during the FIB updates that follow a non- urgent topology change. "Automated key selection extension for the TCP Authentication Option", Brian Weis, 27-Feb-06, This memo describes an automated key selection extension for the TCP [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key selection extension allows two TCP endpoints to authenticate TCP segments using a Message Authentication Code (MAC) key chosen dynamically by an endpoint, rather than using a pre-configured MAC key. "A Document Format for Expressing Consent", Gonzalo Camarillo, 27-Feb-06, This document defines an Extensible Markup Language (XML) format for expressing consent. A permission document written in this format gives a relay permission to perform a particular translation, which is described in the document. "The reference model of IPFIX concentrators", Atsushi Kobayashi, 3-Mar-06, This document defines a reference model for IPFIX concentrators. An IPFIX concentrator is an intermediate node between IPFIX monitoring devices and traffic collectors. It has several capabilities, such as collecting and storing flow records, selecting and aggregating flow records, and exporting flow records. "The Session Initiation Protocol (SIP) Grant Permission Event Package", Gonzalo Camarillo, 27-Feb-06, This document defines the SIP Grant Permission event package. This event package is used by permission servers to inform user agents about translations for which a particular user agent needs to give consent. "The Session Initiation Protocol (SIP) List State Event Package", Gonzalo Camarillo, 27-Feb-06, This document defines the SIP List State event package. This event package is used by Resource List Servers to inform user agents about the consent-related status of the entries in one or several resource lists. "I-FHMIPv6: A Novel FMIPv6 and HMIPv6 Integration Mechanism", Jaehwoon Lee, Sanghyun Ahn, 27-Feb-06, The mobile IPv6 (MIPv6) enables a mobile node (MN) to maintain its connectivity with a correspondent node (CN) while changing its point of attachment. Since, in MIPv6, packets sent from a CN to an MN during handover can be lost, several mechanisms such as FMIPv6 and HMIPv6 have been proposed to reduce the number of lost packets. However, such mechanisms still suffer from the performance degradation due to not only packet losses but also out-of-sequence packets. In this draft, we propose I-FHMIPv6 which integrates FMIPv6 and HMIPv6 efficiently. I-FHMIPv6 uses the Flush message and can minimize packet losses. "A Mechanism to Enable File Transfer with the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, 27-Feb-06, This document provides a mechanism that enables the transfer of one or more files between two User Agents (UAs). SIP and the Session Description Protocol (SDP) offer/answer model are used to signal the establishment of a session. The Message Session Relay Protocol (MSRP) is used to actually transfer the files between the two endpoints. "Non-Custodial (Best-Effort) Multicasting Support in DTN", Susan Symington, 27-Feb-06, This document defines the requirements and constraints that must be imposed when using the Bundle Protocol [2] in order to support the best-effort multicast delivery of bundles within a Delay-Tolerant Network (DTN). The capabilities described herein enable a source node to transmit a bundle to multiple destination nodes without having to originate a separate bundle for each destination node. These capabilities do not support custody transfer of bundles that are being delivered via multicast. "Managed Objects for IPFIX concentrator", Atsushi Kobayashi, 3-Mar-06, This document defines managed objects for IPFIX collectors and concentrators. The IPFIX concentrator has a several capabilities. These capabilities provide collecting flow records, and storing these to database, selecting, aggregating and forwarding these to next IPFIX nodes. These functions have the managed infomation objects. These objects provide information about parameters and instruction rules used by each process. "Requirements for Management of Overload in the Session Initiation Protocol", Jonathan Rosenberg, 27-Feb-06, Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agencies have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. "MPA using IKEv2 and MOBIKE", Yacine El Mghazli, Julien Bournelle, 27-Feb-06, This document discusses the details of pre-authentication in a IPsec protected access environment. It describes an optimized solution that avoids re-establishing an IPsec tunnel after the handover, leveraging on IKEv2 and MOBIKE protocol. "The Effect of NATs on P2P SIP Overlay Architecture", Eric Cooper, Philip Matthews, 27-Feb-06, This document discusses the constraints that NATs put on the possible overlay architectures of a P2P SIP system. Given what seems to be a reasonable set of assumptions on where nodes are deployed and the kinds of NATs they are located behind, the document concludes that a structured partial-mesh overlay network exhibiting a property known as "symmetric interest" is the most reasonable overlay architecture. "Optimized Derivation of AAA-based Handover Keys", Vidya Narayanan, 27-Feb-06, AAA-HK [1] provides a method for a MN and an AR to establish a shared key using a AAA server. To ensure that the round trip to the AAA server does not delay handoff, the handover key must be derived independent of and well ahead of the actual handoff, preferably immediately after moving to a new access router. This document describes one such method of optimizing the handover key derivation by using an AR as an authenticating server, once the MN and AR have established a security association. "Padding Chunk and Parameter for SCTP", Michael Tuexen, Randall Stewart, 27-Feb-06, This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. "Network Based L3 Connectivity and Mobility Management for IPv4", Kuntal Chowdhury, 27-Feb-06, The layer 3 mobility management in a mobile wireless network can be performed with Mobile IPv4. The solution however requires the mobile nodes to have Mobile IPv4 clients. There may be scenarios where the mobile devices do not have Mobile IPv4 clients. The layer 3 mobility for these devices (often called simple IPv4 mobiles) can be done if the network has a Mobile IPv4 client function that can perform Mobile IPv4 procedures on behalf of the mobile nodes. This document defines such a mechanism. "IPv6 over Network based Mobile IPv4", Jay Navali, Kuntal Chowdhury, 27-Feb-06, There is a growing demand for routable IP addresses to support large wireless user base today. Wireless operators are looking for ways to leverage the IPv6 address space to meet the ever increasing number of wireless data users. The operators who has network based IPv4 mobility solutions can leverage the same scheme to provide mobility access service with larger address pool using IPv6 addressing. This document defines such a mechanism. "Diffie-Hellman Exchanges for Multimedia Sessions", Mark Baugher, David McGrew, 27-Feb-06, This memo defines a new Session Description Protocol (SDP) attribute for exchanging Diffie-Hellman (DH) public keys. The attribute is an SDP session-level attribute for describing DH keys, and there is a new media-level parameter for describing public keying material for SRTP key generation. The SDP attribute supports the key establishment schemes of NIST Draft Special Publication 800-56, adds domain parameters and supports external authentication of the DH endpoint without a public key infrastructure. "The Qpopper MIME Mangling (X-MANGLE) and Macro (MDEF) Extensions to POP3", Randall Gellens, 28-Feb-06, This document describes two extensions to the POP protocol that have been supported for several years by some client and servers. One extension, X-MANGLE, allows clients to request that MIME body parts be removed or converted to a simpler format, that only selected headers be transmitted, and/or to for the message to be transcoded to a different character set. The other extension, X-MACRO, allows clients to define macros which are expanded when used, saving repetitive transmissions. "Overlay Multicast Protocol", Mark Pullen, 28-Feb-06, This document defines formats and procedures for middleware that operates at the application layer to provide for transmission of IP multicast over IP networks that do not have network layer multicasting enabled, by means of tunneling IP multicast over IP unicast. This capability is called overlay multicast (OMCAST). While it cannot be as efficient as network layer multicasting, OMCAST allows for transparent support of IP multicast applications. Because the relay agents can cooperate to forward multicast messages in a way modeled after network layer multicast trees, significant reductions in network traffic are possible as compared to parallel transmission by each host to all other participating hosts. However, this protocol only provides mechanisms for the agents to cooperate; it does not prescribe a mechanism for routing messages among the agents. "DNSSEC Lookaside Validation (DLV)", Samuel Weiler, 28-Feb-06, DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNSSEC trust anchors outside of the DNS delegation chain. It allows resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or refuse to publish DS records for their children. "The LDAP Manage Directory Information Tree Control", Kurt Zeilenga, 28-Feb-06, This document defines the Lightweight Directory Access Protocol (LDAP) Manage Directory Information Tree (DIT) Control which allows a directory user agent (a client) to request the directory service temporarily relax enforcement of constraints of the X.500 models. "Advantages of OSPF-MDR", Richard Ogier, 28-Feb-06, This document summarizes and discusses the advantages of OSPF-MDR, a proposed extension of OSPF that supports the MANET interface type. "Using the Boneh-Franklin identity-based encryption algorithm with the Cryptographic Message Syntax (CMS)", Mark Schertler, 28-Feb-06, This document describes the conventions for using the Boneh-Franklin identity-based encryption (BF-IBE) algorithm in the Cryptographic Message Syntax (CMS). The BF-IBE algorithm supports the transport of symmetric keys to encrypt message content. Object identifiers (OIDs) and the convention for encoding a recipient’s identity are also defined. "A Schema Fragment for Flow Distribution", Koshiro Mitsuya, 28-Feb-06, The multiple care-of address registration protocol [1] provides a framework to maintain multiple virtual paths with its home agents. But there is no solution to synchronize a policy for flow distribution on the multiple paths. This document describes a schema fragment (a xml based data set) to define flow distribution policy. A dynamic policy exchange method using SOAP is also introduced. "Multi-Subnet MANETs", Dave Thaler, 28-Feb-06, This document describes an approach to addressing nodes in Mobile Ad-hoc Networks (MANETs) which involves assigning a separate subnet to each MANET router. This approach avoids many of the problems that arise in other approaches, and is intended to allow existing protocols and applications to work unmodified. "Mobility Management using Proxy Mobile IPv4", Kent Leung, 28-Feb-06, Mobile IPv4 is a standard mobility protocol that enables IPv4 device to roam between networks. The mobile device has the Mobile IP function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes a solution based on Proxy Mobile IPv4, which enables some other entity to provide mobility support on behalf of an unaltered and mobility- unaware IPv4 device. "Internationalization in Internet Applications: Issues, Tradeoffs, and Email Addresses", John Klensin, 28-Feb-06, The discussions of internationalized email addresses in the IETF have led to a number of stated requirements. This document identifies some of those requirements in the context of general issues of internationalization of Internet name spaces, demonstrates that the combination of all of the requirements that appear reasonable on first glance adds up to a null solution space, and then suggests a different model for proceeding. "RTP Payload Format for Theora Encoded Video", Luca Barbato, 28-Feb-06, This document describes a RTP payload format for transporting Theora encoded video. It details the RTP encapsulation mechanism for raw Theora data and configuration headers necessary to configure the decoder. Also included within the document are the necessary details for the use of Theora with MIME and Session Description Protocol (SDP). "Multi-TEchnology Recovery (MTER) Problem Statement", Zubair Ahmad, 28-Feb-06, The objective of this document is to begin a discussion that will determine the level of interest at the IETF in documenting how multiple recovery techniques can successfully be combined to protect a set of network resources and the various interactions between these recovery techniques. Potential outcome of this work could be to define new MIBs and/or OAM techniques devoted to such interactions. "Media Server Markup Language (MSML)", Adnan Saleem, Garland Sharratt, 28-Feb-06, The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. Clients can use it to define how multimedia sessions interact on a Media Server and to apply services to individuals 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 to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as IVR dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML. "Internationalized Email Addresses: Scenarios", Harald Alvestrand, 28-Feb-06, This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. "Guidelines for Implementing the Dialog Event Package in User Agents", Dale Worley, 3-Mar-06, This document sets out guidelines for how user agents should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. It is in addition to the basic requirements for dialog event package implementation in RFC 3265 and RFC 4235. "PCC-PCE Communication Requirements for Point to Multipoint Traffic Engineering", Seisho Yasukawa, Adrian Farrel, 28-Feb-06, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of traffic engineered point-to-multipoint (P2MP) label switched paths (LSPs). Since P2MP LSP routes are sometimes complex to compute, and given the use of PCE in MPLS networks it is likely that PCE will be used in P2MP MPLS networks. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint traffic engineering. "Using the Session Initiation Protocol REGISTER Method To Obtain an Emergency Dialstring", James Polk, 28-Feb-06, Most efforts to address emergency calling challenges over IP (and cellular technologies such as GSM, TDMA, CDMA, etc, for that matter) have focused on locating the calling user in order to route the emergency call set-up request to the appropriate Public Safety Answering Point (PSAP). Little or no effort to date has focused on informing the caller what dialstring sequence they may need to use to initiate a call for emergency help. This document describes how the Session Initiation Protocol (SIP) REGISTER Request message is used to inform a user of which emergency dialstring (of the 60 known dialstring choices around the world) they should use, for where they are geographically. "PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, 28-Feb-06, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. An important application of MPLS and GMPLS networks is Virtual Private Networks (VPNs) that may be constructed using the Label Switched Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may be applied as a tool to compute the paths of such tunnels in order to achieve better use of the network resources and to provide better levels of service to the VPN customers. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements that are specific to the application of PCE to VPNs. "The NLS Firewall Application", Melinda Shore, 28-Feb-06, The Network Layer Signaling Transport Layer provides a generalized packetization and messaging framework for on-path signaling. It is designed to carry a variety of "applications." This document describes a lightweight firewall pinholing application, designed to carry requests for firewall resources to firewalls along a path between two endpoints. "An analysis of scaling issues in MPLS-TE backbone networks", Seisho Yasukawa, Adrian Farrel, 28-Feb-06, Traffic engineered Multiprotocol Label Switching (MPLS-TE) is being deployed in provider's backbone networks. The providers wish to grow these networks, and need to discover whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE backbone networks, and examines the value of two techniques for improving scaling. "ECRIT Mapping During Session Initiation Protocol Registration", James Polk, 28-Feb-06, This document discusses four different Layer-7 options to solve the problem of getting the appropriate Public Safety Answering Point (PSAP) Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) into an emergency calling capable device prior to it's user calling for help. "Extended Shim6 Design for ID/loc split and Traffic Engineering", Erik Nordmark, 28-Feb-06, The Shim6 protocol provides for locator agility while satisfying the 'first, do no harm' security requirements. This document outlines some extensions to Shim6 that in addition provides complete separation between identifiers and locators, and allows routers to rewrite the locators in the shim6 packets as a way to provide traffic engineering information to the hosts. The document also outlines a simple extension to allow shim6, with a CGA upper-layer ID, to operate using IPv4 addresses as locators. The purpose of this outline is to stimulate discussions. "Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling", James Polk, 28-Feb-06, Emergency calling is a localized event, requiring a caller to place an specially identified local emergency call to a Public Safety Answering Point (PSAP), while including the location of the caller in that signaling. The function of routing the set-up messaging to the appropriate PSAP is performed by a mapping function that binds a given location with one or more PSAP SIP(S)-URIs. This function is done by the ECRIT mapping protocol. This document analyzes when the ECRIT mapping protocol function can occur, and what general components are involved in that mapping. "Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Seisho Yasukawa, 28-Feb-06, Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses Resource Reservation Protocol traffic engineering extensions (RSVP-TE) as the signaling protocol to establish Label Switched Paths (LSPs). Although the Resource Reservation Protocol (RSVP) on which RSVP-TE is built supports the convergence of traffic flows toward a common destination, this concept has not been exploited in MPLS-TE which has been limited to point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. This document proposes extensions to RSVP-TE procedures and protocol elements to support multipoint-to-point (MP2P) LSPs. "On the applicability of various MIKEY modes and extensions", Steffen Fries, Dragan Ignjatic, 28-Feb-06, Multimedia Internet Keying - MIKEY - is a key management scheme that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time Transport Protocol. MIKEY itself defines four key distribution schemes. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arose, especially in terms of additional key distribution schemes, but also in terms of payload enhancements. This document provides an overview about MIKEY in general as well as the existing extensions in MIKEY, which have been defined or are in the process of definition. "Mobile IPv6 Location Privacy Solutions", Ying Qiu, 3-Mar-06, Mobile IPv6 [1] is an IP layer mobility protocol which allows mobile nodes to remain reachable while moving around on the Internet. With the existing specification, a mobile node's movement can be tracked by simply monitoring the IP addresses in communication involving the mobile node. In this document, we propose techniques for hiding a mobile node's location information from eavesdroppers as well as from correspondent nodes. The proposed techniques are efficient and fully compatible with the base Mobile IPv6 operation. "Home Info Discovery for Mobile IPv6 via ICMPv6 Router Advertisement", Kuntal Chowdhury, Alpesh Patel, 28-Feb-06, For Mobile IPv6 service, the mobile node first connects to an Access Router and obtain an IPv6 address to use it as a Care-of-Address. In many networks, the Access Router sends Router Advertisement to the mobile node to convey various information. If the Access Router has the knowledge of the mobile nodes home info such as home agent address, the Access Router can convey that info to the mobile node along with the Router Advertisement. This document proposes a method that will allow the Access Router to include home info of the mobile node in the Router Advertisement message. "POP3 Support for UTF-8", Chris Newman, 28-Feb-06, This specification extends the Post Office Protocol version 3 (POP3) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. "Network Based Layer 3 Connectivity and Mobility Management for IPv6", Kuntal Chowdhury, Ajoy Singh, 28-Feb-06, The layer 3 connection and mobility management is essential in providing seamless access to services and enhanced user experience in a mobile and nomadic envoirnment. This document defines a mechanism via which service providers can deploy a managed layer 3 connectivity and mobility management scheme that is entirely based on the capabilities in the Network. "Emulating Border Flow Policing using Re-ECN on Bulk Data", Bob Briscoe, 28-Feb-06, Scaling per flow admission control to the Internet is a hard problem. A recently proposed approach combines Diffserv and pre-congestion notification (PCN) to provide a service slightly better than Intserv controlled load. It scales to networks of any size, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It describes bulk border policing that emulates per-flow policing with the help of another recently proposed extension to ECN, involving re-echoing ECN feedback (re-ECN). With only passive, bulk measurements at borders, sanctions can be applied against cheating networks. "IP over 802.16 Problem Statements and Goals", Junghoon Jee, 28-Feb-06, This draft provides overview of 802.16 Network characteristics and Convergence Sublayers, and specifies the problems in running the IETF IP (both IPv4 and IPv6) protocols over 802.16 Networks. This document also presents the goals that point at relevant work to be at IETF. "An Architecture for the Access of IMG Metadata", Hitoshi Asaeda, 28-Feb-06, This document defines an architecture for the access of Internet Media Guide (IMG) metadata. An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document proposes a common architecture that provides the IMG access methods, including the use methods of URN and IMG Envelope. "HIP Extensions for the Traversal of Network Address Translators", Vivien Schmitt, 28-Feb-06, This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators behind NATs to contact HIP responders in the global Internet. Future revisions of this document will describe mechanisms to contact HIP responders behind NATs. "Resource Unavailability (RU) Per Domain Behavior", Georgios Karagiannis, 8-Mar-06, This draft specifies a Per Domain Behavior that provides the ability to Diffserv nodes located at the border or outside Diffserv domain(s) to detect when the resources provided by the Diffserv domain(s) are not available. This PDB is used when the negotiated SLS is associated to throughput (or bandwidth) and when the SLS agreed throughput bound is not statically but loosely defined in order to allow a more efficient utilization of the Diffserv domain(s) and a more simple network management operation. This PDB can be applied in association with either a single Diffserv domain or multiple neighboring Diffserv domains. This specification is denoted as Resource Unavailability (RU) PDB and it follows the guidelines given in RFC 3086. "Reducing redundancy in IPFIX and PSAMP reports", Elisa Boschi, Lutz Mark, 8-Mar-06, This document describes a bandwidth saving methodology for exporting flow or packet information using the IP Flow Information Export (IPFIX) protocol. Being the PSAMP protocol based on IPFIX, these considerations are valid for PSAMP exports as well. The main idea is to separate the export of information common to several flows (or packets) and the specific flow (or packet) information, using two different records. The association between the records is kept using unique Identifiers. "Organizing IETF Process Change", Elwyn Davies, 28-Feb-06, This document sets out a strawman proposal for how to organize the revision and update of any part of the Internet Engineering Task Force (IETF) processes including those for developing standards and other specifications. It does not propose specific changes to any of these processes, which should be the subject of future documents. However, it does propose an initial target area for process change. "Use Cases and Considerations for SIP Client Configuration and Management", Sumanth Channabasappa, Jean-Francois Mule, 28-Feb-06, This document provides use cases for the configuration and management of SIP-based devices (SIP client and applications) based on available IETF protocols and related methodologies. The use cases have been made generic enough to take into account common network topologies and requirements in SIP service deployments. Based on the use cases, we present a preliminary analysis of available IETF protocols that meet these requirements and highlight some of the limitations. "Secure Layer 3 Virtual Private Networks", Pratik Bose, 28-Feb-06, This document presents an framework for secure layer 3 Virtual Private Networks (VPNs) for customer networks that exchange encrypted information through a service provider network. It also describes the necessary interactions between the various functions (e.g. routing and encryption) at the VPN boundary to construct the secure VPN. "The Use of Transport Layer Security (TLS) in the Session Initiation Protocol (SIP)", Vijay Gurbani, Alan Jeffrey, 28-Feb-06, This document explores the use of the Transport Layer Security (TLS) in the Session Initiation Protocol (SIP). We do so by outlining the goals and the non-goals for the use of TLS and SIP. In doing so, a number of open questions are encountered regarding the contents of certificates and the behavior of SIP entities using such certificates. We hope to foster discussion in the SIP working group on these issues. "3G Wireless Support in the SIP/SDP Static Dictionary for Signaling Compression (SigComp)", Haseeb Akhtar, 28-Feb-06, While using SIGComp [4] based compression in SIP/SDP [5] [6], it is imperative to have access to a static dictionary to be used on the first SIP message that the compressor sends out. The session set up time can be reduced significantly if the compression rate of the first SIP message is considerably high. The existing static dictionary for SIP and SDP [2], however, does not include some wireless specific data elements. This document introduces these new data elements that are specific to various wireless access technologies. These new data elements are part of the first SIP message (i.e., originating SIP Invite) used to initiate a session. "New SIP Headers for Reducing SIP Message Size", Haseeb Akhtar, 28-Feb-06, Current SIP messages are text based and inherently large, especially when these messages are to be transmitted over the bandwidth-strained wireless access technologies (a typical orginiating SIP Invite is about 1200 bytes). For most wireless technologies, transmitting the session initiation messages (such as SIP Invite) over the signaling channel can reduce the call setup time substantially. The size limitation of these wireless signaling channels are typically very small (~210 bytes in the uplink and ~110 bytes in the downlink). To address this problem, a new function called Encoding Assitant (EA) has been introduced in the User Agent (UA) and in the SIP Proxy server within the network. Additionally, the method provided in this document defines new SIP option tags and headers. These new option tags and headers allow the UA and a SIP Proxy server within the network (such as the P-CSCF), to exchange information using the signaling channels supported by most wireless access networks. "Link-local Multicast Packet Transmission in 802.16 Networks", Hee-Jin Jang, 28-Feb-06, This document describes how the IPv6 Neighbor Discovery messages with link-local scope could be delivered with multicast CIDs in the 802.16 networks. "Generation ID for LDP", Albert Tian, 28-Feb-06, This document proposed two optional Generation ID TLVs in LDP Hello messages and in LDP Initialization messages to speed up LDP convergence in certain scenarios. "Mobile and Wireless Neighborhood Discovery by Using DHCP", Hee-Jin Jang, 28-Feb-06, This draft suggests a mechanism for proactively discovering capability and configuration of handover candidate networks in the neighborhood of a mobile node. "Pseudowire Performance and Timing Measurement", Thomas Nadeau, Yakov Stein, 28-Feb-06, To-date, no intrinsic mechanisms exist for pseudowires that allow operators to measure the performance of a pseudowire. Only the existing Virtual Circuit Connectivity Verification protocol allows for the verification of connectivity of a pseudowire. This document defines the problems that must be solved in this space, and provides discussion points around the issues of pseudowire performance measurement, including timing synchronization and packet loss detection. "Link Specified CoA Configuration for Heterogeneous Access Networks", Pyung-Soo Kim, 1-Mar-06, This specification defines newly the care-of addresss configuration specified by the new link of the mobile node for Mobile IPv6 handovers in heterogeneous access networks, which allows the correspondent node to know the new link of the mobile node. Using the link specified care-of address, the correspondent node can adjust quickly real-time traffics according to the available bandwidth to the mobile node. "Selective Copy-Editing Experiment for RFCs", Pasi Eronen, 1-Mar-06, This document proposes an RFC 3933 [RFC3933] experiment for the IETF RFC publication process. The experiment is limited in scope and duration. The specific experiment has been chosen because (a) it has potential to provide a significant process improvement, (b) it can be executed at a low cost, (c) it addresses a widely recognized problem in the IETF process, and (d) tool support can be (and has been) built for it. The experiment relates to the copyediting and other manual tasks in the publication process. Specifically, the amount of work these manual tasks require differs widely between drafts, and for a certain subset of drafts there are either very minor editorial changes or no changes needed at all, if we discount the different formatting requirements between RFCs and drafts. The experiment involves identification of this subset of drafts and processing them separately with a "fast path" process that uses almost entirely automated processes. For the drafts that belong to this subset, it is expected that the RFC Editor queuing time is reduced from months or years to weeks or less. "Cryptographic Token Key Initialization Protocol Version 1.0", Magnus Nystrom, 1-Mar-06, This document represents a republication of CT-KIP Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series, and change control is retained within the OTPS process. The body of this document, except for the intellectual property considerations section and the IANA considerations section, is taken directly from the CT- KIP Version 1.0 document. CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. "Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans", Jordi Palet, 1-Mar-06, This document analyzes the rational for using /64 for numbering IPv6 point-to-point links and provides some guidelines to simplify the addressing plans. "Hybrid on-path off-path approach for end-to end signalling accross NSIS domains (HyPath)", Luís Cordeiro, 1-Mar-06, In a multi-domain Internet that offers QoS guaranties for applications, there is the need of signalling among the domain entities that are responsible for the management of QoS. Because different domains have different network protocols and topologies, the HyPath approach uses the NSIS protocol and interactions with the local routing protocols to have an off path signalling in hybrid environments. "Best Current Practices for Inter-domain Instant Messaging using SIP/SIMPLE", Edwin Aoki, 1-Mar-06, This document describes best current practices that operators should use when interconnecting two or more instant messaging and presence communities using SIP/SIMPLE. These best practices are intended to assist in the efficiency and scalability of interconnections between large communities, and to ensure that security and user privacy are maintained across the interdomain boundary. 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. "Update of RFC2976", Peili Xu, 1-Mar-06, The INFO extention method for SIP is introduced in RFC2976 [1], which is base on RFC2543. Since RFC2543 is obsoleted by RFC3261 [3], It is suggested to update RFC2976 to conform to RFC3261. "Requirements for SIP-based VoIP Interconnection", Bob Natale, 1-Mar-06, This is an initial draft for consideration by the SPEERMINT WG as a candidate for the chartered work item dealing with "the minimum set of requirements for SIP-based VoIP interconnection (BCP)", due in March 2007. In its present form, this draft is intended solely to provide a basis for WG discussion about requirements selection. As such, it is primarily structural and descriptive in nature, leaving prescriptive content to later revisions driven by WG consensus. "Label Encoding Solution Decoder and Analysis for GMPLS-controlled Ethernet Label Switching (GELS)", Dimitri Papadimitriou, 1-Mar-06, This document introduces the functional criteria as a decoder ring for the selection of GELS label encoding. After detailing each proposed label encoding, each solution is analyzed against these criteria. "Framework and Requirements for a Layer 2 Control Protocol (L2CP) in Broadband Multi-Service Networks", Sven Ooghe, 1-Mar-06, The purpose of this document is to define a framework for a Layer 2 Control Protocol (L2CP) mechanism between a service-oriented layer 3 edge device (e.g. a BRAS) and a layer 2 Access Node (e.g. a DSLAM) in a multi-service architecture. This mechanism allows to perform QoS- related, service-related and subscriber-related operations. The Layer 2 Control mechanism ensures the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This document does not specify design requirements for network elements. "IETF Meeting Network and Other Technical Requirements", Jordi Palet, 1-Mar-06, This document should be used together with [1] and provides the IAD with network, terminal room and other technical requirements for selecting venues for IETF meetings. "LoST: A Location-to-Service Translation Protocol", Ted Hardie, 1-Mar-06, This document describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. "The User-registered Routable UA URL", Peili Xu, 1-Mar-06, This document analyse those kind of services which allow user to allocate its extention address which can be used as indications to route to its currently associated UA. "Requirements for PW Security", Yakov Stein, 1-Mar-06, This document addresses security requirements for MPLS pseudowires. We investigate security threats arising from the PWE3 architecture, considering confidentiality, data integrity and authentication. "Context Transfer of Mobile IPv6 Multicast Listeners", Hugo Santos, 1-Mar-06, This document describes a framework for the Context Transfer Protocol to provide the transfer of multicast listener context information between Access Router to optimize the re-activation of the multicast flows required by the terminals with minimal service disruption. "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 1-Mar-06, Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls "Protocol Extensions for Signaling Confidential Path Segments in Multiprotocol Label Switching Traffic Engineering.", Richard Bradford, 1-Mar-06, Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the LSP crosses multiple domains such as Autonomous Systems (ASs) the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases such as when ASs are administered by separate Service Providers, it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during LSP setup as the LSP enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document allows a PCE to provide a full path, but to hide the contents of a segment of that path called the Confidential Path Segment (CPS). The CPS may be conveyed in the PCE Communication Protocol (PCEP) and signaled in a Resource Reservation Protocol (RSVP) explicit route either by replacing it with a path key or by encrypting it. "Problem Statement for SIP-signalled Peer-to-Peer Communication across Middleboxes", Juergen Quittek, 1-Mar-06, Middleboxes, particularly firewalls and network address translators, are essential components of today's Internet infrastructure. They are designed to support client-server applications well, but very often they are obstacles for peer-to-peer communication. This memo discusses middlebox traversal issues of SIP-based peer-to-peer communication. Required communication steps are analyzed concerning their potential constraints caused by middleboxes. The requirements derived from this analysis are compared with the capabilites of currently available middlebox traversal methods and SIP signaling standards. The comparison identifies open issues that need to be considered when designing standards for a SIP-based peer-to-peer communication infrastructure. "The Service-Override Header", Steve Donovan, 1-Mar-06, This document proposes a new header for the Session Initiation Protocol. This header, the Service-Override header, is used to communicate application state between two SIP elements. "Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, 1-Mar-06, This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). "Diameter MIPv6 Application for the Integrated Scenario", Hannes Tschofenig, 1-Mar-06, A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document defines a Diameter application to facilitate Mobile IPv6 bootstrapping for the integrated scenario. "Mobile IPv6 Bootstrapping using Diameter in the Split Scenario", Hannes Tschofenig, 9-Mar-06, In Mobile IPv6 deployment a need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document provides a description of the functionality that allows to meet the goals outlined in the MIPv6 AAA Goals document. "Biflow implementation support in IPFIX", Brian Trammell, Elisa Boschi, 1-Mar-06, This document describes how bidirectional flows (biflows) can be implemented in the IP Flow Information Export (IPFIX) protocol. It defines biflows in terms of the IPFIX information model, explores methods for exporing biflow data via IPFIX with the current version of the protocol, and proposes a set of information model extensions for more efficient biflow export and collection. "IPv6 Neighbor Discovery Extensions for Mobility", Jari Arkko, 1-Mar-06, This specification extends IPv6 Neighbor Discovery with features that are useful for mobile nodes. These features provide information for the purposes of detecting the loss of Router Advertisements, determining the global address of the router, or for discovering which routers are also Mobile IPv6 home agents. These extensions are required for Mobile IPv6 operation, but they are also useful for any type of nomadic or mobile nodes. This document revises a part of RFC 3775 which originally defined these extensions. "Authorization for NSIS Signaling Layer Protocols", Jukka Manner, 1-Mar-06, Signaling layer protocols in the NSIS working group may rely on GIST to handle authorization. Still, in certain cases, the signaling layer protocol may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. "Reported Issues with the Security Mechanism Agreement for the Session Initiation Protocol (SIP)", Aki Niemi, 1-Mar-06, This document records some of the issues reported by implementors of the Security Mechanism Agreement for the Session Initiation Protocol (SIP), or RFC 3329. It is intended to serve as an aid in discussions and a checklist for a possible revision of the RFC. " Security Mechanism Agreement for the Session Initiation Protocol (SIP)", Jari Arkko, 1-Mar-06, This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities. Note that this internet-draft is simply a clean RFC 3329 in I-D format, and doesn't yet contain any changes compared to the original. "Enhanced validation of domains for HTTP State Management Cookies using DNS", Yngve Pettersen, 1-Mar-06, HTTP State Management Cookies are used for a wide variety of tasks on the Internet, from preference handling to user identification. An important privacy and security feature of cookies is that their information can only be sent to a servers in a limited namespace, the domain. The variation of domain structures that are in use by domain name registries, especially the country code Top Level Domains (ccTLD) namespaces, makes it difficult to determine what is a valid domain, e.g. example.co.uk and example.no, which cookies should be permitted for, and a TLD-like domain (subTLDs) like co.uk where cookies should not be permitted. This document specifies an imperfect method using DNS name lookups for cookie domains to determine if cookies can be permitted for that domain, based on the assumption that most subTLD domains will not have an IP address assigned to them, while most legitimate services that share cookies among multiple servers will have an IP address for their domain name to make the user's navigation easier by omitting the customary "www" prefix. "The TLD Subdomain Structure Protocol and its use for Cookie domain validation", Yngve Pettersen, 1-Mar-06, This document defines a protocol that can be used by a client to discover how a Top Level Domain (TLD) is organized in terms of what subdomains are used to place closely related but independent domains, e.g. commercial domains in country code TLDs (ccTLD) like .uk are placed in the .co.uk subTLD domain. This information is then used to limit which domains an Internet service can set cookies for, strengthening the rules already defined by the cookie specifications. "FMIPv6 with LinkID", Subba Reddy, 1-Mar-06, FMIPv6 aims to achieve seamless handoff but needs (AP-ID, AR-Info) in PARs to function and can't work if PAR doesn't have an entry for the next AP. In this draft, we present a scheme to dynamically build (AP-ID, AR-Info) tuple in PAR and make FMIPv6 perform even when PAR doesn't have a suitable (AP-ID, AR-Info) tuple by putting LinkID prefix in L2 beacon. "Flow Bindings in Mobile IPv6", Hesham Soliman, 1-Mar-06, This document introduces extensions to Mobile IPv6 [1] that allow nodes to bind a particular flow to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each of their interfaces. "An MP-BGP protocol extension to advertize TE-related PE-CE link information", JP Vasseur, 1-Mar-06, This document proposes MP-BGP protocol extension so as to convey Traffic Engineering Link characterictics of PE (Provider Edge) - CE (Customer Edge) links in order to extend the visibility of the Traffic Engineering Database to those links. This can then be used to more efficiently compute CE-to-CE Traffic Engineering Label Swtiched Path (TE LSP) when required to provide specific services such as bandwidth guarantees and end to end fast protection. "Use Cases for Session Mobility in Multimedia Applications", Diasaku Komiya', 1-Mar-06, Session mobility allows a user to transfer an ongoing session from one device to another device. This document attempts to summarize the use cases for session mobility in multimedia applications. For each use case, we provide possible motivation for the user to initiate a session transfer from one device to another. "ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP", Philip Zimmermann, 7-Mar-06, This document defines ZRTP, RTP (Real-time Transport Protocol) header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a Public Key Infrastructure (PKI) infrastructure. For the media session, ZRTP provides confidentiality, protection against Man in the Middle (MitM) attacks, and, in cases where a secret is available from the signaling protocol, authentication. "Federations for the Domain Policy DDDS Application", Otmar Lendl, 1-Mar-06, This documents defines the policy-type for federations within the Domain Policy DDDS Application. Using this policy-type domain-owners can announce their membership in a federation and thus their willingness to accept incoming communications according to the rules of that federation. Such federations can be used to establish selective peerings e.g. in the Voice over IP and Instant Messaging space. "A Hitchhikers Guide to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 1-Mar-06, The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. Don't Panic! This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. "OSPF MPR Extension for Ad Hoc Networks", Emmanuel Baccelli, 6-Mar-06, This draft describes an OSPF extension tailored for MANET environments. This extension leverages the techniques that were developed by the IETF MANET working group. Currently no existing OSPF interface type corresponds to MANET characteristics. This proposal therefore defines an extension for an OSPF wireless interface. OSPF specificities over the wireless interface are derived from its broadcast interfaces handling. The new OSPF wireless interface combined with MPR mechanisms from the MANET working group, provides efficient operation of OSPF over MANETs. "ECMQV Ciphersuites for TLS", Robert Dugal, Brian Minard, 1-Mar-06, This document describes the changes necessary to permit Transport Layer Security (TLS) to support the Elliptic Curve Menezes-Qu- Vanstone Key Agreement (ECMQV). "Address Autoconfiguration for Hybrid Mobile Ad Hoc Networks", Ilkyun Park, 1-Mar-06, Most of current address autoconfiguration mechanisms for MANET introduce significant load like message flooding, or are dependent on the underlying routing protocols. This document proposes a new mechanism that is intended to minimize these drawbacks. It is also designed to be applicable for hybrid MANET, where a MANET is connected to Internet through one or more Interet gateways. "IPv6 Multicast Packet Delivery over IEEE 802.16 Networks", Sangjin Jeong, Hee-Jin Jang, 1-Mar-06, This memo describes transmission of IPv6 multicast packets over IEEE 802.16 networks, including the methods to deliver various scoped multicast packets. It also presents the methods of forming multicast CIDs on IEEE 802.16 networks. "Session Initiation Protocol (SIP) Registration Event Package Extensionfor Consent-Based Communications", Gonzalo Camarillo, 1-Mar-06, This document defines an extension to the SIP registration event package for communicating whether or not a registrar has obtained permission to perform a translation that was set up through a registration. This extension is used by registrars implementing the framework for consent-based communications in SIP. "The Session Initiation Protocol (SIP) CONSENT Method", Gonzalo Camarillo, 1-Mar-06, This document defines the SIP CONSENT method. SIP relays use CONSENT requests to ask the recipient of a particular translation for permission to perform that translation. In addition, this document defines the Permission-Upload and the Trigger-Consent header fields, and the 470 (Consent Needed) status code. "A New Forking Mechanism for Gathering and Distributing Information", Dale Worley, 1-Mar-06, The rules for SIP proxies are organized so that when a UAC sends an out-of-dialog request, even if the request is forked to a number of UASs, (usually) only one UAS will accept the request, and only the final response from that UAS will be returned to the UAC. This forking mechanism is optimal for an INVITE intended to connect one human user with another human uses, but is poor for requests that have a "one to many" nature, especially PUBLISH and SUBSCRIBE requests, but also including some INVITEs. This document proposes that requests can be marked to specify that they should be forked in a somewhat manner that better supports "one to many" requests. "Design Considerations for State Identifiers in HTTP and WebDAV", Jim Whitehead, 1-Mar-06, This document discusses design considerations for state identifiers in the Hypertext Transfer Protocol (HTTP) and related protocols such as WebDAV. "IPv6 Real-Time Usage of IEEE 802.16: Problem Statement", Pedro Neves, 1-Mar-06, This document addresses the support of real-time services over IEEE 802.16-2004/802.16e [2] [3] networks. Specifically, it addresses Mobile Node fast access, dynamic services modification and fast- handover support in IEEE 802.16-2004 [2], and its limitations. It also describes the problem of service differentiation on the same user in both IEEE 802.16-2004 [2] and IEEE 802.16e [3]. "Issues With Protocols Proposing Multilink Subnets", Dave Thaler, 2-Mar-06, There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. "XENCRYPTED", Stephane Maes, Ray Cromwell, 6-Mar-06, Some deployment models for Lemonade [LEMONADEPROFILE] may require a non-pass-through proxy to fit OMA requirements. The proxy sits between the client and the backend Lemonade server and executes commands on behalf of the client, and rewriting some of the responses. XENCRYPT introduces a new encrypted literal type that allows the backend Lemonade server to end-to-end encrypt sensitive data returned from the mail store, such as message bodies and headers. "IRTF Research Group RFCs", Aaron Falk, 2-Mar-06, This document describes a process for research groups in the Internet Research Task Force to publish RFCs. "ISDN subaddress encoding type for tel URI", Mayumi Munakata, 2-Mar-06, Without a tel URI parameter to carry encoding type of Integrated Services Digital Network(ISDN) subaddress, interworking between ISDN User Part(ISUP) network and Session Initiation Protocol(SIP) network is impossible in some cases. To solve the problem, this document specifies a new tel URI parameter to carry encoding type of ISDN subaddress. "Calling Party Category using SAML", Shida Schubert, 2-Mar-06, Ability to convey a trait information of caller, such as calling party category which includes things like Law Enforcement, Technical Support, Anonymous Caller from Payphone etc. and type of location where the call initiated which includes things like Police Station, Hotel/Motel, Fire Station, Jail etc. might be useful for receiving entity of the call to make an authorization decision on its treatment of incoming call. This draft proposes an approach for conveying trait information for caller's category and call initiating point in SIP using the Security Assertion Markup Language(SAML). It relies on a third party to act as an asserting party to provide information described above. This draft is in a fairly early state and has many details that are missing. This version tries to describe and illustrate what the SAML based solution would look like to aid in evaluating SAML as solution to carry calling party's category and call initiating location information. "IP Tunneling Header Compression", Ana Minaburo, 2-Mar-06, The IP tunneling mechanisms are widely used in mobility (NEMO and Mobile IP), security (VPN) and IP transition. They use an IP encapsualation (at least 2 IP headers), which is very expensive for wireliss links. Header compression mechanisms can be used to reduce this overhead, independent of the payload type. This document defines the use of normal header compression mechanisms for the tunneled (inner) header together with a new header compression mechanism for the tunneling (outer) transport header to reduce the header size. "Atom Syndication Format Revision Tracking", James Snell, 2-Mar-06, This specification defines metadata extensions for use with the Atom Syndication Format to track revisions of entries. "QoS Aware Real-Time Support for IPv6 in IEEE 802.16 Backhaul Scenarios", Pedro Neves, 2-Mar-06, This document addresses the support of IPv6 QoS aware real-time services over IEEE 802.16-2004 [2] networks. In particular, it provides a novel solution to overcome the limitations of the IEEE 802.16-2004 [2] system to support real-time and dynamic environments. Specifically, this solution supports dynamic and fast access from the Mobile Nodes to the network services and dynamic reservations and modifications of services. These fast and dynamic reservations are crucial to the support of fast mobility approaches. Moreover, the proposed solution is also able to provide IPv6 support and efficient traffic differentiation for services running on the same MN. "Transport Layer Security (TLS) Partial Encryption Mode", Eric Rescorla, 2-Mar-06, This document describes an extension to TLS to allow partial encryption of record bodies. This allows the beginning of the record body to be in the clear, thus facilitating debugging and header compression. "Multicast in MPLS/BGP IPv6 VPNs", Wei Cao, 2-Mar-06, This document describes a method by which a Service Provider may deploy IPv6 multicast service in BGP/MPLS IPv6 VPNs. Multicast in IPv4 BGP/MPLS VPN has been in operation for several years and related drafts are on RFC standard track . IPv6 infrastructure is under construction and new application based on IPv6 is being developing now. Multicast will act an important role in the future IPv6 environment. This document reuses and extends the method defined in draft-ietf-l3vpn-2547bis-mcast-01 to support multicast traffic in IPv6 VPNs. Specially, both IPv6 core and IPv4 core are considered in this document. The inter-working between an IPv4 site and an IPv6 sited is outside the scope of this document. "Find the HA that MNs Registered in MIPv6", Jian Zhang, 2-Mar-06, In mobile IPv6 networks, a mobile node must register its new care of address with its home agent after changing its attachment point, so that it can maintain connectivity with peers. In the deployment of MIPv6, there may be multiple home agents for load balancing and/or reliability. In the case of load balancing, some mobile nodes may register their care of addresses with one home agent, and other mobile nodes may register their care of addresses with other home agents. Some applications may need to query the MIPv6 service status of a mobile node from home agents, such as the care of address, the life time of binding, or other information associated with mobile node that is stored on home agents. In order to satisfy this requirement, the first step is to locate which home agent the mobile node belongs to, that is to say to confirm which home agent to query. This document describes a protocol which can be used to locate the home agent that a mobile node belongs to. "ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks", Myung-Ki Shin, Youn-Hee Han, 2-Mar-06, This document provides detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. "A simple heuristic for handover decisions in WLANs", Shigeru Kashihara, 2-Mar-06, This document discusses handover decision criteria for avoiding deterioration in communication quality during WLAN handover, in particular at handover initiation. We first describe problems for handover decision criteria employed by existing mobility management technologies, such as Mobile IP and mSCTP. We then propose the number of frame retransmissions as a simple heuristic for handover decisions and discuss its advantages and disadvantages. "Route Policy and Architecture in SIP Peering Environments", Medhavi Bhatia, 2-Mar-06, The purpose of this document is to help the IETF community understand the route architectures being used today in SIP based peering environments and to outline a set of requirements based on the same for discussion within the community. "PANA bootstrapping IEEE 802.11 security", Rafael Marin Lopez, 2-Mar-06, PANA (Protocol for carrying Authentication for Network Access) is a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA framework defines two types of security associations which can be bootstrapped as a consequence of PANA execution: IP layer security is established with IPsec by using IKE and link-layer security with WPA/IEEE 802.11i in PSK mode. This document is focused on how PANA can bootstrap link layer security through IEEE 802.11i and exposes issues which can be raised as a consequence of this interaction. "Session Initiation Protocol (SIP) for Media Over Datagram Transport Layer Security (DTLS)", Jason Fischl, 2-Mar-06, This document specifies how to use the Session Initiation Protocol (SIP) to establish secure Real-Time Transport Protocol (RTP) media sessions over the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the certificate that will be presented during the DTLS handshake. It relies on the SIP identity mechanism to ensure the integrity of the fingerprint attribute. This allows the establishment of media security along the media path. "Real-Time Transport Protocol (RTP) over Datagram Transport Layer Security (DTLS)", Hannes Tschofenig, Eric Rescorla, 2-Mar-06, This specification defines how to establish secure Real-Time Transport Protocol (RTP) sessions over the Datagram Transport Layer Security (DTLS) protocol. "Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS)", Jason Fischl, Hannes Tschofenig, 2-Mar-06, This specification defines how to use Session Description Protocol (SDP) to signal that media will be transported over Datagram Transport Layer Security (DTLS) and it defines new SDP protocol identifiers. It reuses the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate which will be presented for the DTLS handshake. This allows the security provided by the existing TCP/TLS specifications for stream transported media to also be applicable to media that is transported over a datagram oriented transport. "DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 2-Mar-06, The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver API does not allow a security-aware resolver to communicate detailed results of DNSSEC processing back to the application. This document describes an Application Programming Interface between applications and a validating security-aware stub resolver that allows applications to control the validation process and obtain results of DNSSEC processing. "Extended RADIUS Attributes", Barney Wolff, Greg Weber, 2-Mar-06, The RADIUS protocol is being extended beyond the wildest imaginations of its original designers. These extensions are pushing up against the existing limitations on the numbers, length, base types and grouping of RADIUS attributes. This document specifies a method of relaxing those limitations. "Mobile IPv6 Bootstrapping for the Authentication Option Protocol", Vijay Devarapalli, 2-Mar-06, The current Mobile IPv6 bootstrapping mechanisms require the use of IKEv2 between the mobile node and the home agent. If the Mobile IPv6 signaling messages are protected by the mobility option authentication protocol, then the bootstrapping mechanism based on IKEv2 cannot be used. This document describes bootstrapping mechanisms for Mobile IPv6 when the mobility option authentication protocol is used. "Access Authentication Protocol in FMIP6", Souhwan Jung, Jaeduck Choi, 2-Mar-06, This memo describes a secure authentication protocol between the MN and NAR(New Access Router) in FMIP6. The main idea is that the MN generates an authentication key for handoff, and delivers it to the NAR through an existing secure channel via the AAA server during a pre-authentication process. The NAR verifies the MN using the delivered key when the MN attaches to itself. The main advantage of this scheme over the full authentication procedure is to distribute the heavy overhead of the AAA server such as key generation and management to the MNs. The AAA server in this scheme just forwards the key information to the NAR using an existing secure channel. "An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP)", Eunsoo Shim, 2-Mar-06, This document describes an architecture for peer-to-peer SIP systems in which a separate and independent peer-to-peer overlay layer provides a distributed resource placement and search service for SIP. It also aims to help identify what should be specified for interoperation. "Mobile IP Key Derivation using EAP", Avi Lior, Kuntal Chowdhury, 2-Mar-06, This document provides information on the derivation of Mobility Registration Keys from EAP. "Using Mobile IPv6 for Home LAN Access", Shinta Sugimoto, 2-Mar-06, In this document, we propose to relax forwarding rule of the Mobile IPv6 home agent. In addition to utilizing link-local scope home address, mobile node may request home agent to bypass specific link- local scope multicast traffic which may be of its interest. The extensions allow mobile node to seamlessly access the home network through link-local communication. Modifications to mobility signals for home registration are made in order to realize the extensions. This document also provides a set of requirements and guidelines for target usage scenario and implications to Mobile IPv6 system design. "Limiting the Damage from Amplification Attacks in SIP Proxies", Robert Sparks, 2-Mar-06, This document recommends a mechanism for limiting the number of concurrent branches pursued for any given request. This is intended to reduce the damage caused by amplification attacks. The purpose of this document is to stimulate discussion of the identified problem and proposed solution. Some of the proposed solution language appears normative, but implementors should not treat the current document as such. Comments are solicited, and should be directed to the SIPPING working group list at 'sipping@ietf.org'. "Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEND Protocol", Wassim Haddad, 8-Mar-06, This memo describes a new set of mechanisms, which aims to increase the Secure Neighbor Discovery (SEND) protocol usability by reducing the required processing power on small devices and adapting it to mobile environment requirements while maintaining its efficiency. "An Efficient Loop Detection Algorithm for SIP Proxies", Byron Campen, 2-Mar-06, This document defines a loop-detection algorithm with a cumulative O(n) complexity (O(1) average complexity for each proxy) and average O(log n) state-space, where n is the number of proxies that the message passes through. Also, the backwards-compatibility and security of this algorithm are discussed. Comments are solicited, and should be directed to the SIPPING working group list at 'sipping@ietf.org'. "A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring", James Polk, Brian Rosen, 2-Mar-06, This document defines a new Dynamic Host Configuration Protocol Option for a client to be able to request its locally significant emergency dialstring from the local infrastructure. "Extensions for Datagram Transport Layer Security (TLS) in Low Bandwidth Environments", Nagendra Modadugu, Eric Rescorla, 2-Mar-06, This document describes a series of extensions to Datagram Transport Layer Security (DTLS) which reduce the per-record bandwidth of the data channel. These extensions apply only to the on-the-wire representation of the protocol and do not affect cryptographic processing. "Firewall friendly RTT for MIPv6", Gabor Bajko, Franck Le, 2-Mar-06, This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [2]. The new method is firewall friendly and allows a mobile node to send Binding Update message to its correspondent node (so that Route Optimization can be applied) and ensures that the CN receives the Binding Update, even when either the mobile node, the CN, or both are located behind firewalls. "Multihop Radio Access Network (MRAN) Protocol Specification", Philipp Hofmann, 2-Mar-06, This document presents an IPv6-based protocol for the interconnection of ad hoc networks and the Internet. The protocol enables mobile nodes in ad hoc networks to communicate with correspondent nodes in the Internet. "Pseudo Wires over Provider Backbone Transport", David Allan, 2-Mar-06, This memo describes architecture and procedures for the operation of pseudo wires over provider backbone transport (PBT). "Simultaneous authentication of user and device in Wireless IP Networks", Dongjin Kwak, Young Man Park, 3-Mar-06, This document specifies a new two factor authentication and key establishment (TAKE) protocol that can be applied to low-power mobile devices in wireless IP Networks, using two factor authentication and precomputation. The two factor authentication makes use of user's password and the symmetric key which is stored in the token possessed by a user. "IP Service (Voice and Multimedia) Peering Architecture", Sohel Khan, 3-Mar-06, This document pictorially depicts IP Service (Voice + Multimedia) provider network functional components, peering interface functions, and an IP Service (VM) providers’ peering reference architecture. The draft also calls for developing separate requirements for different types of peering. "Internet Key Exchange Protocol: IKEv2", Paul Hoffman, 3-Mar-06, This document describes version 2 of the Internet Key Exchange (IKE) protocol. It is a restatement of RFC 4306, and includes all of the clarifications from the "IKEv2 Clarifications" document. "Early Binding Updates for Mobile IPv6", Christian Vogt, 3-Mar-06, Mobile IPv6 defines a return-routability procedure for secure use of route optimization between unacquainted nodes. Unfortunately, this procedure is known to have undesired impacts on handoff latency. This document specifies extensions to Mobile IPv6 that eliminate the latency of the return-routability procedure. The extensions thus provide a basis for more efficient reactive as well as proactive handoff management. They are optional and fully backward-compatible. "The IMAP VIEW extension", Arnt Gulbrandsen, Abhijit Menon-Sen, 3-Mar-06, The VIEW extension allows an [IMAP] client to create and manipulate mailbox views (persistent searches). All [IMAP] clients can access a view, as if it were an ordinary mailbox. Clients which implement the VIEW extension can create views. Clients which implement both VIEW and [LISTEXT] can find and modify existing views. "Requirements and methods for SPIT identification using feedbacks in SIP", Saverio Niccolini, 3-Mar-06, This memo describes requirements and gives an overview of possible solutions to send feedbacks using the SIP protocol for the scope of SPIT (SPam over Internet Telephony) identification. Feedback information from the users to the SPIT identification system (e.g., working closely with the callee's SIP proxy server) are important for SPIT detection and prevention and the overall system could benefit from such information and increase its effectiveness. The basic idea is that each user who receives a SPIT call reports it to the SPIT identification system (for example, using a button on the user interface of the client). This memo identifies the parameters that the SPIT identification system may need in order to detect abusive behaviors; moreover it proposes an overview of technical solutions how such information can be sent back to the SPIT identification system by means of the SIP protocol. "Problem Statement for Network Global Mobility Management", Eric Njedjou, Julien Riera, 3-Mar-06, This document discusses the problem of network global mobility management in a context where integrated IP access networks providers are looking for efficient solutions to the inter-system IP mobility problem. The document extends the current scope of netlmm to address the problem of moving between "topologically distant" IP access domains "Diameter Quality of Service Application", Frank Alfano, 3-Mar-06, 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. "QoS Negotiation MO Headers for NEMO Home Network Model", Sunyoung Han, 3-Mar-06, Current NEMO enabled home network technology [1] does not support any kind of inbuilt Quality of Service function. In case of various home network situations, some of prioritized requests are supposed to be occurred under NEMO environment. This memo suggests additional processes for basis of priority enabled home network under NEMO environment. "Examples call flow in race condition on Session Initiation Protocol", Miki Hasebe, 3-Mar-06, This document gives examples of Session Initiation Protocol (SIP) call flows in race condition. Call flows in race conditions are confusing and this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxies. Call flow diagrams and message details are shown. "Requirements for supporting Location-based Authorization Services within the PANA framework", Farooq Anjum, 3-Mar-06, The PANA protocol provides a means to authenticate clients in an IP network using cryptographic credentials. This document identifies scenarios where there may be a need for a client to provide location credentials, in addition to cryptographic credentials, to gain network access. This document also enumerates the requirements for PANA support of location based services. "An Evaluation of Session Initiation Protocol (SIP) for use in Streaming Media Applications", Steven Whitehead, 3-Mar-06, This draft reviews requirements and evaluates solutions to improve the integration of the Session Initiation Protocol (SIP) [RFC3261] to the Real Time Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP] especially in the context of converged media services. The document develops a rationale and solution space for using SIP with streaming media applications. This is done by first considering use cases that are used to define generic requirements to help compare the current and potentially new solutions. The range of solutions is sketched out (at high-level) and advantages and disadvantages discussed. The solutions evaluated address different levels of integration from SIP-only approaches to dual-protocol solutions. "Tools for Peer-to-Peer Network Simulation", Alan Brown, Mario Kolberg, 3-Mar-06, Due to the extremely large scale of P2P overlay networks, complexity has become a major issue. With the number of connected nodes reaching into the millions, a platform which can accurately simulate an overlay network is important. Many freely available network simulators exist, ranging from modelling networks at the packet level to concentrating purely on the overlay network. The following document provides an overview of these simulators, documenting the maximum number of simulated nodes achieved in experiments, the P2P overlay architectures modelled and the chosen implementation language. "A two stage standards process", Randall Atkinson, 3-Mar-06, This document proposes several changes to the Internet standards process, especially a reduction from three to two stages in the IETF standards track. "End-to-End Route Management in the Session Initiation Protocol", Daniel Schwartz, Jeremy Barkan, 3-Mar-06, While much attention has been given in Session Initiation Protocol (SIP) to the process of securing caller identity end-to-end, SIP routing headers (e.g. via, route etc) have not garnered the same attention and have gone largly unchanged since RFC 3261. Since SIP promotes the routing directives to the application layer it is imperative that these decisions not be tampered with by a malicious party. Specifically, Route and Via headers are passed "in the clear" without any security mechanism to insure the integrity of the information. This draft summarizes the problems with the existing "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", Nabil Bitar, 3-Mar-06, This document discusses requirements for the support of the Path Computation Element Communication Protocol (PCECP) in inter-AS applications. Its main objective is to present a set of requirements which would result in guidelines for the definition, selection and specification development for any technical solution(s) meeting these requirements. "An Evaluation of Session Initiation Protocol (SIP) for use in Streaming Media Applications", Steven Whitehead, 5-Mar-06, This draft reviews requirements and evaluates solutions to improve the integration of the Session Initiation Protocol (SIP) [RFC3261] to the Real Time Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP] especially in the context of converged media services. The document develops a rationale and solution space for using SIP with streaming media applications. This is done by first considering use cases that are used to define generic requirements to help compare the current and potentially new solutions. The range of solutions is sketched out (at high-level) and advantages and disadvantages discussed. The solutions evaluated address different levels of integration from SIP-only approaches to dual-protocol solutions. "A URN Namespace for the Name Identification Service", Kyung Soo Ham, 7-Mar-06, This document describes URN namespace for Name Identification Service enabling users to conveniently access such digital resources as e-book, music, moving picture, image, home page, blog page on the world wide web using such simple names as title of contents, author, organization name, blog name, etc. and receive relevant information services. "A Protocol for Network-based Localized Mobility Management", Vijay Raman, 7-Mar-06, This document suggests a local mobility solution controlled by the network within a local mobility domain. The proposed solution employs a Proxy Mobile IPv6 client that generates a Proxy Binding Update message. Two variants of the solution are suggested depending on the realization of the Proxy Mobile IP client function. The security association between the network elements for executing the local mobility is also discussed. "Bidirectional RSVP-TE Tunnel", Xiaohu Xu, Le Zhang, 7-Mar-06, Through the binding of two unidirectional RSVP-TE tunnels established between a pair of LSRs destined to each other, a bidirectional RSVP- TE tunnel is formed. The bidirectional RSVP-TE tunnel can be used to establish L3VPN with virtual router technology. "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", Julien Laganier, Sathya Narayanan, 8-Mar-06, This document specify an IP layer interface between mobile nodes (MN) and access routers (AR) of a network-based localized mobility management (NetLMM) domain. Such an interface is subject to a certain number of threats, amongst which are attacks on the mapping between the MN Identifier and IPv6 address set. A binding enforcement mechanism between those two is hence required to prevent malicious nodes to carry on various attacks like service theft or denial-of-service attacks. In the absence of link-layer specific mechanisms enforcing this binding, it is required to implement such mechanism at the IP layer MN-AR interface. Moreover, it is required that no NetLMM specific software support is present on MNs. The IP layer MN-AR interface described in this document fulfills these two requirements by using the SEND public key as the MN identifier, while being solely based on standard track IPv6 protocols (DNA and SEND) implemented by non-NetLMM MNs. "A Proposal for a Requirement for IP Local Mobility", Vijay Raman, 9-Mar-06, In draft-kempf-netlmm-nohost-req-01.txt, a set of requirements for a protocol for localized mobility management has been described. In this draft, we propose to include an additional requirement that components of existing IETF protocols should be reused wherever possible to avoid extensive standardization activity and to enable reuse of existing IETF-compliant protocol implementations. "ForCES Transport Mapping Layer (TML) Service Primitives", Weiming Wang, Jamal Hadi Salim, 10-Mar-06, This document proposes Service Primitives of Transport Mapping Layer (TML) in a Forwarding and Control Element Separation(ForCES) network element, to standardize the operations of ForCES Protocol Layer (PL) to various types of TMLs. Next Steps in Signaling (nsis) ------------------------------ "NSLP for Quality-of-Service Signaling", Jukka Manner, 9-Mar-06, This draft describes an NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This draft explains the overall protocol approach, design decisions made and provides examples. It specifies object and message formats and processing rules. "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Martin Stiemerling, 1-Feb-06, This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators and firewalls. This NSLP allows hosts to signal along a data path for Network Address Translators and firewalls to be configured according to the data flow needs. The network scenarios, problems and solutions for path-coupled Network Address Translator and firewall signaling are described. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. "GIST: General Internet Signaling Transport", Henning Schulzrinne, Robert Hancock, 10-Feb-06, This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signaling Transport (GIST), which provides a universal service for diverse signaling applications. GIST does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signaling" framework. "QoS-NSLP QSPEC Template", Jerry Ash, 6-Mar-06, The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. "Applicability Statement of NSIS Protocols in Mobile Environments", Sung-Hyuck Lee, 9-Mar-06, The mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocols, and how the protocols operate in different scenarios, and together with mobility management protocols. "RMD-QOSM - The Resource Management in Diffserv QOS Model", Attila Bader, 15-Feb-06, This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. "GIST State Machine", Hannes Tschofenig, 27-Oct-05, This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", Jerry Ash, 5-Mar-06, 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. Network Time Protocol (ntp) --------------------------- "The Network Time Protocol Version 4 Protocol Specification", Jack Burbank, 26-Oct-05, The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This memorandum describes Version 4 of the NTP (NTPv4), introducing several changes from Version 3 of NTP (NTPv3) described in RFC 1305, including the introduction of a modified protocol header to accomodate Internet Protocol Version 6. NTPv4 also includes optional extensions to the NTPv3 protocol,including a dynamic server discovery mechanism and an authentication scheme designed specifically for multicast and dynamically discovered servers. "Requirements for Network Time Protocol Version 4", Dave Plonka, 26-Oct-05, This document defines requirements for the Network Time Protocol (NTP) Version 4. NTP provides the mechanisms to synchronize time and coordinate time distribution amongst internet hosts. "The Network Time Protocol Version 4 Algorithm Specification", William Kasch, 15-Nov-05, The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This memorandum describes the algorithms used by Version 4 of the NTP (NTPv4) to calculate time values. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Jon Callas, 7-Nov-05, This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Open Pluggable Edge Services (opes) ----------------------------------- "OPES SMTP Use Cases", Abbie Barbir, Martin Stecher, 10-Jan-06, The Open Pluggable Edge Services (OPES) framework is application agnostic. Application specific adaptations extend that framework. This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. "SMTP adaptation with OPES", Martin Stecher, Clemens Perz, 17-Oct-05, Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Simple Mail Transfer Protocol (SMTP) adaptation. Together, application-agnostic OPES documents and this SMTP profile constitute a complete specification for SMTP adaptation with OPES. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Framework for Operational Security Capabilities for IP Network Infrastructure", George Jones, 3-Mar-06, This document outlines work to be done and documents to be produced by the Operational Security Capabilities (OPSEC) Working Group. The goal of the working group is to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. The intent is to provide clear, concise documentation of capabilities necessary for operating networks securely, to assist network operators in communicating their requirements to vendors, and to provide vendors with input that is useful for building more secure devices. The working group will produce a list of capabilities appropriate for large Internet Service Provider (ISP) and Enterprise Networks. This work is intended to refine [RFC3871]. "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 18-Jan-06, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Operational Security Current Practices", Merike Kaeo, 26-Oct-05, This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. "Filtering Capabilities for IP Network Infrastructure", Christopher Morrow, 18-Oct-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. "Miscellaneous Capabilities for IP Network Infrastructure", Ross Callon, George Jones, 22-Feb-06, The Framework for Operational Security Capabilities [11] outlines the proposed effort of the IETF OPSEC working group. This includes producing a series of drafts to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. Current plans include separate capabilities documents for Packet Filtering; Event Logging; In-Band and Out-of-Band Management; Configuration and Management Interfaces; AAA; and Documentation and Assurance. This document describes some additional miscellaneous capabilities which do not fit into any of these specific catagories, and whose descriptions are brief enough that it does not seem appropriate to create a separate document for each. Operational Security Current Practices [12] lists current operator practices related to securing networks. This document lists miscellaneous 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 may be cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, tradeoffs, etc. "Network Management Access Security Capabilities", Ronald Bonica, Syed Ahmed, 1-Mar-06, This document describes how network management stations can communicate with the devices that they manage using either the in- band network, an out-of-band network, or a virtual out-of-band network. This document also evaluates each access method in terms of its security capabilities and lists the device capabilities needed to support each method. Open Shortest Path First IGP (ospf) ----------------------------------- "Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, 28-Dec-05, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol for IPv6. Please send comments to ospf@peach.ease.lsoft.com. "OSPF Version 2 Management Information Base", Spencer Giacalone, 30-Jan-06, 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 version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo is intended to update and obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in section 12. Please send comments to ospf@peach.ease.lsoft.com. "Authentication/Confidentiality for OSPFv3", Mukesh Gupta, Nagavenkata Melam, 1-Mar-06, This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP Extension Header. "Traffic Engineering Extensions to OSPF version 3", Kunihiro Ishiguro, 21-Oct-05, This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", Eric Rosen, 10-Mar-04, This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides 'BGP/MPLS IP VPN' service to a customer, and the customer uses OSPF to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPF from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of converting the routes from OSPF to BGP and back to OSPF, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE, and should be ignored by any other PEs that see it. "Extensions to OSPF for Advertising Optional Router Capabilities", Acee Lindem, 2-Dec-05, It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) LSA is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or AS). "Support of address families in OSPFv3", Sina Mirtorabi, 8-Mar-06, This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. "OSPF Multi-Area Adjacency", Sina Mirtorabi, 16-Sep-05, This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. "Multi-Topology (MT) Routing in OSPF", Peter Psenak, 1-Feb-06, This draft describes an extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. "OSPFv3 Graceful Restart", Padma Pillay-Esnault, Acee Lindem, 3-Mar-06, This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State Advertisements (LSA) and other considerations. "OSPF for IPv6", Dennis Ferguson, 2-Mar-06, This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 packet, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. "IANA Considerations for OSPF", Kireeti Kompella, 24-Jun-05, This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Sina Mirtorabi, Abhay Roy, 9-Mar-06, 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. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Protocol for Carrying Authentication for Network Access (PANA)", Dan Forsberg, 3-Mar-06, This document defines the Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA protocol specification covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. "PANA Enabling IPsec based Access Control", Mohan Parthasarathy, 14-Jul-05, PANA (Protocol for carrying Authentication for Network Access) is a protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. "SNMP usage for PAA-EP interface", Yacine Mghazli, 5-Jan-06, The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group recommends the use of Simple Network Management Protocol Version 3 (SNMPv3) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMPv3 as the PAA-EP protocol. "PANA Framework", Prakash Jayaraman, 3-Mar-06, PANA (Protocol for carrying Authentication for Network Access) design provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. This document defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: using PANA over DSL networks and wireless LANs. "PANA Mobility Optimizations", Dan Forsberg, 21-Oct-05, This specification describes PANA optimizations for handling mobility. Proposed optimizations aim reducing protocol latency and signaling associated with PANA-based network access AAA. "State Machines for Protocol for Carrying Authentication for Network Access (PANA)", Victor Fajardo, 21-Oct-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. "Pre-authentication Support for PANA", Yoshihiro Ohba, 6-Mar-06, 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. "Use of Context Transfer Protocol (CXTP) for PANA", Julien Bournelle, 8-Mar-06, 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. Note that only the intra-domain case is considered. This protocol can recover the previously established PANA security context from previous PANA Authentication Agent. Path Computation Element (pce) ------------------------------ "A Path Computation Element (PCE) Based Architecture", Adrian Farrel, 17-Jan-06, 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-layer networks is 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. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. "PCE Communication Protocol Generic Requirements", Jean-Louis Le Roux, Jerry Ash, 2-Feb-06, The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. "Requirements for Path Computation Element (PCE) Discovery", Jean-Louis Le Roux, 10-Feb-06, 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 certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", JP Vasseur, 3-Mar-06, This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a 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. "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", Eiji Oki, 2-Mar-06, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. "IGP protocol extensions for Path Computation Element (PCE) Discovery", Jean-Louis Le Roux, 5-Mar-06, There are various circumstances in which it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information that can used for PCE selection. When the PCE is an LSR participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery consists of relying on IGP flooding. For that purpose this document defines OSPF and ISIS extensions for the advertisement of PCE Discovery information within an IGP area or the entire routing domain. "PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area (G)MPLS Traffic Engineering", Jean-Louis Le Roux, 22-Feb-06, For scalability purposes a network may comprise multiple IGP areas. An inter-area TE-LSP is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end LSR cannot compute alone an inter-area shortest constrained path. One key application of the Path Computation Element (PCE) based architecture is the computation of inter-area TE-LSP paths. This document lists a detailed set of PCE Communication Protocol (PCECP) specific requirements for support of inter-area TE-LSP path computation. It complements generic requirements for a PCE Communication Protocol. Protocol Independent Multicast (pim) ------------------------------------ "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Mark Handley, 25-Oct-05, This document discusses Bi-directional PIM, a variant of PIM Sparse-Mode that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP thus eliminating the requirement for data-driven protocol events. "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, 27-Oct-04, This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. "Bootstrap Router (BSR) Mechanism for PIM", Nidhi Bhaskar, 3-Mar-06, This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. "Protocol Independent Multicast MIB", James Lingard, 24-Jan-06, 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 Protocol Independent Multicast (PIM) protocols (PIM-SM and BIDIR- PIM). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. "Anycast-RP using PIM", Dino Farinacci, Yiqun Cai, 9-Feb-06, This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast- RP, such as MSDP, which has been used traditionally to solve this problem. "PIM Sparse-Mode IETF Proposed Standard Requirements Analysis", Tom Pusateri, 7-Mar-06, This document provides supporting documentation to advance the Protocol Independent Multicast (PIM) Sparse-Mode routing protocol from the IETF Experimental status to Proposed Standard. "The RPF Vector TLV", IJsbrand Wijnands, 6-Mar-06, This document describes a use of the PIM Join Attribute as defined in draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. "Format for using TLVs in PIM messages", A Boers, 10-Mar-06, This document describes a generic TLV attribute encoding format to be added to PIM join messages. Profiling Use of PKI in IPSEC (pki4ipsec) ----------------------------------------- "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Brian Korver, 5-Mar-06, IKE and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. "Requirements for an IPsec Certificate Management Profile", Chistopher Bonatti, 22-Feb-06, This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Standard Certificate Validation Protocol (SCVP)", Ambarish Malpani, 3-Mar-06, SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. "Certificate Management Messages over CMS", Michael Myers, Jim Schaad, 3-Mar-06, This document defines the base syntax for CMC, a Certificate Management protocol using CMS (Cryptographic Message Syntax). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Crytpography 2. The need in S/MIME (Secure MIME) for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. "Certificate Management over CMS (CMC) Transport Protocols", Jim Schaad, Michael Myers, 26-Oct-05, This document defines a number of transport mechanisms that are used to move CMC (Certificate Managment over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are: HTTP, file, mail and TCP. "CMC Complience Document", Michael Myers, Jim Schaad, 6-Mar-06, This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC "Attribute Certificate Policies extension", Christopher Francis, Denis Pinkas, 7-Feb-06, This document describes one certificate extension to explicitly state the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e. to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", Jeong Park, 21-Feb-06, This document defines the Subject Identification Method (SIM) for including a privacy sensitive identifier in the subjectAltName extension of a certificate. The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. "Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile.", Serguei Leontiev, 18-Jan-06, This document supplements RFC 3279. It describes encoding formats, identifiers and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). "Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX", Daniel R. L. Brown, 6-Jan-06, This document gives additional algorithms and associated ASN.1 identifiers for elliptic curve cryptography (ECC) used with the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (PKIX). The algorithms and identifiers here are consistent with both ANSI X9.62-1998 and X9.63-2001, and shall be consistent with the forthcoming revisions of these documents. Consistency shall also be maintained with SEC1 and SEC2, and any revisions or successors of such documents. "Lightweight OCSP Profile for High Volume Environments", Ryan Hurst, Alex Deacon, 18-Jan-06, This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or PKI environments that require a lightweight solution to minimize bandwidth and client side processing. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Dave Cooper, 13-Jan-06, This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. "Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name", Stefan Santesson, 20-Jan-06, 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 the service name and domain name components of a DNS Service Resource Record. "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Russ Housley, Stefan Santesson, 9-Mar-06, This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280. Path MTU Discovery (pmtud) -------------------------- "Path MTU Discovery", Matt Mathis, John Heffner, 6-Mar-06, This document describes a robust method for Path MTU Discovery that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP based Path MTU Discovery for IP versions 4 and 6, respectively. The general strategy of the new algorithm is to start with a small MTU and search upward, testing successively larger MTUs by probing with single packets. If the probe is successfully delivered and satisfies a subsequent verification phase then the MTU is raised. If the probe is lost, it is treated as an MTU limitation and not as a congestion signal. There are several options for integrating PLPMTUD with classical Path MTU Discovery. PLPMTUD can be minimally configured to perform ICMP black hole recovery to increase the robustness of classical Path MTU Discovery, or ICMP processing can be completely disabled, and PLPMTUD can completely replace classical Path MTU Discovery. In the latter configuration, PLPMTUD exactly parallels congestion control. An end-to-end transport protocol adjusts non-protocol properties of the data stream (window size or packet size) while using packet losses to deduce the appropriateness of the adjustments. This technique seems to be more philosophically consistent with the end-to-end principle than relying on ICMP messages containing transcribed headers of multiple protocol layers. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- "Class Extensions for PPP over ATM Adaptation Layer 2", B Thompson, bruce Buffam, Tmima Koren, 4-Feb-02, PPP over ATM Adaptation Layer 2 defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the AAL2 adaptation layer. This document defines a set of class extensions to PPP over AAL2 that implement equivalent functionality to Multi Class Multi Link PPP over a single ATM virtual circuit. Instead of using Multi Link PPP as the basis for fragmentation functionality, this document uses the functionality of the Segmentation and Reassembly Service Specific Convergence Sublayer that is already required as the basic encapsulation format of PPP over AAL2. "Accommodating an MTU/MRU greater than 1492 in PPPoE", Peter Arberg, 22-Nov-05, Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC 2516 [1], mandates a maximum negotiated MRU of 1492. This document outlines a solution to relax that restriction and allow a maximum negotiated MRU greater than 1492 to minimize fragmentation in next generation broadband networks. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Nick Duffield, 5-Jan-05, This document specifies a framework for the PSAMP (Packet Sampling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized reports, form a stream of reports on the selected packets, and to export that stream to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and export are described, along with configuration of the PSAMP functions. "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, 7-Jul-05, This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Measurement Processes and for reporting the technique in use to a Collector. "Definitions of Managed Objects for Packet Sampling", Thomas Dietz, Benoit Claise, 26-Oct-05, This memo defines managed objects for sampling and filtering techniques for IP packet selection. These objects provide information about managed nodes supporting packet sampling, including packet sampling capabilities, configuration and statistics. They also allow to configure packet sampling concerning the IP interface at which packets are sampled, the packet selections methods used for sampling, and the collector to which packet samples are exported. "Packet Sampling (PSAMP) Protocol Specifications", Benoit Claise, 28-Dec-05, This document specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Colleting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. "Information Model for Packet Sampling Exports", Thomas Dietz, 8-Mar-06, This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model. Pseudo Wire Emulation Edge to Edge (pwe3) ----------------------------------------- "Pseudo Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, 1-Feb-06, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. "Pseudo Wire (PW) over MPLS PSN Management Information Base", David Zelig, Thomas Nadeau, 1-Feb-06, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). "Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management", Thomas Nadeau, David Zelig, 1-Feb-06, This memo defines a Management Information Base (MIB) module Which contains Textual Conventions to represent commonly used Pseudo Wire (PW) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PW related MIB modules that would otherwise define their own representations. "SONET/SDH Circuit Emulation over Packet (CEP)", Andrew Malis, 9-Jan-06, This document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over packet-switched networks, and MPLS networks in particular. "Encapsulation Methods for Transport of Ethernet Over MPLS Networks", Luca Martini, 1-Dec-05, An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudo wire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. "Pseudowire Setup and Maintenance using the Label Distribution Protocol", Luca Martini, 13-Jun-05, Layer 2 services (such as Frame Relay, Asyncronus Transfer Mode, Ethernet) can be "emulated" over an MPLS backbone by encapsulating the layer 2 Packet Data Units (PDU) and then transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Dividion Multiplexed and a Synchronous Optical NETworking circuit emulation over a MPLS enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating layer 2 PDUs are specified in a set of companion documents. "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2", Thomas Nadeau, 28-Feb-06, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Native Service Processing of SONET/SDH circuits over a Packet Switch Network (PSN). "Ethernet Pseudo Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, 1-Feb-06, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet Pseudo Wire (PW) services. "PWE3 Fragmentation and Reassembly", Andrew Malis, Mark Townsley, 28-Nov-05, This document defines a generalized method of performing fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) protocols and services. "Encapsulation Methods for Transport of Frame Relay Over MPLS Networks", Luca Martini, Claude Kawa, 2-Mar-06, A frame relay pseudo wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. "Encapsulation Methods for Transport of ATM Over MPLS Networks", Luca Martini, 28-Sep-05, An ATM Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide a ATM service. "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", Luca Martini, 15-Nov-05, This document allocates the fixed Pseudo-wire identifier , and other fixed protocol values for protocols that have been defined in the pseudo wire edge to edge working group. ( PWE3 ) Detailed IANA allocation instructions are also included in this document. "Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks", Luca Martini, 13-Feb-06, A Pseudowire (PW) can be used to carry Point to Point Protocol (PPP), or High-Level Data Link Control (HDLC) Protocol Data Units over an Multi Protocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudo wire. "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", Thomas Nadeau, Rahul Aggarwal, 27-Sep-05, This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with pseudo wire (PW) connections. VCCV supports connection verification applications for PWs regardless of the underlying public service network technology. VCCV makes use of IP-based protocols to perform operations and maintenance functions. This is accomplished by providing a control channel associated with each PW. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. "Structure-Agnostic TDM over Packet (SAToP)", Sasha Vainshtein, Yakov Stein, 21-Feb-06, This document describes a pseudowire encapsulation for TDM (T1, E1, T3, E3) bit-streams that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. "PWE3 Frame Check Sequence Retention", Andrew Malis, 9-Sep-05, This document defines a mechanism for preserving frame FCS through Ethernet, Frame Relay, and HDLC pseudowires. "Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Sasha Vainshtein, 1-Dec-05, This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM)signals as pseudo-wires over packet- switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. "TDM over IP", Yakov Stein, 21-Sep-05, This document describes methods for structure-aware transport of TDM traffic over packet switched networks using pseudowires. "Managed Objects for TDM over Packet Switched Network (PSN)", Orly Nicklass, 9-Mar-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). "PWE3 ATM Transparent Cell Transport Service", Andrew Malis, 9-Sep-05, The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for PWE3 ATM cell encapsulation. "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, 2-Mar-06, This document specifies the mapping of defect states between a Pseudo Wire and the Attachment Circuits (AC) of the end-to-end emulated service. This document covers the case whereby the ACs and the PWs are of the same type in accordance to the PWE3 architecture [PWEARCH] such that a homogenous PW service can be constructed. "Requirements for inter domain Pseudo-Wires", Matthew Bocci, Luca Martini, 26-Oct-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 pseudo-wire domains. "Segmented Pseudo Wire", Luca Martini, 8-Mar-06, This document describes how to connect pseudo wires (PW) between two distinct PW 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. The PW packet data units are simply switched from one PW to another without changing the PW payload. "Control Protocol Extensions for Setup of TDM Pseudowires", Sasha Vainshtein, Yakov Stein, 8-Mar-06, This document defines extension to the PWE3 control protocol [PWE3- CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of TDM pseudo wires. "Dynamic Placement of Multi Segment Pseudo Wires", Florin Balus, 3-Jan-06, There is a requirement for service providers to be able to extend the reach of pseudo wires ( PW ) across multiple Public Switched Network 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. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge Routers. "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", Matthew Bocci, Stewart Bryant, 12-Jan-06, 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. "Target Choice of Pseudowire Type", Luca Martini, George Swallow, 6-Mar-06, The Generalized PWid FEC permits a procedure know as single-sided signaling. In this procedure, one end of the pseudowire always initiates the pseudowire setup and the target of that label mapping message only signals in response. For certain applications of pseudowires it is advantages to configure the pseudowire type (PW type) at the target of the initial label mapping message. This document specifies a means of doing this. "Pseudowire Attachment Identifiers for Aggregation and VPN Autodiscovery", Chris Metz, 28-Feb-06, The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AII). This document defines AII structures in the form of new AII type-length- value fields that support AII aggregation for improved scalability and VPN autodiscovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote PE nodes based on customer need. "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, 1-Mar-06, 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. RADIUS EXTensions (radext) -------------------------- "RADIUS Extension for Digest Authentication", Baruch Sterman, 8-Mar-06, This document defines an extension to the Remote Authentication Dial In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. "Dynamic Authorization Server MIB", Stefaan De Cnodder, 5-Jan-06, 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 Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. "Dynamic Authorization Client MIB", Stefaan De Cnodder, 5-Jan-06, 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 Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. "VLAN, Priority, and Filtering Attributes", Paul Congdon, 18-Jan-06, In certain scenarios it is desirable to limit user access using dynamic VLANs, reprioritization, filters, or redirection. This document proposes additional attributes for this purpose, for use with the Remote Authentication Dial In User Server (RADIUS). The attributes described in this document are expected to be useful in a variety of environments, including enterprise and service provider scenarios. "RADIUS Auth Client MIB (IPv6)", David Nelson, 23-Jan-06, This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. This memo obsoletes 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. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. "RADIUS Auth Server MIB (IPv6)", David Nelson, 23-Jan-06, This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. This memo obsoletes 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. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and Reference clauses to selected objects. "RADIUS Acct Server MIB (IPv6)", David Nelson, 26-Jan-06, This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. This memo obsoletes 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. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. "RADIUS Acct Client MIB (IPv6)", David Nelson, 26-Jan-06, This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. This memo obsoletes 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. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. "RADIUS VLAN and Priority Attributes", Paul Congdon, 22-Feb-06, This document proposes additional attributes for dynamic VLAN assignment and prioritization, for use by IEEE 802.1X authenticators. These attributes are usable within either RADIUS or Diameter. "Filter Attributes", Paul Congdon, 27-Feb-06, In certain scenarios it is desirable to limit user access using filters or redirection. This document proposes additional attributes for this purpose, for use with the Remote Authentication Dial In User Server (RADIUS). The attributes described in this document are expected to be useful in a variety of environments, including enterprise and service provider scenarios. "RADIUS Delegated-IPv6-Prefix Attribute", Joseph Salowey, Ralph Droms, 2-Mar-06, The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is to be delegated to the user. Remote Direct Data Placement (rddp) ----------------------------------- "An RDMA Protocol Specification", Renato Recio, 19-Jul-05, This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into ULP Buffers without intermediate data copies. It also enables a kernel bypass implementation. "Direct Data Placement over Reliable Transports", Hemal Shah, 15-Jul-05, The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", Caitlin Bestler, Lode Coene, 7-Dec-05, This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It comparese and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. "Stream Control Transmission Protocol (SCTP) Remote Direct Memory Access (RDMA) Direct Data Placement (DDP) Adaptation", Randall Stewart, 15-Aug-05, This document describes a method to adapt Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) to Stream Control Transmission Protocol (SCTP) RFC2960 [2] using a generic description found in [RDMA-Draft] [4] and [DDP-Draft] [3]. "Marker PDU Aligned Framing for TCP Specification", Paul Culley, 3-Oct-05, MPA (Marker Protocol data unit Aligned framing) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. "DDP/RDMAP Security", Jim Pinkerton, 9-Mar-06, This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. Finally, the document concludes with a summary of security services for DDP and RDMAP, such as IPsec. Remote Network Monitoring (rmonmib) ----------------------------------- "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Anwar Siddiqui, 14-Feb-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB - RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. Distribution of this memo is unlimited. Distribution of this memo is unlimited. "Real-time Application Quality of Service Monitoring (RAQMON) Framework", Anwar Siddiqui, 22-Feb-06, There is a need to monitor end devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other hand-held computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality of service (QoS) monitoring of various applications that run on these devices, and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time quality of service monitoring of applications. "Transport Mappings for Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU)", Anwar Siddiqui, 24-Jan-06, This memo specifies two transport mappings of the Real-time Application Quality of Service Monitoring (RAQMON) information model defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). "Remote Network Monitoring Management Information Base Version 2", Steven Waldbusser, 5-Oct-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 remote network monitoring devices. This document obsoletes RFC 2021 and the RMON2-MIB module contained in this memo obsoletes the RMON2-MIB module at RFC3273 level. Reliable Multicast Transport (rmt) ---------------------------------- "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", Joerg Widmer, Mark Handley, 3-Mar-06, This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications such as streaming media where a relatively smooth sending rate is of importance. "Raptor Forward Error Correction Scheme for Object Delivery", Michael Luby, 20-Oct-05, This document describes a Fully-Specified FEC scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols. The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. "Forward Error Correction (FEC) Building Block", Mark Watson, 30-Jan-06, This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for delivering content, in addition to the encoded data itself, and for definition of formats and codes for communcation of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols which wish to use FEC codes defined within this framework are also defined. The companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. "Layered Coding Transport (LCT) Building Block", Michael Luby, 5-Mar-06, Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. "Asynchronous Layered Coding (ALC) Protocol Instantiation", Michael Luby, 5-Mar-06, This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. "Basic Forward Error Correction (FEC) Schemes", Mark Watson, 3-Mar-06, This document provides FEC Scheme specifications according to the RMT FEC Building Block for the Compact No-Code FEC Scheme, the Small Block, Large Block and Expandable FEC Scheme, the Small Block Systematic FEC Scheme and the Compact FEC Scheme. "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, 3-Jan-06, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. "Low Density Parity Check (LDPC) Forward Error Correction", Vincent Roca, 2-Mar-06, This document describes two Fully-Specified FEC Schemes, LDPC- Staircase and LDPC-Triangle, and their application to the reliable delivery of objects on packet erasure channels. These systematic FEC codes belong to the well known class of ``Low Density Parity Check'' (LDPC) codes, and are large block FEC codes in these sense of RFC3453. "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", Brian Adamson, 10-Mar-06, This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. "Multicast Negative-Acknowledgment (NACK) Building Blocks", Brian Adamson, 10-Mar-06, This document discusses the creation of reliable multicast protocols utilizing negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. "Reed-Solomon Forward Error Correction (FEC)", Jerome Lacan, 2-Mar-06, This document describes a Fully-Specified FEC scheme for the Reed- Solomon forward error correction code and its application to reliable delivery of data objects on the packet erasure channel. The Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e, they enable a receiver to recover the k source symbols from any set of k received symbols. The implementation described here is compatible with the IPR-free implementation from Luigi Rizzo. Robust Header Compression (rohc) -------------------------------- "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", Ghyslain Pelletier, 4-Jan-06, Existing TCP/IP header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. In addition, existing schemes have not addressed how to compress TCP options such as SACK (Selective Acknowledgements) and Timestamps. This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. "The RFC 3095 Implementer's Guide", Lars-Erik Jonsson, 1-Feb-06, RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP, and ESP. This document clarifies ambiguities and common misinterpretations of RFC 3095, and it also corrects some actual errors in the specification. The corrections and clarifications provided herein must be followed to get interoperable implementations, i.e. this document updates RFC 3095. Further, minor interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles) are also addressed. "Implementer's Guide for SigComp", Abigail Surtees, 8-Mar-06, This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. "SigComp Users' Guide", Mark West, Abigail Surtees, 26-Oct-05, This document provides an informational guide for users of the SigComp protocol. The aim of the document is to assist users when making SigComp implementation decisions; for example the choice of compression algorithm and the level of robustness against lost or misordered packets. "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", Zhigang Liu, 17-Feb-06, This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. "SigComp Torture Tests", Abigail Surtees, Mark West, 26-Oct-05, This document provides a set of "torture tests" for implementers of the SigComp protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. "Integration of Header Compression over IPsec Security Associations", Emre Ertekin, 27-Feb-06, Internet Protocol security mechanisms, such as IP Security (IPsec) [IPSEC], provides various security services for IP traffic. However, the benefits offered by IPsec come at the cost of increased overhead. This document identifies a set of work items that need to be completed to achieve the integration of 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. "The RObust Header Compression (ROHC) Framework", Lars-Erik Jonsson, 14-Dec-05, The RObust Header Compression (ROHC) protocol provides an efficient, flexible and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. RFC 3095 defined the ROHC framework along with an initial set of compression profiles. To improve and simplify the specification, it has been agreed that the framework and the profiles parts of RFC 3095 be split into separate documents. This document explicitly defines the ROHC framework, and thus replaces the framework specification of RFC 3095. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "Generic Threats to Routing Protocols", Abbie Barbir, Sandra Murphy, Yibin Yang, 27-Oct-04, Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. This document provides a description and a summary of generic threats that affects routing protocols in general. The work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. "BGP Security Requirements", Blaine Christian, Tony Tauber, 5-Mar-06, The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. Reliable Server Pooling (rserpool) ---------------------------------- "Architecture for Reliable Server Pooling", Michael Tuexen, 8-Jul-05, This document describes an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. "Comparison of Protocols for Reliable Server Pooling", John Loughney, 13-Jul-05, This document compares protocols that may be applicable for the Reliable Server Pooling problem space. This document discusses the usage and applicability of these protocols for the Reliable Server Pooling architecture. "Aggregate Server Access Protocol (ASAP)", Randall Stewart, 8-Feb-06, Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) [7] provides a high availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) RFC2960 [4]. Each transport protocol to be used by Pool Elements (PE) and Pool Users (PU) MUST have an accompanying transports mapping document. Note that ASAP messages passed between PE's and ENRP servers MUST use SCTP. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for pool handle to address translation, load sharing management, and fault management while ENRP defines the high availability pool handle translation service. "Endpoint Handlespace Redundancy Protocol (ENRP)", Randall Stewart, 8-Feb-06, Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture. Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Randall Stewart, 8-Feb-06, This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) protocols defined within the Reliable Server Pooling (RSERPOOL) architecture. "Reliable Server Pooling: Management Information Base using SMIv2", Jaiwant Mulik, 2-Feb-06, RSerPool [20] is a framework to provide reliable server pooling. This document defines a SMIv2 compliant Management Information Base (MIB) providing access to managed objects in an RSerPool implementation. "Threats Introduced by Rserpool and Requirements for Security in response to Threats", Maureen Stillman, 8-Jul-05, Rserpool is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This Internet draft describes security threats to the Rserpool architecture and presents requirements for security to thwart these threats. "TCP Mapping for Reliable Server Pooling Enhanced Mode", Phill Conrad, Peter Lei, 7-Oct-05, This memo defines the shim protocol that maps the requirements of the ASAP protocol [5] to the capabilities of the TCP protocol [3]. In particular, this shim protocol adds the following capabilties that are required by ASAP, but not provided by TCP: (1) message orientation, (2) heartbeat messages, (3) multiple streams, and (4) undelivered message retrieval (if provided). "Services Provided By Reliable Server Pooling", Phill Conrad, Peter Lei, 7-Oct-05, The Reliable Server Pooling architecture (abbreviated "RSerPool", and defined in [3]), provides a set of services and protocols for building fault tolerant and highly available client/server applications. This memo describes the semantics of the services that RSerPool provides to upper layer protocols. "Reliable Server Pooling Policies", Michael Tuexen, Thomas Dreibholz, 2-Feb-06, This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at name servers and pool users. "Reliable Server Pooling Sockets API Extensions", Aron Silverton, 20-Oct-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). Routing Area Working Group (rtgwg) ---------------------------------- "IP Fast Reroute Framework", Mike Shand, Stewart Bryant, 3-Mar-06, This document provides a framework for the development of IP fast-reroute mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. "Basic Specification for IP Fast-Reroute: Loop-free Alternates", Alia Atlas, Alex Zinin, 6-Mar-06, This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node or shared risk link group (SRLG). The goal of this technology is to reduce the micro-looping and packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop- free and safe to use until the distributed network convergence process completes. "IP MIB for IP Fast-Reroute", Alia Atlas, 7-Mar-06, 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]. "Analysis and Minimization of Microloops in Link-state Routing Protocols", Alex Zinin, 24-Oct-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. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "The Anonymous SASL Mechanism", Kurt Zeilenga, 22-Feb-05, It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. "The Plain SASL Mechanism", Kurt Zeilenga, 21-Mar-05, This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. "Using Digest Authentication as a SASL Mechanism", Paul Leach, 2-Mar-06, This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. "Simple Authentication and Security Layer (SASL)", Alexey Melnikov, Kurt Zeilenga, 24-Jan-06, The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. Additionally, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222. "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 3-Mar-06, This document defines a simple challenge-response authentication mechanism, using a keyed MD5 digest, for use with the Simple Authentication and Security Layer (SASL). "The Kerberos V5 ("GSSAPI") SASL mechanism", Alexey Melnikov, 13-Feb-06, The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] KERBEROS V5 in the Simple Authentication and Security Layer [SASL]. This document replaces section 7.2 of RFC 2222 [SASL], the definition of the "GSSAPI" SASL mechanism. "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon Josefsson, 14-Feb-06, This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the the Simple Authentication and Security Layer (SASL) framework. See for more information. Secure Shell (secsh) -------------------- "SSH File Transfer Protocol", Joseph Galbraith, Oskari Saarenmaa, 26-Jan-06, The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol", Jeffrey Hutzelman, 23-Aug-05, The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method which uses a specified GSSAPI mechanism to authenticate a user, and a family of SSH key exchange methods which use GSSAPI to authenticate a Diffie-Hellman key exchange. This memo also defines a new host public key algorithm which can be used when no operations are needed using a host's public key, and a new user authentication method which allows an authorization name to be used in conjunction with any authentication which has already occurred as a side-effect of GSSAPI-based key exchange. "SSH Public Key File Format", Joseph Galbraith, Rodney Thayer, 3-Mar-06, This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol", Markus Friedl, 12-Aug-05, This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. "Uniform Resource Identifier (URI) Scheme for Secure File Transfer Protocol (SFTP) and Secure Shell (SSH)", Steve Suehring, Joseph Salowey, 2-Feb-06, This document describes the Uniform Resource Identifiers used to locate resources for the Secure File Transfer Protocol (SFTP) and the Secure Shell (SSH) protocols. The document describes the generic syntax involved in URI definitions as well as specific definitions for each protocol. These specific definitions may include user credentials such as username and also may include other parameters such as host key fingerprint. In addition, security considerations and examples are also provided within this document. "Secure Shell Public-Key Subsystem", Joseph Galbraith, 21-Sep-05, Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. "X.509 authentication in SSH", Oskari Saarenmaa, Joseph Galbraith, 6-Mar-06, This document specifies how X.509 certificates and signatures are used within the Secure Shell protocol for user and server authentication. "SSH File Transfer Protocol", Joseph Galbraith, Oskari Saarenmaa, 27-Jan-06, The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Jari Arkko, Iljitsch van Beijnum, 21-Dec-05, This document defines a mechanism for the detection of communication failures between two communicating hosts at IP layer, and an exploration protocol for switching to another pair of interfaces and/or addresses between the same hosts if a working pair can be found. The draft also discusses the roles of a multihoming protocol versus network attachment functions at IP and link layers. "Hash Based Addresses (HBA)", Marcelo Bagnulo, 25-Oct-05, This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. The main idea is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound. "Shim6 Reachability Detection", Iljitsch van Beijnum, 26-Oct-05, The shim6 working group is developing a mechanism that allows multihoming by using multiple addresses. When communication between the initially chosen addresses for a transport session is no longer possible, a "shim" layer makes it possible to switch to a different set of addresses without breaking current transport protocol assumptions. This draft discusses the issues of detecting failures in a currently used address pair between two hosts and picking a new address pair to be used when a failure occurs. The input for these processes are ordered lists of local and remote addresses that are reasonably likely to work. (I.e., not include addresses that are known to be unreachable for local reasons.) These lists must be available at both ends of the communication, although the ordering may differ. Building these address lists from locally available information and synchronizing them with the remote end are outside the scope of this document. This text is for the most part based on discussions on the multi6 list, several multi6 design team lists and the shim6 list, with notable contributions from Erik Nordmark, Marcelo Bagnulo and Jari Arkko. Suggestions and additions are more than welcome. "Level 3 multihoming shim protocol", Marcelo Bagnulo, Erik Nordmark, 7-Mar-06, The SHIM6 protocol is a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing properties, without assuming that a multihomed site will have a provider independent IPv6 address prefix which is announced in the global IPv6 routing table. The hosts in a site which has multiple provider allocated IPv6 address prefixes, will use the shim6 protocol specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original one stop working. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Extension: Variables", Kjetil Homme, 20-Dec-05, In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 3028) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. "SIEVE Email Filtering: Spamtest and Virustest Extensions", Cyrus Daboo, 20-Jan-06, The SIEVE email filtering language "spamtest", "spamtestplus" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. "Sieve Email Filtering: Body Extension", Philip Guenther, Jutta Degener, 8-Mar-06, This document defines a new primitive for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. "Sieve Email Filtering: Editheader Extension", Philip Guenther, Jutta Degener, 8-Mar-06, This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. "SIEVE Email Filtering: IMAP flag Extension", Alexey Melnikov, 2-Feb-06, Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords. "Sieve Email Filtering -- Subaddress Extension", Ken Murchison, 17-Feb-06, On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. "Sieve Extension: Relational Tests", Wolfgang Segmuller, Barry Leiba, 28-Dec-05, This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. "Sieve Email Filtering: Vacation Extension", Tim Showalter, Ned Freed, 2-Feb-06, This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. "Sieve: An Email Filtering Language", Tim Showalter, Philip Guenther, 8-Mar-06, This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs. "The SIEVE mail filtering language - reject and refuse extensions", Matthew Elvey, Alexey Melnikov, 5-Mar-06, This memo defines the SIEVE mail filtering language (RFC <<3028bis>>) "reject" extension. A Joe-job is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by the bounces, Message Disposition Notifications (MDNs) and messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This document updates definition of "reject" to allow for rejecting messages during the SMTP transaction. "Sieve Extension: Notifications", Alexey Melnikov, 6-Feb-06, Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but is expected that using existing instant messaging infrastructure such as Zephyr, Jabber, or SMS messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. "Sieve Notification Mechanism: mailto", Barry Leiba, Michael Haardt, 13-Dec-05, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. "Sieve Notification Mechanism: xmpp", Peter Saint-Andre, Alexey Melnikov, 18-Jan-06, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. "Sieve Email Filtering -- Regular Expression Extension", Kenneth Murchison, 27-Feb-06, In some cases, it is desirable to have a string matching mechanism which is more powerful than a simple exact match, a substring match or a glob-style wildcard match. The regular expression matching mechanism defined in this draft should allow users to isolate just about any string or address in a message header or envelope. "Sieve Extensions: MIME Tests, MIME Bodypart Iteration, Replacement and Enclosure", Tony Hansen, Cyrus Daboo, 2-Mar-06, The current Sieve language has no way to look at individual MIME parts, looping mechanism, or any way to manipulate those individual parts. This document defines extensions for each of these needs. This document is being discussed in the MTA-FILTERS mailing lists, ietf-mta-filters@imc.org. Signaling Transport (sigtran) ----------------------------- "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", Ken Morneault, Javier Pastor-Balbas, 10-Feb-06, This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332. "SUA Implementor's guide", Lode Coene, John Loughney, 8-Mar-06, This document contains a compilation of all defects found up until the publication date for SUA [RFC3868] [1]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SUA to clarify errors in the original SUA document. This document updates RFC3868 and text within this document supersedes the text found in RFC3868. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Adam Roach, Jonathan Rosenberg, Ben Campbell, 3-Jan-05, This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. "The Message Session Relay Protocol", Ben Campbell, 27-Feb-06, This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Jonathan Rosenberg, 26-Oct-05, This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. "Extensible Markup Language (XML) Formats for Representing Resource Lists", Jonathan Rosenberg, 9-Feb-05, In multimedia communications, presence and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services which are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists which are referenced from the first. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", Henning Schulzrinne, 21-Dec-05, The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status and the overall role of the presentity. These extensions include presence information for persons, services (tuples) and devices. "Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information", Mikko Lonnfors, 21-Oct-05, By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of presence data that has actually changed. "Presence Information Data format (PIDF) Extension for Partial Presence", Mikko Lonnfors, 8-Mar-06, The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. "Functional Description of Event Notification Filtering", Hisham Khartabil, 16-Mar-05, The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", Hisham Khartabil, 16-Mar-05, The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Mikko Lonnfors, Krisztian Kiss, 23-Jan-06, Interoperation of instant messaging and presence systems has been defined in the IMPP working group. The IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. This memo defines an extension to represent SIP User Agent capabilities in the Presence Information Document Format (PIDF) compliant presence documents. "CIPID: Contact Information in Presence Information Data Format", Henning Schulzrinne, 21-Dec-05, The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for Presence Information Data Format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", Henning Schulzrinne, 21-Dec-05, The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension ( element) that allows a presentity to declare its status for a time interval fully in the future or the past. "Presence Authorization Rules", Jonathan Rosenberg, 9-Mar-06, Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", Markus Isomaki, 22-Oct-04, This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is mainly intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs based on which it builds the overall presence state for the presentity. "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", Cullen Jennings, 22-Feb-06, Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are set up as part of a session using the SIP protocol. MSRP (Message Session Relay Protocol) is a protocol for near real-time, peer-to- peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. "A Data Model for Presence", Jonathan Rosenberg, 23-Jan-06, This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. "Publication of Partial Presence Information", Mikko Lonnfors, 8-Mar-06, The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bear a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, 9-Mar-06, This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", Jari Urpalainen, 8-Mar-06, 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 require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. Session Initiation Protocol (sip) --------------------------------- "Management Information Base for the Session Initiation Protocol (SIP)", Dave Walker, 9-Mar-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy, Redirect and Registrar servers. "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 16-Feb-05, The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", Eric Burger, 27-Oct-04, This document proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Jon Peterson, Cullen Jennings, 26-Oct-05, The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, 7-Mar-06, When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency in environments where the connection could be opened in either direction. "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 21-Oct-05, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. "Suppression of Session Initiation Protocol REFER Method Implicit Subscription", Orit Levin, 17-Jan-06, This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP option tag "norefersub" is defined to indicate support for this extension. A new SIP header field "Refer-Sub" is defined to request the usage of this extension. "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Dec-05, This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. "Session Initiation Protocol Location Conveyance", James Polk, Brian Rosen, 7-Mar-06, This document defines how the Session Initiation Protocol (SIP) conveys, or pushes, user location information from one SIP entity to another SIP entity. SIP Location Conveyance is always end to end, but sometimes the embedded location information can be acted upon by SIP Servers to direct where the message goes, based on where the user agent client is. "Conveying Feature Tags with Session Initiation Protocol REFER Method", Orit Levin, Alan Johnston, 17-Jan-06, This document extends the REFER method, defined in RFC 3515, to convey feature parameters defined in RFC 3840. "End-to-middle Security in the Session Initiation Protocol (SIP)", Kumiko Ono, Shinya Tachimoto, 25-Oct-05, Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than 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 a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity. "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Cullen Jennings, Rohan Mahy, 7-Mar-06, Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS (Transport Layer Security) server. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. "Requesting Answering Modes for the Session Initiation Protocol (SIP)", Dean Willis, Andrew Allen, 15-Dec-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 related to answering 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, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 17-Jan-06, The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. "Diagnostic Responses for SIP Hop Limit Errors", Scott Lawrence, 27-Feb-06, The SIP protocol imposes a limit on the number of hops a request may make from a sender to the recipient. When this limit is reached, a 483 error response is returned. The present form of the 483 response does not provide enough information for the sender or proxies on the path to diagnose failures whose symptom is that the hop limit is reached. This document proposes additional diagnostic information to be returned in a 483 response. "Addressing an Amplification Vulnerability in Forking Proxies", Robert Sparks, 1-Mar-06, This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Session Initiation Protocol Service Examples", Alan Johnston, 7-Mar-06, This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join headers. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, 7-Mar-06, This document defines a framework and requirements for multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals which embody the spirit of SIP applications as used on the Internet. "Best Current Practices for NAT Traversal for SIP", Chris Boulton, 3-Mar-06, Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NAT) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding call flows. "A Session Initiation Protocol (SIP) Event Package for Conference State", Jonathan Rosenberg, 5-Jul-05, This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) Events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference URI. Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. "Session Initiation Protocol Torture Test Messages", Robert Sparks, 15-Nov-05, This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, 7-Mar-06, This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. "Interworking between SIP and QSIG", John Elwell, 19-Jan-04, This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. "A Framework for Session Initiation Protocol User Agent Profile Delivery", Dan Petrie, 8-Mar-06, This document defines the application of a set of protocols for providing profile data to SIP user agents. The objective is to define a means for automatically providing profile data a user agent needs to be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent profile data is defined here. As part of this framework a new SIP event package is defined here for the notification of profile changes. This framework is also intended to ease ongoing administration and upgrading of large scale deployments of SIP user agents. The contents and format of the profile data to be defined is outside the scope of this document. "Session Initiation Protocol Call Control - Conferencing for User Agents", Orit Levin, 6-Jun-05, This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension", Jonathan Rosenberg, Paul Kyzivat, 6-Oct-05, This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in section 7.2 of RFC3841 [3]. "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Eric Burger, 29-Dec-04, This document describes a SIP Event Package "kpml" that enables monitoring of DTMF signals and uses XML documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML scripts that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML scripts to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Jul-05, This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. "Framework for Transcoding with the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 30-Nov-05, This document defines a framework for transcoding with SIP. This framework includes how to discover the need of transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. "Emergency Services URI for the Session Initiation Protocol", Henning Schulzrinne, 30-Jan-06, As part of an overall architecture for supporting emergency calling for the Session Initiation Protocol (SIP), this document defines universal emergency SIP URIs, sip:sos@domain and sips:sos@domain, that allows SIP user agents to contact the local emergency call center. It also defines conventions that increase the high probability of reaching the appropriate emergency call center. The document does not define any SIP protocol extensions. "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", Jon Peterson, 27-Jan-06, This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol. While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Gonzalo Camarillo, Adam Roach, 30-Jan-06, This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionaly, it defines a framework for SIP URI-List services which includes security considerations applicable to these services. "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Alan Johnston, 27-Feb-06, This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Gonzalo Camarillo, 27-Feb-06, This document specifies a mechanism that allows a SIP User Agent Client (UAC) to request a SIP URI-list (Uniform Resource Identifier list) service to send a SIP MESSAGE request to a set of destinations. The client sends a SIP MESSAGE request that includes the payload along with the URI-list to the MESSAGE URI-list service, which sends a similar MESSAGE request to each of the URIs included in the list. "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 24-Oct-05, This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE. Instead of having a subscriber send a SUBSCRIBE for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. "Refering to Multiple Resources in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 24-Oct-05, This document defines extensions to the SIP REFER method so that this method can be used to refer servers to multiple resources. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. "Certificate Management Service for The Session Initiation Protocol (SIP)", Cullen Jennings, Jon Peterson, 7-Mar-06, This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service. The Credential Service also allows users to store and retrieve their own certificates and private keys. "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 18-Jan-06, The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 1-Mar-06, The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent- based communications in SIP. "Framework for real-time text over IP using SIP", Arnoud Van Wijk, 8-Mar-06, This document provides a framework for the implementation of real- time text conversation over the IP network using the Session Initiation Protocol and the Real-Time Transport Protocol. It lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on existing protocols and techniques. This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. "The Session Initiation Protocol (SIP) and Spam", Jonathan Rosenberg, 9-Mar-06, Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user to user communications. The Session Initiation Protocol (SIP) defines a system for user to user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. Discussions on this draft should be directed at sipping@ietf.org. "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", Gonzalo Camarillo, 18-Jan-06, This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "IPv6 Transition in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 8-Feb-06, This document describes how IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., an IPv4-only and an IPv4/IPv6) user agents are considered in this document. "Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag", Gonzalo Camarillo, 6-Sep-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. "Reg Event Package Extension for GRUUs", Paul Kyzivat, 27-Feb-06, This draft defines an extension to RFC 3680 [2] for representing the GRUU associated with a Contact. "A User Agent Profile Data Set for Media Policy", Volker Hilt, 19-Oct-05, This specification defines a document format for media properties of Session Initiation Protocol (SIP) sessions, such as the codecs or media types to be used. This format can used to define media properties in SIP user agent profile data sets and SIP session policies. It extends the Schema for SIP User Agent Profile Data Sets. "Multiple Dialog Usages in the Session Initiation Protocol", Robert Sparks, 3-Mar-06, Several methods in the Session Initiation Protocol can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative document and makes no normative statements of any kind. "Session Initiation Protocol Package for Voice Quality Reporting Event", Amy Pendleton, 27-Feb-06, This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. "Extensible Markup Language (XML) Format Extension for Representing Capacity Attributes in Resource Lists", Miguel Garcia-Martin, Gonzalo Camarillo, 27-Feb-06, This document specifies an XML extension to the resource list format for qualifiying resources with the capacity in which they are included in the resource list. "Example call flows using Session Initiation Protocol (SIP) security mechanisms", Cullen Jennings, Kumiko Ono, 28-Feb-06, This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. S/MIME Mail Security (smime) ---------------------------- "CMS Symmetric Key Management and Distribution", Sean Turner, 14-Jan-03, This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS)", Serguei Leontiev, Grigorij Chudov, 19-Jan-06, This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption of arbitrary message contents. "CMS Advanced Electronic Signatures (CAdES)", John Ross, 2-Dec-05, This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). The format can be considered as an extension to RFC 3369 and RFC 2634, where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC amounts to a transposition of the ETSI TS 101 733 V.1.6.3 (CMS Advanced Electronic Signatures - CAdES) and is technically equivalent to it. Softwires (softwire) -------------------- "Softwire Problem Statement", Xing Li, 3-Mar-06, The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6-only networks and IPv6 networks across IPv4-only networks in a way that will encourage multiple, inter-operable vendor implementations. At the highest level, the Softwires Working Group is tasked to identify, and extend where necessary, standard protocols to support a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved as part of a solution phase following the completion of this document, within a relatively tight "time-to-market" as requested by operators at IETF 63. Some individual requirements (and non-requirements) are also identified in this document at times in order to better describe the specific scope for a given problem definition. Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Daniel Burnett, Saravanan Shanmugham, 9-Dec-05, The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. Session PEERing for Multimedia INTerconnect (speermint) ------------------------------------------------------- "SPEERMINT Requirements and Terminology", Dave Meyer, 21-Feb-06, This document outlines the solutions space requirements and defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Source-Specific Multicast (ssm) ------------------------------- "Source-Specific Multicast for IP", Hugh Holbrook, Bradley Cain, 5-Oct-05, IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "Signed syslog Messages", John Kelsey, 29-Nov-05, This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog". "Syslog Management Information Base", Glenn Keeni, 12-Dec-05, This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog devices. "The syslog Protocol", Rainer Gerhards, 3-Jan-06, This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. "Transmission of syslog messages over UDP", Anton Okmianski, 10-Nov-05, This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementors are required to support this transport protocol. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Improving the Robustness of TCP to Non-Congestion Events", Sumitha Bhandarkar, 15-Feb-06, This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. "Improving TCP's Robustness to Blind In-Window Attacks", Randall Stewart, Mitesh Dalal, 15-Feb-06, A recent study indicates that some types of TCP connections have an increased vulnerability to spoofed packet injection attacks than previously believed [SITW]. TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Note: Both [SITW] and [DTASA] provide charts which can give the reader an idea as to the time it takes to penetrate an unprotected system. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by carefly crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document proposes small modifications to the way TCP handles inbound segments that can reduce the probability of such an attack. "A Roadmap for TCP Specification Documents", Martin Duke, 28-Feb-06, This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. "Defending TCP Against Spoofing Attacks", Joseph Touch, 22-Feb-06, Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. The susceptibility to attack increases as the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. "TCP User Timeout Option", Lars Eggert, Fernando Gont, 27-Oct-05, The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. The advisory TCP User Timeout Option allows conforming TCP implementations to exchange their local user timeouts. This is an in-protocol mechanism to allow a host to modify its local user timeout for a connection based on knowledge of the peer's user timeout. Increasing the user timeouts allows established TCP connections to survive extended periods of disconnection. Decreasing user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only across short periods of disconnection. "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", Aleksandar Kuzmanovic, 24-Jan-06, This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. "TCP Congestion Control", Mark Allman, 26-Jan-06, This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. "TCP's Reaction to Soft Errors", Fernando Gont, 24-Feb-06, This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including that in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, it describes a modification to TCP's reaction to soft errors that has been implemented in a variety of TCP/IP stacks to help overcome this problem. "ICMP attacks against TCP", Fernando Gont, 27-Feb-06, This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks. Transport Layer Security (tls) ------------------------------ "ECC Cipher Suites for TLS", Vipul Gupta, 20-Oct-05, This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. "Using SRP for TLS Authentication", Dave Taylor, 11-Oct-05, This memo presents a technique for using the Secure Remote Password protocol ([SRP], [SRP-6]) as an authentication method for the Transport Layer Security protocol [TLS]. "Using OpenPGP keys for TLS authentication", Nikos Mavroyanopoulos, 17-Jan-06, This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. "The TLS Protocol Version 1.1", Tim Dierks, Eric Rescorla, 23-Jun-05, This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "Transport Layer Security (TLS) Extensions", Simon Blake-Wilson, 4-Oct-05, This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. "AES Counter Mode Cipher Suites for TLS and DTLS", Nagendra Modadugu, Eric Rescorla, 28-Feb-06, This document describes the use of the Advanced Encryption Standard (AES) Counter Mode for use as a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) confidentiality mechanism. "The TLS Protocol", Tim Dierks, Eric Rescorla, 2-Mar-06, This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Transport Area Working Group (tsvwg) ------------------------------------ "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Randall Stewart, 8-Mar-06, This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, 21-Feb-06, This document describes a mapping of the Stream Control Transmission Protocol SCTP RFC2960 [RFC2960] into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", Randall Stewart, 27-Oct-05, This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time based way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. "TCP Extended Statistics MIB", Matt Mathis, 9-Mar-06, This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. "Implementing an Emergency Telecommunications Service for Real Time Services in the Internet Protocol Suite", Fred Baker, James Polk, 2-Mar-06, RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others call for call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior for the data which meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the MLPP and GETS standards. The architectures described here are applicable beyond these organizations. "A Resource Reservation Protocol Extension for the Reduction of Bandwidth of a Reservation Flow", James Polk, Subha Dhesikan, 25-Jan-06, This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations or other forms of RSVP tunnels. "Configuration Guidelines for DiffServ Service Classes", Jozef Babiarz, 17-Feb-06, This document describes service classes configured with Diffserv, recommends how they can be used and how to construct them using Differentiated Service Code Points (DSCP), traffic conditioners, Per- Hop Behaviors (PHB), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. "Quick-Start for TCP and IP", Sally Floyd, 7-Mar-06, This document 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 (e.g., after an idle period). 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 option in the IP header of 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 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. "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", Michael Tuexen, 8-Mar-06, 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 shared keys between the sender and receiver. The new parameters are used to establish the shared keys. "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels", Francois Le Faucheur, 6-Feb-06, RFC 3175 specifies aggregation of RSVP end-to-end reservations over aggregate RSVP reservations. This document specifies 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 aggregate 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. "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", Aleksandar Kuzmanovic, 21-Nov-05, This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", Sally Floyd, 17-Jan-06, 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. "Stream Control Transmission Protocol (SCTP) Security Threats", Randall Stewart, 20-Jan-06, 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. "Stream Control Transmission Protocol", Randall Stewart, 17-Feb-06, This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi- homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. "QoS Signaling in a Nested Virtual Private Network", Fred Baker, Pratik Bose, 28-Feb-06, 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. "Generic Aggregate RSVP Reservations", Francois Le Faucheur, 2-Mar-06, [RSVP-AGG] defines aggregate RSVP reservations allowing resources to be reserved in a Diffserv network for a given DSCP from a given source to a given destination. [RSVP-AGG] also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address and DSCP. However, this is not supported by the aggregate reservations defined in [RSVP-AGG]. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given DSCP from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. Usenet Article Standard Update (usefor) --------------------------------------- "Usenet Best Practice", Charles Lindsey, 16-Mar-05, This Draft is intended to become a "Best Current Practice" RFC. Its purpose is to set out how software should behave and conventions which users should observe, in order that Netnews in general, and Usenet in particular, should provide the most effective service to its users. "Netnews Article Format", Charles Lindsey, 6-Mar-06, This document specifies the syntax of network news (Netnews) articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document supersedes RFC 1036, updating it to reflect current practice and incorporating incremental changes specified in other documents. "News Article Architecture and Protocols", Charles Lindsey, 6-Jan-06, This Draft, together with its companion draft [USEFOR], are intended as standards track documents, together obsoleting RFC 1036, which itself dates from 1987. This Standard defines the architecture of Netnews systems and specifies the requirements to be met by software which originates, distributes, stores and displays Netnews articles. Backward compatibility has been a major goal of this endeavour, but where this standard and earlier documents or practices conflict, this standard should be followed. In most such cases, current practice is already compatible with these changes. A companion Best Current Practice document [USEAGE], addressing requirements which are present for Social rather than Normative reasons is in preparation. IPv6 Operations (v6ops) ----------------------- "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Sebastien Roy, 17-Jan-06, This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. "IPv6 Enterprise Network Analysis", Jim Bound, 15-Feb-06, This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. "Reasons to Move NAT-PT to Experimental", Cedric Aoun, Elwyn Davies, 21-Oct-05, This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Standards Track to Experimental status. "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman Asadullah, 21-Oct-05, This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies using tunneling mechanisms and native IPv6. "IPv6 Network Architecture Protection", Gunter Van de Velde, 25-Oct-05, Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT. "IPv6 Transition/Co-existence Security Considerations", Elwyn Davies, 8-Mar-06, The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. "Using IPsec to Secure IPv6-in-IPv4 Tunnels", Pekka Savola, 8-Mar-06, This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", Tim Chown, 9-Mar-06, Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. "Best Current Practice for Filtering ICMPv6 Messages in Firewalls", Elwyn Davies, Janos Mohacsi, 9-Mar-06, In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Virtual Router Redundancy Protocol for IPv6", Robert Hinden, 1-Oct-04, This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address associated with a virtual router is called the Master, and forwards packets sent to this IP address. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discovery [ND] mechanisms. "Definitions of Managed Objects for the VRRP over IPv4 and IPv6", Kalyan Tata, 30-Sep-05, This specification defines a Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol for both IPv4 and IPv6 as defined in RFC 3768 and RFC xxxx ( RFC-editor, this is currently draft-ietf-vrrp-ipv6-spec-07.txt). This memo obsoletes RFC 2787. "Timer Enhancements to Reduce Failover Times for the Virtual Router Redundancy Protocol for IPv4", Robert Hott, 13-Mar-06, The router survivability capability provided by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the requirements for many LAN environments. There are, however, LAN environments that have sub-second failover requirements and thus a need for finer granularity of the VRRP timers. This draft proposes extensions to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals. A new message type is introduced which permits the timer granularity for the Advertisement Interval to be specified. In addition, a new field is introduced permitting the specification of the number of missed ADVERTISEMENTs before a Virtual Router Master is declared down. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "HTTP Extensions for Distributed Authoring - WebDAV", Lisa Dusseault, 21-Feb-06, WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1999, and this specification makes minor revisions mostly due to interoperability experience. "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, 23-Feb-06, This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. Widget Description Exchange Service (widex) ------------------------------------------- "Widget Description Exchange Service (WIDEX) Requirements", Vlad Stirbu, Dave Raggett, 17-Jan-06, This document defines functional requirements for a framework and a protocol used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update/mutation operations. Centralized Conferencing (xcon) ------------------------------- "Conferencing Scenarios", Roni Even, Nermeen Ismail, 8-Sep-05, This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text and interactive text sessions. These conferencing scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, 1-Dec-05, Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. "A Framework and Data Model for Centralized Conferencing", Mary Barnes, 9-Mar-06, This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. "Connection Establishment in the Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, 16-Dec-05, This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. This document also specifies a digest authentication mechanism for BFCP based on shared secrets.