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. IP over IEEE 802.16 Networks (16ng) ----------------------------------- "Transmission of IP over Ethernet over IEEE 802.16 Networks", Maximilian Riegel, Sangjin Jeong, HongSeok Jeon, 30-Jan-09, This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections which the IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, Pascal Thubert, 8-Dec-08, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context information to allow compression of arbitrary prefixes and addresses. This document specifies an interface to an abstract context database but the content and the management of the database are out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. This framework specifies UDP compression and is prepared for additional transports. "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Nicolas Chevrollier, Dominik Kaspar, JP Vasseur, 9-Mar-09, This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). After describing the characteristics of a LoWPAN, this document provides a list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG. A complete list of practical use cases is not the goal of this document. "Neighbor Discovery for 6LoWPAN", Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Erik Nordmark, 9-Mar-09, This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over energy and bandwidth constrained wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery with 6LoWPAN has several problems. Standard Neighbor Discovery was not designed for wireless links, and the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new ND mechanism allowing for efficient Duplicate Address Detection over entire LoWPANs. In addition it specifies context dissemination for use with router advertisements, claim and defend addressing, and the support of extended LoWPANs over backbone links. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 25-Mar-09, This document provides the problem statement for 6LoWPAN routing. It also defines the requirements for 6LoWPAN routing considering IEEE 802.15.4 specificities and the low-power characteristics of the network and its devices. IPv6 Maintenance (6man) ----------------------- "IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes", Hemant Singh, Wes Beebee, Erik Nordmark, 7-May-09, IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference; that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of on-link from [RFC4861]. "Handling of overlapping IPv6 fragments", Suresh Krishnan, 8-Mar-09, The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, Scott Baillie, Umberto Bonollo, 8-Jul-08, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Laird Popkin, Stefano Previdi, Richard Woundy, Yang Yang, 17-Apr-09, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for ALTO, which should be considered when specifying, assessing, or comparing protocols and implementations, and it solicits feedback and discussion. "Application-Layer Traffic Optimization (ALTO) Problem Statement", Jan Seedorf, Eric Burger, 21-Apr-09, Peer-to-peer applications, such as file sharing, real-time communication, and live media streaming, use a significant amount of Internet resources. Such applications often transfer large amounts of data in direct peer-to-peer connections. However, they usually have little knowledge of the underlying network topology. As a result, they may choose their peers based on measurements and statistics that, in many situations, may lead to suboptimal choices. This document describes problems related to optimizing traffic generated by peer-to-peer applications and associated issues such optimizations raise in the use of network-layer information. Access Node Control Protocol (ancp) ----------------------------------- "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", Sven Ooghe, Norbert Voigt, Michel Platnic, Thomas Haag, Sanjay Wadhwa, 6-May-09, The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", Hassnaa Moustafa, Hannes Tschofenig, Stefaan De Cnodder, 4-Mar-09, The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. "Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay Wadhwa, Jerome Moisand, Swami Subramanian, Thomas Haag, Norber Voigt, Roberta Maglione, 9-Mar-09, This document describes proposed extensions to the GSMPv3 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. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. Audio/Video Transport (avt) --------------------------- "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Eve Schooler, Joerg Ott, Julian Chesterfield, 26-Mar-09, 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 not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Ott et al. Internet Draft - Expires Sept 2009 [page 2] RTCP with Unicast Feedback "RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family", Jun Matsumoto, Mitsuyuki Hatanaka, 24-Apr-09, This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (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 ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 11-Apr-09, 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 describes 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, Jean-Marc Valin, Alfred Heggestad, 7-May-09, 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).Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published. "How to Write an RTP Payload Format", Magnus Westerlund, 2-Mar-09, 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. "Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins, Magnus Westerlund, 6-Aug-07, This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. "RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis, 6-Mar-09, This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. Table of Contents Status of this Memo...............................................1 Abstract..........................................................2 "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 3-Feb-09, This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) 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 and TCP, and it 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. "RTP Payload Format for DV (IEC 61834) Video", Katsushi Kobayashi, Kazuhiro Mishima, Stephen Casner, Carsten Bormann, 23-Mar-09, This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document Obsoletes RFC 3189. "RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 11-May-09, This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. "Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud, 30-Jan-09, This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla, 28-Feb-09, This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. "The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP", Seokung Yoon, Haeryong Park, Joongman Kim, Hyuncheol Jeong, Yoojae Won, 23-Apr-09, This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). "RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 9-Mar-09, This memo describes an RTP Payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RTP Payload format is based on the description in RFC 3984. "RTP Payload Format for SPIRIT IP-MR Speech Codec", Andrey Setsko, 15-Apr-09, This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and introduced redundancy for robustness against packet loss. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 9-Mar-09, The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptivity and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. "RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio", Frans Bont, Stefan Doehla, Malte Schmidt, Ralph Sperschneider, 22-Jan-09, This memo describes extensions for the RTP payload format defined in RFC3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards compatible transmission inside an MPEG-4 audio elementary stream. In addition a layered transmission scheme without using the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. "Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu, Michael Lague, 27-Oct-08, This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP). "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 9-Mar-09, This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP) does not mandate a single media security mechanism. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Roni Even, Tom Kristensen, 1-May-09, This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, 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. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17. "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 28-Apr-09, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. "RTCP XR Report Block for Burst/Gap Loss metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications. "RTCP XR Report Block for Burst/Gap Discard metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. "RTCP XR Report Block for Post-Repair Loss metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of a simple post-repair loss count metric for use in a range of RTP applications. It complements the pre-repair loss count metric "cumulative number of packets lost" provided by RFC3550. "RTCP XR Report Block for Packet Delay Variation Metric Reporting", Geoff Hunt, Alan Clark, 28-Apr-09, This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. "RTCP XR Report Block for Measurement Identity", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block carrying parameters which identify a measurement, to which one or more other RTCP XR Report Blocks may refer. "RTCP XR Report Block for Loss Concealment metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of Loss Concealment metrics primarily for audio applications of RTP. "RTCP XR Report Block for Jitter Buffer Metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications. "RTCP XR Report Block for Discard metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. "RTCP XR Report Block for Delay metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications. "RTCP XR Report Block for Concealed Seconds metric Reporting", Geoff Hunt, Alan Clark, 25-Feb-09, This document defines an RTCP XR Report Block that allows the reporting of Concealed Seconds metrics primarily for audio applications of RTP. "Rapid Synchronisation of RTP Flows", Colin Perkins, Thomas Schierl, 7-May-09, This memo outlines how RTP multimedia sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces several mechanisms to reduce the initial synchronisation delay for multimedia sessions. It updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. A new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. Therefore, a synchronized insertion of RTP header extensions is recommended. "RTP Payload format for GSM-HR", Xiaodong Duan, Shuaiyu Wang, Magnus Westerlund, Karl Hellwig, Ingemar Johansson, 15-Apr-09, This document specifies the RTP payload format for packetization of the GSM Half-Rate speech codec. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip Matthews, 12-Apr-09, If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. "Traversal Using Relays around NAT (TURN) Extension for IPv6", Gonzalo Camarillo, Oscar Novo, 9-Mar-09, This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute 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). "NAT Behavior Discovery Using STUN", Derek MacDonald, Bruce Lowekamp, 9-Mar-09, This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Simon Perreault, Jonathan Rosenberg, 4-May-09, This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. "Test vectors for STUN", Remi Denis-Courmont, 18-Nov-08, The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", Remi Denis-Courmont, 27-Nov-08, This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). Those allow DCCP applications, such as streaming applications to operate consistently. These requirements are very similar to the TCP requirements for NATs already published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 16-Feb-09, Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. 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 a 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 NATs 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 and multi-point traversal scenario. "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, 7-Mar-09, This document defines two URI schemes and the resolution mechanism to convert these URIs to a list of server transport addresses that can be used between a Traversal Using Relays around NAT (TURN) client and server. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya, 26-Apr-09, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. "BFD For MPLS LSPs", Rahul Aggarwal, Kireeti Kompella, Thomas Nadeau, George Swallow, 20-Jun-08, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a Multi Protocol Label Switched (MPLS) Label Switched Path (LSP) data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 5-Feb-09, 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. "BFD for Multihop Paths", Dave Katz, David Ward, 5-Feb-09, This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 5-Feb-09, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. "Generic Application of BFD", Dave Katz, David Ward, 5-Feb-09, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. "BFD for Multipoint Networks", Dave Katz, David Ward, 5-Feb-09, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", Jonathan Rosenberg, 9-Mar-09, The Session Initiation Protocol (SIP) has been designed as a general purpose protocol for establishing and managing multimedia sessions. It provides many core functions and extensions in support of features such as transferring of calls, parking calls, and so on. However, interoperability of more advanced features between different vendors has been poor. This document describes the reason behind these interoperability problems, and presents a framework for addressing them. "An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)", John Elwell, 6-Jan-09, This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP) and specifies some best practices to help achieve interoperability. This work is being discussed on the bliss@ietf.org mailing list. "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Roland Jesske, 8-Dec-08, The features "call completion on busy subscriber" and "call completion on no reply" allow the calling party of a failed call to be notified when the called party becomes available to receive a call. This document describes an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations at the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, 9-Mar-09, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document lists requirements and compares implementation options for this feature. Extensions to the SIP dialog event package are proposed. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Benchmarking IPsec Devices", Merike Kaeo, Tim Van Herck, Michele Bustos, 3-Apr-09, 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 Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, 8-Mar-09, This document describes the methodology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The methodology can be applied to any link-state IGP, such as ISIS and OSPF. Link-State IGP Data Plane Route Convergence "Terminology for Benchmarking Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, 8-Mar-09, This document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF. Link-State IGP Data Plane Route Convergence "Considerations for Benchmarking Link-State IGP Data Plane Route Convergence", Scott Poretsky, 8-Mar-09, This document discusses considerations for benchmarking Interior Gateway Protocol (IGP) Route Convergence for any link-state IGP, such as Intermediate System-Intermediate System (ISIS) and Open-Shorted Path first (OSPF). A companion methodology document is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. A companion "Methodology for Benchmarking IPsec Devices", Merike Kaeo, Tim Van Herck, 3-Apr-09, 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 "Benchmarking Terminology for Protection Performance", Scott Poretsky, Jay Karthik, 8-Mar-09, 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, avoiding dependence on specific sub-IP protection mechanisms. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). Protection Performance "Methodology for benchmarking MPLS protection mechanisms", Scott Poretsky, Shankar Rao, 8-Mar-09, This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. This document provides test methodologies and testbed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time applications bound to MPLS based traffic engineered tunnels. The benchmarking terms used in this document are defined in [TERM-ID]. "MPLS Forwarding Benchmarking Methodology for IP Flows", Aamer Akhter, Rajiv Asati, Carlos Pignataro, 21-Apr-09, This document describes a methodology specific to the benchmarking of Multi-Protocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. "Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 4-Mar-09, This document provides a terminology for benchmarking SIP performance in networking devices. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The performance benchmark metrics are obtained for the SIP control plane and media plane. The terms are intended for use in a companion methodology document for complete performance characterization of a device in a variety of conditions making it possible to compare performance of different devices. It is critical to provide test setup parameters and a methodology document for SIP performance benchmarking because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. It is necessary to have terminology and methodology standards to ensure that reported benchmarks have consistent definition and were obtained following the same procedures. Benchmarks can be applied to compare performance of a variety of SIP networking devices. "Methodology for Benchmarking SIP Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 4-Mar-09, This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in SIP benchmarking terminology document. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Both scale and establishment rate are measured by signaling plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, P-CSCF, and Server paired with a Firewall/NAT device. Better-Than-Nothing Security (btns) ----------------------------------- "IPsec Channels: Connection Latching", Nicolas Williams, 9-Apr-09, This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. "C-Bindings for IPsec Application Programming Interfaces", Michael Richardson, Nicolas Williams, Miika Komu, Sasu Tarkoma, 24-Mar-09, IPsec based security is usually transparent for applications and they have no standard APIs for gathering information on connection security properties. This document specifies an API that increases the visibility of IPsec to applications. The API allows applications to allow BTNS extensions, control the channel bindings, and control also other security properties related to IPsec. This document presents C-bindings to the abstract BTNS API. "IPsec End-Point Channel Bindings and API", Nicolas Williams, 9-Apr-09, This document defines channel bindings for IPsec and describes an abstract API and a BSD sockets API extension for obtaining channel bindings of "connection latches". Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 19-Apr-09, This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol 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 calendaring systems. These scheduling methods permit two or more calendaring 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, 19-Apr-09, This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information, independent of any particular calendar service or protocol.Editorial Note (To be removed by RFC Editor prior to publication) This document is a product of the Calendaring and Scheduling Standards Simplification (Calsify) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the ietf-calsify@osafoundation.org [1] mailing list. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "CAPWAP Protocol Base MIB", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 28-Feb-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. "CAPWAP Protocol Binding MIB for IEEE 802.11", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 3-Mar-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Kohei Shiomoto, Adrian Farrel, Richard Rabbat, Arthi Ayyangar, Zafar Ali, 9-Dec-08, Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle. "Ethernet Traffic Parameters", Dimitri Papadimitriou, 17-Apr-09, This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. "OSPFv2 Routing Protocols Extensions for ASON Routing", Dimitri Papadimitriou, 7-Apr-09, The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines to the OSPFv2 Link State Routing Protocol to meet the routing requirements for routing in an ASON. D.Papadimitriou et al. - Expires October 2009 [page 1] draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt April 2009 Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Zafar Ali, JP Vasseur, Anca Zamfir, 9-Mar-09, MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. "draft-ietf-ccamp-gmpls-vcat-lcas-07.txt", Greg Bernstein, Richard Rabbat, Huub Helvoort, 18-Dec-08, This document describes requirements for, and 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 Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Masanori Miyazawa, Tomohiro Otani, Kenji Kumaki, Thomas Nadeau, 30-Jan-09, This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", Dimitri Papadimitriou, Martin Vigoureux, Kohei Shiomoto, Deborah Brungard, Jean-Louis Le Roux, 17-Apr-09, There are specific requirements for the support of networks comprising Label Switching Routers (LSR) participating in different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi- Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. "Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 13-Feb-09, There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, Tomohiro Otani, Ruiquan Jing, 29-Mar-09, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for Dynamicly provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the Dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. "Data Channel Status Confirmation Extensions for the Link Management Protocol", Dan Li, Huiying Xu, Fatai Zhang, Snigdho Bardalai, Julien Meuric, Diego Caviglia, 5-May-09, As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. Li Expires November 2009 [page 1] draft-ietf-ccamp-confirm-data-channel-status-03.txt May 2009 "RSVP Extensions for Path Key Support", Adrian Farrel, Richard Bradford, JP Vasseur, 7-Mar-09, The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation. "Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE", Don Fedyk, David Allan, Himanshu Shah, Nabil Bitar, Attila Takacs, Diego Caviglia, Alan McGuire, Nurit Sprecher, Lou Berger, 25-Feb-09, This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching", Lou Berger, Don Fedyk, 25-Feb-09, This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services. Support for MEF and ITU defined parameters are also covered. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)", Lou Berger, Don Fedyk, 25-Feb-09, This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. "Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt", Richard Rabbat, 24-Mar-09, 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. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. "Service Provider Requirements for Ethernet control with GMPLS", Wataru Imajuku, Yoshiaki Sone, Muneyoshi Suzuki, Kazuhiro Matsuda, Tomohiro Otani, Kenichi Ogaki, Nabil Bitar, 10-Dec-08, Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled Ethernet label switch networks. "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", Lou Berger, Don Fedyk, 25-Feb-09, This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Greg Bernstein, 3-Mar-09, This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model does not include optical impairments. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", Greg Bernstein, 4-Mar-09, This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, 3-Mar-09, A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMPLS routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. "OAM Configuration Framework and Requirements for GMPLS RSVP-TE", Attila Takacs, Don Fedyk, He Jia, 9-Mar-09, OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Don Fedyk, Dinesh Mohan, Hao Long, 9-Mar-09, The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK]. Cga & Send maIntenance (csi) ---------------------------- "SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 9-Mar-09, This document analysis the use of hashes in SeND, possible threats and the impact of recent attacks on hash functions used by SeND. Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc5280] and does not provide support for the hash algorithm agility. The purpose of the document is to provide analysis of possible hash threats and to decide how to encode the hash agility support in SeND. "Securing Neighbor Discovery Proxy Problem Statement", Greg Daley, Jean-Michel Combes, Suresh Krishnan, 8-Mar-09, Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform neighbor discovery operations on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor discovery messages. Neighbor Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to Secured Neighbor Discovery. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 22-Jun-07, The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia 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. "The DCCP Service Code", Gorry Fairhurst, 28-Apr-09, This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g. network address translators and firewalls). This document updates the specification provided in RFC 4340. "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Sally Floyd, Eddie Kohler, 10-May-09, This document specifies a profile for Congestion Control Identifier 4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP [RFC4828], a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. "DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", Gorry Fairhurst, 2-May-09, This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g. a DCCP server behind a firewall, or a Network Address Port Translator), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. "Quick-Start for Datagram Congestion Control Protocol (DCCP)", Gorry Fairhurst, 28-Apr-09, This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID-2, CCID-3 and CCID-4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 4-Mar-09, This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. "Subnet Allocation Option", Richard Johnson, Jay Kumarasamy, Kim Kinnear, Mark Stapp, 11-Mar-09, This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Ralph Droms, Bernie Volz, 6-Feb-09, The DHCP Relay Agent Assignment Notification (RAAN) 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. "Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms, 17-Nov-08, This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. "DHCPv6 Server Reply Sequence Number Option", Bernie Volz, Ralph Droms, 4-Feb-09, This memo defines the Server Reply Sequence Number option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is sent from a DHCPv6 server to a DHCPv6 relay agent to allow a relay agent to detect proper sequencing of Relay-Reply messages that could be delivered out of order. "Guidelines for Creating New DHCP Options", David Hankins, 24-Feb-09, This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. "Container Option for Server Configuration", Ralph Droms, 24-Mar-09, In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 21-Apr-09, In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages. "Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund Kamath, Stefaan De Cnodder, 25-Feb-09, As per industry trends, Access Networks have been migrating from traditional ATM based networks to Ethernet networks. In Ethernet based access networks, Access Concentrators are typically configured to act as a transparent bridge in Layer 2 mode. These Access Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent functionality does not provide means to avoid flooding of DHCP messages and also needs to be extended to support DHCP LeaseQuery This draft discusses these issues and provides solutions for the same. "The DHCPv4 Relay Agent Identifier Suboption", Mark Stapp, 18-Dec-08, This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device. The value may be administratively-configured or may be generated by the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. "DHCPv6 option for network boot", Thomas Huth, Jens Freimann, Vincent Zimmer, Dave Thaler, 14-Apr-09, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 which are required for booting a node from the network. "DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 14-Jan-09, Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing, prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. Existing leasequery mechanism is data driven which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues. "DHCPv6 Vendor-specific Message", Bernie Volz, 12-Jan-09, This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes. "DHCPv4 Vendor-specific Message", Bernie Volz, 12-Jan-09, This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes. "Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 13-Feb-09, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. "Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications", David Hankins, 2-Mar-09, The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the current defined standard. This document seeks to provide clarification of actual behaviour and guidance for some situations that were previously omitted. Diameter Maintenance and Extensions (dime) ------------------------------------------ "The Diameter API", Victor Fajardo, Pat Calhoun, David Frascone, 28-Apr-09, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes an 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. "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", Jouni Korhonen, Hannes Tschofenig, Julien Bournelle, Gerardo Giaretta, Madjid Nakhjiri, 28-Apr-09, Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP Home Agent and a Diameter server. This document defines the Home Agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 6-May-09, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. "Diameter Quality of Service Application", Dong Sun, Pete McCann, Hannes Tschofenig, Tina Tsou, Avri Doria, Glen Zorn, 7-May-09, This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. "Diameter Applications Design Guidelines", Victor Fajardo, Tolga Asveren, Hannes Tschofenig, Glenn McGregor, John Loughney, 24-Nov-08, The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. "Quality of Service Parameters for Usage with Diameter", Jouni Korhonen, Hannes Tschofenig, Elwyn Davies, 9-Mar-09, This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter. The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per- hop behavior class object. "Quality of Service Attributes for Diameter", Jouni Korhonen, Hannes Tschofenig, Mayutan Arumaithurai, Mark Jones, Avi Lior, 23-Feb-09, This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. "Diameter Support for EAP Re-authentication Protocol", Lakshminath Dondeti, Julien Bournelle, Lionel Morand, Sebastien Decugis, 14-Jan-09, EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the EAP peer and an EAP re-authentication server through any EAP/ERP authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP codes specified in the ERP specification. Additionally, this document also defines specific Diameter processing rules relevant to ERP. "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", Jouni Korhonen, Julien Bournelle, Kuntal Chowdhury, Ahmad Muhanna, Ulrike Meyer, 16-Apr-09, This specification defines the Diameter support for the Proxy Mobile IPv6 and the corresponding mobility service session setup. The policy information needed by the Proxy Mobile IPv6 is defined in mobile node's policy profile, which could be downloaded from the Diameter server to the Mobile Access Gateway once the mobile node attaches to a Proxy Mobile IPv6 Domain and performs access authentication. During the binding update exchange between the Mobile Access Gateway and the Local Mobility Anchor, the Local Mobility Anchor can interact with the Diameter server in order to update the remote policy store with the mobility session related information. "Diameter User-Name and Realm Based Request Routing Clarifications", Jouni Korhonen, Mark Jones, Lionel Morand, Tina Tsou, 10-May-09, This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Service Overview", Tony Hansen, Dave Crocker, Phillip Hallam-Baker, 20-Apr-09, This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", header field, Author Domain, return error, Eric Allman, Jim Fenton, Mark Delany, John Levine, 11-May-09, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail, and how other hosts can access that record. "DomainKeys Identified Mail (DKIM) Development, Deployment and Operations", Tony Hansen, Ellen Siegel, Phillip Hallam-Baker, Dave Crocker, 9-Mar-09, DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational and migration considerations for DKIM. "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", Dave Crocker, 21-Apr-09, This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures. Specifically the document clarifies the nature, roles and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one. Detecting Network Attachment (dna) ---------------------------------- "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", Greg Daley, Erik Nordmark, 9-Mar-09, 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. "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 24-Feb-09, Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. DNS Extensions (dnsext) ----------------------- "DNS Zone Transfer Protocol (AXFR)", Edward Lewis, 30-Mar-09, The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The definition of AXFR, has proven insufficient in detail, forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 14-Jan-09, This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", Jelte Jansen, 24-Apr-09, This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). "Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 6-Mar-09, The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. "Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records", Francis Dupont, 8-May-09, The main purpose of this document is to deprecate the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system), and the use of MD5 in TKEY (secret key establishment for DNS). "DNS Proxy Implementation Guidelines", Ray Bellis, 23-Apr-09, This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. Domain Name System Operations (dnsop) ------------------------------------- "Locally-served DNS Zones", Mark Andrews, 26-Feb-09, Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics. "I'm Being Attacked by PRISONER.IANA.ORG!", Joe Abley, William Maton, 9-Mar-09, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send DNS reverse mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely- coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. "AS112 Nameserver Operations", Joe Abley, William Maton, 9-Mar-09, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Devices in such environments may occasionally originate reverse DNS queries corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that they are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authority servers. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation. "DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 9-Mar-09, This document recommends a preferred format for specifying trust anchors in DNSSEC validating security-aware resolvers and describes how such a resolver should initialize trust anchors for use. This document also describes different mechanisms for keeping trust anchors up to date over time. "Requirements for Management of Name Servers for the DNS", Wesley Hardaker, 4-May-09, Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration and control methods. Although some service monitoring platforms can test the functionality of the DNS itself there is not an interoperable way to manage (monitor, control and configure) the internal aspects of a name server itself. This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. "DNSSEC Operational Practices, Version 2", Olaf Kolkman, Miek Gieben, 6-Mar-09, 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 of 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. Email Address Internationalization (eai) ---------------------------------------- "Mailing Lists and Internationalized Email Addresses", Randall Gellens, 20-Nov-08, This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. "POP3 Support for UTF-8", Chris Newman, Randall Gellens, 20-Nov-08, This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. "An update to the mailto URI scheme for Email Address Internationalization", Martin Duerst, 9-Mar-09, This document updates the definition of the mailto: URI Scheme for use with internationalized email addresses. "Displaying Downgraded Messages for Email Address Internationalization", Kazunori Fujiwara, 9-Mar-09, This document describes how to display downgraded messages which originally contain internationalized E-mail addresses or internationalized header fields. "Internationalized Delivery Status and Disposition Notifications", Chris Newman, Alexey Melnikov, 16-Dec-08, Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne, 5-Mar-09, This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 27-Mar-09, The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. "Framework for Emergency Calling using Internet Multimedia", Brian Rosen, Henning Schulzrinne, James Polk, Andrew Newton, 27-Mar-09, The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. "Location Hiding: Problem Statement and Requirements", Henning Schulzrinne, Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett, 12-Oct-08, The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. "Specifying Holes in LoST Service Boundaries", James Winterbottom, Martin Thomson, 12-Oct-08, This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Henning Schulzrinne, Hannes Tschofenig, 7-Mar-09, The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism can be used for bulk exchange of elements between two entities. As such, this document can also be used without the LoST protocol. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 24-Mar-09, This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. EAP Method Update (emu) ----------------------- "Requirements for a Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna, Hao Zhou, Joseph Salowey, 26-Feb-09, This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. "Channel Binding Support for EAP Methods", Charles Clancy, Katrin Hoeper, 4-Mar-09, This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. Telephone Number Mapping (enum) ------------------------------- "IANA Registration for IAX Enumservice", Ed Guy, 14-Feb-09, This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761. "IANA Registration of Enumservices: Guide, Template and IANA Considerations", Hoeneisen Bernie, Alexander Mayrhofer, Jason Livingood, 15-Feb-09, This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. "A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services", Rohan Mahy, 10-Mar-08, 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. "IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata'", Richard Shockey, 29-Sep-08, This document registers the Enumservice 'pstndata' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new URI type 'pstndata:'. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future. "ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06, Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Scott Bradner, Lawrence Conroy, Kazunori Fujiwara, 4-May-09, This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. "IANA Registration for Enumservice UNUSED", Richard Stastny, Lawrence Conroy, Jim Reid, 29-Mar-08, This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. 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 allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". "Update of legacy IANA Registrations of Enumservices", Bernie Hoeneisen, Alexander Mayrhofer, 15-Feb-09, This document specifies a revision of all Enumservices that have been registered at IANA under the nowadays obsolete regime of [RFC3761]. It mainly adds the new fields to the IANA Registration Template as specified in [I-D.ietf-enum-enumservices-guide], and makes at the same time some corrections of editorial nature. FEC Framework (fecframe) ------------------------ "RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 5-May-09, This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. "DVB Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer, 27-Jan-09, This document describes the Application-layer Forward Error Correction (FEC) protocol that was developed by the Digital Video Broadcasting (DVB) consortium for the protection of media streams over IP networks. The DVB AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB AL-FEC offers a good protection against both bursty and random packet losses at a cost of decent complexity. The 1-D interleaved parity code and Raptor code have already been specified in separate documents and the current document normatively references these specifications. "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", Ulas Kozat, Ali Begen, 7-Mar-09, This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework document and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. "RTP Payload Format for Raptor FEC", Mark Watson, 6-Mar-09, This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Forwarding Element Model", Joel Halpern, Jamal Hadi Salim, 7-Oct-08, This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol [2]. 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 document, RFC3654 [6]. "ForCES Protocol Specification", Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Salim, Hormuzd Khosravi, Weiming Wang, 2-Mar-09, 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, this specification also defines the requirements for the Transport Mapping Layer (TML).Authors The participants in the ForCES Protocol Team, primary co-authors and co-editors, of this protocol specification, are: Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern who has done extensive editing in support of congruence between the model and this protocol specification. Without his participation and persistence, this specification might never have been completed. "ForCES MIB", Robert HAAS, 10-Sep-08, This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). "SCTP based TML (Transport Mapping Layer) for ForCES protocol", Jamal Hadi Salim, Kentaro Ogawa, 29-Jan-09, This document defines the SCTP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) [RFC2960] and also describes how this TML addresses all the requirements described in [RFC3654] and the ForCES protocol [FE-PROTO] draft. "ForCES Interoperability Draft", Evangelos Haleplidis, Kentaro Ogawa, Xin-ping Wang, 4-Mar-09, This document describes the details of the interoperability test of the Forward and Control Element Separation (ForCES) protocol that will take place in the University of Patras in Rio, Greece, in the fourth week of July 2009. This informational draft provides necessary information, for all parties who wish to participate in the interoperability test. Geographic Location/Privacy (geopriv) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, Hannes Tschofenig, John Morris, Jorge Cuellar, James Polk, 9-Feb-09, This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. "Carrying Location Objects in RADIUS and Diameter", Hannes Tschofenig, Farid Adrangi, Mark Jones, Avi Lior, Bernard Aboba, 7-May-09, This document describes procedures for conveying access network ownership and location information based on a civic and geospatial location format in Remote Authentication Dial In User Service (RADIUS) and Diameter. 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. "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 21-Feb-09, This document provides a problem statement, lists requirements and captures design aspects for a Geopriv Layer 7 Location Configuration Protocol L7 (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. "HTTP Enabled Location Delivery (HELD)", Mary Barnes, James Winterbottom, Martin Thomson, Barbara Stark, 11-May-09, A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of session-layer. This document describes the use of HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer Security (HTTP/TLS) as transports for the protocol. "Requirements for a Location-by-Reference Mechanism", Roger Marshall, 26-Feb-09, This document defines terminology and provides requirements relating to Location-by-Reference approach using a location URI to handle location information within signaling and other Internet messaging. "Discovering the Local Location Information Server (LIS)", Martin Thomson, James Winterbottom, 7-May-09, Discovery of the correct Location Information Server (LIS) in the local access network is necessary for devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 9-Mar-09, This document creates a Dynamic Host Configuration Protocol (DHCP) Option for the downloading of a Uniform Resource Identifier (URI) pointing to the geolocation record of an endpoint. This URI, called a Location-by-Reference (LbyR), points to a record on a location server which tracks the geolocation of the endpoint. Once downloaded by an endpoint, this LbyR can be forwarded to another entity, to be dereferenced if this entity wants to learn the geolocation of the sender endpoint. "Implications of 'retransmission-allowed' for SIP Location Conveyance", Jon Peterson, Ted Hardie, John Morris, 9-Mar-09, This document explores an ambiguity in the interpretation of the element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to these ambiguities. Documents standardizing the SIP location conveyance mechanisms will be standards-track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. "Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition", Karl Wolf, Alexander Mayrhofer, 19-Feb-09, This document provides a guideline for creating civic address consideration documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address consideration documents. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 25-Feb-09, 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. "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 7-Apr-09, This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. "Routing System Stability", Dimitri Papadimitriou, James Lowe, 22-Mar-09, Understanding the dynamics of the Internet routing system is fundamental to ensure its robustness/stability and to improve the mechanisms of the BGP routing protocol. This documents outlines a program of activity for identifying, documenting and analyzing the dynamic properties of the Internet and its routing system. Host Identity Protocol (hip) ---------------------------- "Basic HIP Extensions for Traversal of Network Address Translators", Miika Komu, Tom Henderson, Hannes Tschofenig, Jan Melen, Ari Keraenen, 9-Mar-09, This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment", Gonzalo Camarillo, Pekka Nikander, Jani Hautakorpi, Alan Johnston, 9-Mar-09, This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. Handover Keying (hokey) ----------------------- "Distribution of EAP based keys for handover and re-authentication", Katrin Hoeper, Yoshihiro Ohba, 3-Apr-09, This document describes a mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain- specific root key (DSRK) or a domain-specific usage-specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. The document defines a key distribution exchange (KDE) protocol using Remote Authentication Dial In User Service (RADIUS) that can distribute these different types of root keys and discusses its security requirements. "EAP Pre-authentication Problem Statement", Wenson Wu, Yoshihiro Ohba, 8-Mar-09, EAP (Extensible Authentication Protocol) pre-authentication is defined as the use of EAP to pre-establish EAP keying material on a target authenticator prior to arrival of the peer at the access network managed by that authenticator. This draft discusses EAP pre- authentication problems in detail. Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. "HTTP/1.1, part 2: Message Semantics", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields. "HTTP/1.1, part 3: Message Payload and Content Negotiation", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. "HTTP/1.1, part 4: Conditional Requests", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. "HTTP/1.1, part 5: Range Requests and Partial Responses", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. "HTTP/1.1, part 6: Caching", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. "HTTP/1.1, part 7: Authentication", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 9-Mar-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication. "Security Requirements for HTTP", Paul Hoffman, Alexey Melnikov, 7-Mar-09, Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade- offs of each. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 1-Dec-08, This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. Internet Architecture Board (iab) --------------------------------- "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, Peter Koch, 9-Mar-09, This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. Internationalized Domain Names in Applications (Revised) (idnabis) ------------------------------------------------------------------ "The Unicode code points and IDNA", Patrik Faltstrom, 22-Dec-08, This document specifies rules for deciding whether a code point, considered in isolation, is a candidate for inclusion in an Internationalized Domain Name. It is part of the specification of IDNA2008. "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", John Klensin, 9-Mar-09, Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. "Internationalized Domain Names in Applications (IDNA): Protocol", John Klensin, 8-May-09, This document is the revised protocol definition for internationalized domain names (IDNs). The rationale for changes, the relationship to the older specification, and important "An updated IDNA criterion for right-to-left scripts", Harald Alvestrand, Cary Karp, 29-Nov-08, The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI rule for IDNA labels. "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", John Klensin, 9-Mar-09, This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. Inter-Domain Routing (idr) -------------------------- "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 18-Feb-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. "Dissemination of flow specification rules", Pedro Roque Marques, Nischal Sheth, Robert Raszuk, Barry Greene, Jared Mauch, Danny McPherson, 21-Apr-09, This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. "Revisions to the BGP 'Minimum Route Advertisement Interval'", Paul Jakma, 15-Dec-08, This document revises the specification of the BGP MRAI timer, by deprecating the previously recommended values and by allowing for withdrawals to be exempted from the MRAI. "Advertisement of Multiple Paths in BGP", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 19-Dec-08, 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. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 26-Jan-09, Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. "Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4)", Jeffrey Haas, 18-Feb-09, This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. "BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 17-Apr-09, Currently the Autonomous System (AS) 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. "Error Handling for Optional Transitive BGP Attributes", John Scudder, Enke Chen, 16-Apr-09, According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. It also revises the error handling procedures for several existing optional transitive attributes. "BGP Link Bandwidth Extended Community", Pradosh Mohapatra, Rex Fernando, 21-Apr-09, This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. "The Accumulated IGP Metric Attribute for BGP", Rex Fernando, Pradosh Mohapatra, Eric Rosen, James Uttaro, 8-May-09, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. IP Flow Information Export (ipfix) ---------------------------------- "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, 9-Mar-09, This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. "Specification of the IPFIX File Format", Brian Trammell, Elisa Boschi, Lutz Mark, Tanja Zseby, Arno Wagner, 24-Oct-08, This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. "Exporting Type Information for IPFIX Information Elements", Elisa Boschi, Brian Trammell, Lutz Mark, Tanja Zseby, 14-Apr-09, This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements, and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. "IPFIX Mediation: Problem Statement", Atsushi Kobayashi, Benoit Claise, Haruhiko Nishida, Christoph Sommer, Falko Dressler, Emile Stephan, 30-Apr-09, Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. IPFIX Mediation covers two classes of mediation: context mediation for traffic data and transport mediation for transport protocols. This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. "IPFIX Mediation: Framework", Atsushi Kobayashi, Haruhiko Nishida, Benoit Claise, 10-Feb-09, This document describes a framework for IPFIX Mediation. This framework details the IPFIX Mediation reference model and the components of an IPFIX Mediator. "IPFIX Export per SCTP Stream", Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, 26-Jan-09, This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise, 9-Mar-09, This document specifies a data model for the configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. IP Performance Metrics (ippm) ----------------------------- "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, Lei Liang, Al Morton, 28-Apr-09, The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). "Spatial Composition of Metrics", Al Morton, Emile Stephan, 7-Mar-09, 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. "Reporting IP Performance Metrics to Users", Stanislav Shalunov, Martin Swany, 9-Mar-09, The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. "A One-Way Packet Duplication Metric", Henk Uijterwaal, 17-Apr-09, When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive. In earlier work a metric for packet loss has been defined. This metric quantifies the case where a packet that is sent, does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. "More Features for the Two-Way Active Measurement Protocol - TWAMP", Al Morton, Kaynam Hedayat, 5-May-09, This memo describes a simple extension to TWAMP - the Two-Way Active Measurement Protocol. The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also requests that IANA establish a registry for additional new features, called the TWAMP-Modes registry. "TWAMP Reflect Octets Feature", Al Morton, Len Ciavattone, 7-Mar-09, The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, and/or ensures that the same test packet sizes are used in both directions. "Individual Session Control Feature for TWAMP", Al Morton, Murtaza Chiba, 7-Mar-09, The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Internet Key Exchange Protocol: IKEv2", Charlie Kaufman, Paul Hoffman, Yoav Nir, Pasi Eronen, 24-Apr-09, This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. "Redirect Mechanism for IKEv2", Vijay Devarapalli, Kilian Weniger, 11-May-09, IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. "Wrapped ESP for Traffic Visibility", Manav Bhatia, Ken Grewal, Gabriel Montenegro, 30-Apr-09, This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of ESP [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. "IKEv2 Session Resumption", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 1-May-09, The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach requires passing opaque data from the IKEv2 responder to the IKEv2 initiator, which is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but recommendations are provided. "IPv6 Configuration in IKEv2", Pasi Eronen, Julien Laganier, Cheryl Madson, 18-Nov-08, When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Sheila Frankel, Suresh Krishnan, 6-Mar-09, Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. "Heuristics for Detecting ESP-NULL packets", Tero Kivinen, Daniel McDonald, 16-Apr-09, This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. IS-IS for IP Internets (isis) ----------------------------- "IPv6 Traffic Engineering in IS-IS", Jon Harrison, Jon Berger, Mike Bartlett, 6-Jan-09, 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. "Extensions to IS-IS for Layer-2 Systems", Ayan Banerjee, 3-Mar-09, 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 supporting 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. Integrated Security Model for SNMP (isms) ----------------------------------------- "Secure Shell Transport Model for SNMP", David Harrington, Joseph Salowey, Wesley Hardaker, 11-May-09, This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also 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 monitoring and managing the Secure Shell Transport Model for SNMP. "Transport Subsystem for the Simple Network Management Protocol (SNMP)", David Harrington, Juergen Schoenwaelder, 6-May-09, This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. "Transport Security Model for SNMP", David Harrington, Wesley Hardaker, 6-May-09, This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models", Kaushik Narayan, David Nelson, 29-Apr-09, This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. Provisioning of Symmetric Keys (keyprov) ---------------------------------------- "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", Andrea Doherty, Mingliang Pei, Salah Machani, Magnus Nystrom, 9-Feb-09, DSKPP is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private-key capabilities in the cryptographic modules, and with or without an established public-key infrastructure. Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre- generated symmetric keys to a cryptographic module. This document builds on information contained in [RFC4758], adding specific enhancements in response to implementation experience and liaison requests. "Symmetric Key Package Content Type", Sean Turner, Russ Housley, 16-Jan-09, This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax can be used to digitally sign, digest, authenticate, or encrypt this content type. "Portable Symmetric Key Container (PSKC)", Philip Hoyer, Mingliang Pei, Salah Machani, 22-Feb-09, This document specifies a symmetric key format for transport and provisioning of symmetric keys (for example One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of crypto modules, such as a strong authentication device. The standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- "Generic Security Service API Version 2 : Java Bindings Update", Mayan Upadhyay, Seema Malkani, 16-Feb-09, 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 "Generic Security Service API version 2 : Java Bindings" (RFC2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience. The GSS-API is described at a language independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC2743). 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" (RFC2025) and "The Kerberos Version 5 GSS-API Mechanism (RFC4121). "Extended Generic Security Service Mechanism Inquiry APIs", Nicolas Williams, 1-Apr-09, 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 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. "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 6-Apr-09, This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. "GSS-API Extension for Storing Delegated Credentials", Nicolas Williams, 8-Mar-09, 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, 1-Apr-09, This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. "GSS-API Naming Extensions", Nicolas Williams, Leif Johansson, 8-Mar-09, 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 model to support name attribute transfer between GSS-API peers. Kerberos (krb-wg) ----------------- "A Generalized Framework for Kerberos Pre-Authentication", Sam Hartman, Larry Zhu, 9-Mar-09, Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a mechanism called pre-authentication for proving the identity of a principal and for better protecting the long-term secrets of the principal. This document describes a model for Kerberos pre-authentication mechanisms. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the KDC with a reply key delivery mechanism; this secure channel can be used to protect the authentication exchange thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. "Problem statement on the cross-realm operation of Kerberos", Shoichi Sakane, 30-Oct-08, There are some issues when the cross-realm operation of the Kerberos Version 5 [RFC4120] is employed into actual specific systems. This document describes some examples of actual systems, and lists requirements and restriction of the operation in such system. Then it describes issues when we apply the cross-realm operation to such system. "OTP Pre-authentication", Gareth Richards, 8-Apr-09, The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One Time Password (OTP) authentication. "An information model for Kerberos version 5", Leif Johansson, 8-Mar-09, 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. "Kerberos ticket extensions", Love Astrand, 18-Nov-08, The Kerberos protocol does not allow ticket extensions. This make it harder to deploy features like PKCROSS. Since the Kerberos protocol did not specified extensibility for the Ticket structure and the current implementations are aware of the contents of tickets, the extension protocol cannot simply extend the Ticket ASN.1 structure. Instead, the extension data needs to be hidden inside the ticket. This protocol defines two methods to add extend the tickets. The first method requires updated clients and is more in line with the future development of Kerberos. The second way does not require update client. To take advantage of this protocol the server (KDC or application server) need to update a well. The two methods are equivalent and there is a 1-1 mapping between them. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires", Sharon Galtzur, Alexander Vainshtein, 21-Apr-09, This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure- aware (CESoPSN style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (TDMoIP style) pseudowires over L2TPv3 is left for further study. "L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro, 13-Apr-09, This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate more granular error states for Attachment Circuits (ACs) and Pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the "Circuit Status" AVP, updating RFC3931, RFC4349, RFC4454, RFC4591, and RFC4719. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "Provisioning, Autodiscovery, and Signaling in L2VPNs", Eric Rosen, 5-May-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). "L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, Simon Delord, Philippe Niger, 14-Jul-08, 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 PWOAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. "ARP Mediation for IP Interworking of Layer 2 VPN", Eric Rosen, Himanshu Shah, Giles Heron, Vach Kompella, 6-Mar-09, The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". 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. "VPLS Interoperability with CE Bridges", Dinesh Mohan, Ali Sajassi, 29-Sep-08, 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 IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have currently been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This draft extends the PE model described in RFC 4664 based on IEEE 802.1ad bridge module and illustrates a clear demarcation between IEEE bridge module and IETF LAN emulation module. By doing so, it describes that the majority of interoperability issues with CE bridges can be delegated to 802.1ad bridge module, thus removing the burden on IETF LAN emulation module within a VPLS PE. "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Yuji Kamite, Frederic JOUNAY, Ben Niven-Jenkins, Deborah Brungard, Lizhong Jin, 18-Jan-09, This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, 26-Apr-09, [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes the MAC addresses in the VPLS that does not require relearning due to such topology change. This document defines an extension to MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that needs to be relearned. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa, 5-Mar-09, 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. "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter, 27-Apr-09, This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. "Four-octet AS Specific BGP Extended Community", Yakov Rekhter, Srihari Sangli, Dan Tappan, 26-Mar-09, 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. "IPv6 Address Specific BGP Extended Communities Attribute", Yakov Rekhter, 26-Mar-09, Current specifications of BGP Extended Communities [RFC4360] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 7-Mar-09, Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (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". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 29-Apr-09, More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- "Lemonade Notifications Architecture", Randall Gellens, Stephane Maes, 8-Jul-08, This document discusses how to provide notification and filtering mechanisms to mail stores to meet Lemonade goals. This document also discusses the use of server to server notifications, and how server to server notifications fit into an architecture which provides server to client notifications. Gellens [page 1] Expires January 2009 Internet Draft Lemonade Notifications Architecture July 2008 "The Lemonade Profile", Dave Cridland, Alexey Melnikov, Stephane Maes, 23-Feb-09, This document describes a profile (a set of required extensions, restrictions and usage modes), dubbed Lemonade, of the IMAP, mail submission and Sieve 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 several extensions to IMAP and Mail Submission protocols. "Streaming Internet Messaging Attachments", Neil Cook, 26-Mar-09, This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the URLAUTH authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Extensible Markup Language Evidence Record Syntax", A. Jerman Blazic, Jerman Blazic, Tobias Gondrom, 26-Jan-09, In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)", Thomas Kunz, Susanne Okunick, Ulrich Pordesch, 24-Mar-09, Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time which may be in the past, at the present time or in the future. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 27-Feb-09, 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. "Update to the Language Subtag Registry", Doug Ewell, 25-Feb-09, This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], for use in forming tags for identifying languages. As an Internet-Draft, it also contained a complete replacement of the contents of the Registry to be used by IANA in updating it. To prevent confusion, this material was removed before publication. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic MANET On-demand (DYMO) Routing", Ian Chakeres, Charles Perkins, 8-Mar-09, The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile routers in wireless, multihop networks. DYMO determines unicast routes among DYMO routers within the network in an on-demand fashion, offering improved convergence in dynamic topologies. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, 9-Mar-09, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol. The protocol embodies an optimization of the classical link state algorithm tailored to the requirements of a Mobile Ad hoc NETwork (MANET). "MANET Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, Christopher Dearlove, Justin Dean, 26-Mar-09, This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). "Definition of Managed Objects for the DYMO Manet Routing Protocol", Sean Harnedy, Robert Cole, Ian Chakeres, 24-Feb-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the DYMO routing process. The DYMO MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting routing problems. "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy, 24-Apr-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process. The SMF MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting multicast forwarding problems. MBONE Deployment (mboned) ------------------------- "Unicast-Prefix-based IPv4 Multicast Addresses", Dave Thaler, 9-Mar-09, This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. "IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton, Leo Vegoda, Dave Meyer, 15-Apr-09, This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138. "Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)", Hiroshi Ohta, Hiroaki Satou, Susheela Vaidya, Tsunemasa Hayashi, Haixiang He, 12-Jan-09, This memo presents requirements in the area of accounting and access control for IP multicasting. The scope of the requirements is limited to cases that Authentication, Accounting and Authorization (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). General requirements for accounting and admission control capabilities including quality-of-service (QoS) related issues are listed. This memo assumes that these capabilities can be realized by functions implemented at edges of a network based on IGMP or MLD. 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 this memo. This memo defines requirements related to AAA issues for multi- entity provider models in which the network service provider and content provider cooperate to provide CDS and various related AAA functions for purposes such as protecting and accounting for the access to content and network resources. The requirements are generally not relevant to cases in which there is not a reason to share AAA functions between separate entities. "AAA and Admission Control Framework for Multicasting", Christian Jacquenet, Tsunemasa Hayashi, Haixiang He, Hiroaki Satou, 28-Jan-09, IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network usage are concerned. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services" [I-D.mboned-maccnt-req]. The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination. "Multicast Ping Protocol", Stig Venaas, 2-Dec-08, The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information such as multicast tree setup time. This protocol is based on an implementation of tools called ssmping and asmping. "Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Tatuya Jinmei, Bill Fenner, Stephen Casner, 8-Mar-09, This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. "Requirements for IP Multicast Session Announcement in the Internet", Hitoshi Asaeda, Vincent Roca, 9-Mar-09, The Session Announcement Protocol (SAP) [3] was used to announce information for all available multicast sessions to the prospective receiver in an experimental network. It is easy to use, but not scalable and difficult to control the SAP message transmission in a wide area network. This document describes the major limitations SAP has and the requirements for multicast session announcement in the global Internet. Media Server Control (mediactrl) -------------------------------- "Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 26-Feb-09, This document describes a Framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. 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 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. "An Architectural Framework for Media Server Control", Tim Melanchuk, 27-Nov-08, This document describes an Architectural Framework for Media Server Control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. "SIP Interface to VoiceXML Media Services", Dave Burke, Mark Scott, 8-Feb-09, This document describes a SIP interface to VoiceXML media services. Commonly, application servers controlling media servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.Comments Please send comments on this draft to the MEDIACTRL mail list, mediactrl@ietf.org. "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 2-Mar-09, This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, DTMF collect and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. "A Mixer Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 8-Mar-09, This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 4-Mar-09, This document provides a list of typical Media Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. Mobility EXTensions for IPv6 (mext) ----------------------------------- "Multiple Care-of Addresses Registration", Ryuji Wakikawa, Vijay Devarapalli, George Tsirtsis, Thierry Ernst, Kenichi Nagami, 20-Apr-09, According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that 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 accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. "NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", Wesley Eddy, Will Ivancic, Terry Davis, 20-Jan-09, This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. "AAA Goals for Mobile IPv6", Gerardo Giaretta, Ivano Guardini, Elena Demaria, Julien Bournelle, Rafa Lopez, 2-May-08, In commercial and enterprise 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 (e.g. NAS and AAA server) offers also a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. "Mobile IPv6 Support for Dual Stack Hosts and Routers", Hesham Soliman, 7-Apr-09, The current Mobile IPv6 and NEMO specifications support IPv6 only. 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 home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. "Automotive Industry Requirements for NEMO Route Optimization", Roberto Baldessari, Thierry Ernst, Andreas Festag, Massimiliano Lenardi, 15-Jan-09, This document specifies requirements for NEMO Route Optimization techniques as identified by the automotive industry. Requirements are gathered from the Car2Car Communication Consortium and ISO Technical Committee 204 Working Group 16 (CALM). The document also overviews the current status of ETSI TC ITS, which is going to unify the approaches of these two automotive consortia in a single communication architecture. "Flow Bindings in Mobile IPv6 and Nemo Basic Support", George Tsirtsis, Hesham Soliman, Nicolas Montavont, Gerardo Giaretta, Koojana Kuladinithi, 30-Apr-09, This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct their peers to direct downlink flows to specific addresses. "Mobility Support in IPv6", Dave Johnson, Charles Perkins, Jari Arkko, 9-Mar-09, This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 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 the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, Francis Dupont, Wassim Haddad, 6-Mar-09, 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. "Binding Revocation for IPv6 Mobility", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kuntal Chowdhury, Parviz Yegani, 30-Mar-09, This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. Mobility for IPv4 (mip4) ------------------------ "The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised", Ravindra Rathi, Kent Leung, Hans Sjostrand, 6-Apr-09, 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 Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. "Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz, Vijay Devarapalli, Sri Gundavelli, Brian Haley, 9-Mar-09, This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a new Mobile IPv4 message type designed for this purpose. "The Definitions of Managed Objects for Mobile IP UDP Tunneling", Hans Sjostrand, 23-Feb-09, This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent when Mobile IP Traversal of Network Address Translation (NAT) Devices are used. Mobility for IPv6 (mip6) ------------------------ "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 25-Aug-08, 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 and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. "MIP6-bootstrapping for the Integrated Scenario", Kuntal Chowdhury, Alper Yegin, 21-Apr-08, Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. "DHCP Options for Home Information Discovery in MIPv6", Hee-Jin Jang, Alper Yegin, Kuntal Chowdhury, JinHyeock Choi, 22-May-08, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- "IEEE 802.21 Mobility Services Framework Design (MSFD)", Telemaco Melia, Gabor Bajko, Subir Das, Nada Golmie, Juan Zuniga, 30-Jan-09, This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for mobility service (MoS) discovery and transport layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the mobility service (MoS). Instead, it is assumed that either lower layer (e.g., link layer) security mechanisms, or overall system-specific proprietary security solutions, are used. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", Gabor Bajko, Subir Das, 4-May-09, This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS)[MSFD]. These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in [IEEE802.21]. "Locating IEEE 802.21 Mobility Servers using DNS", Gabor Bajko, 20-Oct-08, This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide IEEE 802.21 [IEEE802.21] defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21 [IEEE802.21], in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [IEEE802.21]. "Fast Handovers for Proxy Mobile IPv6", Hidetoshi Yokota, Kuntal Chowdhury, Rajeev Koodli, Basavaraj Patil, Frank Xia, 1-May-09, Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility when it performs a handover from one access router to another and fast handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered not any different from that of MIPv6. When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network- based mobility management. This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. "Transient Binding for Proxy Mobile IPv6", Marco Liebsch, Ahmad Muhanna, Oliver Blume, 9-Mar-09, This document specifies a mechanism which enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry which is used for inter-MAG handover optimization. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. "Mobile IPv6 Fast Handovers", Rajeev Koodli, 4-Mar-09, Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of 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 (VoIP). 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. This documents updates the packet formats for the Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to Mobility Header Type. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 9-Mar-09, This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of 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). "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Jonathan Rosenberg, 29-Oct-07, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). "An Extension to the Session Description Protocol (SDP) for Media Loopback", Nagarjuna Venna, Paul Jones, Arjun Roychowdhury, Kaynam Hedayat, 18-Feb-09, The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/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, Real-time Text 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, Real-time Text and Video Over IP performance metrics. "Connectivity Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, Gonzalo Camarillo, David Oran, Dan Wing, 9-Mar-09, This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. "SDP Capability Negotiation", Flemming Andreasen, 11-Jul-08, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g. RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and media formats) may be provided in other documents. "SDP media capabilities Negotiation", Robert Gilman, Roni Even, Flemming Andreasen, 26-Feb-09, Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This extension is designed to map easily to existing and future SDP media attributes, but not encodings or formatting. "Source-Specific Media Attributes in the Session Description Protocol (SDP)", Jonathan Lennox, Joerg Ott, Thomas Schierl, 31-Oct-08, The Session Description Protocol provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, identified by their Synchronization Source Identifiers (SSRCs), in SDP, associate attributes with these sources, and express relationships among sources. It also defines several source-level attributes which can be used to describe properties of media sources. "Signaling media decoding dependency in Session Description Protocol (SDP)", Thomas Schierl, Stephan Wenger, 3-Apr-09, This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). "SDP: Session Description Protocol", Mark Handley, 10-Mar-09, 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. "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Brian Stucker, Hannes Tschofenig, 9-Mar-09, Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. "The SDP (Session Description Protocol) Grouping Framework", Gonzalo Camarillo, 13-Jan-09, In this specification, we define a framework to group "m" lines in SDP (Session Description Protocol) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. "Forward Error Correction Grouping Semantics in Session Description Protocol", Ali Begen, 30-Apr-09, The Session Description Protocol (SDP) supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the semantics that was defined in RFC 4756 generally fail to provide the specific grouping relationships between the source and repair flows when there are more than one source and/or repair flows in the same group. Furthermore, the existing semantics does not support describing additive repair flows. This document addresses these issues by introducing new FEC grouping semantics. SSRC-level grouping semantics is also introduced in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. "Negotiation of Generic Image Attributes in SDP", Ingemar Johansson, Kyunghun Jung, 16-Apr-09, This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a e.g a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. "Session Description Protocol (SDP) Extension For Setting Up Audio Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)", Miguel Garcia-Martin, Simo Veikkolainen, 25-Feb-09, This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio media stream over circuit-switched bearers in the Public Switched Telephone Network (PSTN). Message Organization (morg) --------------------------- "IMAP4 Multimailbox SEARCH Extension", Barry Leiba, Alexey Melnikov, 23-Jan-09, The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete. This also introduces mailbox field in ESEARCH responses, allowing a client to pipeline the searches if it chooses. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. "The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions", Arnt Gulbrandsen, 28-Jan-09, The SEARCH=INTHREAD extension extends the IMAP SEARCH command to operate on threads as well as individual messages. Other commands which search are implicitly extended. The THREAD=REFS extension provides a threading algorithm using (almost) only the References header field for use with the IMAP THREAD command. "Display-based Address Sorting for the IMAP4 SORT Extension", Dan Karp, 29-Jan-09, This document describes an IMAP protocol extension enabling server- side message sorting based on the commonly-displayed portion of the From header. "The IMAP SEARCH=ADDRESS Extension", Arnt Gulbrandsen, 30-Jan-09, The SEARCH=ADDRESS extension extends IMAP search to operate on exact addresses and domains. Without this extension, one has to search on substrings and/or do the searching clientside. "IMAP4 Extension for returning STATUS information in extended LIST", Alexey Melnikov, Timo Sirainen, 14-Feb-09, Many IMAP clients display information about total number of messages/ total number of unseen messages in IMAP mailboxes. In order to do that they are forced to issue a LIST or LSUB command, to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. "Additional collation algorithms for use in IMAP and Sieve", Alexey Melnikov, 14-Feb-09, This document defines extra collation that were found useful when searching for text in email messages.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. "IMAP4 Extension for Fuzzy Search", Timo Sirainen, 16-Apr-09, This document describes an IMAP protocol extension enabling server to perform searches with inexact string matching and assigning relevancy scores for matched messages.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. Multiprotocol Label Switching (mpls) ------------------------------------ "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, Thomas Nadeau, Kiran Koushik, 24-Feb-09, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. "MPLS Traffic Engineering Soft Preemption", Denver Maddux, Curtis Villamizar, Amir Birjandi, and Swallow, JP Vasseur, 2-Feb-09, This document specifies Multiprotocol Label Switching (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 reroute request notification 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. "Component Link Recording and Resource Control for TE Link Bundles", Zafar Ali, Dimitri Papadimitriou, 9-Mar-09, 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 Record Route Object (RRO) is not enough for the administrative purpose. Network service A.Zamfir et al. - Expires September 2009 [page 1] Component Link Record. & Resource Control for TE Link Bundles 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 Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, Kireeti Kompella, IJsbrand Wijnands, Bob Thomas, 20-Apr-09, 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. LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. 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. "Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module", Adrian Farrel, Seisho Yasukawa, Thomas Nadeau, 17-Apr-09, 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 point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. "LDP Capabilities", Bob Thomas, Shivani Aggarwal, Rahul Aggarwal, Jean-Louis Le Roux, Cisco Systems, 23-Apr-09, A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. "Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message", JP Vasseur, George Swallow, Ina Minei, 2-Feb-09, The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Path (TE LSP). This document does not define any new protocol extensions. "Security Framework for MPLS and GMPLS Networks", Luyuan Fang, Michael Behringer, 9-Mar-09, This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and [RFC3945]). This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as Inter-AS and Inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. "Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", Zafar Ali, George Swallow, 4-Mar-09, There are many deployment scenarios which require Egress LSR to receive binding of the RSVP-TE LSP to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Mechanism for performing LSP-Ping over MPLS tunnels", Nitin Bahadur, Kireeti Kompella, George Swallow, 1-Feb-09, This document describes methods for performing lsp-ping traceroute over mpls tunnels and for traceroute of stitched mpls LSPs. The techniques outlined in RFC 4379 are insufficient to perform traceroute FEC validation and path discovery for a LSP that goes over other mpls tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. "LDP End-of-LIB", Rajiv Asati, Pradosh Mohapatra, 14-Jan-09, There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. "PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri Papadimitriou, JP Vasseur, 30-Jan-09, This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. "MPLS-TP Requirements", Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher, Satoshi Ueno, 4-Apr-09, This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union (ITU)-IETF effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). This work is based on two sources of requirements; MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T. The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS transport profile is constructed. The requirements are not implementation requirements. "A Framework for MPLS in Transport Networks", Matthew Bocci, Stewart Bryant, Lieven Levrau, 27-Nov-08, This document specifies an archiectectural framework for the application of MPLS in transport networks. It describes a profile of MPLS that enables operational models typical in transport networks networks, while providing additional OAM, survivability and other maintenance functions not currently supported by MPLS. "MPLS Generic Associated Channel", Matthew Bocci, Martin Vigoureux, George Swallow, David Ward, Stewart Bryant, Rahul Aggarwal, 30-Apr-09, This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. "Requirements for OAM in MPLS Transport Networks", Martin Vigoureux, David Ward, Malcolm Betts, 9-Mar-09, This document lists the requirements for the Operations, Administration and Maintenance functionality of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. Architectural, functional and operational requirements are covered in this document. "Requirements for Label Edge Router Forwarding of IPv4 Option Packets", William Jaeger, John Mullooly, Tom Scholl, David Smith, 11-Dec-08, This document imposes a new requirement on Label Edge Routers (LER) specifying that when determining whether to MPLS encapsulate an IP packet, the determination is made independent of any IP options that may be carried in the IP packet header. Lack of a formal standard has resulted in different LER forwarding behaviors for IP packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IP option packets that belong to a prefix-based FEC but fail to be MPLS encapsulated simply due to their header options present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IP packets with header options cannot operate in certain MPLS environments. This new requirement will reduce the risk of IP options-based security attacks against LSRs as well as assist LER operation across MPLS networks which minimize the IP routing information carried by LSRs. "MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, Eric Gray, Adrian Farrel, 16-Apr-09, This document specifies the requirements necessary to manage the elements and networks that support an MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union - Telecommunications Standardization Sector (ITU-T) and Internet Engineering Task Force (IETF) effort to include a MPLS Transport Profile within the IETF MPLS architecture. The requirements are driven by the management functionality needs defined by ITU-T for packet transport networks. Gray, et al Expires October, 2009 [page 1] Internet-Draft MPLS-TP NM Requirements April, 2009 "An Inband Data Communication Network For the MPLS Transport Profile", Dieter Beller, Adrian Farrel, 8-May-09, The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices. The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier grade packet transport network based on MPLS packet switching technology. This document describes how the G-ACh may may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). The document explains how MCN and SCN packets are encapsulated, carried on the G-ACh, and demultiplexed for "MPLS-TP OAM Framework and Overview", Italo Busi, Ben Niven-Jenkins, 26-Mar-09, Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is based on a profile of the MPLS and pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document provides a framework that supports a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. "Multiprotocol Label Switching Transport Profile Survivability Framework", Nurit Sprecher, Adrian Farrel, Himanshu Shah, 6-Apr-09, Network survivability is the network's ability to restore traffic following failure or attack; it plays a critical factor in the delivery of reliable services in transport networks. Guaranteed services in the form of Service Level Agreements (SLAs) require a resilient network that detects facility or node failures very rapidly, and immediately starts to restore network operations in accordance with the terms of the SLA. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet transport technology that combines the packet experience of MPLS with the operational experience of transport networks like SONET/SDH. It provides survivability mechanisms such as protection and restoration, with similar function levels to those found in established transport networks such as in SONET/SDH networks. Some of the MPLS-TP survivability mechanisms are data plane-driven and are based on MPLS-TP OAM fault management functions which are used to trigger protection switching in the absence of a control plane. Other survivability mechanisms utilize the MPLS-TP control plane. This document provides a framework for MPLS-TP survivability. Multicast Security (msec) ------------------------- "Updates to the Group Domain of Interpretation (GDOI)", Brian Weis, Sheela Rowles, 9-Mar-09, This memo describes updates to the Group Domain of Interpretation (GDOI) . It provides clarification where the original text is unclear. It also includes adds several new algorithm attribute values, including complete support for algorithm agility. "Use of TESLA in the ALC and NORM Protocols", Vincent Roca, Aurelien Francillon, Sebastien Faurite, 17-Dec-08, This document details the TESLA packet source authentication and packet integrity verification protocol and its integration within the ALC and NORM content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian Weis, 5-Mar-09, Advanced Encryption Standard (AES) counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of AES counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. Network Endpoint Assessment (nea) --------------------------------- "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", Ravi Sahita, Stephen Hanna, Kaushik Narayan, 17-Apr-09, This document specifies PB-TNC, a Posture Broker Protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. "PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC", Kaushik Narayan, 17-Apr-09, This document specifies PA-TNC, a Posture Attribute Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. Network Configuration (netconf) ------------------------------- "Partial Lock RPC for NETCONF", Balazs Lengyel, Martin Bjorklund, 19-Feb-09, The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. "NETCONF Monitoring Schema", Mark Scott, Sharon Chisholm, Martin Bjorklund, 9-Mar-09, This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, subscriptions, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. "With-defaults capability for NETCONF", Andy Bierman, Balazs Lengyel, 6-Apr-09, The NETCONF protocol defines ways to read configuration data from a NETCONF agent. Part of this data is not set by the NETCONF manager, but rather a default value is used. In many situations the NETCONF manager has a priori knowledge about default data, so the NETCONF agent does not need to send it to the manager. In other situations the NETCONF manger will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF manager to control whether default values are part of NETCONF messages. "NETCONF Configuration Protocol", Rob Enns, Martin Bjorklund, Juergen Schoenwaelder, 4-Mar-09, The Network Configuration Protocol (NETCONF) 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. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "IPv4 Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, 23-Apr-09, This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. "GRE Key Option for Proxy Mobile IPv6", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kent Leung, 5-May-09, This specification defines a new Mobility Option for allowing the mobile access gateway and the local mobility anchor to negotiate GRE (Generic Routing Encapsulation) encapsulation mode and exchange the downlink and uplink GRE keys which are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. "Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Rajeev Koodli, Heeseon Lim, Nishi Kant, Suresh Krishnan, Julien Laganier, 9-Apr-09, Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. "Interactions between PMIPv6 and MIPv6: scenarios and related issues", Gerardo Giaretta, 1-May-09, The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols are both deployed in a network require some analysis and considerations. This document describes all identified possible scenarios, which require an interaction between PMIPv6 and MIPv6 and discusses all issues related to these scenarios. Solutions and recommendations to enable these scenarios are also described. NETCONF Data Modeling Language (netmod) --------------------------------------- "YANG - A data modeling language for NETCONF", Martin Bjorklund, 19-Apr-09, YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. "Common YANG Data Types", Juergen Schoenwaelder, 9-Mar-09, This document introduces a collection of common data types to be used with the YANG data modeling language. "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", Ladislav Lhotka, Rohan Mahy, Sharon Chisholm, 29-Apr-09, This draft describes the mapping rules for translating YANG data models into XML schemas using Document Schema Definition Languages (DSDL) and outlines the procedure for validating various types of NETCONF protocol data units using these schemas. "An Architecture for Network Management", Philip Shafer, 3-Mar-09, NETCONF and YANG are pieces of an ambitious plan to improve network management. NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content trafficked via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network services providers. Network File System Version 4 (nfsv4) ------------------------------------- "Remote Direct Memory Access Transport for Remote Procedure Call", Thomas Talpey, Brent Callaghan, 4-Dec-08, A protocol is described providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (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", Thomas Talpey, Brent Callaghan, 16-Apr-08, This draft defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4 and 4.1 over such an RDMA transport. "NFS Version 4 Minor Version 1", Spencer Shepler, Mike Eisler, David Noveck, 15-Dec-08, This document describes NFS version 4 minor version one, including features retained from the base protocol (NFS version 4 minor version zero which is specified in RFC3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version one include: Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version one has no dependencies on NFS version 4 minor version zero, and is considered a separate protocol. Thus this document neither updates nor obsoletes RFC3530. NFS minor version one is deemed superior to NFS minor version zero with no loss of functionality, and its use is preferred over version zero. Both NFS minor version zero and one can be used simultaneously on the same network, between the same client and server. "pNFS Block/Volume Layout", David Black, Stephen Fridella, Jason Glasgow, 23-Dec-08, 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, Brent Welch, Jim Zelenka, 15-Dec-08, 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, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor Version 1 specify a layout-type-independent layer; layout-type-specific information is conveyed using opaque data structures which internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-based pNFS Layout Type in companion with the main NFSv4 Minor Version 1 specification. "NFSv4 Minor Version 1 XDR Description", Spencer Shepler, Mike Eisler, David Noveck, 15-Dec-08, This Internet-Draft provides the XDR description for NFSv4 minor version one. "IANA Considerations for RPC Net Identifiers and Universal Address Formats", Mike Eisler, 30-Jan-09, This Internet-Draft lists IANA Considerations for RPC Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This Internet-Draft updates, but does not replace, RFC1833. "Administration Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 6-Mar-09, This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Requirements for Federated File Systems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 20-Apr-09, This document describes and lists the functional requirements of a federated file system and defines related terms. "NSDB Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 20-Feb-09, This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "NFSv4.0 XDR Description", Thomas Haynes, 2-Apr-09, This Internet-Draft provides the XDR description for NFS version 4.0. "Network File System (NFS) version 4 Protocol", Thomas Haynes, 2-Apr-09, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3530 as the definition of the NFS version 4 protocol. Individual Submissions (none) ----------------------------- "Salted Challenge Response (SCRAM) SASL Mechanism", Abhijit Menon-Sen, Alexey Melnikov, Chris Newman, Nicolas Williams, 30-Mar-09, The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. "Cisco Systems' Simple Certificate Enrollment Protocol", Andy Nourse, Xiaoyi Liu, J Vilhuber, Cheryl Madson, 21-Jan-09, This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 23-Jan-07, This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC provides advanced and feature rich conferencing services with security as main design principal. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other specifications 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, 19-Jan-07, This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [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, 19-Jan-07, 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. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol supports passphrase (pre-shared secret) authentication and public key (and certificate) authentication based on digital signatures. "LDAP Transactions", Kurt Zeilenga, 19-Dec-08, 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. 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. This document extends LDAP to support transactions. "Diversion Indication in SIP", Stuart Levy, Bryan Byerly, John Yang, 1-May-09, This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. "Multicast in MPLS/BGP IP VPNs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 31-Dec-08, This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems. "SILC Commands", Pekka Riikonen, 19-Jan-07, 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. "Multicast DNS", Stuart Cheshire, Marc Krochmal, 11-Sep-08, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. ""duri" and "tdb" URN namespaces based on dated URIs", Larry Masinter, 3-Feb-09, This document defines two namespaces of URNs, based on using a timestamp with an (encoded) URI. The results are namespaces in which names are readily assigned, offer the persistence of reference that is required by URNs, but do not require a stable authority to assign the name. The first namespace ("duri") is used to refer to URI- identified resources as they appeared at a particular time. The second namespace ("tdb") is useful as a way of creating URNs that refer to physical objects or even abstractions that are not themselves networked resources. The definition of these namespaces may reduce the need to define new URN namespaces merely for the purpose of creating stable identifiers. In addition, they provide a ready means for identifying "non- information resources" by semantic indirection. Note This document is not a product of any working group. Many of the ideas here have been discussed since 2001. This document has been discussed on the mailing list . "Requirements for Replacing AppleTalk", Stuart Cheshire, Marc Krochmal, 17-Nov-08, One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement. "Compressed Data within an Internet EDI Message", Terry Harding, 27-Aug-08, This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. "Analysis of Inter-Domain Routing Requirements and History", Elwyn Davies, Avri Doria, 16-Feb-09, This document analyses the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical concensus of the research group at the date of publication. [Note to RFC Editor: Please replace the reference in the abstract with a non-reference quoting the RFC number of the companion document when it is allocated, i.e., '(RFC xxxx)' and remove this note.] "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Dan Petrie, Alan Johnston, 5-Mar-09, This document defines a framework and requirements for call control and 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 that embody the spirit of SIP applications as used on the Internet. "An IPv4 Flowlabel Option", Thomas Dreibholz, 7-Jan-09, 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. "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, 19-Jan-07, 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. "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. "EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 2-Feb-09, This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). "Session Initiation Protocol Call Control - Transfer", Robert Sparks, Alan Johnston, 3-Mar-09, 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. "Split Multi-link Trunking (SMLT)", Roger Lapuh, Dinesh Mohan, Richard Mcgovern, 8-Jul-08, 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 aggregationsubnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC3768]. 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. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 7-Jan-09, This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "A Framework for Session Initiation Protocol User Agent Profile Delivery", Sumanth Channabasappa, 13-Feb-08, This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) User Agents in SIP deployments. The framework provides a means to deliver profile data that User Agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP User Agents can discover sources, request profiles and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "Sieve Email Filtering: Include Extension", Cyrus Daboo, Aaron Stone, 9-Mar-09, The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, as well as supporting common 'libraries' of scripts. Users are able to include their own personal scripts or site-wide scripts provided by the local Sieve implementation. Change History (to be removed prior to publication as an RFC) Changes from -05 to -06: a. Aaron Stone joins as author. b. Removed | characters from the script examples. c. Updated draft references to published RFCs. Changes from -04 to -05: a. Fixed examples. b. Relaxed requirement that imported/exported variables be set before being used. Changes from -03 to -04: a. Fixed missing 2119 definitions. b. Defined interaction with variables through use of import and export commands. Changes from -02 to -03: a. Refreshing expired draft (updated for nits). b. Syntax -> Usage. c. Updated to 3028bis reference. Changes from -01 to -02: a. Minor formatting changes only - refreshing expired draft. Changes from -00 to -01: a. Added IPR boiler plate. b. Re-ordered sections at start to conform to RFC style. c. Moved recursion comment into General Considerations section. d. Switched to using optional parameter to indicate personal vs global. e. Explicitly state that an error occurs when a missing script is included.Open Issues (to be resolved prior to publication as an RFC) a. Interaction with variables (scoping). Should variables be carried over between scripts that are included? Or should variables defined in an included script be local to that script only? "GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)", Alexandr Afanasiev, Nikolaj Nikishin, Boleslav Izotov, Elena Minaeva, Serguei Murugov, Igor Ustinov, Anatolij Erkin, Grigorij Chudov, Serguei Leontiev, 8-Dec-08, This document is intended to register new cipher suites for the Transport Layer Security (TLS) protocol, according to the procedure specified in TLS Protocol standards. 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. "A Set of Possible Requirements for a Future Routing Architecture", Avri Doria, Elwyn Davies, Frank Kastenholz, 16-Feb-09, The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. "Connection Reuse in the Session Initiation Protocol (SIP)", Vijay Gurbani, Rohan Mahy, Brett Tate, 9-Mar-09, This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. "TTL-Based Security Option for the LDP Hello Message", Enke Chen, Albert Tian, 9-Mar-09, 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. "Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", Sanjib HomChaudhuri, Marco Foschiano, 19-Aug-08, This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead. Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home basement networks) are mentioned in the following to exemplify its possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", Aki Niemi, Krisztian Kiss, Salvatore Loreto, 22-Feb-09, This memo specifies the throttle, forge and average mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages, but in particular the throttle mechanism is especially designed to be used in combination with a subscription to a Resource List Server (RLS). "PATCH Method for HTTP", Lisa Dusseault, James Snell, 13-Apr-09, Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. "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. "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. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Marc Blanchet, Florent Parent, 6-May-08, 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. "An Extension for EAP-Only Authentication in IKEv2", Pasi Eronen, Hannes Tschofenig, Yaron Sheffer, 6-Apr-09, 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 methods other than public key signatures. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 20-Apr-09, 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. "Using GOST 28147-89, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms for XML Security", Serguei Leontiev, Pavel Smirnov, Aleksandr Chelpanov, 28-Jan-09, This document specifies how to use Russian national cryptographic standards GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94 with XML Signatures, XML Encryption, WS-SecureConversation, WS- SecurityPolicy and WS-Trust. A number of Uniform Resource Identifiers (URIs) and XML elements are defined. "DNS Blacklists and Whitelists", John Levine, 17-Nov-08, 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 the 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. IRTF Notice This document is a product of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force. It represents the consensus of the ASRG with respect to practices to improve interoperability of DNS based blacklists and whitelists, but does not constitute an IETF or Internet standard. [NOTE TO RFC EDITOR: Please remove this paragraph in publication.] Comments and discussion may be directed to the ASRG mailing list, asrg@irtf.org. "Guidelines for Management of DNSBLs for Email", Chris Lewis, Matt Sergeant, 17-Nov-08, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists ("DNSBLs") of IP addresses or domain names intended to help guide email filtering. This memo discusses guidelines for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list. "RADIUS Error Messages", Glen Zorn, 17-Nov-08, This document describes new RADIUS protocol elements designed to allow the communication of packet and attribute errors between RADIUS servers and clients. "Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07, In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. "Internet Mail Architecture", Dave Crocker, 12-Apr-09, Over its thirty-five year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants must work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. "IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07, This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. "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. "Vendor Specific RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, Tiebing Zhang, Jesse Walker, Joseph Salowey, 6-Mar-09, This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. "Extending the Space Available for TCP Options", Wesley Eddy, Adam Langley, 1-Jul-08, 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. "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. "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. "The IPvLX Architecture", Fred Templin, 11-May-07, The IETF has embraced IPv6 as the next-generation Internet protocol, but global IPv4 deployment continues in private addressing domains behind Network Address Translators (NATs). This document envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as identifiers (and sometimes also locators) and IPv4 addresses serving as locators (and sometimes also identifiers). This document proposes an architectural framework for IPv6/IPv4 coexistence called: "IPvLX (IP with virtual Link Extension)". "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 8-Mar-09, This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The documents summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. "Using Kerberos V5 over the Transport Layer Security (TLS) protocol", Simon Josefsson, 9-Mar-09, This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features. This document updates RFC 4120. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 8-Jul-08, 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 "The "OpenPGP" mail and news header field", Atom Smasher, Simon Josefsson, 20-May-08, This document describes the "OpenPGP" mail and news header field. The field provide information about the sender's OpenPGP key. See for more information. "Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 14-Apr-09, The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). "VoIP Configuration Server Address Option", Richard Johnson, 6-Jan-09, This memo documents existing usage for the "VoIP Configuration Server Address Option" (previously known as the "TFTP Server IP Address Option"). The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942 [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "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. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, Henning Schulzrinne, Srisakul Thakolsri, Wolfgang Kellerer, 18-Nov-07, Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is intended as an informational document. "The 'mailto' URI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 9-Mar-09, This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Magnus Westerlund, Per Frojdh, 8-May-09, 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. "Unintended Consequence of two NAT deployments with Overlapping Address Space", Pyda Srisuresh, Bryan Ford, 23-Mar-09, This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. "Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07, The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP). "Multiple Attachments for EDI-INT", Kyle Meadors, 15-Dec-08, The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided. "Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004", Chih-Chang Hsu, 22-Jul-05, In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a protocol intended for small group multicasting. It combined three similar datagram simulcasting protocols that were submitted as earlier Internet Drafts by a number of different research groups. After that, researchers in those groups worked together to further develop, experiment and conduct standardization in IETF as well as in the open source community. This resulted in several implementations of protocol stacks, systems of multi-party video conference and group management, and mechanisms for harmonizing XCAST with ASM and SSM. In addition, an XCAST backbone for various experiments has been launched to operate inter-continentally. One of the main purposes of this document is to summarize the efforts undertaken by XCAST community as "best current practices" that would then be formally introduced to the IETF/IRTF community. In addition, we raise an issue concerning IANA resource allocation, which prevents us from widely expanding our experimental networks as well as distributing our software. Finally, we request IESG and other experts to check the validity of our proposed protocol and make any suggestions about how IANA can assign appropriate resources accordingly. "SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 27-Mar-06, The CAPWAP problem statement [3] describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another. "An Extensible Format for Email Feedback Reports", Yakov Shafranovich, John Levine, Murray Kucherawy, 17-Apr-09, This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. "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. "The 'news' and 'nntp' URI Schemes", Frank Ellermann, 2-Apr-08, This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on standards track. "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. "Bundle Security Protocol Specification", Susan Symington, Stephen Farrell, Howard Weiss, Peter Lovell, 23-Mar-09, This document defines the bundle security protocol, which provides data integrity and confidentiality services. We also describe various bundle security considerations including policy options. "Distributing Address Selection Policy using DHCPv6", Tomohiro Fujisaki, Arifumi Matsumoto, Shirou Niinobe, Ruri Hiromi, Ken-ichi Kanayama, 9-Mar-09, This document describes a new DHCPv6 option for distributing address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior. "Location Conveyance for the Session Initiation Protocol", James Polk, Brian Rosen, 9-Mar-09, This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent clients. "Using non-ASCII Characters in RFCs", Xiaodong Faltstrom, Paul Hoffman, Tim Bray, 14-Apr-09, This document specifies a change to the IETF process in which Internet Drafts and RFCs are allowed to contain non-ASCII characters. The proposed change is to change the encoding of Internet Drafts and RFCs to UTF-8 when non-ASCII characters are needed. "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. "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, 7-Jan-09, 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. "RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, 29-Apr-09, RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks. The attributes defined in this document are usable both within RADIUS and Diameter. "Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris Cross, 31-Jul-07, 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. "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Cullen Jennings, 11-May-09, The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. 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 from the User Agent to its Registrar. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 7-Jan-09, 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 RFC4960, it is designed to integrate cryptographic functions into SCTP. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 9-Oct-08, 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. "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 17-Nov-08, This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. "Operational Reliability for EDIINT AS2", John Duker, Dale Moberg, 24-Apr-09, The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. "Link Adaptation for IPv6-in-(foo)*-in-IPv4 Tunnels", Fred Templin, 14-May-07, IPv6-in-(foo)*-in-IPv4 tunnels must support a minimum Maximum Transmission Unit (MTU) of 1280 bytes for IPv6 via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document specifies a link adaptation mechanism for IPv6-in-(foo)*-in- IPv4 tunnels that presents an assured MTU to the IPv6 layer using tunnel endpoint-based segmentation/reassembly and dynamic segment size probing. "EDI-INT Features Header", Kyle Meadors, 1-Oct-08, With the maturity of the EDI-INT standard of AS1, AS2 and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDI-INT applications and could cause potential problems with implementations. "HIP DHT Interface", Jeff Ahrenholz, 9-Mar-09, This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service. "Enhanced Fast Handover for Mobile IPv6 based on IEEE 802.11 Network", Youngsong Mun, 20-Feb-09, 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. "Delay-Tolerant Networking Security Overview", Stephen Farrell, Susan Symington, Howard Weiss, Peter Lovell, 8-Mar-09, 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 its purpose is mainly to document design decisions. "MTLS: (D)TLS Multiplexing", Mohamad Badra, Ibrahim Hajjeh, 21-Apr-09, The (Datagram) Transport Layer Security ((D)TLS) standard provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex several application data over a single (D)TLS. This document defines MTLS, an application-level protocol running over (D)TLS Record protocol. The MTLS design provides application multiplexing over a single (D)TLS session. Therefore, instead of associating a (D)TLS session with each application, MTLS allows several applications to protect their exchanges over a single (D)TLS session. "Password-Authenticated Diffie-Hellman Exchange (PAK)", Igor Faynberg, Sarvar Patel, Zachary Zeltsan, Alec Brusilovsky, 10-Apr-09, 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. PAK provides Forward Secrecy. "Moving Forwards with IETF Process Evolution", Elwyn Davies, 26-Oct-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. "A User Agent Profile Data Set for Media Policy", Volker Hilt, Gonzalo Camarillo, Jonathan Rosenberg, 7-Mar-09, This specification defines a document format for the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in a session. This document format is based on XML and extends the Schema for SIP User Agent Profile Data Sets. It can be used to describe the properties of a specific SIP session or to define policies that are then applied to different SIP sessions. "Privacy Aspects Terminology", Wassim Haddad, Erik Nordmark, 26-Dec-08, This memo introduces 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. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 3-Mar-09, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol works by arranging 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. 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 briefly gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion,and these are described more fully in a companion document [re-ecn-motive]. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. Changes from previous drafts (to be removed by the RFC Editor) Full diffs created using the rfcdiff tool are available at From -06 to -07 (current version): Major changes made following splitting this protocol document from the related motivations document [re-ecn-motive]. Significant re-ordering of remaining text. New terminology introduced for clarity. Minor editorial changes throughout. "IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard, 5-Oct-08, This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services. "DTCP: Dynamic Tasking Control Protocol", David Cavuto, 19-Nov-08, Dynamic Tasking Control Protocol is a message-based 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. "RTCP-XR Summary", Alan Clark, Amy Pendleton, Alan Johnston, Henry Sinnreich, 5-Mar-09, 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. "SIP Interface to VoiceXML Media Services", Dave Burke, 12-Jul-07, This document describes a SIP interface to VoiceXML media services, which is commonly employed between application servers and media servers offering VoiceXML processing capabilities. "Extending ICMP for Interface and Next-hop Identification", Alia Atlas, Ronald Bonica, Nuova Systems, Naiming Shen, Enke Chen, 3-Nov-08, This memo defines ICMP extensions, using ICMP multi-part messages, through which a router or host can explicitly identify an interface by ifIndex, name, and/or address, as already used in MIBs and by OSPF. The interfaces so identified can be the interface upon which an undeliverable datagram arrived, a sub-IP member of that interface, and the interface through which the datagram would have been sent. The nexthop IP address can also be provided as part of the outgoing interface information. The extensions defined herein are particularly useful when troubleshooting networks with unnumbered interfaces, parallel interfaces and/or asymmetric routing. "OCRA: OATH Challenge-Response Algorithms", David M'Raihi, Salah Machani, Johan Rydell, David Naccache, Siddharth Bajaj, 9-Jan-09, This document describes the OATH algorithm for challenge-response authentication and signatures. This algorithm is based on the HOTP algorithm [RFC4226] that was introduced by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF in 2006. "Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 6-Apr-09, 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 needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. 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. "The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 17-Feb-09, A package is a logical entity that holds a collection of 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. "Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ Housley, 10-Sep-07, This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information is exchanged in the supplemental data handshake message. "Accounting on Softwires", Bruno Stevant, Laurent Toutain, Francis Dupont, David Binet, 20-Apr-09, 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.1. Motivation The Softwires WG is working on a solution to bring IPvX connectivity over an IPvY network [RFC4925]. This solution may be deployed and managed by access network operators to provide for example IPvX continuity of service. Operators should then consider the Softwires solution as an extension of their access network service. For operators, AAA [RFC2865] is the key feature for access network deployment: Authentication verifies user credentials, Authorization ensures access network integrity and Accounting provides information for billing and network management. Information from accounting usually includes measurements of in and out octets and packets [RFC2867]. As an alternative access network, the Softwires solution should provide similar AAA features. For instance accounting on the softwire should gives to the operator measurements of the traffic generated by the user using this access network. In a dual stack (IPvX and IPvY) network, the operator may want to manage information about the comparative usage of both protocols, for example for billing purpose. When the softwire is used to access IPvX over IPvY, accounting information will be specific to IPvX. Operators should be able to differentiate for which version of IP such information are relevant. This differentiation may become important if such operators offer a softwire solution for both IPvX over IPvY and IPvY over IPvX access networks.2. Study case In this section is given an example of IPv6 access over IPv4 network which is similar to the Hub-and-Spokes problem stated in the Softwires WG ([RFC4925]). The Point6box architecture uses L2TP [RFC2661] and PPP for IPv6 tunneling over IPv4 (see Figure 1). Radius manages AAA parameters for the access network created by the tunnel. On the server side, PPP sends to RADIUS accounting information measuring the traffic generated by the customer. /---------------------------\ CPEv6 | +--------------+ | DHCPv6 +-----+ | /....>| DHCPv6 relay |<........................>| P | | . +--------------+ | CPEv4 | o | | | . | L2TP IPv6 | | L2TP +-----+ | i | |-- X | . | server |=======================b=== n B | | | v +--------------+ | @@ @@ | r| | t o | | | +--------+ ^ | @ @@ @ | N i|-| 6 x | |-- Y | | DHCPv6 | | |--@ IPv4 @------| A d| +-----+ | | | server | | | @ @@ @ | T g| | | +--------+ | | @@ @@ PEv4 | e|----------| \-------------|-------------/ +-----+ RA-> |-- Z | PEv6 | +--------+ | clients | RADIUS | | RADIUS | server |<-/ +--------+ IPv4/v6 ISP Customer Figure 1: Point6Box Service Architecture3. Problem statement The accounting information defined for tunnels [RFC2867] includes attributes Acct-{Input,Output}-Octets and Acct-{Input,Output}-Packets for traffic measurements. These attributes do not depend of the version of IP used by the monitored traffic. Operators may not be able to differenciate IPv4 from IPv6 traffic in their accounting statistics. This non-differentiation even leads to mis-usages: In the current PPP implementation from BSD, the values of these attributes are only based on IPv4 statistics collected from IPCP protocol. No statistics are collected for IPv6 from IPV6CP. This proposal should decide which attributes may be candidate for IP- version differentiation. In operating system MIBs, values for in/out octets on a network interface are independent of the IP version. Having such values for each version may be usefull for monitoring and billing purpose. However the differentiation is done for in/out IPv4 and IPv6 packets on a network interface. Operators can extract from these values some hints about the usage of each version of the IP protocol but can not give quantitative report of bandwidth usage. "BR Organization Mapping for the Extensible Provisioning Protocol (EPP)", Frederico Neves, Hugo Koji Kobayashi, 24-Aug-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. "Encrypted Key Transport for Secure RTP", David McGrew, Flemming Andreasen, Lakshminath Dondeti, 9-Mar-09, 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. "4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions", Jianping Wu, Yong Cui, Xing Li, Mingwei Xu, Chris Metz, 14-Apr-09, The emerging and growing deployment of IPv6 networks, in particular IPv6 backbone networks, will introduce cases where connectivity with IPv4 networks is desired. In one such case, an Internet Service Provider (ISP) operating an IPv6 backbone network will accomodate connectivity and offer transit services for attached legacy IPv4 networks and applications. This is accomplished through the use of IPv4-over-IPv6 (4over6) tunnels established between dual-stack IPv4/ IPv6 edge routers. Along with the growth of IPv6 backbones networks and the corresponding increase in the number of attached IPv4 networks, the complexity of the interconnection tunnel topology will severely increase to support the IPv4 transit service across the backbone. The manual configuration mechanism for a potentially large number of IPv4-over-IPv6 tunnels will cause an insufferable operational burden. This document addresses this problem and presents a mechanism for the automatic discovery and creation of 4over6 tunnels employing multi-protocol BGP extensions. The mechanisms described in this document have been implemented, tested and deployed on the CNGI-CERNET2 IPv6 testbed. "The Qpopper MIME Mangling and Macro Extensions to POP3", Randall Gellens, 17-Nov-08, This document describes two extensions to the POP protocol that have been supported for several years by some client and servers. One extension, 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 for the message to be transcoded to a different character set. The other extension, MACRO, allows clients to define macros which are expanded when used, saving repetitive transmissions. The MANGLE extension has been useful in at least two situations: it allows clients on constrained devices to avoid downloading body parts which cannot be used on the device, and clients which use the TOP command to "peek" at messages can have the preview transformed into more usable content, as well as avoiding the transmission of undesired headers. The MACRO extension has been especially useful in conjunction with MANGLE, since a MANGLE request can become relatively lengthy. "WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 1-Dec-08, Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client 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 Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2 "Media Server Markup Language (MSML)", Garland Sharratt, Adnan Saleem, 3-Feb-09, 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. "Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli, 27-Jan-09, Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Organizing IETF Process Change", Elwyn Davies, 13-Jun-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. "ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 4-Mar-09, This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. "A New Forking Mechanism for Session Initiation Protocol (SIP)", Dale Worley, 3-Mar-09, 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 an alternative forking mechanism that better supports "one to many" requests, and that mechanism be the standardized meaning of the (existing but weakly specified) "Request-Disposition: no-cancel, parallel" header. "DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 30-Jan-09, The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not specify how a validating stub resolver should communicate results of DNSSEC processing back to the application. This document describes an API between applications and a validating stub resolver that allows applications to control the DNSSEC validation process and obtain results of DNSSEC processing. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 7-Jan-09, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). "Fast Initial OSPFv2 LSDB Synchronization for BMA", Mitchell Erblich, 27-Mar-06, This memo documents a feature that significantly decreases the initial LSDB synchronization time in Broadcast Multiple Access (BMA) environments. This implementation only requires a single OSPF speaker per psuedo-node to support this functionality. These changes are implicitly supported within the OSPFv2 protocol. This memo is not intended to serve as a model for any other implementation. "Access Right Distribution Protocol (ARDP)", Alexandre Cassen, 12-Jan-09, This document describes a protocol using multicast to securely distribute IPTV management elements such as IPTV customer's access rights. The protocol typically runs on any piece of equipments to locally store owned customers IPTV service access right. This design provides access control at edge level. "Limited IP Header Compression over PPP", Janusz Jurski, 8-Mar-07, The negotiation options specified in RFC 2509 defined an all-or-nothing strategy for applying header compression: peers were assumed to support compression for any combination of headers. [RFC3544] refined that strategy to make it possible to negotiate header compression for only TCP or only non-TCP packets (and also added Enhanced RTP-Compression negotiation option). The current document further refines the strategy by also making it possible to negotiate header compression for only particular combinations of headers or header types. "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 7-Jan-09, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.", Volker Hilt, Gonzalo Camarillo, 12-Jul-08, This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. "The use of AES-192 and AES-256 in Secure RTP", David McGrew, 5-Mar-09, This memo describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It defines Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. "Certificate Management Service for The Session Initiation Protocol (SIP)", Cullen Jennings, Jason Fischl, 3-Nov-08, This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event 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, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. "Virtual Enterprise Traversal (VET)", Fred Templin, 13-Apr-09, Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including SOHO networks, Mobile Ad-hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. "Secure Beacon: Securely Detecting a Trusted Network", Yaron Sheffer, Yoav Nir, 21-Jan-08, Remote access clients, in particular IPsec-based ones, are heavily deployed in enterprise environments. In many enterprises the security policy allows remote-access clients to switch to unprotected operation when entering the trusted network. This document specifies a method that lets a client detect this situation in a secure manner, with the help of a security gateway. We propose a minor extension to IKEv2 to achieve this goal. "Web Linking", Mark Nottingham, 16-Apr-09, This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field. "Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 6-Mar-09, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. "Diameter Credit Control Application MIB", Glen Zorn, Subash Comerica, 6-Mar-09, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application. "SIP SAML Profile and Binding", Hannes Tschofenig, Jeff Hodges, Jon Peterson, James Polk, Douglas Sicker, 9-Mar-09, 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)". "Considerations for Information Services and Operator Services Using SIP", John Haluska, Renee Berkowitz, Paul Roder, Wesley Downum, Richard Ahern, Paul Lung, Nicholas Costantino, Chris Blackwell, Jim Mellinger, 15-Dec-08, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to reproduce the current PSTN behaviour. "Reporting Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 8-Jan-09, Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. The memo then proceeds to discuss "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds). "Identifying and Reacting to Unsolicited DNS Queries", Peter Koch, 9-Mar-09, This document deals with unsolicited Domain Name System (DNS) queries directed towards authoritative name servers. It identifies reasons for the existence of these queries and lists some observed or proposed reactions. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, 8-Mar-09, [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes the MAC addresses in the VPLS that does not require relearning due to such topology change. This document defines an extension to MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that needs to be relearned. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "DHCP Option for LDAP Directory Services discovery", Giuseppe Paterno, 28-Sep-06, This document defines an experimental DHCP option for delivering configuration information for LDAP services. Through this option, the client receives an LDAP URL [8] of the closest available LDAP server/replica that can be used to authenticate users or look up any useful data. "Definitions for TCP Connection Metrics", Terry Brugger, 17-Aug-06, Numerous metrics, or features, have been used to describe TCP connections. These features are frequently of interest to the network intrusion detection community, and occasionally the network engineering community. While researchers may understand these terms when used by others, there are no formal definitions of these terms such that two researchers looking at the same connection will necessarily calculate the same values for all the metrics. This paper will propose a potential set of connection metrics with formal definitions of each. "Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD", Martin Thomson, James Winterbottom, 14-Jan-09, A framework for the exchange of capabilities in HELD is described. Capabilities for enabling device-based measurements and device-based location generation are defined based on this framework. "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", Susan Symington, Robert Durst, Keith Scott, 2-Feb-09, This document defines an encapsulation-specific application agent capability and a bundle payload format for use with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines the capability and format for placing one or more bundles inside of the payload field of an encapsulating bundle's Bundle Payload Block. "DTLS transport mapping for SYSLOG", Tom Petch, Rainer Gerhards, 31-Mar-09, This document describes the transport of syslog messages over DTLS (Datagram Transport Level Security). It provides a secure transport for syslog messages in cases where a connection-less transport is desired. "Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 24-Mar-09, This document defines an extension block that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide its endpoint ID (EID) to the next-hop receiving node. Knowledge of the EID of a previous-hop node may be required in some circumstances to support certain routing protocols (e.g., flood routing). The Previous Hop Insertion block is always removed from the bundle by the receiving node so that it's duration within the bundle lasts for exactly one hop. This document defines the format and processing of this Previous Hop Insertion Block. "The Hypertext Transfer Protocol (HTTP) Entity Tag ("ETag") Response Header in Write Operations", Julian Reschke, 2-Mar-09, The Hypertext Transfer Protocol (HTTP) specifies a state identifier, called "Entity Tag", to be returned in the "ETag" response header. However, the description of this header for write operations such as PUT is incomplete, and has caused confusion among developers and protocol designers, and potentially interoperability problems. This document explains the problem in detail and suggests both a clarification for a revision to the HTTP/1.1 specification (RFC2616) and a new header for use in responses, making HTTP entity tags more useful for user agents that want to avoid round-trips to the server after modifying a resource. "Automatic Telephone Configuration Protocol", Bernd Buxmann, Ralf Hintner, 16-Aug-06, This document is about the Automatic Telephone Configuration Protocol (ATCP). ATCP provides a framework for passing configuration information to SIP-telephones in a Voice over IP-network and to register users in the network. ATCP needs DHCP for configuring the telephones with TCP/IP-networkparameters (e.g. IP-address). "Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Henning Schulzrinne, Hannes Tschofenig, Martin Thomson, Singh Vishal, 9-Mar-09, The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. The PIDF-LO specification made a subset of the functionality offered by the Geography Markup Language (GML) standard 3.0 mandatory to implement. This document defines child elements to the element specified in RFC 4119 to carry temporal feature elements useful for tracking moving objects. Elements are defined that enable expression of speed, heading, acceleration and facing of the presentity. "Transporting User to User Call Control Information in SIP for ISDN Interworking", Alan Johnston, Joanne McMillen, 12-Feb-09, Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document discusses requirements and approaches and recommends a new header field be standardized. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is an Automatic Call Distributor (ACD) in a contact center. "IPv6 Dynamic Flow Label Switching (FLS)", Martin Beckman, 22-Mar-07, This document seeks to establish a standard for the utilization of the Class of Service Field and the us of the Flow Label Field within the IPv6 Header and establish a methodology of switching packets through routers using the first 32-bits of the IPv6 header using Flow Label Switching on packets rather than full routing of packets. Within the first 32-bits of an IPv6 header exists the requisite information to allow for the immediate “switching” on an ingress packet of a router, allowing for “Label Switching” of a native IPv6 packet. This allows the establishment of VPN circuits in a dynamic manner across transit networks. The establishment of “Flows” based upon the 20-bit “Flow Label” value can be done dynamically with minimal effort and configuration of the end-point routers of the flow. The flows can be managed or open, encrypted or in the clear, and will allow for greater scalability, security, and agility in the management and operation of networks. "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Martin Beckman, 9-Mar-07, This document outlines a methodology for IPv6 Header Compression via mapping the source and destination addresses into a flow label value per address pair sessions with a specific traffic class field value to identify the packet as “address-less” compressed header. The resultant headers, sans addresses shrink from 320 bits to 64 bits. This mapping is locally specific to the router port and the connecting hosts/router ports. Specifically written for use on low bandwidth links (less than T1 or 1.544Mbps), IPv6 AMP’s applicability goes to integration of cellular/WiFi appliances and will be critical for tactical uses for military and first responder applications. "Congestion Control in the RFC Series", Michael Welzl, Wesley Eddy, 30-Oct-08, This document is an informational snapshot produced by the IRTF's Internet Congestion Control Research Group (ICCRG). It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Douglas Stebila, Jon Green, 26-Apr-09, This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. "DAI Parameter for the "tel" URI", James Yu, David Hancock, Flemming Andreasen, 6-Jan-09, This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements. "GSSAPI authentication for HTTP", Leif Johansson, 8-Mar-09, This document specifies a template extension to the HTTP Negotiate authentication mechanism defined in RFC4559 which supports mutual authentication, fast session-based re-authentication and channel bindings. An IANA registry for such GSS-API HTTP authentication mechanisms is defined. "Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, 8-Mar-09, This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", Peter Saint-Andre, 8-Mar-09, This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obsoletes RFC 3921. "A Uniform Resource Name Namespace For The GSM Association (GSMA) and the International Mobile station Equipment Identity(IMEI)", Andrew Allen, Paul Gosden, David McDonald, Michael Montemurro, 15-Apr-09, This specification defines a Uniform Resource Name namespace for the GSMA and sub namespaces for the IMEI (International Mobile station Equipment Identity), and for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile (GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, and the Universal Mobile Telecommunications System (UMTS). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA (GSM Association). "Sharing Transaction Fraud Data", Siddharth Bajaj, 11-Feb-09, This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. M'RAIHI Expires - August 2009 [page 2] Sharing Transaction Fraud Data February 2009 "Simple SIP Usage Scenario for Applications in the Endpoints", Kundan Singh, Henry Sinnreich, Alan Johnston, Eunsoo Shim, 30-Apr-09, For Internet-centric usage, the number of SIP related standards for presence, IM and audio/video communications can be drastically reduced by using only the rendezvous and session initiation capabilities of SIP. The simplification is based on avoiding emulating telephony and its model of the intelligent network. 'Simple SIP' by contrast relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIA). Significant telephony features may also be implemented in the endpoints. This approach for SIP reduces the number of SIP standards to comply with, currently from roughly 100 and still growing, to about 10. References for NAT traversal and for security are also provided. "Session Initiation Protocol (SIP) Overload Control", Volker Hilt, Indra Widjaja, Henning Schulzrinne, 7-Mar-09, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines an overload control mechanism for SIP. "Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware", Patrick Cain, David Jevans, 30-Jul-08, This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. The extensions defined in this document are used to generate two different types of reports: a fraud and phishing report and a wide- spread spam report. Although similar in structure, each report has different required objects and intents.RFC 2129 Keywords "Use of Target Identity in HTTP-Enabled Location Delivery (HELD)", Martin Thomson, Hannes Tschofenig, Richard Barnes, James Winterbottom, 26-Feb-09, When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where a Target's location can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Target requests the Target's location. This document extends the HELD protocol to allow the location request message to carry Target identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. "A Framework for Session Initiation Protocol (SIP) Session Policies", Volker Hilt, Gonzalo Camarillo, Jonathan Rosenberg, 1-Nov-08, 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. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. "MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing", Kilian Weniger, Genadi Velev, 28-Nov-08, This document discusses the problem of correspondent node-targeted location privacy in Mobile IPv6 and proposes a mechanism to achieve simultaneous optimized routing and full correspondent node-targeted IP address location privacy. The mechanism utilizes the MIPv6 bootstrapping mechanisms and does neither require any new network entities nor changes to home agent or correspondent node implementations. "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Ibrahim Hajjeh, 28-Nov-08, This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. "IODEF/RID over SOAP", Brian Trammell, Kathleen Moriarty, 25-Feb-08, 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 interoperable 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/TLS and SOAP over BEEP. "Real-time Inter-network Defense", Kathleen Moriarty, 24-Nov-08, Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams 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. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve 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. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", Jani Hautakorpi, Gonzalo Camarillo, Bob Penfield, Alan Hawrylyshen, Medhavi Bhatia, 5-Jan-09, This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document 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. "SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", Takuya Sawada, Paul Kyzivat, 1-Jan-09, The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. "OSPF Extensions for Dynamic Placement of Multi-Segment Pseudowires", Matthew Bocci, Dimitri Papadimitriou, Alex Zinin, Mustapha Aissaoui, Andrew Dolganow, Yuji Kamite, Luca Martini, Frederic JOUNAY, 15-Apr-09, Multi-segment pseudowires have been defined to enable emulated layer 1 and layer 2 services to be delivered from an IP based packet switched network over a sparse mesh of PSN tunnels and PW control protocol sessions. MS-PWs can be used to scale PW based networks over both a single AS, or between multiple ASs, and there is a particular need to be able to dynamically route MS-PWs through a given AS to reach PEs at or beyond the edge of the AS, where the route of the PW through each AS needs to be automatically determined. This draft proposes extensions to OSPF to enable the automatic advertisement of summarized PW FECs, thus enabling the dynamic routing of MS-PWs across an OSPF domain. "Dynamic Host Configuration Protocol Option for Geodetic Location Information", Martin Thomson, James Winterbottom, 18-Jan-09, This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with an indication of uncertainty for each. Separate parameters indicate the reference datum for each of these values. "Fast Macro Mobility Handovers in HMIPv6", Youngsong Mun, 20-Feb-09, In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that "IEEE 802.21 Basic Schema", Kenichi Taniuchi, Yoshihiro Ohba, Subir Das, 2-Nov-08, This document describes an RDF (Resource Description Framework) schema defined in IEEE 802.21 as the basic schema for Media- Independent Information Service. This document serves as the Specification required by the IANA to maintain a global registry for storing the RDF schema. "Distributed DNS Implementation in IpV6", Lican Huang, 13-Jan-09, This file is a proposal for P2P based Domain Name query stratagy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. "Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 2-Mar-09, This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. "Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and Multihomed Nodes", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Basavaraj Patil, Hannes Tschofenig, 9-Mar-09, This memo describes privacy threats related to the MAC and IP layers identifiers in a mobile and multi-homed environment. "Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem Statement", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Basavaraj Patil, 14-Feb-09, This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 10-Dec-08, The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP. "Requirements for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 10-Dec-08, This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. "A Framework for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 10-Dec-08, This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. "PSTN scope of PCN Charter", Stuart Goldman, Robert Schafer, Frank Suraci, Bob Schaefer, 2-Mar-09, The IETF PCN Working Group has continued its work investigating pre- congestion and admission control mechanisms. This work has progressed under the current charter, but has not yet considered related legacy PSTN interactions or the need for ubiquitous connectivity between users on dissimilar networks. The PCN charter could be improved by a strong positive statement to the effect committing to future work addressing legacy networks. In that light, please consider the questions below which include differential PCN treatment based on traffic types, security, and PSTN interoperability concerns. It seems helpful to have a touchstone of some concerns relative to the PSTN network and IP network Gateway in order to confirm that they will be addressed in future work. This attempt is motivated by a desire to avoid the accidental omission of a topic that may be hard to "retrofit" in later. "Common Architecture Label IPv6 Security Option (CALIPSO)", Michael StJohns, 6-Mar-09, This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level secure (MLS) networking environments that are both trusted and trustworthy. "Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 4-Mar-09, The Mobile IPv6 Fast Handovers (FMIPv6) specification currently does not explicitly define prefix management over point-to-point links when a Mobile Node (MN) uses a prefix to formulate a new Care-of- Address (CoA). In this document a mechanism is developed for assigning unique prefixes to the MN by the Previous Access Router (PAR). The New Access Router (NAR) dynamically assigns a unique prefix called dedicated prefix to any MN that is performing a handover. Both reactive and predictive modes of FMIPv6 are explained. "The stale-if-error HTTP Cache-Control Extension", Mark Nottingham, 8-May-08, The stale-if-error HTTP Cache-Control extension improves availability of some kinds of cached content by allowing servers and clients to instruct caches to use stale responses when certain error conditions are encountered. "The stale-while-revalidate HTTP Cache-Control Extension", Mark Nottingham, 8-May-08, The stale-while-revalidate HTTP response Cache-Control extension allows servers to instruct caches to serve stale responses while validating them, to avoid latency in some situations. "Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)", Dale Worley, 6-Mar-09, An increasing number of SIP architectures implement multiple path routing (MPR), which is the providing of more than one path for a call to reach a destination user agent (UA). A typical example is a redundant pair of gateways from a SIP system to the PSTN. A call from the SIP system to the PSTN can pass through either gateway to ultimately reach the destination telephone. In order to gain the benefits of redundancy in case one of the gateways fails or reaches capacity, a proxy forks INVITEs serially to both gateways. Unfortunately, if the call passes through one gateway but fails at the destination phone (e.g., ring-no-answer), the proxy will then fork the call to the other gateway, because the proxy has no way to know that the call failed at the destination phone rather than at the first gateway. The second fork will fail in the same way at the same destination phone. This annoys both the caller (because the call takes twice as long as it should before failing) and anyone within earshot of the destination phone. Similar failures plague any other SIP architecture where a request can reach a destination through multiple paths. To gain the benefits of MPR without suffering from this problem, the proxy which forks a request onto the redundant paths needs to be able to determine if a fork that failed reached the destination UA and was rejected by the UA (and so an alternate path should not be tried), or if the fork failed before reaching the UA (and so an alternate path should be attempted). This document is to begin a discussion of strategies for making this determination. "A BEEP Binding for the HELD Protocol", Martin Thomson, James Winterbottom, 13-Jan-09, A BEEP binding is described for HELD. This binding is more suitable than the basic HTTP binding in scenarios where multiple messages are sent between the same two parties. "Digital Signature Methods for Location Dependability", Martin Thomson, James Winterbottom, 5-Jan-09, The dependability of location information is closely related to the degree of trust placed in the source of that information. This document describes techniques that can be used to mitigate the impact of falsifying location information. The application of digital signatures is described, relating these methods to the attacks that they address. "FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 9-Mar-09, This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package", Sandeep Sharma, Joe Stone, Rajesh Kumar, 4-Mar-09, This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC. "IP Tunneling Optimization in a Mobile Environment", Wassim Haddad, Mats Naslund, Pekka Nikander, 9-Mar-09, This memo introduces a simple tunneling optimization mechanism, which removes the need for inserting an additional header in the IP packet. The main goals are to minimize the packet size, provide a simpler protocol design and a better efficiency. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, San Jose, Florin Balus, 23-Mar-09, The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB has been standardized as IEEE 802.1ah-2008, which is an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where IEEE 802.1ah functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS with existing IEEE 802.1ad (aka QinQ) Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which PBB functionality can be incorporated into H-VPLS with existing MPLS access. "The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec", Akihiro Kato, Satoru Kanno, Masafumi Kanda, 8-Mar-09, This document describes the use of the Camellia block ciper algorithm in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. "SASL Yet Another Password Mechanism", Kurt Zeilenga, 29-Apr-09, This document describes a password authentication mechanism, called YAP-SHA-256, for use in protocols which support Simple Authentication and Security Layer (SASL) framework. The mechanism relies on security services provided by a lower layer, such as Transport Layer Security (TLS), to protect the authentication exchange, and subsequent application data exchange, from common attacks. The YAP-SHA-256 mechanism may be viewed as an alternative to other password-based SASL mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5. "EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband", Richard Pruss, Glen Zorn, 30-Apr-09, This document defines Dynamic Host Configuration Protocol (DHCP) extensions that provide for end-user authentication prior to configuration of the host. The primary applicability is within a Digital Subscriber Line (DSL) Broadband network environment in order to enable a smooth migration from the Point to Point Protocol (PPP). "Media Description for IKE in the Session Description Protocol (SDP)", Makoto Saito, Dan Wing, 5-Mar-09, This document extends the protocol identifier of SDP so that it could negotiate the use of IKE for media session in SDP offer/answer model. And it also specifies the method to boot up IKE and generate IPsec SA using self-signed certificate under the mechanism of comedia-tls. This document extends RFC 4572. In addition, it defines a new attribute "udp-setup", which is similar to "setup" attribute defined in RFC 4145, to enable endpoints to negotiate their roles in the IKE session. Considering the case that pre-shared keys can be used for authentication in IKE, a new attribute "psk-fingerprint" is also defined. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 17-Nov-08, This document provides the problem statement for 6LoWPAN routing. It also defines the requirements for 6LoWPAN routing considering IEEE 802.15.4 specificities and the low-power characteristics of the network and its devices. "The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec", Akihiro Kato, Satoru Kanno, Masayuki Kanda, Tetsu Iwata, 6-Mar-09, This memo specifies two new algorithms. One is the usage of Cipher- based Message Authentication Code (CMAC) with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-CMAC-96. Latter is pseudo-random function based on CMAC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-CMAC-PRF-128. "LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire", Philippe Niger, Yuji Kamite, Frederic JOUNAY, 6-Mar-09, This document provides a solution to extend Label Distribution Protocol (LDP) signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the source-initiated P2MP PW setup and maintenance. "Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", Michael Procter, 22-Apr-09, Call Park and Call Retrieve are useful telephony services that are familiar to many users. Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be taken, with varying degrees of interoperability. This draft discusses a number of feature variations, and how they may be implemented using existing techniques. An additional URI parameter is also described, which enables further common use-cases to be implemented. "An Architecture for Human Meetings and Dating websites using other Social Networking Internet resources.", Varun Srivastava, 29-Aug-07, This document describes an architecture for online meetings and dating websites. The proposed architecture can use its own profiles database as well as the other internet based social networking database resources. The document proposes a modular design for online meeting and similar kind of applications on Internet. The architecture proposes an application specific search without breaching privacy of the registered members. It also proposes to utilize member profiles from legacy databases and websites as well as other implementations of this architecture. "The DVB-RCS MIB", Petter Amundsen, Micheline Lambert, Hans-Peter Lexow, Stephane Combes, 11-May-09, This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS). It defines a set of MIB entities to characterize the behavior and performance of network layer entities deploying DVB-RCS. "Adding Acknowledgement Congestion Control to TCP", Sally Floyd, 23-Jan-09, This document describes a possible congestion control mechanism for acknowledgement traffic (ACKs) in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost or ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. "Campus/Building Relative Location for Civic Location Format", Marc Linsner, Allan Thomson, 6-Mar-09, This document defines additional civic address parameters for use in Location Objects [1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These additional parameters allow expression of a relative location within a building or campus. "DNSSEC Trust Anchor History Service", Wouter Wijngaards, 5-Mar-09, When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Sub-Types", Jonathan Rosenberg, 12-Nov-07, The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and provides insufficient granularity as a capability. This specification allows a UA to indicate which application sub-types the agent supports. "A Session Initiation Protocol (SIP) Extension for the Identification of Services", Keith Drage, 24-Mar-09, This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains, or use in the Internet at large. The document also defines a URN to identify both services and UA applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. "Reclassification of the APEX RFCs to Historic", Marshall T. Rose, 4-Jun-07, This memo reclassifies the APEX RFCs (RFCs 3340-3343) from PROPOSED STANDARD to HISTORIC. "Delay-Tolerant Networking Retransmission Block", Susan Symington, 3-Apr-09, This document defines an optional extension block, called a Retransmission Block (RB), that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. The Retransmission Block (RB) is designed to be used within a DTN that, as a matter of policy, deletes all replayed bundles from the network. It is designed to be used in a network that permits duplicate bundles to be forwarded if those bundles have been retransmitted by a custodian, that may (if possible) permit duplicate bundles to be forwarded if those bundles are in intentional or unintentional routing loops (contingent on the availability of mechanisms to distinguish looping bundles from other bundles), but that will consider all other duplicate bundles to be maliciously replayed bundles and delete them as such. The Retransmission Block is designed to be inserted into a bundle by a custodian when the custodian is retransmitting that bundle. The purpose of the RB is to mark the bundle as a custody-based retransmission so that it can be distinguished from other types of duplicate bundles and thereby be spared from deletion. This document defines the format and processing of this new Retransmission Block. "An XCON Client Conference Control Package for the Media Control Channel Framework", Chris Boulton, Mary Barnes, 26-Mar-09, The Centralized Conferencing framework defines a model whereby client initiated interactions are required for creation, deletion, manipulation and querying the state of a of conference. This document defines a Media Control Channel Package for XCON client initiated Conference Control. The Package is based on the Media Control Channel Framework, which is also used for media server control, thus optimizing the implementation for some entities participating in an XCON system. "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", Gorry Fairhurst, Thomas Schmidt, Matthias Waehlisch, 15-Apr-09, This document discusses current mobility extensions to IP layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and for mobile senders using Any Source Multicast and Source Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual roadmap for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Handle Resolution Option for ASAP", Thomas Dreibholz, 7-Jan-09, This document describes the Handle Resolution option for the ASAP protocol. "Media Resource Brokering", Chris Boulton, Lorenzo Miniero, 4-Mar-09, The MediaCtrl work group in the IETF is currently proposing an architecture for controlling media services. The Session Initiation Protocol (SIP) will be used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:M combinations of Application Servers and Media Servers. "TLS using EAP Authentication", Yoav Nir, Yaron Sheffer, Hannes Tschofenig, Peter Gutmann, 21-Apr-09, This document describes an extension to the TLS protocol to allow TLS clients to authenticate with legacy credentials using the Extensible Authentication Protocol (EAP). This work follows the example of IKEv2, where EAP has been added to the IKEv2 protocol to allow clients to use different credentials such as passwords, token cards, and shared secrets. When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol message and before the Finished message, effectively creating an extended handshake before the application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message. Using EAP for client authentication allows TLS to be used with various AAA back-end servers such as RADIUS or Diameter. TLS with EAP may be used for securing a data connection such as HTTP or POP3. We believe it has three main benefits: o The ability of EAP to work with backend servers can remove that burden from the application layer. o Moving the user authentication into the TLS handshake protects the presumably less secure application layer from attacks by unauthenticated parties. o Using mutual authentication methods within EAP can help thwart certain classes of phishing attacks. "EAP-Based Keying for IP Mobility Protocols", Vidya Narayanan, Gerardo Giaretta, 16-Nov-07, EAP [1] is increasingly used for network access authentication in various networks. Also, key generating EAP methods are being adopted in various systems for the purposes of cryptographic protection between an EAP peer and an enforcement point in the network. Key generating EAP methods produce an MSK and an EMSK in accordance with [1]. The MSK is meant for use by the EAP lower layer at the peer and the authenticator and is used differently by various lower layers. The EMSK hierarchy is defined in [2]. The EMSK hierarchy is meant to be extensible to derive keys for various usages. This document defines the key hierarchy and key derivations for using the EMSK hierarchy for keying in IP mobility protocols. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 7-Jan-09, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "MIKEY DHHMAC-SAS: The New MIKEY Transportation Mode", Alexandre Barreto, Antonio Faleiros, 18-Jun-07, This document presents a new transport mode to the Multimedia Internet KEYing (MIKE) protocol, the MIKEY-DHHMAC-SAS. The MIKEY has as its objective the negotiation of cryptography parameters necessaries to the establishment of a secure (SRTP/SRTCP) end-to-end multimedia channel, but all its operation modes have some kind of limitation that prevents it of being used to this purpose. The MIKEY-DHHMAC-SAS solves theses existing limitations in MIKEY-DH and MIKEY-DHHMAC modes by adding the features of key continuity and Short Authentication String (SAS), making possible its use in any end-to- end multimedia scenario. "Guidelines for Using the Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 25-Sep-08, This is an informational document that provides guidelines for using the privacy mechanism for Session Initiation Protocol (SIP), that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and SDP parameters for each of the privacy header values (priv-values). "ECC Brainpool Standard Curves and Curve Generation", Manfred Lochter, Johannes Merkle, 6-Mar-09, This Memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). "Establishing Location URI Contexts using HTTP-Enabled Location Delivery (HELD)", James Winterbottom, Hannes Tschofenig, Martin Thomson, 14-Apr-09, This document describes a protocol extension for the HTTP-Enabled Location Delivery (HELD) protocol. It allows a Target to manage their location information on a Location Information Server (LIS) through the application of constraints invoked by accessing a location URI. Constraints described in this memo restrict how often location can be accessed through a location URI, how long the URI is valid for, and the type of location information returned when a location URI is accessed. Extension points are also provided. "Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests", Robert Sparks, 2-Mar-09, This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, 9-Mar-09, This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. [RFC Editor: Please remove this paragraph before publication.] This is a draft to update RFC 3987 and move towards IETF Draft Standard. For an issues list/change log and additional information (including mailing list information), please see http://www.w3.org/International/iri-edit. For discussion and comments on this draft, please use the public-iri@w3.org mailing list. "Collection Synchronization for WebDAV", Cyrus Daboo, 8-Mar-09, This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. "Addressing Record-Route issues in the Session Initiation Protocol (SIP)", Thomas Froment, Christophe Lebel, Ben Bonnaerens, 6-Mar-09, A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPv4 or IPv6 addresses, and URI parameters that could influence the routing such as the transport parameter (for example transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching or IPv4 to IPv6 scenarios...), the question arises on what should be put in Record-Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. "RADIUS Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri Gundavelli, Damjan Damic, 7-Apr-09, This document defines new attributes to facilitate Proxy Mobile IPv6 operations using RADIUS infrastructure. The RADIUS interactions take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document also defines a RADIUS based interface between the Local Mobility Anchor and the RADIUS server for authorizing received initial Proxy Binding Update messages for the mobility service session. In addition to the mobility session setup related RADIUS interaction, this document defines the baseline for both the Mobile Access Gateway and the Local Mobility Anchor generated accounting. "Flow Selection Techniques", Lorenzo Peluso, Tanja Zseby, 2-Mar-09, Flow selection is the process in charge of electing a limited number of flows from all of those observed at an observation point to be considered into the measurement process chain. The flow selection process can be enabled at different stages of the monitoring reference model. It can be performed at metering time once the packet classification has been executed, i.e. flow state dependent packet selection, or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collector applications. This document illustrates the motivations which might lead flow selection to be performed and presents a classification of the related techniques. The document furthermore provides an information model for configuring flow selection techniques and discusses what information about the flow selection process is beneficial to be exported by adopting a suitable information model. "An Architecture for Location and Location Privacy in Internet Applications", Richard Barnes, Matt Lepinski, Alissa Cooper, John Morris, Hannes Tschofenig, Henning Schulzrinne, 9-Mar-09, Location-based services (such as navigation applications, emergency services, management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. "Authority-to-Individuals Communication for Emergency Situations: Requirements, Terminology and Architecture", Steve Norreys, 9-Mar-09, Public safety agencies need to provide information to the general public before and during large-scale emergencies. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document summarizes requirements for protocols to alert individuals within a defined geographic area. "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 7-Mar-09, The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). "Pre-Congestion Notification Encoding Comparison", Kwok Chan, Georgios Karagiannis, T Moncaster, Michael Menth, Philip Eardley, Bob Briscoe, 8-Mar-09, A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document explores different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide guidance and recommendation based on different criteria. This document also provides a historical trace of the consideration on different encoding alternatives for Pre- Congestion Notification. "An Evaluation Framework for Data Modeling Languages in Network Management Domain", Hui Xu, Debao Xiao, 6-May-09, With rapid development of next generation networks, it is expected that a separate effort to study data modeling languages in the interest of network management should be undertaken. Based on a good understanding of the requirements of data modeling in next generation network management domain, evaluation on management data modeling languages becomes an essential way for the purpose of standardization to replace proprietary data models in the near future. Our project aims to establish a framework for evaluation to measure the capabilities of management data modeling languages in meeting those requirements by a set of criteria, which are modeling approaches, interoperability, conformance, extensibility, readability, data representation and security considerations. "File Transfer Protocol HOST Command", Paul Hethmon, Robert McMurray, 1-Dec-08, The File Transfer Protocol, as defined in RFC 959 [1] and RFC 1123 Section 4 [6], is one of the oldest and widely used protocols on the Internet. This document addresses the subject of creating multi-homed FTP hosts servers on a single IP address. This is achieved by extending the FTP specification to add a HOST command that is used to specify individual FTP hosts. "Open Research Issues in Internet Congestion Control", Michael Welzl, Michael Scharf, Bob Briscoe, Dimitri Papadimitriou, 17-Apr-09, This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. "Administrative Specific Elements for Civic Location Format", Marc Linsner, Subha Dhesikan, Hannes Tschofenig, 6-Mar-09, This document defines additional civic address parameters for use in Location Objects [1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These addition parameters allow expression of administrative specific location data elements. "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Mike Tyson, Carlo Kopp, 21-Dec-07, This document presents the Lightweight GNSS (Global Navigation Satellite System) Support Protocol (LGSP). The Lightweight GNSS Support Protocol (LGSP) is being developed in order to provide a comprehensive solution which solves the problems inherent in traditional radio-based Differential GPS (DGPS) protocols. LGSP will also provide additional support for GNSS user equipment, such as a GPS almanac retrieval method, allowing compatible units to perform faster almanac acquisition, thus resulting in less time until an initial position measurement can be established. Other supporting features include alternative distribution of GPS navigation messages and differential correction messages, a hierarchical mirroring architecture, redundant backup operation and load balancing functions. "Routing and Addressing Problem Statement", Thomas Narten, 9-Mar-09, There has been much discussion over the last years about the overall scalability of the Internet routing system. This document attempts to describe what the actual problem is and the various demands being placed on the routing system that have made finding a straightforward solution difficult. Comments should be sent to rrg@psg.com or to radir@ietf.org. "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Murali Sridharan, Kun Tan, Deepak Bansal, Dave Thaler, 11-Nov-08, Compound TCP (CTCP) is a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. This document describes the Compound TCP algorithm in detail, and solicits experimentation and feedback from the wider community. The key idea behind CTCP is to add a scalable delay-based component to the standard TCP's loss-based congestion control. The sending rate of CTCP is controlled by both loss and delay components. The delay-based component has a scalable window increasing rule that not only efficiently uses the link capacity, but on sensing queue build up, proactively reduces the sending rate. "Identification of Communications Services in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 4-Aug-08, This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent. This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly - including fraud, interoperability failures and stifling of innovation. "A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization", Ashutosh Dutta, Victor Fajardo, Yoshihiro Ohba, Kenichi Taniuchi, Henning Schulzrinne, 14-Feb-09, This document describes a framework of Media-independent Pre- Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol and is best applicable to support optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff related operations to take place before the mobile has moved to the new network. We describe the details of all the associated techniques and its applicability for different scenarios involving various mobility protocols during inter-domain handover. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Message Body Handling in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 9-Mar-09, This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. "Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti Makela, Jouni Korhonen, 29-Apr-09, This document describes a Home Agent assisted route optimization extension to IPv4 Network Mobility Protocol. "Checksum Ciphersuites for the Bundle Protocol", Wesley Eddy, Lloyd Wood, Will Ivancic, 4-Mar-09, The Delay-Tolerant Networking Bundle Protocol includes a custody transfer mechanism to provide acknowledgements of receipt for particular bundles. No checksum is included in the basic DTN Bundle Protocol, however, so at intermediate hops, it is not possible to verify that bundles have been either forwarded or passed through convergence layers without error. Without assurance that a bundle has been received without errors, the custody transfer receipt cannot guarantee that a correct copy of the bundle has been transferred, and errored bundles are forwarded instead of being discarded. This document attempts to address the situation by defining new ciphersuites for use within the existing Bundle Security Protocol's Payload Integrity Block (formerly called the Payload Security Block) to provide error-detection functions regardless of an implementation's support for other, more complex, security-providing ciphersuites. This creates the checksum service needed for error- free reliability, but does so at the expense of divorcing security concerns from the few new reliability-only ciphersuite definitions that are introduced here. This document discusses in necessary detail the advantages and disadvantages of this approach and the existing constraints that combined to drive this design. "Using Self-Delimiting Numeric Values in Protocols", Wesley Eddy, 9-Jan-09, Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type within proposed Delay-Tolerant Networking protocols. The basic goal of an SDNV is to hold a non-negative integer value of arbitrary magnitude, without consuming much more space than necessary. The primary motivation is to conserve the bits sent across low-capacity or energy-intensive links typical of NASA deep- space missions, with a secondary goal of allowing the protocol to automatically adjust to unforseen usage scenarios. This can be desirable in that it allows protocol designers to avoid making difficult and potentially erroneous engineering decisions that may have to be hacked around in the future. This document describes formats and algorithms for SDNV encoding and decoding, and discusses implementation and usage of SDNVs. "H.248/MEGACO Registration Procedures", Christian Groves, Yangbo Lin, 7-Apr-09, This document updates the H.248/MEGACO IANA Package Registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. "Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension", Russ Housley, Sam Ashmore, Carl Wallace, 4-Mar-09, This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints X.509 certificate extension. This extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a protected content. In particular, the CMS content constraints certificate extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this certificate extension indicates the content types that the certified public key is authorized to validate. If the authorization check is successful, the CMS content constraints certificate extension also provides default values for absent attributes. "Agent-based multicast support for moving networks (NEMO)", Dirk v. Hugo, 4-Feb-09, This document describes an approach to support multicast listeners and senders located within a moving IPv6 network (NEMO). A NEMO is built up by at least one Mobile Router (MR) and a set of Mobile Network Nodes (MNNs). The MR handles all routing related tasks to provide connectivity between the MNNs and an access network including mobility management. Correspondingly the MR also subscribes to multicast groups and forwards emerging multicast traffic on behalf of a MNN. For optimised routing of multicast data a hierarchical multicast agent is introduced as a logical entity providing an anchor to the multicast tree. In the MR a corresponding functionality is defined which decides on the location of the specific agent to be used for a distinct multicast traffic. "Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, Loa Andersson, Stuart Cheshire, 23-Feb-09, This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols. "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 4-May-09, A method is described by which a Device is able to provide location- related measurement data to a LIS within a request for location information. Location-related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment. When a LIS generates location information for a Device, information from the Device can improve the accuracy of the location estimate. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. "URI Scheme for Java(tm) Message Service 1.0", Roland Merrick, Peter Easton, Derek Rokicki, Eric Johnson, 17-Nov-08, This document defines the format of Uniform Resource Identifiers (URI) as defined in [RFC3986], for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS) [REF-JMS]. It was originally designed for particular uses, but should have general applicability wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS destination. The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it. "Sieve Email Filtering: Sieves and display directives in XML", Ned Freed, Srinivas Vedam, 23-Mar-09, This document describes a way to represent Sieve email filtering language scripts in XML. Representing sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools. The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. Change History (to be removed prior to publication as an RFC Changed representation of comments in XML to use a comment element. Update references. Added an IANA registration of a URN for the Sieve namespace. Updated XML Schema to allow largely unrestricted use of material in other namespaces. Add compact Relax NG schema. Updated example stylesheet to handle material in other namespaces. Corrected stylesheet handling of elements. Added a section defining the structured comment convention. Moved the examples section to an appendix. Added text to clarify that the examples in the various appendices are in fact code components and may therefore be reused. Added a section on validation requirements. Clarified various editor requirements and trust issues, restricted the use of "*/" in non-Sieve XML content. Added XML reference. "Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Preethi Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar, 18-Feb-09, Stream Control Transmission Protocol (SCTP) [RFC4960] specifies Selective Acknowledgements (SACKs) to allow a transport layer data receiver to acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK information is advisory because the data receiver is permitted to renege; that is, later discard a DATA chunk which previously has been SACKed. Since delivery of a SACKed out-of-order DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept in the data sender's retransmission queue until this DATA chunk is cumulatively acked. This document specifies Non-Renegable Selective Acknowledgements (NR- SACKs), an extension to SCTP's acknowledgment mechanism. NR-SACKs enable a data receiver to explicitly acknowledge out-of-order DATA chunks that have been delivered to the receiving application. (Recall that, in SCTP, out-of-order data sometimes can be delivered.) NR-SACKs also enable a data receiver to indicate any out-of-order DATA chunks on which the receiver guarantees never to renege. As opposed to SACKed DATA chunks, a sender can consider NR-SACKed DATA chunks as never requiring retransmission, thus freeing space in the data sender's retransmission queue sooner. "Chatrooms within a Centralized Conferencing (XCON) System", Chris Boulton, Mary Barnes, 7-Mar-09, The document "A Framework for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic. The primary examples within this framework focus on audio and video as the media types for the session. This document provides an overview of the mechanisms defined in the centralized conferencing framework that can be used to support chatrooms. In addition, the document describes additional functionality and requirements necessary to provide feature rich chatroom functionality. "A Feature Set for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 9-Mar-09, This document defines a protocol feature set for the Extensible Messaging and Presence Protocol (XMPP), in accordance with the concepts and formats proposed by Larry Masinter within the NEWTRK Working Group. "Distributed Universal Resource Name Resolution based on Distributed DNS", Lican Huang, 16-Jan-09, This file is a proposal for Universal Resource Name resolution based on P2P DNS. "OCSP Algorithm Agility", Phillip Hallam-Baker, 2-Dec-08, The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. "PCEP Requirements for WSON Routing and Wavelength Assignment", Tomonori Takeda, Tomohiro Otani, Young Lee, Greg Bernstein, 2-Mar-09, This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Additionally, optical impairments may add further constraints on the paths available for use. "Certificate profile and certificate management for SEND", Suresh Krishnan, Ana Kukec, Khaja Ahmed, 9-Mar-09, Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on Resource Certificates along with extended key usage values required for SEND. "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 26-Feb-09, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 5-Mar-09, The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, but is simpler than the methods previously documented. "The Camellia Cipher in OpenPGP", David Shaw, 8-Dec-08, This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. "SMTP Service Extension for Indicating Message Authentication Status", Murray Kucherawy, 17-Apr-09, This memo defines an extension to the Simple Mail Transfer protocol (SMTP) service whereby a server can indicate its ability to accept and apply information regarding the efforts of upstream SMTP servers to establish authenticity of the message via various authentication methods. "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", Scott Lawrence, Vijay Gurbani, 8-Apr-09, This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. "Domain Certificates in the Session Initiation Protocol (SIP)", Vijay Gurbani, Scott Lawrence, Bell Laboratories, 8-Apr-09, This document describes how to construct and interpret certain information in a X.509 PKIX-compliant certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of cetificates. "Flow Aware Transport of MPLS Pseudowires", Stewart Bryant, Clarence Filsfils, Ulrich Drafz, Vach Kompella, Joe Regan, Shane Amante, 2-Mar-09, Where the payload carried over a pseudowire carries a number of identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. "Flow Distribution Rule Language for Multi-Access Nodes", Conny Larsson, Michael Eriksson, Koshiro Mitsuya, Kazuyuki Tasaka, Romain Kuntz, 24-Feb-09, This document defines an OS independent rule language as a mean to define and perform per flow path selection for a multi-homed node. Per flow path selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. The flow distribution rule set is used by the node itself but also exchanged with other nodes that needs to know about the multi-homed node's capability of receiving data on multiple network interfaces. This document does not define how the rule set is transferred between nodes. "MVPN Profiles Using PIM Control Plane", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 31-Dec-08, The MVPN (Multicast Virtual Private Network) architecture is divided into a number of functional "layers". At each layer, multiple options are allowed. It is necessary to allow multiple options at each layer because "one size doesn't fit all." However, it is not expected that any particular implementation will support all the possible combinations of options. To ensure multi-vendor interoperability, it is useful to specify "profiles", where each profile is a particular combination of options. The number of specified profiles will be much less than the total number of possible combination, and a given implementation can be characterized by saying which profiles it supports. This document describes two profiles that use a PIM control plane. "End-Host Authentication for HIP Middleboxes", Tobias Heer, Klaus Wehrle, Miika Komu, 27-Feb-09, The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension allows middleboxes to verify the liveness and freshness of a HIP association and, thus, to secure access control in middleboxes. "An HTTPS Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 23-Feb-09, This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target. A held: URI scheme is defined for use with resources that can be accessed using the mechanisms defined in this document. [Note: this is a provisional inclusion only] "Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 30-Nov-08, The key concepts of uncertainty and confidence as they pertain to location information are defined. Methods for the manipulation of location estimates that include uncertainty information are outlined. "DTLS-SRTP Key Transport (KTR)", Dan Wing, 9-Mar-09, The existing DTLS-SRTP specification allows SRTP keys to be established between a pair of SRTP endpoints. However, when there are more than two participants in an SRTP session, DTLS-SRTP is unable to provide a single key for all of the participants. This existing limitation of DTLS-SRTP prevents deploying DTLS-SRTP in certain scenarios. This document describes an extension to DTLS-SRTP called Key Transport (KTR). This extension transports SRTP keying material from one DTLS-SRTP peer to another, so the same SRTP keying material can be used by multiple DTLS-SRTP peers. This extension eliminates the need to key each SRTP session individually, allowing cost-effective deployment of several DTLS-SRTP scenarios. "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, 13-Feb-09, This document specifies the "Mutual authentication protocol for Hyper-Text Transport Protocol". This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication. Unlike Basic and Digest HTTP access authentication protocol, the protocol ensures that server knows the user's entity (encrypted password) upon successful authentication. This prevents common phishing attacks: phishing attackers cannot convince users that the user has been authenticated to the genuine website. Furthermore, even when a user has been authenticated against an illegitimate server, the server cannot gain any bit of information about user's passwords. The protocol is designed as an extension to the HTTP protocol, and the protocol design intends to replace existing authentication mechanism such as Basic/Digest access authentications and form-based authentications. "Rogue IPv6 Router Advertisement Problem Statement", Tim Chown, Stig Venaas, 9-Mar-09, When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the Router Advertisement (RA) message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this draft we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. "LISP Alternative Topology (LISP+ALT)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 24-Feb-09, This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. "BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 6-Mar-09, In order to provide an end-to-end MPLS TE LSP between customer sites within a BGP/MPLS IP-VPN, it is highly desirable for a Path Computation Element (PCE) to be able to dynamically discover a set of Path Computation Elements (PCEs) that know VPN routes. In BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines a new attribute and describes how PCE information can be carried using BGP. "RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 18-Feb-09, This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format has wide applicability, such as 3D video streaming, free-viewpoint video, and 3DTV. "IGMP and MLD Extensions for Mobile Hosts and Routers", Hitoshi Asaeda, Thomas Schmidt, 8-Mar-09, This document describes IGMP and MLD protocol extensions for mobile hosts and routers. IGMP and MLD are necessary protocols for hosts to request join or leave multicast sessions. While the regular IGMP and MLD protocols support communication between mobile hosts and routers over wireless networks, this document discusses the conditions how mobile hosts and routers use IGMP and MLD in their communication more effectively. Aside from a modified protocol semantic, optional "Notification function" and "Listener Hold function" for the IGMP and MLD protocols are introduced. "A Session Description Protocol (SDP) Control Package Attribute", Chris Boulton, 27-Mar-09, This document defines a new Session Description Protocol (SDP) media- level attribute: "ctrl-package". The "ctrl-package" attribute conveys details of the SIP Control Framework extension packages that are supported by a client participating in an offer/answer exchange. "UA-Driven Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 7-Apr-09, This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUU) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. "Test Cases for the use of Galois/Counter Mode (GCM) and Galois Message Authentication Code (GMAC) in IPsec ESP", David McGrew, 9-Mar-09, This note provides test cases for the use of AES GCM and GMAC in ESP, as defined in RFC4106 and RFC4543, and clarifies some points in the latter specification. "Reporting of DKIM Verification Failures", Murray Kucherawy, 28-Jan-09, This memo presents an extension to the DomainKeys Identified Mail (DKIM) specifications to allow public keys for verification to include a reporting address to be used to report message verification issues, and extends an Internet Message reporting format to be followed when generating such reports. "An overload control package for the Session Initiation Protocol (SIP).", Youssef Chadli, Xavier Marjou, 25-Feb-09, This document specifies an event package for the notification of overload control using the Session Initiation Protocol (SIP) events framework. The overload control package allows an upstream server to retrieve overload control information from a downstream server and to be notified when this information changes. This information is used by the upstream server to adapt its flow toward the downstream server and thus to avoid overloading it. "Interworking LISP with IPv4 and IPv6", Darrel Lewis, Dave Meyer, Dino Farinacci, Vince Fuller, 27-Jan-09, This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP [LISP]) to interoperate with Internet sites not running LISP. A fundamental property of LISP- speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IP addresses, routes for them are not carried in the global routing system so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces two such mechanisms: the first uses a new network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts while the second adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package", Jari Urpalainen, 3-Oct-08, This document describes an "xcap-diff" SIP event package for the SIP Event Notification Framework, which clients can use to receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP-Diff format. "Specifying Location Quality Requirements in Location Protocols", Martin Thomson, James Winterbottom, 23-Feb-09, Parameters that define the expected quality of location information are defined for use in location protocols. These parameter can be used by a requester to indicate to a Location Server quality requirements for the location information it requests. If applicable, the Location Server is able to use this information to control how location information is determined. An optional indication of whether the quality requirements were met is defined to be provided by the Location Server alongside location information. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 8-Mar-09, As a foundation for the definition of application-specific, bi- directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 8-Mar-09, This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 8-Mar-09, This document defines a bi-directional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 8-Mar-09, This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions", Peter Saint-Andre, 8-Mar-09, This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP). "Syntax for binding documents with time stamps", Adriano Santoni, 20-Apr-09, This document describes an envelope which can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed. The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 3852. "Extensible Supply-chain Discovery Service Problem Statement", , 17-Nov-08, This document discusses the requirements of an application layer protocol for Discovery Services. Discovery Services at its core offers to authenticated and authorized users the means to discover resources of information for a particular identifier. The information resource can be any data source which provides an interface on a network that allows for retrieval of the data. An information resource could publish its network address (reference to the resource) to a Discovery Service coupled with an identifier. Then an authenticated and authorized user could query the Discovery Service with the same identifier to receive reference information to the resources. Interfacing with the resources for actually retrieving the data is out of scope of Discovery Services; the role of Discovery Services is to enable a client to find the network addresses and types (e.g. URLs) of information resources for a particular identifier of interest. This protocol is applicable to numerous scenarios such as track and trace in trade supply chains, where a number of independent resources may hold information about a particular object and may have an interest in selective sharing of that information, in order to improve the efficiency of the supply chain network. However, other applications can be envisaged, as a 'bottom-up' or 'grassroots' way for generators of information content to: 1) declare that they have information or commentary on a particular topic or subject (which might be a physical object, geographic location or even an abstract concept) 2) specify a network address through which that content can be retrieved, 3) specify restrictions about the community of clients that are entitled to receive knowledge about the existence of their content or see the link. This approach can be contrasted with the top-down approach of existing web search engines that rely on crawling/spidering of content that must be already posted in the public domain before it can be indexed - and where the link information is generally made publicly available in a manner that does not discriminate between clients on an individual basis. This document outlines a set of design concerns that an application layer protocol needs to address in order to be widely adopted and deployable on public networks This document obsoletes "Extensible Supply-chain Discovery Service Problem Statement draft-rezafard-esds-problem-statement-02". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", Paul Hoffman, 16-Feb-09, 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. "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos Mavrogiannopoulos, 25-Nov-08, This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo replaces the Experimental [RFC5081]. "Shim6 Implementation Report : LinShim6", Sebastien Barre, 10-Feb-09, LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. "Special Use IPv4 Addresses", Michelle Cotton, Leo Vegoda, 24-Feb-09, This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. Special IPv6 addresses are described in RFC 5156. "EAP Authentication Using Only A Password", Dan Harkins, Glen Zorn, 19-Nov-08, This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. "Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, Elwyn Davies, Samo Grasic, 9-Mar-09, 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 there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as Delay and Disruption Tolerant). The document presents an architectural overview followed by the protocol specification. "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 19-Aug-08, For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulated border nodes. These virtual topologies may span multiple IP- and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. "Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 2-Mar-09, This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. "Scaling Requirements for Presence in SIP/SIMPLE", Avshalom Houri, Sriram Parameswar, Edwin Aoki, Vishal Singh, Henning Schulzrinne, 27-Jan-09, The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. "Enabling an Enhanced Care-of Address Reachability Test for the Home Agent", Wassim Haddad, Francis Dupont, 9-Mar-09, This memo aims to improve Mobile IPv6 protocol security by enabling an enhanced care-of address rechability test for the home agent. The main goals are to discourage a rogue mobile node from misleading its home agent to flood a targeted foreign network and to empower the latter to thwart this type of attack if launched at a later stage. "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", John Elwell, 16-Jan-09, SIP has a mechanism for conveying the asserted identity of the originator of a request by means of the P-Asserted-Identity header field. This header field is specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of this header field by a trusted UAC, does not specify the use of P-Asserted-Identity and P-Preferred- Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations. This work is being discussed on the sipping@ietf.org mailing list. "Essential correction for IPv6 ABNF and URI comparison in RFC3261", Vijay Gurbani, Brian Carpenter, Brett Tate, 25-Nov-08, This memo corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. "Linguistic Guidelines for the Use of the Arabic Language in Internet Domains", Abdulaziz Al-Zoman, Ayman El-Sherbiny, Mansour Farah, Ibaa Oueichek, 6-Feb-09, This document constitutes technical specifications for the use of Arabic in Internet Domain names and provides linguistic guidelines for Arabic Domain Names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets", Martin Dolly, Dale Worley, 8-Mar-09, This document defines the requirements and a format for SIP user agent profile data. An overall schema is specified for the definition of profile datasets. 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 datasets to be included in profile data. "ILNP Concept of Operations", Randall Atkinson, 10-Dec-08, This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator Network Protocol (ILNP). "Change Process for the Session Initiation Protocol (SIP)", Jon Peterson, Cullen Jennings, 26-Feb-09, This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP). As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area which are, respectively, responsible for the maintenance of the core SIP specifications and development of new efforts to extend and apply SIP. This document obsoletes RFC3427. "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Salvatore Loreto, Gonzalo Camarillo, 9-Mar-09, SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP' and 'SCTP/ TLS' protocol identifiers for SDP. "A BGP Inter-AS Cost Attribute", Iljitsch van Beijnum, Rolf Winter, 9-Mar-09, Although BGP implementations have extensive path selection algorithms, in practice operators have trouble performing satisfactory traffic engineering of incoming traffic based on BGP attributes that are taken into account in the path selection algorithm alone. For this reason, many ASes deaggregate their address range(s) into smaller blocks and announce these blocks differently to different neighboring ASes in order to arrive at the desired traffic flow. This practice contributes to the growth of the global routing table, which drives up capital expenditures for networks engaging in inter-domain routing. This memo introduces a new inter-domain metric that supports finer-grained traffic engineering than current BGP attributes. "Usecases and Benefits of end to end ECN support in PCN Domains", Zaheduzzaman Sarker, Ingemar Johansson, 20-Nov-08, This document provides an informative overview of possible use cases where ECN marking can be used for inelastic traffic. It outlines benefits of preserving the ECN support in a PCN domain. As ECN provides with a simple mechanism for network nodes to inform the end points about possible upcoming congestion and resulting packet losses and delay increase, the scheme can be useful for adaptive real-time media applications, thus enabling them to adjust the transmission rate to avoid quality degradation due to congestion. By showing the benefits of ECN this memo asks the working group to consider end to end ECN support in PCN domain. "Indirect Presence Publication with the Session Initiation Protocol(SIP)", Miguel Garcia, Hannes Tschofenig, Henning Schulzrinne, 6-Mar-09, SIP is extended by the SIP-events framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence' and this presence information is carried in Presence Information Data Format (PIDF) documents. The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document is typically used when presentities publish their own presence since these presentities are typically the source of the information. However, there are cases when the presentity is not the direct source of the presence information. One such example is location information where the end host may obtain a reference to location information as opposed to as a value. The endpoint is typically not interested in knowing its own location information, but other users or entities might be. So, if the endpoint gets its own location information with a reference and wants to publish it embedded in its presence information, it first needs to de-reference it for getting a value, and then it can embed that value in its presence information. While this is certainly a correct sequence, it adds a round-trip to the presence publication, in addition to a demand processing power and network bandwidth consumption. There is a need for a mechanism that the presentity can use to publish indirect references, such as indirect location references. This document discusses a few variants that may be used to provide this functionality. "Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 23-Feb-09, Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. "Specifying a Circular Uncertainty Area Using DHCP", Hannes Tschofenig, James Winterbottom, 7-Mar-09, This document specifies how a circular area representing the location of device can be returned using DHCP. The document also shows how the data returned from DHCP can be encoded into GML for using in a PIDF-LO in an unambiguous or contentious manner. This document is a contribution to the ongoing discussion on RFC 3825; it represents one possible solution to address the discussed issues. "The Session Initiation Protocol (SIP) P-Private-Network-Indication Private-Header (P-Header)", Hans Erik van Elburg, Keith Drage, 19-Feb-09, This document describes why a private network indication is needed. A private network indication allows other nodes in a network to treat private network traffic to a different set of rules then public network traffic. The indication also distinguishes one private network from another private network. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 4-Feb-09, This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA as required by section 4.2 of RFC 3427. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. "Hierarchical Host Identity Tag Architecture", Sheng Jiang, 11-May-09, This document analyzes the problems and limitation of the current flat-structured Host Identity Tag architecture. The document specifies a hierarchical HIT architecture which is compatible with the flat-structured HIT architecture. This architecture and the process of HIT generation ensure the global uniqueness of HITs. This architecture also enables the multiple Host Identity Protocol management domains, solves the deployment problem of current flat- structured HIT architecture. It also enhances the scalability and resolution efficiency of the mapping system from HIT to IP or FQDN. "Kerberos Option for DHCPv6", Masahiro Ishiyama, Shoichi Sakane, 12-Mar-09, This document defines a new DHCPv6 option to carry a set of configuration information related to the Kerberos protocol [RFC4120]. This document also defines three sub-options to be used within this new option, which specify a realm name of the Kerberos, a list of IP addresses of the Key Distribution Center of that realm, and a client principal name to distinguish a Kerberos client by the DHCPv6 server. "Requirements for the graceful shutdown of BGP sessions", Bruno Decraene, Pierre Francois, cristel pelsser, Zubair Ahmad, Antonio Jose Elizond Armengol, 6-Mar-09, The BGP protocol is heavily used in Service Provider networks both for Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an AS Border Router or BGP session breakdown on customers' or peers' traffic. However simply taking down or even up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no more satisfactory for new applications (e.g. voice over IP, on line gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. "Rbridges: TRILL Header Options", Donald Eastlake 3rd, 23-Apr-09, The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-12.txt, specifies minimal hooks for options. This draft fully describes the format for options and specifies an initial set of options. "One time Password in IKE version 2 (non-EAP based)", Abhishek Singh, Sunil Kumar, 24-Nov-08, IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document presents the changes in Internet Key Exchange Version 2 for one time password. The proposed method of using OTP in IKEv2 not only enhances the security but also has less number of exchange messages as compared to existing OTP-EAP based method. "EAP Method Support for Transporting AAA Payloads", Charles Clancy, Avi Lior, Glen Zorn, 2-May-09, This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well. "Cryptographic Algorithm Implementation Requirements for Routing Protocols", Manav Bhatia, Vishwas Manral, 1-Dec-08, The interior gateway routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and Message Digest 5 (MD5) [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the Secure Hash Algorithm (SHA) family of hash functions for authenticating routing protocol packets for RIP [RFC4822], IS-IS [ISIS-HMAC] and OSPF [OSPF- HMAC]. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms thereby ensuring that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication of these routing protocols as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, cristel pelsser, Clarence Filsfils, 6-Mar-09, This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers, involving the shutdown of BGP peering sessions. "LoWPAN simple fragment Recovery", Pascal Thubert, Jonathan Hui, 27-Mar-09, Considering that 6LoWPAN packets can be as large as 2K bytes and that an 802.15.4 frame with security will carry in the order of 80 bytes of effective payload, a packet might end up fragmented into as many as 25 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints. "Location-to-Service Translation Protocol (LoST) Extensions", Andrea Forte, Henning Schulzrinne, 23-Mar-09, An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X". "Filename Preservation for EDIINT Protocol", Terry Harding, 17-Nov-08, The intent of this document is to be placed on the RFC track as an Informational RFC. "The BagIt File Packaging Format (V0.96) http://www.ietf.org/internet-drafts/draft-kunze-bagit-03.txt", Andy Boyko, John Kunze, Justin Littman, Liz Madden, Brian Vargas, 24-Nov-08, This document specifies BagIt, a hierarchical file packaging format for the exchange of generalized digital content. A "bag" has just enough structure to safely enclose a brief descriptive "tag" and a payload but does not require any knowledge of the payload's internal semantics. This BagIt format should be suitable for disk-based or network-based file hierarchy transfer. One important use case is the possibility of eventual safe return of a received bag. Tag information consists of a small number of top-level reserved file names, checksums for transfer validation, and optional small metadata blocks. "TOTP: Time-based One-time Password Algorithm", David M'Raihi, Salah Machani, Mingliang Pei, Johan Rydell, 5-Jan-09, This document describes an extension of one-time password algorithm HOTP as defined in [RFC4226] to support time based moving factor. "X.509 Key and Signature Encoding for the KeyNote Trust Management System", Angelos Keromytis, 30-Mar-09, This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]). "A Quick Crash Detection Method for IKE", Yoav Nir, Frederic Detienne, Pratima Sethi, 20-Apr-09, This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. "Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 15-Apr-09, A de-centralised, self-contained and managed storage protocol. A system to provide strong storage fail over by using existing resources over networks distributing vital data evenly. Rapid deployment and high redundancy for small to medium organisations as well as individuals. Designed to reduce dependency on tape backup systems. The protocol also has implications for long term archiving. By classifying data vitality values the limitations in physical space due to bandwidth constrictions can be overcome and the usefulness of DIAP maximised. "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08, This document specifies a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. It ensures highly adaptive and loop-free routing while causing only low processing and traffic cost. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 6-Mar-09, It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is advantageous to use PCE to calculate customer MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP- VPNs. "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", Juergen Schoenwaelder, Alex Clemm, Anirban Karmakar, 9-Feb-09, 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 mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams, 24-Apr-08, This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. "Conversion of MIB to XSD for NETCONF", Debao Xiao, Yanan Chang, 24-Nov-08, NETCONF needs a data model for its process of standardization. This documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity, general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. "Inter-technology handover in PMIPv6 domain", Domagoj Premec, Teemu Savolainen, 9-Mar-09, Proxy Mobile IPv6 [RFC5213] is a network based mobility management protocol which provides IP mobility service to a host in a way which is transparent to the host itself. This document analyses the scenario in which the mobile node equipped with multiple network interfaces roams in a Proxy Mobile IPv6 domain consisting of multiple access networks. If the mobile node wants to preserve IP session continuity across different network interfaces as it moves from one access network to another it needs to be enhanced with a new, PMIPv6- specific functionality. "LISP for Multicast Environments", Dino Farinacci, Dave Meyer, John Zwiebel, Stig Venaas, 26-Nov-08, This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. "Extended Random Values for TLS", Eric Rescorla, Margaret Salter, 2-Mar-09, This document describes an extension for using larger client and server Random values with Transport Layer Security (TLS) and Datagram TLS (DTLS). "ECC in OpenPGP", Andrey Jivsov, 31-Dec-08, This document proposes an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow set of parameters for best interoperability and it does so within the framework it defines that can be expanded in the future to allow more choices. "Indication of support for keep-alive", Christer Holmberg, 26-Mar-09, This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. "Definition of Managed Objects for the Neighborhood Discovery Protocol", Robert Cole, Ian Chakeres, 21-Feb-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems. "Response Code for Indication of Terminated Dialog", Christer Holmberg, 9-Apr-09, This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. "System for Managing a Shared Domain Registry", Matthew Hunt, 30-Nov-08, This document describes the typical usage and communication protocol of a client/server shared registry system for management of domain name registrations. The system described is a "thick registry" system, providing support for the storage and management of both the technical and the registrant contact information concerning domain registrations. The system relies on the existing HTTP and HTTPS infrastructure for transport and secure transfer to avoid having to implement a dedicated protocol and server environment. A bespoke XML format is used to communicate between clients and the SRS server. Comments are solicited and should be addressed to the mailing list at srsstandards-l@nzrs.net.nz and/or the author. The mailing list management page can be found at . "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", Alexander Mayrhofer, Christian Spanring, 12-Feb-09, This document specifies an Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location by latitude, longitude and optionally altitude in a compact, simple, human-readable, and protocol independent way. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 4-Mar-09, This document provides methodology and framework for quantifying performance of selective monitoring of IP flows on a network device and export of this information to a collector as specified in the IPFIX documents [RFC5101]. Novak Expires September 1, 2009 "Location Measurements for IEEE 802.16e Devices", Martin Thomson, James Winterbottom, 1-Dec-08, IEEE 802.16e defines means for true mobility within an 802.16 wireless network. Determining an accurate location for 802.16e devices requires information on radio parameters. A format is defined for location-related measurement data that can be provided by an 802.16e device. This measurement data can be used by a Location Information Server (LIS) to more accurately determine the location of the device. A separate measurement used for identifying WiMAX session-related parameters is also provided. "Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP)", Chunxiu Li, Yan Li, 18-Nov-08, This document introduces a Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP), which is useful for the access control application of SNMP protocol. This document describes the procedure of access control in SVACM with Remote Authentication Dial In User Service (RADIUS) server for authorization. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for SVACM. "Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)", Martin Thomson, 23-Mar-09, The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes an BEEP feature that enables asynchrony for individual channels. "Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary", Karl Wolf, 3-Mar-09, LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not provide information about the geographical region for which the returned service list is valid. Therefore, this document proposes a ServiceListBoundary. "Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 23-Mar-09, This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). "Random Data Encryption Mechanism (RDEM)", Mukul Jaitly, 1-Jun-08, This document describe an data encryption specification which is based on random bytes selection of data and random key generation. This encryption process accepts variable input and the key size is dependent on the input data. This encryption process does not depend upon any 128 or 256 fixed block encryption. The mechanism for encryption is simpler to implement, but gives key complexity of more than 256 bit encryption. "BGP Extended Community Attribute for QoS Marking", Thomas Martin Knoll, 7-Jan-09, This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community Attribute. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking attribute makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The attribute provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. "ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 9-Mar-09, This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to be used in NAT444 model which is used during the transition period to IPv6. "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 7-Mar-09, NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. This document specifies NAT64, and gives suggestions on how they should be deployed. "Additional DNS Resource Records", Randall Atkinson, 10-Dec-08, This note describes two additional optional Resource Records for use with the Domain Name System (DNS). At present these optional resource records are subject of experimentation in certain IPv6 networks. Limited deployment is anticipated in the near future. "Nonce Destination Option", Randall Atkinson, 10-Dec-08, This document describes an experimental Nonce Destination Option that could be used as part of an Identifier Locator Network Protocol (ILNP) that is based upon IPv6. "Attention Request (POKE) for Instant Messaging", Gustavo Garcia, Jose-Luis Martin, 12-Feb-09, This document specifies a message content type and XML format to request attention from a targeted user. This feature is usually known as poke, nudge or buzz in existing messaging platforms. Its primary use is as an additional instant messaging capability that can be sent in the middle of a instant messaging session or in a standalone message at any time. "Requirements for Dialog Correlation in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Salvatore Loreto, 5-Mar-09, This document justifies the need and lists the requirements for correlating SIP (Session Initiation Protocol) dialogs. The correlated dialogs may or may not be related to the same multimedia session. Being able to logically correlate multiple SIP dialogs is useful for applications that, for different reasons, need to establish several SIP dialogs to provide a given service. The logical correlation of two SIP dialogs is also useful, for instance, to correlate an incoming with an outgoing dialog at a B2BUA. "Conversion parameters for IMAP CONVERT", Alexey Melnikov, 7-Mar-09, This is a companion document to the IMAP CONVERT (RFC 5259) extension defined by the Lemonade Working Group. It defines additional conversion parameters for conversions of images, audio, video and textual body parts. It also demonstrates additional CONVERT usage scenarios. "Pairtrees for Object Storage (V0.1) http://www.ietf.org/internet-drafts/draft-kunze-pairtree-01.txt", John Kunze, Martin Haye, Erik Hetzner, Mark Reyes, Cory Snavely, 26-Nov-08, This document specifies Pairtree, a filesystem hierarchy for holding objects that are located within that hierarchy by mapping identifier strings to object directory (or folder) paths two characters at a time. If an object directory (folder) holds all the files, and nothing but the files, that comprise the object, a "pairtree" can be imported by a system that knows nothing about the nature or structure of the objects but can still deliver any object's files by requested identifier. The mapping is reversible, so the importing system can also walk the pairtree and reliably enumerate all the contained object identifiers. To the extent that object dependencies are stored inside the pairtree (e.g., fast indexes stored outside contain only derivative data), simple or complex collections built on top of pairtrees can recover from index failures and reconstruct a collection view simply by walking the trees. Pairtrees have the advantage that many object operations, including backup and restore, can be performed with native operating system tools.1. The basic pairtree algorithm The pairtree algorithm maps an arbitrary UTF-8 [RFC3629] encoded identifier string into a filesystem directory path based on successive pairs of characters, and also defines the reverse mapping (from pathname to identifier). In this document the word "directory" is used interchangeably with the word "folder" and all examples conform to Unix-based filesystem conventions which should tranlate easily to Windows conventions after substituting the path separator ('\' instead of '/'). Pairtree places no limitations on file and path lengths, so implementors thinking about maximal interoperation may wish to consider the issues listed in the Interoperability section of this document. The mapping from identifier string to path has two parts. First, the string is cleaned by converting characters that would be illegal or especially problemmatic in Unix or Windows filesystems. The cleaned string is then split into pairs of characters, each of which becomes a directory name in a filesystem path: successive pairs map to successive path components until there are no characters left, with the last component being either a 1- or 2-character directory name. The resulting path is known as a _pairpath_, or _ppath_. abcd -> ab/cd/ abcdefg -> ab/cd/ef/g/ 12-986xy4 -> 12/-9/86/xy/4/ Armed with specific knowledge of a given namespace's identifier distribution, one might achieve more balanced or efficient trees by mapping to paths from character groupings other than successive pairs. Pairtree assumes that this sort of optimization, however, being tailored to individual and transient namespace conditions, is often less important than having a single generalized and shareable mapping. It uses pairs of characters to achieve hierarchies that exhibit a reasonable balance of path length and fanout (number of probable entries in any component directory).2. Pairpath termination and object encapsulation A ppath (pairpath) terminates when it reaches an object. A little jargon helps explain this. A _shorty_ is a 1- or 2-character directory name, or any file or directory name that begins with "pairtree" (these are reserved for future use). A ppath consists of a sequence of "shorties" ending in a non-shorty, such as a 3-character directory name or the 2-character file name "xy". The pairtree below contains two objects with identifiers "abcd" and "abcde". ab/ | \--- cd/ | |--- foo/ | | README.txt | | thumbnail.gif | | | |--- master_images/ | | | ... | | ... | | | \--- gh/ | \--- e/ | \--- bar/ | metadata | 54321.wav | index.html An object is reached when a non-shorty is detected. An object is _properly encapsulated_ if it is entirely contained in a non-shorty directory that is the immediate child of a shorty directory, in other words, if the 1- or 2-char directory name ending the object's ppath contains exactly one non-shorty directory that holds all the object's descendants. The two objects "abcd" and "abcde" above are properly encapsulated. Any shorty directory found at the same level as the non-shorty extends the pairtree. So while the "foo/" directory above does not subsume "e/" at the same level, by encapsulation, it does subsume the "gh/" underneath it (i.e., "gh/" is invisible to the pairtree algorithm, at least on a first pass). Practice will vary according to local custom as to how to name the encapsulating object directory beneath that last shorty. Its name is completely independent of the object identifier. For example, every object directory in a pairtree could have the uniform name "thingy". It is common for the directory name to be a terminal substring of the object identifier, as in: id: 13030_45xqv_793842495 ppath: 13/03/0_/45/xq/v_/79/38/42/49/5/793842495 All objects should be properly encapsulated. If an object is detected that is _improperly encapsulated_, that is, when a ppath ends with a shorty directory that contains more than one non-shorty, the detecting system should take corrective action. In this situation, also known as a "split end", all those non-shorties (directories and files) are considered to belong to one object (not properly encapsulated) identified by the containing ppath. Excluding shorties from the object permits one identifier to be a substring of another (e.g., "abcd" and "abcde" can co-exist in a pairtree), and defining ppath termination in this way prevents "hidden riders", or data residing in a pairtree that is not contained or accounted for in any object. Here is an example of an improperly encapsulated object named "bent". be/ | \--- nt/ [ split end: two files, no encapsulation ] | README.txt | report.pdf | \--- ef/ | ... If a "split end" is encountered, an importing system is encouraged to normalize it by creating a single object directory called "obj" and pushing the non-shorties in question underneath it, as in: be/ | \--- nt/ | |--- obj/ [ split end repaired with "obj" directory ] | | README.txt | | report.pdf | \--- ef/ | ... "HIP support for RFID", Pascal Urien, 15-Dec-08, This document describes an architecture based on the Host Identity Protocol (HIP), for active tags, i.e. RFIDs that include tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-Tags never expose their identity in clear text, but hide this value (typically an EPC-Code) by a particular equation (f) that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occurred between HIP- Tags and portals; they are shuttled by IP packets, through the Internet cloud. "TLS Key Generation", Pascal Urien, 15-Dec-08, The TLS protocol is widely deployed and used over the Internet. Client and server nodes compute a set of keys called the key-block, according to a pseudo random function (PRF). This draft proposes a keying infrastructure based on the TLS protocol. It suggests defining an additional Key Distribution Function (KDF) in order to deliver a set of cryptographic keys. In a peer to peer mode keys are directly produced as inputs of the KDF functions. For centralized architectures they are delivered through containers, secured with keys derived from the KDF function. "Things To Be Considered for RFC 3484 Revision", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 16-Mar-09, RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484. "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", Randall Stewart, Peter Lei, Michael Tuexen, 16-Feb-09, 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. "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 29-Dec-08, The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. Each digital signature added to a response increases the size of the response, which could result in the response message being truncated. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they prefer in a DNSSEC response by defining an EDNS option to list a client's preferred algorithms. "A three state extended PCN encoding scheme", T Moncaster, Bob Briscoe, Michael Menth, 9-Mar-09, Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This baseline encoding specified how two encoding states could be encoded into the IP header. This document specified an extension to the baseline encoding that enables three encoding states to be carried in the IP header as well as enabling limited support for end-to-end ECN. Status (to be removed by RFC Editor) This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. The PCN Working Group will be asked to adopt this memo as a Working Group document describing one of several possible experimental PCN encoding schemes. The intention is that the title of this document will change to avoid confusion with the three state marking scheme. Changes from previous drafts From 00 to 01: o Checked terminology for consistency with [I-D.ietf-pcn-baseline-encoding] o Minor editorial changes. "On RFC Streams, Headers, and Boilerplates", Leslie Daigle, Olaf Kolkman, 22-Apr-09, RFC documents contain a number of fixed elements such as the title page header, standard boilerplates and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 7-Apr-09, IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima, Thomas Nadeau, 17-Feb-09, This document specifies an inter-chassis communication protocol (ICCP) that enables PE redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", Kevin Igoe, Jerome Solinas, 8-Dec-08, Secure Shell (SSH, RFC 4251) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality and data integrity services. The purpose of this document is to show how the AES Galois/Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer "Certified Electronic Mail", Francesco Gennai, Alba Shahin, Claudio Petrucci, Alessandro Vinciarelli, 6-Feb-09, Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. After 2 years of technical tests, in 2005 the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal value. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. "Common Functions of Large Scale NAT (LSN)", Tomohiro Nishitani, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 19-Nov-08, This document defines common functions of multiple types of Large Scale Network Address Translation (NAT) that handles Unicast UDP, TCP and ICMP. "DHCP Based Configuration of Mobile Node from Home Network", Hui Deng, Peng Yang, 22-Feb-09, This document describes the mechanism for providing the host configuration parameters needed for network service from home network based on DHCPINFORM. DHCPINFORM message has been widely used by client to obtain other configuration information and could be sent to local broadcast address or server unicast address. Mobile IP specification could support DHCPINFORM broadcast or unicast message straightfully without any revision. "Providing Satellite Navigation Assistance Data using HELD", Martin Thomson, James Winterbottom, 5-Jan-09, This document describes a method for providing Global Navigation Satellite System (GNSS) assistance data using the HTTP-Enabled Location Delivery (HELD) protocol. An assistance data request is included with the HELD location request and the Location Information Server (LIS) provides assistance data along with location information. "Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources", Ted Hardie, Vidya Narayanan, 9-Mar-09, Identifying overlay networks and the resources found within in them presents a number of bootstrapping problems. While those hard problems are under discussion, this draft proposes a small set of URI-based mechanisms which are intended to be generically useful for providing pointers to peer-to-peer overlay networks in web pages, email messages, and other textual media. "MVPN: Optimized use of PIM, Wild Card Selectors, Bidirectional Tunnels, Extranets", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 29-Apr-09, Specifications for a number of important topics were arbitrarily omitted from the initial MVPN specifications, so that those specifications could be "frozen" and advanced. The current document provides some of the missing specifications. The topics covered are: (a) using Wild Card selectors to bind multicast data streams to tunnels, (b) using Multipoint-to-Multipoint Label Switched Paths as tunnels, (c) binding bidirectional customer multicast data streams to specific tunnels, (d) running PIM (i.e., sending and receiving multicast control traffic) over a set of tunnels that are created only if needed to carry multicast data traffic, and (e) extranets. "MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, Eric Gray, 6-Feb-09, This document specifies the requirements necessary to manage the elements and networks that support an MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union - Telecommunications Standardization Sector (ITU-T) and Internet Engineering Task Force (IETF) effort to include a MPLS Transport Profile within the IETF MPLS architecture. The requirements are driven by the management functionality needs defined by ITU-T for packet transport networks. Gray, et al Expires August, 2009 [page 1] Internet-Draft MPLS-TP NM Requirements February, 2009 "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", JP Vasseur, Dust Networks, 7-Mar-09, This document specifies routing metrics to be used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link attributes, this document specifies a set of routing metrics suitable to LLNs. "Updates to Referred-By in the Session Initiation Protocol (SIP).", Nadia Bishai, Salvatore Loreto, Adamu Haruna, 1-Mar-09, SIP has a mechanism for conveying the identity of the referrer of a request by means of the Referred-By header field. This header field may be used when exploding a SIP MESSAGE request to a pre-defined group URI and when exploding a SIP INVITE request to an ad-hoc group or to a pre-defined group URI. The Referred-By header is only included if the P-Asserted-Identity header field or From header field in the exploded SIP requests needs to carry another value, e.g. the URI of a pre-defined group, or a conference focus URI. In those cases, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity header field or to the From header field of the original SIP request received before exploding to convey to the receiver the identity of the original inviting sender. RFC 3892 restricts the value of the header to only one SIP URI. However the P-Asserted-Identity header field currently allows two URI values and may be expanded in the future to carry more than two values as described in draft-ietf-sipping-update-pai-09. This document extends the Referred-By definition to support more than one value as well. "Management Information Base for the SEcure Neighbor Discovery (SEND) protocol", Alberto Garcia-Martinez, 18-Dec-08, This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol. "Management Information Base for Cryptographically Generated Addresses (CGA)", Alberto Garcia-Martinez, 18-Dec-08, This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA). "Lightweight DHCPv6 Relay Agent (LDRA)", David Miles, Sven Ooghe, Wojciech Dec, Suresh Krishnan, Alan Kavanagh, 18-Nov-08, This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. "Secure DHCPv6 Using CGAs", Sheng Jiang, Sean Shen, 8-Jan-09, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 16-Feb-09, This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. "Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6 Coexistence and Transition", Xing Li, Maoke Chen, Congxiao Bao, Hong Zhang, Jianping Wu, 9-Feb-09, This document presents the concept and practice of the prefix- specific and stateless address mapping mechanism (IVI) for IPv4/IPv6 coexistence and transition. In this scheme, subsets of the IPv4 addresses are embedded in prefix-specific IPv6 addresses and these IPv6 addresses can therefore communicate with the global IPv6 networks directly and can communicate with the global IPv4 networks via stateless gateways. The IVI scheme supports the end-to-end address transparency and incremental deployment. This document is a comprehensive report on the IVI design and its deployment in large scale public networks. Version 01 of the IVI document is a simplified version of version 00 to present the main concepts and recent practice of the IVI translation scheme. "The Model for Net and App Interaction", Ray Aatarashi, Megumi Ninomiya, 25-Mar-09, This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. "The VLAN Model for Applications", Megumi Ninomiya, Ray Aatarashi, 25-Mar-09, This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. This document propose the VLAN model for the application users. "The References Header for SIP", Dale Worley, 22-Feb-09, This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. "Common TCP Evaluation Suite", Lachlan Andrew, Sally Floyd, Gang Wang, 6-Jan-09, This document presents an evaluation test suite for the initial evaluation of proposed TCP modifications. The goal of the test suite is to allow researchers to quickly and easily evaluate their proposed TCP extensions in simulators and testbeds using a common set of well- defined, standard test cases, in order to compare and contrast proposals against standard TCP as well as other proposed modifications. This test suite is not intended to result in an exhaustive evaluation of a proposed TCP modification or new congestion control mechanism. Instead, the focus is on quickly and easily generating an initial evaluation report that allows the networking community to understand and discuss the behavioral aspects of a new proposal, in order to guide further experimentation that will be needed to fully investigate the specific aspects of a new proposal. "DNS SRV Records for HTTP", Cullen Jennings, 8-Mar-09, This document specifies a new URI scheme called http+srv which uses a DNS SRV lookup to locate a HTTP server. The http+srv scheme operates in the same way as an http scheme but instead of the normal DNS lookup that a http scheme would use, it first tries an DNS SRV lookup. This memo also defines a https+srv scheme that operates in the same was as an https URI but uses DNS SRV lookups. The draft is being discussed on the apps-discuss@ietf.org list. "HTTP API for Updating DNS Records", Cullen Jennings, Tom Daly, Jeremy Hitchcock, 8-Mar-09, This specification defines a simple HTTP based scheme for clients to update DNS records. The draft is being discussed on the apps-discuss@ietf.org list. "GMPLS RSVP-TE recovery extension for data plane initiated reversion", Attila Takacs, Benoit Tremblay, 9-Mar-09, GMPLS RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently these extensions cannot signal request for revertive protection neither values for the associated timers to the remote endpoint. This document extends the PROTECTION Object allowing sub-TLVs, and defines two sub-TLVs to carry wait-to-restore and hold-off intervals. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Nic Neate, 9-Mar-09, Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address issues that arise when a P2MP-TE LSP is signaled in multi-domain networks. Specifically, it does not provide a mechanism to avoid re-merges in inter-domain P2MP TE LSPs. This document provides a framework and protocol extensions for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., 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 Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). "Camellia Cipher Suites for TLS", Akihiro Kato, Masayuki Kanda, Satoru Kanno, 5-Apr-09, This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the ciphersuites originally specifed in RFC 4132 by counterparts using the newer cryptographic hash algorithms from the SHA-2 familiy. This document obsoletes RFC 4132. "Problem Statement and Requirement of Simple IP Multi-homing of the Host", Min Hui, Hui Deng, 9-Mar-09, This document discusses current issues with simple IP multi-homing. In order to have deep understanding of the issue, the document also analyzes related works in IETF. In the end gives the requirements of the simple IP multi-homing in concern of technical implements. Simple IP multi-homing focuses on simultaneous multiple IP connections of the host. "Best Current Practice for IP-based In-Vehicle Emergency Calls", Brian Rosen, Hannes Tschofenig, Ulrich Dietz, 7-Mar-09, This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information. "Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne, 6-Mar-09, For location-based applications, such as emergency calling or roadside assistance, the identity of the requestor is less important than accurate and trustworthy location information. A number of protocols are available to supply end systems with either civic or geodetic information. For some applications it is an important requirement that location information has not been modified in transit or by the end point itself. This document investigates different threats, the adversary model, and outlines three possible solutions. The document concludes with a suggestion on how to move forward. "MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov Weingarten, 7-May-09, The intention of this document is to analyze the set of requirements for Operations, Administration, and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether existing OAM tools (either from the current MPLS toolset or from the ITU-T documents) can be applied to these requirements. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP. "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", Jari Arkko, Vesa Lehtovirta, Pasi Eronen, 18-Nov-08, This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. "A Uniform Resource Name (URN) Namespace for CableLabs", Eduardo Cardona, Sumanth Channabasappa, Jean-Francois Mule, 5-Jan-09, This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by Cable Television Laboratories Inc. (CableLabs). CableLabs publishes specifications that define unique and persistent resources that make use of the Cablelabs URN namespace. "SRTP Store-and-Forward Use Cases and Requirements", Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman, 9-Mar-09, The Secure Real-time Transport Protocol (SRTP) was designed to allow simple and efficient protection of RTP. To provide this, encryption and authentication of media and control signaling are tightly coupled to the RTP session, and the information in the RTP header. Hence, in general, it is not possible to perform store-and-forward of protected media. This document gives, based on a use case analysis, requirements that SRTP and new SRTP transforms need to satisfy in order to allow secure store-and-forward operation. A first outline on how to introduce the needed new functionality and transforms in SRTP is also presented. "Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6 Domains", Niklas Neumann, Xiaoming Fu, Jun Lei, Gong Zhang, 9-Mar-09, This document specifies mechanisms to setup and maintain handover and data forwarding procedures that allow a mobile node to move between different domains that provide (localized) network-based mobility support based on Proxy Mobile IPv6 for that node. "End-to-End Identity Important in the Session Initiation Protocol (SIP)", John Elwell, 25-Feb-09, This document surveys existing mechanisms in the Session Initiation Protocol (SIP) for identifying and authenticating the source of a SIP request (or caller identification). It describes how identification and authentication are not always end-to-end and the problems that this can lead to, particularly since media security based on techniques such as DTLS-SRTP is dependent on end-to-end authenticated identification of parties. This work is being discussed on the sip@ietf.org mailing list. "A way for a host to indicate support for 240.0.0.0/4 addresses", Teemu Savolainen, 20-Feb-09, This document describes how in certain deployment scenarios the 240.0.0.0/4 address space can be taken into use in incremental and backwards compatible manner. "Bulk Re-registration for Proxy Mobile IPv6", Domagoj Premec, Basavaraj Patil, Suresh Krishnan, 9-Mar-09, The Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This mechanism is also intended to be used by a MAG to re-establish bindings at a new LMA when its old LMA fails. "Teredo Extensions", Dave Thaler, 8-Mar-09, This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs), and support for more efficient communication. "BGP Class of Service Interconnection", Thomas Martin Knoll, 11-May-09, This document focuses on Class of Service Interconnection at inter- domain interconnection points. It specifies two new transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability" is deliberately kept simple and denotes the general EF, AF Group BE and LE forwarding support across the advertising AS. The second "CoS Parameter Attribute" is of variable length and contains a more detailed description of available forwarding behaviours using the PHB id Code encoding. Each PHB id Code is associated with rate and size based traffic parameters, which will be applied in the ingress AS Border Router for admission control purposes to a given forwarding behaviour. "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", Bill Steeg, Ali Begen, Tom Caenegem, Zeev Vax, 16-Apr-09, When an RTP receiver joins a primary multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition interval, size of the Reference Information as well as the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTCP protocol machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/accompanies the primary multicast stream. This unicast RTP flow may be transmitted at a faster than natural rate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. "TICTOC Requirement", Silvana Rodrigues, Kurt Lindqvist, 2-Mar-09, Distribution of high precision time and frequency over the Internet and special purpose IP networks is becoming more and more needed as IP networks replace legacy networks and as new applications with need for frequency and time are developed on the Internet. The IETF formed the TICTOC working group to address the problem and perform an analysis on existing solutions and the needs. This document summarizes application needs, as described and agreed on at an TICTOC interim meeting held in Paris from June 16 to 18, 2008. "Private Extensions to the Session Initiation Protocol (SIP) for Asserter Identification within Trusted Networks", Hadriel Kaplan, 8-Mar-09, This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to identify the asserter of private user identity defined in RFC 3325. The use of these extensions is only applicable inside a set of administrative domains with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general identity model suitable for use between different trust domains, or use in the Internet at large. "Opaque MSRP Path Uri", Derek MacDonald, 9-Mar-09, The Message Session Relay Protocol(MSRP) does not allow privacy and topology hiding, such that MSRP users can hide the IP Address of their systems. This limitation is due to the fact that MSRP Path headers contain physical IP addresses. This document describes a mechanism which adds a level of indirection to allow privacy and topology hiding, to prevent remote parties and a man-in-the-middle from learning the IP Address and port information of the MSRP client. It also defines the option tag msrp-opaque, to indicate such support. "Datagram Transport Layer Security Transport Model for SNMP", Wesley Hardaker, 8-May-09, This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides authentication and privacy services for SNMP applications. This document describes how the DTLS Transport Model (DTLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators, operate in environments where a connectionless (e.g. UDP or SCTP) transport is preferred, and integrates well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for monitoring and managing the DTLS Transport Model for SNMP. "IP Flow Anonymisation Support", Elisa Boschi, Brian Trammell, 30-Mar-09, This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymization metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", Mary Barnes, Chris Boulton, Lorenzo Miniero, Simon Romano, 9-Mar-09, This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. "Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, 9-Mar-09, This document describes a Session Traversal Utilities for NAT (STUN) usage for discovering the path MTU between a client and a server. "Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs", Zafar Ali, 9-Mar-09, There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object [RFC3471], [RFC3473]. The document proposes use of some dedicated PID values to cover some typical cases of multiple payloads carried by the LSP. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "IPv4 ID Uniqueness Requirements", Joseph Touch, Matt Mathis, 9-Mar-09, The IPv4 Identification (ID) field enables fragmentation and reassembly, but is required and must be unique within the maximum segment lifetime on all packets. If implemented as required, this uniqueness would limit all connections to 6.4 Mbps; since this is ubiquitously not the case, it is clear that existing systems violate the current requirement. This document updates the requirements for the IP ID field to more closely reflect current practice, and to more closely match IPv6, in which the field is defined only when a packet is actually fragmented. Even when fragmented, this document recommends that the ID field uniqueness consider the reordering context, rather than an arbitrary, unenforced upper bound on segment lifetime. "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy, 28-Feb-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process. The SMF MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting multicast forwarding problems. "HIP Extensions for Object to Object Communications", Gyu Myoung Lee, Jun Kyun Choi, Taesoo Chung, 12-Mar-09, This document explains the concept of object to object communications and specifies naming and addressing issues for object identification. In order to use Host Identity Protocol (HIP) for object to object communications, this document provides the extended architecture of HIP according to mapping relationships between host and object(s). In addition, packet formats and considerations for HIP extensions concerning object are specified. "Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, 9-Mar-09, The purpose of this document is to provide applicability of Access Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements), is described in a multi-service reference architecture in order to perform QoS-related, service- related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device- device communication. This allows for performing access link related operations within those network elements to meet performance objectives. "Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 1-May-09, Diversion header is not standardized but widely used to convey diverting information in Session Initiation Protocol (SIP) signaling. This informational document proposes a way to make interwork call diversion information contained in a Diversion header with a History- Info header. In addition, an interworking policy is proposed to manage the headers coexistence. The History-Info header is described in [RFC4244]. Since the Diversion header is used in many existing networks implementations for transport of diversion informationand its interworking with standardized solutions is not obvious, an interworking recommendation is needed. "Advertisement of the best external route in BGP", Pedro Roque Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, 25-Mar-09, The base BGP specifications prevent a BGP speaker from advertising any route that is not the best route for a BGP destination. This document specifies a modification of this rule. Routes are divided into two categories, "external" and "internal". A specification is provided for choosing a "best external route" (for a particular value of the Network Layer Reachability Information). A BGP speaker is then allowed to advertise its "best external route" to its internal BGP peers, even if that is not the best route for the destination. The document explains why advertising the best external route can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. The document also generalizes the notions of "internal" and "external" so that they can be applied to Route Reflector Clusters and Autonomous System Confederations. "Location and Discovery of Subsets of Resources", Lican Huang, 16-Jan-09, This file is a proposal for location and discovery of filter resources selected by search-conditions. The peers,which are virtually grouped, construct n-tuple overlay virtual hierarchical tree overlay network. With cached addresses of peers, the overload of traffic in tree structure can be avoided. The resources are classified into hierarchical domains, and registered into the peers which are located in the same domain virtual groups as the resources'. This proposal supports flexible queries by a SQL-like query statement. "Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet", Brian Rosen, 5-Jan-09, The -phonebcp draft currently requires endpoints to disable sending a BYE on an emergency call. Insufficient justification and lack of attention to the entire problem has caused comment on that section of the document. This document attempts to define the problem and the requirements to controlling disconnect on emergency calls. "IESG Procedures for Handling of Independent and IRTF Stream Submissions", Harald Alvestrand, Russ Housley, 19-Nov-08, This document describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. "Dynamic Host Configuration Protocol Option for Dual-Stack Lite", David Hankins, 23-Mar-09, This document describes how Dual-Stack Lite configuration (the Softwire Concentrator (SC)'s address) can be obtained by a Softwire Initiator (SI) via DHCPv6. "Guidance on Interoperation and Implementation Reports", Lisa Dusseault, Robert Sparks, 1-Apr-09, Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. "SASL Mechanism Family for External Authentication: EXTERNAL-*", Simon Josefsson, 18-Apr-09, This document describes a way to perform client authentication in the Simple Authentication and Security Layer (SASL) framework by referring to the client authentication provided by an external security layer. We specify a SASL mechanism family EXTERNAL-* and one instance EXTERNAL-TLS that rely on the Transport Layer Security (TLS) protocol. This mechanism differs to the existing EXTERNAL mechanism by alleviating the a priori assumptions that servers and clients needs somehow negotiate out of band which secure channel that is intended. This document also discuss the implementation of authorization decisions. See for more information. "Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08, The Transport Layer Security (TLS) protocol does not support the use of client public key pairs without X.509 security certificates. This document circumvents this limitation: an end-entity has access to the public domain private key of a dummy (or "explicitly meaningless") Certification Authority (CA), and can thus freely issue an X.509 security certificate for interoperability purposes. Given these workaround requirement and solution approach, the document limits itself to the strict minimal set of standardization provisions. This supports the orderly cohabitation of auto issued certificates and normal TLS traffic relying on the full Public Key Infrastructure (PKI) model. "Problems observed with RSVP recovery signaling", Andrew Rhodes, Nic Neate, David McWalter, 4-Mar-09, Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider. "GSS-API: Delegate if approved by policy", Love Astrand, Sam Hartman, 15-Jan-09, Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers as well as CIFS file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). "Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Headers", Julian Reschke, 30-Dec-08, By default, message header parameters in Hypertext Transfer Protocol (HTTP) messages can not carry characters outside the ISO-8859-1 character set. RFC 2231 defines an escaping mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies a profile of that encoding suitable for use in HTTP. "EDNS Option for performing a data PING", Bert Hubert, David Ulevitch, 20-Apr-09, For various reasons, it may be desirable to ask a remote nameserver to add certain data to the response to a query. This document describes an EDNS option that implements such behavioiur. "Rbridge Notes", Donald Eastlake 3rd, 10-Dec-08, This document provides additional informational material related to RBridges, which are devices that implement the TRILL protocol. It is a supplement to the RBridges base protocol specification and includes discussion of tradeoffs in some features and configurations of RBridges. In addition, it provides a sketch of a proof that, with reasonable assumptions, persistent loops do not occur in a TRILL campus. "Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6", Hidetoshi Yokota, Sri Gundavelli, Kent Leung, 9-Apr-09, Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching. "Images in RFCs", Robert Braden, John Klensin, 24-Nov-08, Documents in the RFC series normally use only plain-text ASCII characters and a fixed-width font. However, there is sometimes a need to supplement the ASCII text with images -- e.g., graphics, equations, or pictures. The historic solution to this requirement has allowed secondary PDF and/or Postscript files, but this approach has seldom been used because it is awkward for authors and publisher. This memo suggests a convenient scheme for logically including authoritative diagrams, illustrations, equations, or other graphics within RFCs. "The Metalink Download Description Format", Anthony Bryan, 4-Mar-09, This document specifies Metalink Documents, an XML-based download description format. "Resolver side mitigations", Wouter Wijngaards, 24-Feb-09, This document describes a set of mitigations that stop the known variations of the Kaminsky cache poisoning attacks against the DNS system, for which only resolver side deployment is necessary. "Transport Layer Security (TLS) Authorization Using KeyNote", Angelos Keromytis, 30-Mar-09, This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to [AUTHZ]. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged during the supplemental data handshake message. "Never Ending Network Addresses: IPv4 Multiplexing through IPv6", Alessandro Spinella, 20-Jan-09, While the wide use of IPv4 "private" addresses [RFC1918] lead to a great flexibilty degree of uninterconnected networks and use of IPv6 offer a huge address space; no "nice" mechanism exist to hide overlap of existing IPv4 "private" networks if and when the sum of used address spaces is greater than the IPv4 "private" address space. This document specifies how to walk around the matter without any coordination, renumbering or IPv6 adoption by overlapping networks owners. "Encapsulation Methods for Transport of InfiniBand over MPLS Networks", Suresh Shelvapille, Vikas Puri, 6-Mar-09, An InfiniBand(IB) pseudowire (PW) is used to carry InfiniBand frames over an MPLS network. This enables service providers to offer "emulated" InfiniBand services over existing MPLS networks. This document specifies the encapsulation of InfiniBand PDUs within a pseudowire. It also specifies how islands of IB fabrics can be connected via PWs to form a single IB subnet. "SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services", Milan Patel, 7-May-09, This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. "Delay-Tolerant Networking Metadata Extension Block", Susan Symington, 3-Apr-09, This document defines an extension block that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. This Metadata Extension Block is designed to be used to carry application-level information that DTN nodes can use to make DTN-level processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The actual metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for encoding metadata as URIs, is defined in this document. Other metadata types may be defined in separate documents. "BU/BA Based Prefix Delegation Support for Mobile Networks", Behcet Sarikaya, Frank Xia, 9-Mar-09, This document defines prefix delegation support for mobile networks. Mobile Router dynamically requests its Mobile Network Prefixes from its Home Agents using Binding Update both at the home link and at the visited links. Home agents get the prefixes delegated using DHCPv6 Prefix Delegation and reply to the Mobile Router with Binding Acknowledgement. "RTP Payload Format for MPEG-4 Audio/Visual Streams", Malte Schmidt, Frans Bont, Stefan Doehla, 27-Feb-09, This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Multipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). Comments are solicited and should be addressed to the working group's mailing list at avt@ietf.org and/or the author(s). "Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections", Julian Reschke, 13-Jan-09, The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. "Comparison of OSPF-MDR and OSPF-OR", Richard Ogier, 8-Mar-09, This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison and a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability. "Comparison of OSPF-MDR and OSPF-MPR", Richard Ogier, 8-Mar-09, This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-MPR. It includes a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability, and a simulation comparison. "Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements", Greg Bernstein, 5-May-09, In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document discusses possible alternatives and enhancements to the existing approach to TED creation. This document gives architectural alternatives for these enhancements and their potential impacts on network nodes, routing protocols, and PCEs. "The OAuth Core Protocol", Eran Hammer-Lahav, Blaine Cook, 23-Mar-09, This document specifies the OAuth core protocol. OAuth provides a method for clients to access server resources on behalf of another party (such a different client or an end user). It also provides a redirection-based user agent process for end users to authorize access to clients by substituting their credentials (typically, a username and password pair) with a different set of delegation- specific credentials. "Stateless Address Mapping (SAM) Avoiding NATs and restoring the end-to-end model in IPv6", Remi Despres, 24-Mar-09, Stateless Address Mapping (SAM) is a generic mechanism to support global addressing across network zones where routing is based on a different address space. With it, the end-to-end model, lost in IPv4 with the deployment of NATs, can be restored without losing services that NAT44s offer beyond address-space extension (private addressing, basic firewall, site multihoming, privacy protection, host-rooted subnets). Global-address packets are encapsulated in local-address packets to traverse SAM zones, and global prefixes are statelessly mapped into local addresses. For the IPv6-IPv4 coexistence period, port-restricted IPv4 addresses are used to extend the global IPv4 address space. "RFC Editor Model (Version 1)", Olaf Kolkman, 22-Apr-09, The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advicory group and an (optional) Independent Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality, maintaining timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. "Clearance Sponsor Attribute", Sean Turner, 4-Mar-09, This document defines the clearance sponsor attribute. This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes. "Device Owner Attribute", Sean Turner, 4-Mar-09, This document defines the deviceOwner attribute. This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes. "Threat Model for Networks Employing AAA Proxies", Stefan Winter, Katrin Hoeper, 9-Mar-09, This memo defines a threat model for access networks with AAA proxies. Use cases of current and future applications in which AAA proxies are employed are described and it is discussed how proxies could launch attacks in the defined use cases. The risk associated with these attacks in each use case is analyzed. In addition, mitigation techniques used in current AAA deployments are discussed and best practices for mitigating the identified attacks are identified. As a result, this draft can serve as a guideline for risk assessments and problem mitigation by providers, implementers and protocol designers of systems with proxies. "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", Ed Guy, 5-Oct-08, This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. "Revised Default Values for the BGP 'Minimum Route Advertisement Interval'", Paul Jakma, 17-Nov-08, This document briefly examines what is known about the effects of the BGP MRAI timer, particularly on convergence. It highlights published work which suggests the MRAI interval as deployed has an adverse effect on the convergence time of BGP. It then recommends revised, lower default values for the MRAI timer, thought to be more suited to today's Internet environment. "LMA Discovery for Proxy Mobile IPv6", Jouni Korhonen, Vijay Devarapalli, 24-Feb-09, Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This specification describes a number of possible dynamic Local Mobility Anchor discovery solutions. "IMAP Annotation for Indicating Message Authentication Status", Murray Kucherawy, 17-Apr-09, This memo defines an application of the IMAP (Internet Message Access Protocol) Annotations facility whereby a server can store and retrieve meta-data about a message relating to message authentication tests performed on the message and the corresponding results. "Operating MPLS Transport Profile LSP in Loopback Mode", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, Carlos Pignataro, Rahul Aggarwal, Nabil Bitar, Martin Vigoureux, Italo Busi, Lieven Levrau, Laurent Ciavaglia, 9-Mar-09, This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) to operate an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) in loopback mode for management purpose. This extension can be used to loop either all traffic (i.e, data and control traffic) or only specific OAM traffic at a specified LSR on the path of the MPLS-TP LSP back to the source.Contents "PREFIX64 Comparison", Hiroshi Miyata, Marcelo Bagnulo, 9-Mar-09, This draft compares different IPv6 prefix formats that can be used by IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 Internet. The goal of the draft is asses the benefits and problems of each proposed format and make a recommendation about which prefix to use in the different scenarios considered. "Routing and Addressing in Next-Generation EnteRprises (RANGER)", Fred Templin, 6-Feb-09, RANGER is an architectural framework for scalable routing and addressing in next generation enterprise networks. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multi-homing and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements, and provides a comprehensive framework for IPv6/IPv4 coexistence. "Host Metadata for the Web", Mark Nottingham, Eran Hammer-Lahav, 10-Feb-09, This memo describes a method for locating host-specific metadata for the Web. "RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support", Glen Zorn, 17-Dec-08, This document defines a set of RADIUS Attributes which are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. "IPv6 destination header option for IPv4 translator mapping notification", Remi Denis-Courmont, 9-Mar-09, This memo defines a new IPv6 Destination header option to convey the transport mapping information from an IPv4-IPv4 protocol translator to the IPv6 end of a protocol-translated packet flow. "Session Initiation Protocol (SIP) INFO Method and Package Framework", Eric Burger, Hadriel Kaplan, Christer Holmberg, 27-Jan-09, This document defines the new SIP INFO method and a mechanism for defining, negotiating and exchanging Info Packages that use the INFO method. Applications that need to exchange session-related information within a SIP INVITE-created dialog, also known as application level information, use these INFO requests. This draft addresses issues and open items from RFC 2976 and replaces it. "RADIUS Support for Prefix Authorization", Behcet Sarikaya, Frank Xia, 9-Mar-09, This document specifies a new attribute for supporting prefix authorization. Using RADIUS protocol, a client requests prefixes from a server; the client gives back the prefixes to the server; the client is responsible for renewing the prefixes when the lifetime expires. The RADIUS server can also renumber prefixes. RADIUS clients can be home agents in MIPv6 and NEMO scenario, local mobile anchors in Proxy MIPv6 scenario, or common access routers. "Using mLDP through a Backbone where there is no Route to the Root", IJsbrand Wijnands, Eric Rosen, Maria Napierala, 7-Apr-09, The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address which is known to the intermediate nodes. "RTP Payload Format for Bluetooth's SBC audio codec", Christian Hoene, Frans Bont, 17-Dec-08, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Volker Hilt, 7-Mar-09, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. "Requirements for the Support of Continuously Varying Values in Presence", Martin Thomson, 16-Dec-08, The attributes of continuous-valued data are examined in respect to presence systems. The limitations of the existing presence system with respect to continuous-valued data is examined. Requirements are formulated that would enable the use of the presence system for this data, with an emphasis on providing the watcher with a means of control over the measurement process. "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion", Mohammed Boucadair, Pierre Levis, Gabor Bajko, Teemu Savolainen, 30-Jan-09, This memo proposes a solution, based on fractional addresses, to face the IPv4 public address exhaustion. It details the solution and presents a mock-up implementation, with the results of tests that validate the concept. It also describes architectures and how fractional addresses are used to overcome the IPv4 address shortage. A comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions is also elaborated in the document. "IPv6 Inverse Neighbor Discovery Update", Pascal Thubert, Eric Levy-Abegnoli, 27-Feb-09, This draft updates the Inverse Discovery Specification [RFC3122] to provide Secure Neighbor Discovery. The behaviour of the protocol is slightly amended to enable an easier management of the addresses on a link and enable Secure ND. "Renumbering still needs work", Brian Carpenter, Randall Atkinson, Hannu Flinck, 6-May-09, This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally there is a gap analysis identifying possible areas for future work. "Local Mobile Anchor Discovery Using DHCP", Frank Xia, Behcet Sarikaya, 29-Apr-09, This draft defines a DHCP-based scheme to enable dynamic discovery of a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. Existing Dynamic Host Configuration Protocol (DHCP) options are used allowing a Mobile Access Gateway (MAG) to request the LMA's IP address, Fully Qualified Domain Name (FQDN), or home network prefix via the DHCP response. "Service Differentiation Using Virtualization of Mobile Network", Chulhyun Park, Eun Paik, 11-Mar-09, A mobile network can be multihomed as described in [RFC4980]. This document describes the experimental result of service differentiation using multihoming of multiple prefixes. The multiple prefixes in IPv6 NEMO implements multiple virtual mobile network on a single physical NEMO. Then, service differentiation can be achieved using several virtual mobile networks that exist on a single mobile network. As a result, this configuration can be used for service differentiation for each mobile network node inside the mobile network by prioritizing among the virutal mobile networks or forwarding traffic from each virtual mobile network to different access networks. In this experiment, a mobile router with multiple interfaces can make connection to several access networks simultaneoulsly. "CGA Extension Header of IPv6", Dong Zhang, Padmanabha Nallur, 11-May-09, This document specifies a method based on Cryptographically Generated Addresses (CGA) for protecting the IPv6 network from address spoofing. The basic idea is to define a new IPv6 extension header which is called CGA header. Three new options of CGA header are introduced to satisfy the need of verification between all CGA-aware nodes. This document also illustrates the proposed verification procedure under several different situations. Additionally, a possible alternative way using destination options header to take CGA information is described. "Framework and Requirements for Composite Transport Group (CTG)", So Ning, Andrew Malis, Dave McDysan, Lucy Yong, Frederic JOUNAY, 14-Feb-09, This document states a traffic distribution problem in today's IP/ MPLS network when multiple physical or logical links are configured between two routers. The document presents a Composite Transport Group framework as TE transport methodology over composite link for the problems and specifies a set of requirements for Composite Transport Group(CTG). "Learning the IPv6 Prefix of an IPv6/IPv4 Translator", Dan Wing, Xuewei Wang, Xiaohu Xu, 11-May-09, Some IPv6 applications obtain IPv4 address literals and want to communicate with those IPv4 hosts through an IPv6/IPv4 translator. The IPv6 application can send an IPv6 packet through the translator if it knows the IPv6 prefix of the IPv6/IPv4 translator. In many IPv6/IPv4 translation deployments, that IPv6 prefix is not fixed; rather, the prefix is chosen by the network operator. This specification provides three methods for a host to learn the IPv6 prefix of its IPv6/IPv4 translator. "Report from the IETF workshop on P2P Infrastructure, May 28, 2008", Jon Peterson, Alissa Cooper, 23-Feb-09, This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased P2P traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract out feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. "An extension to RELOAD to support Direct Response and Relay Peer routing", XingFeng Jiang, Roni Even, 27-Dec-08, This document proposes an extension to RELOAD to support direct response and relay peer routing modes. The document starts with the problem statement and addresses concerns about these two routing modes mentioned in RELOAD. Then methods about how to detect whether a node is publicly reachable in P2PSIP situations are discussed. The last part proposes extensions to RELOAD for supporting these additional routing modes. "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao Bao, 24-Feb-09, This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. "IP/ICMP Translation Algorithm", Fred Baker, 21-Feb-09, This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateless and a stateful mode. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment with neither state nor configuration in the IP/ICMP translator. In the stateful mode, translation state is maintained between IPv4 address/transport_port tuples and IPv6 address/ transport_port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Significant issues exist in the stateless and stateful modes that are not addressed in this document, related to the address assignment and the maintenance of the translation tables, respectively. This document confines itself to the actual translation. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. The changes in this document reflect five components: 1. Redescribing the network model to map to present and projected usage. 2. Moving the address format to the framework document, to coordinate with other drafts on the topic. 3. Description of both stateful and stateless operation. 4. Some changes in ICMP. 5. Updating references.Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. "LDAP schema for storing SCRAM secrets", Alexey Melnikov, 19-Nov-08, This memo describes how authPassword LDAP attribute can be used for storing secrets used by Salted Challenge Response (SCRAM) Simple Authentication and Security Layer (SASL) Mechanism. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-sasl@imc.org. "DTN Bundle Metadata Confidentiality Specification", Peter Lovell, 8-Mar-09, This document described a confidentiality ciphersuite for metadata in Delay-Tolerant Networking (DTN) Bundle Protocol (BP) bundles. The content has been incorporated into the Bundle Security Protocol specification [refs.DTNBSP] and this separate document is now withdrawn. "DTN EID References Specification", Peter Lovell, 8-Mar-09, This document described a convention for storing references to Delay- Tolerant Networking (DTN) Bundle Protocol (BP) endpoint identifiers [EIDs] within extension blocks of bundles. The content has been incorporated into RFC 5050 [refs.DTNBP] and this separate document is now withdrawn. "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", Greg Bernstein, 5-May-09, The operation of optical networks requires information on the physical characterization of optical network elements, subsystems, devices, and cabling. These physical characteristics may be important to consider when using a GMPLS control plane to support path setup and maintenance. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with GMPLS control plane protocols and mechanisms to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks. "Information Model for Impaired Optical Path Validation", Greg Bernstein, 24-Feb-09, This document provides an information model for the optical impairment characteristics of optical network elements for use in path computation and optical path validation. This model is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This model is intentionally compatible with a previous impairment free optical information model used in optical path computations and wavelength assignment. "Delivery of Request-URI Targets to User Agents", Jonathan Rosenberg, Hans Erik van Elburg, Christer Holmberg, Francois Audet, Shida Schubert, 9-Mar-09, When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a registered or configured contact URI of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History-Info header field which allows it to be used to support those cases. "Time synchronization method in packet-switched transport network for mobile backhaul", Li He, Fei Su, 8-Apr-09, This document introduces a phase/time transfer application mode employing popular packet-based method IEEE Std 1588-2008 i.e. PTP with support of common physical layer method Synchronous Ethernet in a packet-switched transport network for mobile backhaul and phase/ time transfer protection switching. "Additional Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 9-Mar-09, This memorandum aims at defining additional ANCP protocol extensions (beyond those already defined) to support some of the Multicast use cases defined in the ANCP Framework document that are not yet supported. "NAT444 with ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 9-Mar-09, This document describes one of the network models that is designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence. "Multiprotocol Label Switching Transport Profile Ring Protection Analysis", Jian Yang, Hui Su, 30-Apr-09, The three potential solutions to the MPLS-TP ring protection were addressed in the report of the IETF-ITU-T Joint Working Team(JWT). Each solution has different attributes and advantages. This document provides an analysis for MPLS-TP based on the ring protection. "BFD Extensions in Support of Performance Measurement", Xinchun Guo, Mach Chen, 9-Mar-09, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to support Performance Measurement for IP/MPLS network. Specifically, it defines BFD extensions for measuring packet loss, delay and delay variation for arbitrary paths between systems. "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum, Masahito Endo, 7-Mar-09, DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with NAT64, an IPv6 IPv4 translator to enable client- server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with NAT64. "PMIPv6 Extensions for Multicast", Hitoshi Asaeda, Pierrick Seite, Jinwei Xia, 8-Mar-09, This document describes Proxy Mobile IPv6 (PMIPv6) extensions and solutions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and establish a bi-directional tunnel to manage mobility for mobile nodes within the Proxy Mobile IPv6 domain. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. "Extended Home Link Support for DSMIPv6", Domagoj Premec, 9-Mar-09, Mobile IPv6 Support for Dual Stack Hosts and Routers allows the mobile node to maintain connectivity for its IPv6 home address while attached to the IPv4-only home link. This document specifies how a mobile node can maintain connectivity for its IPv4 home address while attached to an IPv6-only home link. "The A+P Approach to the IPv4 Address Shortage", Randy Bush, Olaf Maennel, Jan Zorz, Steven Bellovin, Luca Cittadini, 9-Mar-09, We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before we run out of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft discusses the possibility of address sharing by treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a device, we propose to extended the address by "stealing" bits from the port number in the TCP/UDP header, leaving the applications a reduced range of ports. This means assigning the same IP to different clients (e.g., CPE's, mobile phones), each with its port-range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process - not some smart boxes in the core. "Definition of Managed Objects for the MANET Optimized Link State Routing Protocol version 2", Robert Cole, Thomas Clausen, 21-Feb-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring and managing aspects of the Optimized Link State Routing protocol version 2. The Optimized Link State Routing MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting Mobile Ad-Hoc Networks routing problems. "DHCPv6 and CGA Interaction: Problem Statement", Sheng Jiang, Sean Shen, 12-Jan-09, This document presents a problem statement for the possible interactions between DHCPv6 and CGA. Firstly, in order to support the co-existing scenarios of DHCPv6 and CGA, Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. Then, some extended scenarios are also discussed in this document, including using CGAs in DHCPv6 operations to enhance the security features and using DHCPv6 to serve the CGA generation. "IPv6-to-IPv6 Network Address Translation (NAT66)", Margaret Wasserman, Fred Baker, 9-Mar-09, This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Address Translation (NAT66) function that provides the address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while minimizing, but not completely eliminating, the problems associated with NAT44. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Multi-Party Text Chat", Peter Saint-Andre, Salvatore Loreto, Fabio Forno, 8-Mar-09, This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a many-to-many chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). "Real-time Transport Control Protocol (RTCP) in Overlay Multicast", Jegadish Devadoss, Joerg Ott, Igor Curcio, 9-Mar-09, The Real-time Transport Control Protocol (RTCP) is designed to operate along with Real-time Transport Protocol (RTP) in unicast, single-source multicast and any-source multicast environments. With the availability of overlay multicast and Application Layer Multicast (ALM), the suitability of RTCP in such environments needs to be analyzed. The applicability of the existing RTCP reporting architectures in overlay multicast and ALM environments are investigated and the new features that may be required are discussed in this document. "Session Initiation Protocol (SIP) Event Package for Content Push Delivery", Martin Dolly, Salvatore Loreto, Kent Bogestam, 6-Mar-09, This document specifies an event package for content push delivery protocol over SIP. The purpose is to allow an application on a UA to subscribe to updates to its own application events containing either content or references to the content. This document describes how content can be pushed out to an application by the use of push events. A new SIP event package is defined for notification of push events for content delivery. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, 9-Mar-09, This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. "Threshold Secret Sharing", David McGrew, Praveen Patnala, Alfred Hoenes, 9-Mar-09, Threshold secret sharing (TSS) provides a way to generate N shares from a value, so that any M of those shares can be used to reconstruct the original value, but any M-1 shares provide no information about that value. This method can provide shared access control on key material and other secrets that must be strongly protected. This note defines a threshold secret sharing method based on polynomial interpolation in GF(256) and a format for the storage and transmission of shares. It also provides usage guidance, describes how to test an implementation, and supplies test cases. "Mechanism for performing LSP-Ping over RSVP protection paths", Nitin Bahadur, Kireeti Kompella, Kenji Kumaki, 1-Dec-08, This document describes methods for performing lsp ping over mpls rsvp-te protection paths, when the protection paths are not in use. Conventional LSP-Ping follows the same path as data traffic. In some cases, it might be useful to follow the data path of protection paths (detours and bypasses) to ensure that the those paths are fully functional. This document describes enhancements to LSP-Ping to perform ping over such paths. "Considerations for IPv6 Address Selection Policy Changes", Tim Chown, 9-Mar-09, RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines mechanisms for nodes to perform source and destination address selection choices when faced with multiple addresses to choose between when initiating a communication. While RFC3484 recognised the need for implementations to be able to change the policy table, a requirement has now also emerged for administrators to be able to dynamically change the policy tables from a central control point, and for nomadic hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC3484, where default policies are currently defined. "Comcast's ISP Experiences In a P4P Technical Trial", Chris Griffiths, Jason Livingood, Laird Popkin, Richard Woundy, Yang Yang, 27-Apr-09, This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008. This trial used iTracker technology being considered by the IETF, as part of the Application Layer Transport Optimization (ALTO) working group. "Authenticated Encryption with AES-CBC and HMAC-SHA1 (and other generic combinations of ciphers and MACs)", David McGrew, 9-Mar-09, This document specifies algorithms for authenticated encryption with additional authenticated data (AEAD) that are based on the composition of the Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC) mode of operation for encryption, and the HMAC- SHA1 message authentication code (MAC). It also separately defines a generic composition method that can be used with other MACs and randomized ciphers (that is, ciphers that use random initialization vectors). These algorithms are randomized, and thus are suitable for use with applications that cannot provide distinct nonces to each invocation of the AEAD encrypt operation. "DRINKS Use cases and Protocol Requirements", Sumanth Channabasappa, 3-Feb-09, This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. "BGP Prefix Origin Validation", Pradosh Mohapatra, John Scudder, 5-Mar-09, A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix hijacking and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized. This document describes a simple validation mechanism to partially satisfy this requirement. "On the implementation of TCP urgent data", Fernando Gont, Andrew Yourtchenko, 2-Feb-09, This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, and raises awareness about the reliability of TCP urgent indications in the current Internet. "On the generation of TCP timestamps", Fernando Gont, 2-Feb-09, This document describes an algorithm for selecting the timestamps (TS value) used for TCP connections that use the TCP timestamp option, such that the resulting timestamps are monotonically-increasing across connections that involve the same four-tuple {local IP address, local TCP port, remote IP address, remote TCP port}. The properties of the algorithm are such that it reduces the possibility of an attacker of guessing the exact value. Additionally, it describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. "IPv4/v6 NAT With Explicit Control (NAT-XC)", Keith Moore, 8-Mar-09, This document describes a mechanism called NAT-XC (for NAT with Explicit Control) for translating between IPv4 and IPv6. NAT-XC is distinguished from other IPv4/IPv6 translations schemes in that it separates the translation between IPv4 and IPv6 from the management of address bindings for such a translation; and is designed to allow applications to be explicitly aware of, and control, their address bindings. NAT-XC can be used by both IPv4 clients wishing to communicate via IPv6, and IPv6 clients wishing to communicate via IPv4. NAT-XC appears to be usable in a wide variety of scenarios requiring communication across IPv4/IPv6 boundaries. "Healthy Food and Special Dietary Requirements for IETF meetings", Mary Barnes, 8-Mar-09, This document describes the basic requirements for food for folks that attend IETF meetings require special diets, as well as those that prefer to eat healthy. While, the variety of special diets is quite broad, the most general categories are described. There can be controversy as to what constitutes healthy eating, but there are some common, generally available foods that comprise the basis for healthy eating and special diets. This document provides some recommendations to meeting planners, as well as participants, in handling these requirements. "DHCP options for Access Point Name and attach type indication", Basavaraj Patil, Kuntal Chowdhury, Domagoj Premec, 8-Mar-09, Access Point Names are used in wireless networks which are based on 3GPP standards to identify a specific gateway element. A mobile node which attaches via a 3GPP access network indicates the gateway to which connectivity is desired by providing the gateways access point name, in the network attach signaling messages. This document specifies a new DHCP option which enables the mobile node to request connectivity to a gateway, identified by the access point name, in DHCP messages. A mobile node whose mobility is managed by the network using Proxy Mobile IPv6 protocol may perform a handover from one access technology to another. This document defines a DHCP option which enables the host to indicate to Proxy Mobile IPv6 elements in the access network if the attachment via the new interface is a handover or a new connection. "OAuth Access Tokens using credentials", Bill hOra, Stephen Farrell, 9-Mar-09, OAuth Access Tokens using credentials is a technique for allowing user agents to obtain an OAuth access token on behalf of a user without requiring user intervention or HTTP redirection to a browser. OAuth itself is documented in the OAuth Core 1.0 Specification.Editorial Note To provide feedback on this Internet-Draft, email the authors. "Rapid Synchronisation of RTP Flows", Colin Perkins, Thomas Schierl, 9-Mar-09, This memo outlines how RTP multimedia sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. A new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. "Line identification in IPv6 Router Solicitation messages", Suresh Krishnan, Alan Kavanagh, Sven Ooghe, Balazs Varga, 8-Mar-09, In ethernet based aggregation networks, several subscriber premises may be connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received router solicitation messages. "Load Balancing based on IPv6 Anycast and pseudo-Mobility", Wanming Luo, XiaoDong Lee, Wei Mao, Mei Wang, 23-Mar-09, Load balancing is a key factor for both IPv4 to IPv6 transition mechnisms, e.g.NAT-PT or Tunnel broker, and Multihoming to improve their scalability and Robustness. In fact, that is a method, by which IP packet can be distributed across a pool of servers, instead of directing to a single server.Load balancing has been widely used by NAT, Web service and FTP service. However, current load balancing software and implementations have problems such as poor scalability, inability to balance session flow, long latency time and topological constraint on server pool. This document describes a method using pseudo-anycast and pseudo- mobility based on Mobile IPv6 to implement load balancing in session level in IPv6 network, by which those problems above can be solved. Futhermore, this method only need little modification to Mobile IPv6 in the servers' and agent's side; as for the general users, it need not any modification. "Multicast VPN fast upstream failover", Thomas Morin, Yakov Rekhter, Rahul Aggarwal, Wim Henderickx, Praveen Muley, 9-Mar-09, This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP mVPN routing so that a C-multicast route can be advertised toward a standby upstream PE. "Interworking between MPLS-TP and IP/MPLS", Riccardo Martinotti, Diego Caviglia, Nurit Sprecher, 6-Mar-09, Purpose of this ID is to illustrate interworking scenarios between network(s) supporting MPLS-TP and network(s) supporting IP/MPLS. Main interworking issues and open points are highlighted. "IP Router Alert Considerations and Usage", Francois Le Faucheur, 9-Mar-09, The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM, IGMP/MLD and MRD are some of the protocols which make use of the IP Router Alert option. This document discusses security aspects and common practices around the use of the current IP Router Alert option and discusses consequences on the use of IP Router Alert by existing or new applications. Common practices in IP Router Alert implementation facilitating router protection are also discussed. "Mobile IPv6 IPsec Route Optimization (IRO)", Arnaud Ebalard, 17-Nov-08, This memo specifies an improved alternate route optimization procedure for Mobile IPv6 designed specifically for environments where IPsec is used between peers (most probably with IKE). The replacement of the complex Return Routability procedure for a simple mechanism and the removal of HAO and RH2 extensions from exchanged packets result in performance and security improvements. "Border Router Discovery Protocol (BRDP) Based Routing", Teco Boot, 17-Nov-08, This document specifies a mechanism for routing in multi-homed edge networks. The default gateway routing mechanism is replaced with routing to Border Routers that correspond with the source address of the packets. "Using the Router Alert Option for Packet Interception in GIST", Robert Hancock, 17-Nov-08, The Generic Internet Signalling Transport (GIST) protocol depends on packet interception to identify the nodes that should participate in signalling sessions. The base protocol assumes n-tuple analysis of the packet header as the interception algorithm. This document describes an experimental extension to GIST to use the Router Alert Option (RAO) to enhance interception efficiency. It describes the tradeoffs in using such an approach including the impact on legacy equipment and protocol deployability, and also the considerations to be taken into account in selecting values for the RAO value field. "Context Reflection: Context Transfer for Proxy Mobile IPv6", Ryuji Wakikawa, Sawako Kiriyama, Jinwei Xia, 17-Nov-08, This document introduces a simple Context Transfer mechanism for Proxy Mobile IPv6. This context transfer mechanism can carry information of a mobile node between mobility anchor gateways without any assumption of inter-MAG trust nor direct connectivity. "Hierarchical OLSR", Yannick Lacharite, Maoyu Wang, Pascale Minet, Thomas Clausen, 18-Nov-08, This document describes the Hierarchical Optimized Link State Routing (HOLSR) mechanism for heterogeneous mobile ad hoc networks. In this specification a heterogeneous mobile ad hoc network is defined as a network of mobile nodes that are characterized by different communication capabilities, such as communication channels, processing powers or energy levels. The HOLSR mechanism is an extension to the OLSRv2 protocol. HOLSR takes advantage of the node's distinct communications capabilities to reduce the routing control overhead in large heterogeneous ad hoc networks, thus improving the performance of the routing mechanism. More precisely, HOLSR defines a hierarchy in the network and presents a routing scheme for this hierarchical structure with a better scalability. "An IRI/URI Namespace for International Object Identifiers (OIDs)", John Larmouth, Olivier Dubuisson, 18-Nov-08, This internet draft defines the IRI/URI scheme for International Object Identifiers. The syntax and semantics of the IRI is specified below using the International Object Identifier tree specified in [ITU-T X.660]. "The Remote Framebuffer Protocol", Tristan Richardson, John Levine, 10-Apr-09, RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces which allows a client to view and control a window system on another computer. Because it works at the framebuffer level RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC, Virtual Network Computing. "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, 18-Nov-08, This document proposes an extension for Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification. Although this document has been written specifically to introduce two new Authentication types it describes how BFD can use Hashed Message Authentication Code (HMAC) construct along with the Secure Hash algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions to authenticate the control packets. The method described in this document is generic and can be used to extend BFD to support any cryptographic hash function in the future. "Using SCTP as a Transport Layer Protocol for HTTP", Preethi Natarajan, Paul Amer, Jonathan Leighton, Fred Baker, 9-Mar-09, Hyper-Text Transfer Protocol (HTTP) [RFC2116] requires a reliable transport for end-to-end communication. While historically TCP has been used for this purpose, this document proposes an alternative -- the Stream Control Transmission Protocol (SCTP) [RFC4960]. Similar to TCP, SCTP offers a reliable end-to-end transport connection to applications. Additionally, SCTP offers other innovative services unavailable in TCP. The objectives of this draft are three-fold: (i) to highlight SCTP services that better match HTTP's needs than TCP, (ii) to propose a design for persistent and pipelined HTTP 1.1 transactions over SCTP's multistreaming service, and (iii) to share some lessons learned from implementing HTTP over SCTP. Finally, open issues warranting more discussion and/or investigation are listed. "CRAM-MD5 to historic", Kurt Zeilenga, 18-Nov-08, This document recommends the retirement of the CRAM-MD5 authentication mechanism, and discusses the reasons for doing so. This document recommends RFC 2195 and its predecessor, RFC 2095, be moved to Historic status. "Ethernet MAC Destination Address for Multicast MPLS", Thomas Morin, Wim Henderickx, Praveen Muley, Satyam Sinha, 18-Nov-08, This document identifies a set of required clarifications to make it explicit what Ethernet MAC destination address is to be used for multicast MPLS packets, and intends to provide an update to RFC5332. "Applicability of NAT-PMP with Service Provider Deployments of Network Address Translation", James Woodyatt, 19-Nov-08, In an effort to conserve global scope IPv4 address allocations, service providers are deploying network address/port translators in their interior routing domain and assigning private addresses to residential and small office subscriber sites. This document discusses the applicability of NAT-PMP is such networks to support application requiring dynamic TCP and UDP port forwarding. "vCard XML Schema", Simon Perreault, 6-May-09, This document defines the XML schema of the vCard data format. "A Session Identifier for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 8-Mar-09, There are several reasons for having a globally unique session identifier for the same SIP session, which can be maintained across B2BUA's and other SIP middle-boxes. This draft proposes a new SIP header to carry such a value: Session-ID. "Oxum: Octet Stream Sum http://www.ietf.org/internet-drafts/draft-kunze-oxum-00.txt", John Kunze, 18-Nov-08, This document specifies "oxum", a two-part number, OCTETS.STREAMS, that is a kind of simple size summary for complex digital objects. In the mainstream case of a complex object that is a set of files, the STREAMS part is the total number of files and the OCTETS part is the total number of 8-bit bytes across all those files; for example, an oxum of 876543.21 could mean a total of 876,543 bytes across 21 files. Which set of streams comprises a complex object for an oxum computation depends in general on the object's type. One important type is the stream set defined by the set of files contained in a file hierarchy. An oxum is not a checksum in that, while a changed oxum means a changed object, an unchanged oxum does not mean an unchanged object.1. The size of a digital object It can be hard to characterize the size of an arbitrary digital object. Word count, page count, image dimensions, video running time, or number of database records might all be useful metrics, depending on the type of the object. For a single file, one crude but easily obtained metric is the number of octets (8-bit bytes) in the file. This document introduces an analogous metric for a _complex digital object_, by which we mean an object that is not equivalent to a single file. A complex object may consist of a group of files or parts of one or more files (e.g., a database).2. The octet stream sum (oxum) A complex digital object that has a well-defined set of octet streams, such as a document represented by a group of 14 text and image files, has a well-defined "oxum" (octet stream sum). The oxum is a two part number such as 567898.14 which corresponds to 567,898 octets spread over 14 files. The general form of an oxum is OCTETS.STREAMS where STREAMS is the total number of streams (e.g., files) and OCTETS is the total number of octets across all those streams. In general, these two numbers will be positive integers, although there may be situations (not described here) in which it makes sense for either one of them to be left unspecified with a hyphen ('-'). The period ('.') separator is required. Other examples: 1998.10 # 1998 octets spread over 10 streams 105.3 # 105 octets, 3 streams (not 105 and 3 tenths) 21436794142.831 # almost 19 Gigabytes spread over 831 streams 709895249489.8756 # about 661 Gb, or 710 Gb if you divide by 1000 -.1 # one stream, but number of octets not known yet The oxum is designed to be machine readable and to fit into a variety of syntactic contexts, such as command lines, file paths, URL [RFC3986] query strings, and XML [XML] tags. Note that the oxum is _not_ designed as a secure digest or checksum. While an oxum cannot change without a change to the object, an unchanged oxum absolutely does not imply an unchanged object. Do not use oxum in place of a cryptographic digest algorithm (cf. SHA1 [RFC3174]).3. Oxum complex object types An _oxum object type_ is used to describe how to derive an object's stream set. For oxum to be meaningful for an object type, the type must have a well-defined, canonical stream set. Once the stream set is known, the oxum computation is straightforward and the streams can be processed in any order. One especially natural way to derive a stream set is to define a way to reduce an object type to a file group. Files are primal streams. In this document, a "regular" file is a contiguous sequence of octets with a well-defined start and end, whether the sequence is named in static storage (e.g., "memo.pdf") or is unnamed and recently retrieved (e.g., a web page) from a network socket. There are many filesystem entities that are not regular files, including directory nodes, block special files, and symbolic links. In this document, the word "file" usually refers to a regular file. A (regular) file is an oxum-ready stream. As a base case, a complex object consisting of exactly one file has an oxum of the form "OCTETS.1", as in 12345.1 Things get more interesting when dealing with more than one file. Any private or public agreement can be made about what constitutes a file group, hence a stream set, for the purposes of an oxum computation. A stream set might be declared to comprise all the attachments of an email message, or all the files resulting from a normalized dump procedure run against the tables of a database. An easily delineated group is all the files contained in a directory. Any recognized group of regular files can form on oxum stream set, including a simple manifest or list of filenames. For example, a transfer protocol might use oxum to help set the receiver's expectations in terms of total bytes and files contained in a transferred package [GRABIT]. "P4P: Provider Portal for P2P Applications", Richard Alimi, Doug Pasko, Laird Popkin, Ye Wang, Yang Yang, 18-Nov-08, P4P is a framework that enables Internet Service Providers (ISPs) and network application software distributors to work jointly and cooperatively to optimize application communications. The goals of this cooperation are to reduce network resource consumption and to accelerate network applications. In this document, we specify how P4P allows ISPs to provide network guidance to applications, allowing clients to exchange data more effectively. The applications we focus on are those that can have a choice in connection patterns, in particular peer-to-peer (P2P) applications. "Single PCN Threshold Marking by using PCN baseline encoding for both admission and termination controls", Daisuke Satoh, Yukari Maeda, Oratai Phanachet, Harutaka Ueno, 9-Mar-09, [I-D.ietf.pcn.architecture] defines two rates, admissible and supportable, per link that divide PCN traffic load into three states. PCN admission control and flow termination mechanisms operate in accordance with these three states. [I-D.ietf.pcn.baseline.encoding] defines one bit for packet marking. This document proposes an algorithm for marking and metering by using pre-congestion notification (PCN) baseline encoding for both flow admission and flow termination. The ratio of marked packets determines the three link states: no packets marked, some packets marked, and all packets marked. To achieve this marking behaviour, we use two token buckets. One is not used for marking but for a marking switch; the other is used for marking. The token bucket for marking has two thresholds. One is TBthreshold.threshold, already defined in [I-D.ietf-pcn- marking-behaviour], and the other is a new threshold, which is set to be the number of bits of a metered-packet smaller than the token bucket size. Therefore, the new threshold is larger than TBthreshold.threshold. If the amount of tokens is less than TBthreshold.threshold, all the packets are marked as defined in [I-D.ietf-pcn-marking-behaviour]. If the amount of tokens is less than the new threshold and greater than TBthreshold.threshold, one- Nth packets are marked. We evaluated the performance of admission control and flow termination using a simulation. For admission control, the results show that the performance of the algorithm was almost the same as, but slightly inferior to, that of CL [draft-briscoe-tsvwg-cl-phb-03]. For flow termination, the performance of the algorithm was almost the same as CL when the load was 1.2 times the supportable rate, but it was superior to CL when the load was high (two times the supportable rate). Furthermore, in the algorithm, over termination percentages of all the bottleneck links are almost the same in the case of multi-bottleneck. In CL, the over termination percentages of all the bottleneck links are different and those at upstream bottleneck links are higher than those at downstream bottleneck links because of accumulation of marked packets. "LDAP Dereference Control", Pierangelo Masarati, Howard Chu, 19-Nov-08, This document describes the Dereference Control for LDAP. This control is intended to provide a concise means to collect extra information related to cross-links present in entries returned as part of search responses. "LDAP "What Failed?" Control", Pierangelo Masarati, 19-Nov-08, This document describes the LDAP "What Failed?" control. This control allows DUAs to request, in response to a failed operation request, the object identifier of those extensions that caused the operation to fail. "Usage Agnostic Overlay Operation in RELOAD", Vidya Narayanan, 20-Nov-08, RELOAD [1] defines an overlay framework for providing peer-to-peer connectivity and storage/retreival primitives for applications. Applications or usages are expected to reside on top of such an overlay. In general, this is a good design that allows multiple applications to use the same overlay framework. In such a design, however, there are some decisions to be made in terms of what is an overlay function and what must be defined by a usage. These decisions should generally be based on whether the particular function is expecting an operation or guarantee from the overlay nodes in general or from a particular usage only. This type of separation is especially crucial to avoid needing flag days for upgrading nodes in order to accommodate a newer usage version for performing the overlay operation. "UDP Convergence Layers for the DTN Bundle and LTP Protocols", Hans Kruse, Shawn Ostermann, 19-Nov-08, This document specifies the use of the User Datagram Protocol (UDP) as a method for transporting DTN protocol data over the Internet. The specification covers both the use of UDP as a convergence layer for the Bundle Protocol as well as the use of UDP to carry LTP segments. "Destination-Driven On-Demand Multicast Routing Protocol", Ke Tian, Jian Ma, 19-Nov-08, Our protocol embeds a destination-driven feature into the on-demand multicast structure building process of an existing multicast protocol ODMRP (On-Demand Multicast Routing Protocol), which is a mesh-based multicast scheme and uses a forwarding group concept. The design objective of destination-driven on-demand multicast routing protocol (D-ODMRP) is to improve the multicast forwarding efficiency for wireless Ad Hoc networks. To achieve this goal, the path to reach a multicast destination is biased towards those paths passing through another multicast destination. "A SIP Event Package for Subscribing to Changes to an HTTP Resource", Adam Roach, 8-Jan-09, The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. This document further proposes that the HTTP work necessary to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources. "Alternative Proposal for Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Marc Petit-Huguenin, 9-Mar-09, This document proposes to use a shared TCP connection between a Traversal Using Relays around NAT (TURN) client and a TURN server instead of the multiple TCP connections proposed by [I-D.ietf-behave-turn-tcp] "draft-somogyi-sdp-amr-bicc-like-00", Gabor Somogyi, 21-Nov-08, This document describes and update to File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. The new format allows better interworking with widely deployed mobile telecommunication switching systems. This document updates RFC 4867 [RFC4867]. "Revisions to the BGP 'Minimum Route Advertisement Interval'", Paul Jakma, 25-Nov-08, This document revises the specification of the BGP MRAI timer, by deprecating the previously recommended values and by allowing for withdrawals to be exempted from the MRAI. "Behaviour of BitTorrent service in an IP Shared Address Environment", Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain Villefranque, 12-Jan-09, This memo describes the behaviour of BitTorrent service in the context of IP shared addresses. It provides an overview of the used testbed and main results of the tests that have been conducted in order to assess the limitations of an architecture based on shared IP addresses. "HTTP Cache-Control Extensions for Stale Content", Mark Nottingham, 28-Nov-08, This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. "Updates to the Updates to Asserted Identity in the Session Initiation Protocol (SIP)", Hadriel Kaplan, 29-Nov-08, An update to the [RFC3325] is currently being defined in [draft- update-pai], to add additional request method types and use-cases for P-Asserted-Identity applicability. The update does not, however, apply to SIP responses, ACK or CANCEL requests. This draft proposes an update to the update, to add SIP response, ACK and CANCEL support. Kaplan Expires May 29, 2009 [page 1] Updates to the Update for PAI in SIP November 2008 "Identifying ESP-NULL Packets", Manav Bhatia, 1-Dec-08, Encapsulating Security Payload (ESP) [RFC4303] provides data integrity protection, confidentiality and data origin authentication for data transported in an IP packet. There are various applications and protocols that do not require confidentiality but only need data integrity assurance or data origin authentication. Since ESP support is mandatory for IPSec, such applications end up using ESP with NULL encryption. However, because of the way ESP is defined, it is impossible for firewalls and intermediate routers to differentiate between encrypted ESP and ESP NULL packets by simply examining them. This poses problems for the firewalls since such packets cannot be filtered and identified. It poses a different set of problems for routers since such packets cannot be properly filtered, classified and prioritized. This document proposes an extension to ESP so that firewalls and routers can disambiguate between ESP encrypted and ESP NULL encrypted packets. "Portable Contacts: A Common Format and Protocol for Accessing Contacts", Joseph Smarr, 2-Dec-08, This document specifies Portable Contacts, XML and JSON address book document formats and an interface for accessing address book and friends-list information over HTTP. "Tiered Routing for IPv4 and IPv6 (TRIP)", Margaret Wasserman, 2-Dec-08, This document describes a mechanism for scalable, tiered Internet routing, called TRIP. The goal of TRIP is to decrease the growth rate of the core Internet routing tables by increasing route aggregation and constraining the propagation of multihoming and traffic engineering routes. TRIP accomplishes this goal by defining separate routing domains for edge networks and transit networks. All current, non-TRIP-aware networks and nodes are considered part of the transit domain. Edge network domains may be created by deploying TRIP at a domain-boundary routers or within IP (v4 or v6) endpoints. In addition to defining the basic TRIP mechanism, this document describes an incremental deployment path that provides a means for endpoints in TRIP-enabled edge networks to talk directly to non-TRIP- aware end-points in transit domain. This is accomplished without the need to advertise edge network prefixes in the global routing tables or to create a separate global routing domain for edge network prefixes. "Policy based monitoring and learning of context for enhanced QoS guarantees", Ilka Miloucheva, Christof Brandauer, Georg Panholzer, 4-Dec-08, In order to enhance the policy provisioning and QoS guarantees, policy monitoring and context learning facilities are used. This document is focussed on facilities for monitoring and learning of context integrated in autonomous policy management system for enhanced user-centric Quality of Service (QoS) guarantees in heterogeneous Internet environment. The autonomous policy management includes components aimed at automation of QoS policy specification, provisioning and adaptation based on common policy repository. Integration of monitoring and context learning facilities allows to consider measurement and context data for more efficient policy provisioning and adaptation. The goal is to collect measurement and context information, in order to support automated policy decision and adaptation of actor's policies, when specific events (patterns) are detected in a given network context. "Suite B Certificate and Certificate Revocation List (CRL) Profile", Jerome Solinas, L Zieglar, 6-May-09, This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile." "Compressed Bundle Header Encoding (CBHE)", Scott Burleigh, 9-Apr-09, This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed manner within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention. CBHE compression is a convergence-layer adaptation. It is opaque to bundle processing. It therefore has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence layer adaptation implementations. "Real-time Transport Control Protocol Extension Report for Run Length Encoding of Discarded Packets", Joerg Ott, Igor Curcio, Varun Singh, 8-Dec-08, The Real-time Transport Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the jitter buffer after successful reception. "Multiple Tunnel Support for Mobile IPv4", Sri Gundavelli, Kent Leung, 8-Dec-08, This document defines extensions to Mobile IPv4 protocol for allowing a mobile node or a mobile router with multiple interfaces to register a care-of address for each of the available interfaces and to simultaneously establish multiple Mobile IP tunnels to the home agent, each through a different interface path. This capability is required for enabling a mobile node to utilize all the available wireless access links and build an higher aggregated data pipe to the home agent by setting the home address reachability over all of those tunnel paths. "Internet Message Access Protocol (IMAP) - URL Access Identifier Extension", Neil Cook, 26-Mar-09, The existing IMAP URL specification (RFC 5092) lists several identifiers and identifier prefixes, that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new identifiers as well as an IANA mechanism to register new identifiers for future applications. This document updates RFC 5092. "Indicating Message Authentication System Parameters", Murray Kucherawy, 17-Apr-09, This memo defines simple extensions to IMAP, POP3 and SMTP to permit a user's message reading software (Mail User Agent, or MUA) to determine the properties of its environment with respect to available message authentication services. "Multiple Interfaces Problem Statement", Marc Blanchet, 9-Dec-08, A multi-homed host receives node configuration information from each of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple configuration objects that are global to the node are received on the many interfaces the multi-homed host has. This document describes these issues. "Transmission of IPv4 Packets over ISATAP Interfaces", Fred Templin, 24-Mar-09, The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. "Dynamic policy specification and management for heterogeneous Internet environment", David Wagner, 10-Dec-08, This document presents requirements and architecture for dynamic user-centric Quality of Service (QoS) policy specification and management in heterogeneous Internet environments. The hierarchical policy specification is based on mapping and refinement of policies at business, intermediate, operational and configuration level. The QoS policy request are selected for heterogeneous network environment considering the restrictions of the users as specified in SLAs and identity management facilities. "Architectural Implications of Locator/ID Separation", Dave Meyer, Darrel Lewis, 26-Jan-09, Recent work on Locator/ID Separation has focused primarily on the control plane protocols concerned with finding Identifier-to-Locator mappings. However, experience gained with a trial deployment of a system designed to implement Locator/ID Separation has revealed two general classes of problems which must be resolved after the mapping is found: The Locator Path Liveness Problem and the State Synchronization Problem. These problems have implications for the data plane as well as the control plane. "IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano, 17-Feb-09, This document provides a guide for IPv6 deployment in Internet Exchange Points (IXP). It includes information about the switching fabric configuration, the addressing plan options and general organizational tasks to be performed. IXP are mainly a layer 2 device (the switching fabric) and in many case the best recommendations state that IPv6 traffic and management should not be handled differently than in IPv4. "ICMP Locator Update message", Randall Atkinson, 10-Dec-08, This describes an experimental ICMPv6 message type to dynamically update Identifier/Locator bindings for an Identifier Locator Network Protocol based upon IPv6. "An IPv4 - IPv6 multicast translator", Stig Venaas, 12-Dec-08, This document describes an IPv4 - IPv6 translator device that embeds all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts to receive from and send to IPv4 multicast groups. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 7-Jan-09, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "An SMTP Extension for email postage", Ben April, John Leslie, Bart Schaefer, 13-Dec-08, The Anti-Spam Research Group is considering research into how operators of mail systems sometimes might want to pay for transmission of e-mail. This document details an extension to the SMTP email protocol for this purpose. "Simple Mail Transfer Protocol", John Klensin, 14-Dec-08, 20 This document is a specification of the basic protocol for Internet 21 electronic mail transport. It consolidates, updates, and clarifies 22 several previous documents, making all or parts of most of them 23 obsolete. It covers the SMTP extension mechanisms and best practices 24 for the contemporary Internet, but does not provide details about 25 particular extensions. Although SMTP was designed as a mail 26 transport and delivery protocol, this specification also contains 27 information that is important to its use as a "mail submission" 28 protocol for "split-UA" (User Agent) mail reading systems and mobile 29 environments. 56 58 Internet-Draft RFC5321-Numbered Dec 2008 "Enterprise Number for Documentation Use", Pasi Eronen, David Harrington, 2-Mar-09, This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. "Internationalized Delivery Status and Disposition Notifications", Chris Newman, Alexey Melnikov, 15-Dec-08, Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. "Specifying transport mechanisms in Uniform Resource Identifiers", Lloyd Wood, 23-Mar-09, This document describes a simple extension of the Uniform Resource Identifier (URI) format that allows preferred transport mechanisms, including protocols, ports and interfaces, to be specified as parseable additions to the scheme name. This explicit configuration is beneficial for separation of the HyperText Transfer Protocol (HTTP) from underlying transports, which has been increasingly recognised as useful when a variety of ways of transporting or configuring use of HTTP are available and a choice of mechanism to use must be indicated. "BFD with Graceful Restart", Palanivelan A, 5-Jan-09, This document proposes an extension for Bidirectional Forwarding Detection (BFD) to support Graceful restart, in complementing Graceful restart support of the underlying protocol.This shall work consistently irespective of the bfd mode or protocol or the type of restart.This document describes the challenges to bfd in surviving a graceful restart and a generic solution to succeed. "A Workable Variation on Rights Contributors Provide to the IETF Trust", John Klensin, 15-Dec-08, RFC 5378, "Rights Contributors Provide to the IETF Trust", has been interpreted in a way that is unworkable in practice for updates to documents created before it came into effect, and for other documents that derive significant amounts of text from such earlier documents. It requires, as a condition of Internet Draft posting or RFC publication or even as a condition of posting of Internet Drafts, that authors or editors obtain rights from people who may be unavailable or uncooperative. This specification modifies the RFC 5378 rules to permit the IETF to continue to do work in an orderly fashion when documents containing earlier text are involved and permission is not easily obtained. "Application of the Precautionary Principle by the IETF http://iucg.org/draft-iucg-precaution-00.txt", Jean-Francois Morfin, 15-Dec-08, This Memo documents how the IETF pursues its mission in adherence to the Precautionary cardinal principle and may benefit from its application in its goal to make the Internet work better and in addressing some of its documented problems. "Registry for BGP-4 OPEN Options", John Scudder, 16-Dec-08, The base BGP specification specifies a mechanism to include optional parameters with the OPEN message. Optional parameters are identified by a type code. However, no IANA registry exists for this type code. This document requests IANA to create such a registry. "Expressing Confidence in a Location Object", Martin Thomson, 17-Dec-08, A confidence element is described that expresses the estimated probability that the associated location information is correct. This element conveys information that might otherwise be lost about the probability distribution represented by a region of uncertainty. "Extension to the Session Description Protocol (SDP) for Bypass of Border Gateways", Richard Ejzak, 17-Dec-08, This document describes an extension to the Session Description Protocol (SDP) that can be used by systems of cooperating networks using Application Level Gateways (ALG) to insert border gateways performing as Network Address Port Translators (NAPT) between their IP realms to identify when border gateways can be bypassed for more efficient media flow. This extension can be used by networks based on a protocol using the SDP offer/answer model, such as the IP Multimedia Subsystem (IMS) of the Third Generation Partnership Project (3GPP), which is based on the Session Initiation Protocol (SIP). ALGs using this extension can determine within a single SDP offer/answer transaction when the insertion of a new border gateway would cause the media path to re-enter an IP realm visited elsewhere within the media path, and to bypass one or more border gateways that would otherwise be included in the media path. This extension also works with hosted NAPT traversal schemes to establish a direct media path between endpoints within the same IP realm. Optional procedures provide additional means to improve media flow. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 5-Mar-09, This document describes some important characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. "Explicit Notification Extension (ECN) Support for RTP Sessions", Ken Carlberg, Piers O'Hanlon, 18-Dec-08, This document describes a design to support Explicit Congestion Notification (ECN) for the RTP layer. The design defines a means of end-to-end negotiated support of ECN using the Session Description Protocol (SDP) and a new RTCP Extended Report. "RTCP Extended Report for ECN Marked Packets", Piers O'Hanlon, Ken Carlberg, 18-Dec-08, This document describes a Real-Time Control Protocol (RTCP) Extended Report (XR) containing information derived from the reception of Explicit Congestion Notification (ECN) marked packets. This document symbiotic with the approach described in [rtp-ecn], which presents one approach in establishing end-to-end ECN support for real-time sessions. "A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service", Ranjit Avasarala, Subir Saha, John-Luc Bakker, 22-Dec-08, 3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and in particular the Communication Diversion (CDIV) using IP Multimedia (IM) core Network (CN) subsystem supplementary service. As part of CDIV, a (SIP) Event Notification Framework-based mechanism is used for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. This SIP event package is applicable to the IMS and may not be applicable to the general Internet. "draft-kumar-mpls-fec-to-nhlfe-mib-00", Subodh Kumar, Ronald Bonica, 19-Dec-08, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for FEC-to-NHLFE for use in Multiprotocol Label Switching (MPLS)network. The MIB module defined in this document is used for configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). "Additional Portable Symmetric Key Container (PSKC) Algorithm Profiles", Philip Hoyer, Mingliang Pei, Salah Machani, Andrea Doherty, 24-Dec-08, The Portable Symmetric Key Container (PSKC) contains a number of XML elements and XML attributes carrying keys and related information. Not all algorithms, however, are able to use all elements and for other algorithm certain information is mandatory. This lead to the introduction of PSKC algorithm profiles that provide further description about the mandatory and optional information elements and their semantic, including extensions that may be needed. The main PSKC specification defines two PSKC algorithm profiles, namely "HOTP" and "PIN". This document extends the initial set and specifies nine further algorithm profiles for PKSC. "Cookie-based HTTP Authentication", Thomas Broyer, 4-Jan-09, This document specifies an HTTP authentication scheme for use when credentials are validated by an out-of-band mechanism (not defined here) and later communicated to the server through the use of a cookie. Which out-of-band mechanism should be used, and how, is described by the 401 (Unauthorized) response body. It is common practice that this mechanism is an HTML form, sending the user's credentials with the use of an HTTP POST request to a tier URL which will set a cookie in response; though this document doesn't preclude the use of other mechanisms. "Secure and Scalable Location Routing Protocol (SSLRP) for Ad Hoc Networks", Xian-wei Zhou, Shuai Du, Ji-jian Meng, Kun Shi, Guang Yang, Ling Zhou, 6-Jan-09, The Secure and Scalable Location Routing Protocol (SSLRP) is a secure and distributed routing protocol designed for ad hoc networks of mobile nodes with location information. Commonly, each node acquires its own geographic position using a mechanism such as the Global Position System (GPS). The SSLRP addresses each node using the hybrid of its multi-level hierarchical address and unique identifier at the moment of network initialization. Certain measures were adopted to ensure security of the network. "Architectural Considerations of IP Anycast", Danny McPherson, David Oran, 6-Jan-09, This memo discusses architectural implications of IP anycast. "A Multihoming Based IPv4/IPv6 Transition Approach", Jun Bi, You Wang, Lizhong Xie, 6-Jan-09, How to make IPv4 users utilize IPv6 applications is a typical scenario of the IPv4/IPv6 inter-operation. Nowadays, Tunnel Broker and 6to4 tunnel mechanisms are the popular solutions for this problem. This paper proposes a multihoming based algorithm MI46 to integrate Tunnel Broker and 6to4 tunnel mechanism. It overcomes the shortcomings of both Tunnel Broker and the 6to4 tunnel mechanism to form an optimized method to make the IPv4 users use the IPv6 applications. "Connecting IPvX Networks over IPvY with a P2P Method", Jun Bi, You Wang, Xiaoxiang Leng, 6-Jan-09, This document presents a new method - PXP- to connect IPvX islands together over IPvY network and reduce the reliance on the relays of existing transition mechanisms by shifting the burden to edge gateways on each island. In this method, direct tunnels are set up between the IPvX islands, and a P2P overlay network is maintained between their gateways to propagate information of tunnel end points. "The Univer6 Architecture for IPv6 Transition", Jun Bi, You Wang, Xiangbin Cheng, 6-Jan-09, IPv6 transition is becoming an important research topic recently. In traditional architecture, transition mechanisms are closely connected with application, protocol stack, and network equipments. This makes the transition process very complicated, and increases the difficulty of network management. In this document, we present a new network architecture called Univer6. It uses IPv6 as a unified middle layer,thus can adapt to various kinds of applications and network equipments. Univer6 will help provide a smooth transition towards IPv6, simplify network management process, and accelerate the development of IPv6. "Adaptive Routing Protocol", Xingwei Wang, ZhanKao Wen, WeiXin Wu, WeiDong Wang, Yao Fu, 5-May-09, This document describes an Adaptive Routing Protocol. It provides a routing protocol of Swarm Intelligence based network model, to a certain extent, this protocol can solve problems accompanied by network expansion and Dynamic network Increasing. This paper presents a routing protocol to adapt the self-organizing network, defines a set of terms and describes the message format and appropriate action sequences. "Self-organizing network model", Xingwei Wang, XiuShuang Yi, Yu Wang, Ming Dong, Qiang Chen, 6-May-09, In this paper, a swarm intelligence based self-organizing network model was introduced to network providers. The problems of the existing network as well as the characteristics of the NGI (Next Generation Internet) were described to illustrate the motivation of the proposed self-organizing network model. A network architecture model based on swarm intelligence was introduced, the used technical terms was defined. The network parameters, network behaviors and node stability under the proposed model were described. Especially, some important QoS routing elements under the proposed model, such as the user QoS routing requirements, link satisfaction degree, utility computation, unicast path and multicast tree evaluation, mathematical model of QoS route optimization and small-world behaviors, were introduced. "Delay-Tolerant Networking Superseding Bundle Extension Block", S. Parikh, Susan Symington, Keith Scott, Robert Durst, R. Edell, 6-Jan-09, This document defines an optional Bundle Protocol block called the Superseding Bundle Extension Block (SBEB) for use with the Bundle Protocol in the context of the Delay-Tolerant Networking Architecture. Applications use this block to call for the removal of previously sent bundles that are rendered obsolete by more recent bundles. Upon receiving a bundle with an SBEB, a node will search its bundle store (and outbound queues) for bundles that are obsoleted by other related bundles according to their source and destination EID, and the SBEB cookie (if present), and may delete some or all of them. Discarding obsolete bundles helps conserve storage space and prevents expending resources in further forwarding bundles that are no longer relevant. The bundle protocol already uses expiration times to remove bundles that are no longer useful to applications. The SBEB is a way for applications to mark bundles that a node may delete prior to their expiration times. "Definition of ACH TLV Structure", Sami Boutros, Stewart Bryant, Siva Sivabalan, George Swallow, David Ward, 9-Mar-09, In some application of the associated channel header (ACH), it is necessary to have the ability to include a set of TLVs to provide additional context information for the ACH payload. This document defines a number of TLV types. NOTE the family of Address Types is known to be incomplete. The authors request that members of the MPLS-TP community provide details of their required address formats in the form of text for the creation of an additional sections similar to Section 3.1. NOTE other TLV types will be added in further revisions of this document. The authors request that members if the MPLS-TP community requiring new TLVs to complete there MPLS-TP specifications provide details of their required TLV in the form of text for the creation of additional sections similar to Section 2.2. "Authentication-Results Header Field Security Issues", Douglas Otis, 7-Jan-09, The proposed [I-D.kucherawy-sender-auth-header] defines a header field used to capture email verification results of border receptions. These results are then conveyed to Mail User Agents (MUA) and downstream filters. This header field is to augment filtering decisions and message annotations that can be made visible to recipients. The annotations could affirm originating domains or content integrity when based upon Domainkeys or DKIM results, or a domain's authorization of a publicly transmitting SMTP client IP address when based upon Sender-ID or SPF results, or that the SMTP client IP address maps to a matching domain within the DNS reverse namespace. Although the draft acknowledges the conflation of authorization with authentication in section 1.5.2, and explicitly declares Sender-ID and SPF as the authorization of the transmitting SMTP client, it still fails to offer the authenticated entity being trusted in the exchange, the IP address of the SMTP client. An authenticated entity is essential for reputation assessments which section 4.1 indicates should be made prior to results being revealed. A reputation check is often a necessary step to mitigate abuse and fraud. Even so, the header offers no assurance that any reputation check has been made, nor does it ensure that the trusted entity, the IP address of the SMTP client, can be determined by the MUA or downstream filter. "Security Context Addendum to IPsec", Joy Latten, George Wilson, Serge Hallyn, Trent Jaeger, 8-Jan-09, This document describes the high-level requirements needed within IPsec to support Mandatory Access Control (MAC) on network communications. It describes the extensions to the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange Protocol Version 2 [RFC4306]. It also describes the negotiation of the security context for a particular Authentication Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] security association. "draft-jml-ipsec-ikev1-security-context-00", Joy Latten, George Wilson, Serge Hallyn, Trent Jaeger, 8-Jan-09, This document describes the need for and use of a security context within IPsec. It describes the extension to the Internet IP Security Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. This extension supports the negotiation of the security context for a particular IP Authentication Header (AH) [RFC4302] or IP Encapsulating Security Payload (ESP) [RFC4303] security association. "Including text under former copyright conditions", Brian Carpenter, Harald Alvestrand, 11-May-09, This document specifies a procedure for including text in an IETF document for which the current copyright conditions defined in RFC 5378 cannot readily be met. "The Web Socket protocol", Ian Hickson, 24-Apr-09, This protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that understands the protocol. It is intended to fail to communicate with servers of pre-existing protocols like SMTP or HTTP, while allowing HTTP servers to opt-in to supporting this protocol if desired. It is designed to be easy to implement on the server side.Author's note This document is automatically generated from, and is therefore a subset of, the HTML5 specification produced by the WHATWG. [HTML5] "The Criterion of Session State", Gao yang, 6-Mar-09, There is debate on the topic of "Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE". The reason of the confusion is some application/session usages of offer/answer imply the nest transaction(mean transaction theory, not mean sip transaction) concept, but whitout unambiguous definition. This paper reveal the concept of nest transactions in current RFC and other well known application/session usages. And then clarify that there is no ambiguous state of session modification using current RFC definition. "Content-Type Processing Model", Adam Barth, Ian Hickson, 9-Jan-09, Many Web servers supply incorrect Content-Type headers with their HTTP responses. In order to be compatible with these Web servers, Web browsers must consider the content of HTTP responses as well as the Content-Type header when determining the effective mime type of the response. This document describes an algorithm for determining the effective mime type of HTTP responses that balances security and compatibility considerations. "Connection verification for MPLS Transport Profile LSP", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 9-Mar-09, This document specifies method for verifying the connection of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for management purpose. The proposed extension is based on MPLS Operation, Administration, and Maintenance (OAM). The goal is to verify that an MPLS-TP is properly setup in both control and data planes, as well as to record the identities of all the LSRs along the path of MPLS-TP LSP. "Private Extension to the Session Initiation Protocol (SIP) for Debugging", Peter Dawes, 9-Jan-09, Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. "Ad hoc On-demand Distance Vector and Dynamic Local Repair (AODV-DLR) Routing", Jihong Zhao, 9-Jan-09, The Ad hoc On-Demand Distance Vector and Dynamic Local Repair (AODV-DLR) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It adopts dynamic local repair in which a route repair message is used to not only attempt to discovery a route to destination, but also try to set up a route to downstream node (next hop or next two hop). It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. "Link-based Resource Descriptor Discovery", Eran Hammer-Lahav, 23-Mar-09, This memo describes LRDD (pronounced 'lard'), a process for obtaining information about a resource identified by a URI. The 'information about a resource', a resource descriptor, provides machine-readable information that aims to increase interoperability and enhance the interaction with the resource. This memo only defines the process for locating and obtaining the descriptor, but leaves the descriptor format and its interpretation out of scope. "Performance Monitoring of MPLS Transport Profile LSP", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 9-Mar-09, This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) for monitoring the performance of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) with respect to packet loss and unidirectional delay/jitter. "Fault Management for the MPLS Transport Profile", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 9-Mar-09, This draft specifies a fault management mechanism for MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP). The proposed mechanism is based on a generic way of notifying a Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) of a fault on an MPLS-TP LSP using new type of MPLS Operation, Administration, and Maintenance (OAM) messages. "Multiple Home Network Prefixes Considerations in Handover involving Network and Client Based IP Mobility Protocols", Desire Oulai, Suresh Krishnan, 12-Jan-09, Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) are the base protocols defined by IETF for network based and client based mobility. This document analyzes PMIPv6 and two MIPv6 extensions, DSMIP and NEMO, with regard to multiple Home Network Prefixes handling during handover. "Remote Procedure Call (RPC) Security Version 3", Nicolas Williams, 12-Jan-09, This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides for: compound authentication of client hosts and users to server (constructed by generic composition), channel binding, security label assertions for multi-level and type enforcement, privilege assertions and identity assertions. "Internationalizing Domain Names in Applications (IDNA) version 2", Paul Hoffman, 4-Mar-09, IDNA has been a world-wide success since it was introduced over five years ago. However, it has some notable deficiencies, including being tied to an old version of the Unicode standard and needless restrictions that prevented some languages from being used. This document describes IDNA version 2, which rectifies those problems while making the fewest changes necessary to the original protocol. "Source Address Finding (SAF) for IPv6 Translation Mechanisms", Dave Thaler, 6-Feb-09, There are various recent proposals that would result in IPv6 translation becoming permanent. RFC 3424 discusses UNilateral Self- Address Fixing (UNSAF) mechanisms which are required for applications to work with most translation schemes, points out a number of problems with them, and requires an exit strategy for any UNSAF mechanism. This document discusses an alternative to UNSAF mechanisms should IPv6 translation become permanent. "The keyword to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(Keyword)", Guoqiang Zhang, XiaoDong Lee, 15-Jan-09, This memo discusses the use of the Domain Name System(DNS) for storage of Keyword to URI mapping. More specifically, how DNS can be used for identifying URIs associated with one Keyword. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. ""The OAM Acronym Soup"", Loa Andersson, Malcolm Betts, Ronald Bonica, Huub Helvoort, Dan Romascanu, 16-Jan-09, At first glance the acronym "OAM" seems to be well known and well understood. Looking at it a bit more closely reveals a set of recurring problems that are revisited time and again. This document has one primary and a secondary goal. The primary goal is to find an understanding of OAM that is feasible for the MPLS Transport Profile (MPLS-TP)effort. The secondary goal is to make this understanding applicable in a wider scope "RTP NTP header extension for decoding order recovery in layered codecs", Thomas Schierl, 15-Jan-09, This memo describes an RTP header extension mechanism to be used with timestamp-based decoding order recovery of RTP flows containing layered codecs. The header extension may be most useful in the presence of clock skew as well as for early decoding order recovery. The RTP header extension is based on [RFC5285] and extends the RTP header by the lower 56bit part of the NTP timestamp corresponding to the RTP timestamp of the same packet as defined in [RFC3550] for the RTCP sender reports. This memo further gives guidance on how decoding order is recovered in RTP flows using the NTP timestamp information when parts of a layered, multi-view or multi- descriptions coding media are transported in different RTP flows. "A YANG Module for the NETCONF Protocol", Andy Bierman, 19-Jan-09, The NETCONF protocol contains several data types and protocol operations which could be utilized in NETMOD data models, written with the YANG data modeling language. This document contains a YANG module defining the NETCONF data types and protocol operations, in order for other YANG modules to properly import and augment the definitions in a common way. "Embedding Host Identity Tags Data in DNS", Oleg Ponomarev, Andrei Gurtov, 9-Mar-09, This document proposes conventions to access and manage Host Identity Tag (HIT) mappings using the Domain Name System (DNS) interface. "The HTTP Origin Header", Adam Barth, Collin Jackson, Ian Hickson, 21-Jan-09, This document defines the HTTP Origin header. The Origin header is added by the user agent to describe the security context that initiated an HTTP request. HTTP servers can use the Origin header to defend themselves against Cross-Site Request Forgery (CSRF) attacks. "Heuristics for Detecting ESP-NULL packets", Tero Kivinen, Daniel McDonald, 22-Jan-09, This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. "MAC Security Label Support for NFSv4", David Quigley, James Morris, 22-Jan-09, This Internet-Draft describes additions to NFSv4 minor version one to support Mandatory Access Control systems. The current draft describes the mechanism for transporting a MAC security label using the NFSv4.1 protocol and the semantics required for that label. In addition to this it describes an example system of using this label in a fully MAC aware environment. "Multihoming Problem Statement in NetLMM", Mohana Jeyatharan, Chan-Wah Ng, 9-Mar-09, The Proxy Mobile Internet Protocol version 6 (PMIPv6) supports multihoming whereby a mobile node (1) gets assigned prefixes by the local mobility anchor which are associated with an interface of a mobile node and are managed by the PMIPv6 elements as a single IP mobility session, and (2) can connect to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access and get assigned a different set of prefix(es) per interface, since being each interface managed via an independent mobility session. However, PMIPv6 needs multihoming enhancements such that it needs the ability to instantiate additional IP mobility sessions associated with an already active interface or a secondary interface of the mobile node which has an established IP mobility session at a local mobility anchor (LMA), the ability to selectively share home network prefix(es) across access technology types and extended support for multiple IP mobility sessions in a scenario where multiple interfaces of the mobile node are connected to a single mobile access gateway (MAG). This memo highlights such required enhancements to PMIPv6 multihoming with respect to improved operations and extended applicability to different deployment scenarios. "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", Gregory Lebovitz, 13-Mar-09, In the March of 2006 the IAB held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for "[t]ightening the security of the core routing infrastructure." Four main steps were identified for improving the security of the routing infrastructure. One of those steps was "securing the routing protocols' packets on the wire." One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity. Many different routing protocols exist and they employ a range of different transport subsystems. Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols. Many routing protocols already have some method for accomplishing cryptographic message authentication. However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated. This document creates a roadmap of protocol specification work for the use of modern cryptogrpahic mechanisms and algorithms for message authentication in routing protocols. It also defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 23-Jan-09, This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. "BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 17-Apr-09, Currently the Autonomous System (AS) 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. "Extensions to RTCP for Rapid Synchronization", Peilin Yang, Baohua Lei, Zixuan Zou, 7-Mar-09, This document specifies an extension to "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) " [RFC4585] to reduce multicast session synchronization time and improve the user experience when a video receiver joins a multicast stream. "The 'about' URI scheme", Joseph Holsten, Lachlan Hunt, 11-May-09, This document specifies the URI (Uniform Resource Identifier) scheme "about". About URIs are designed to be an internal, application- level identifier. Unlike many other URI schemes, the resolution of, and resources represented by, about URIs are left entirely to each individual application. "Make TCP more Robust to Long Connectivity Disruptions", Alexander Zimmermann, Arnd Hannemann, 28-Jan-09, TCP was designed with fixed, wired networks in mind. As a result TCP performs suboptimal in networks where connectivity disruptions are frequent, e.g., in wireless (multi-hop) networks. One reason for the performance degradation is TCP's over-conservative behavior in face of long connectivity disruptions. This document describes how connectivity disruption indications provided by standard ICMP messages may be exploited to improve TCP's performance. An RTO revert strategy is proposed that enables earlier detection of whether connectivity to a previously disconnected peer node has been restored or not. The scheme is a sender only modification which fully respects the TCP congestion control principles. "IPv4 Shortage: Needs and Open Issues", Pierre Levis, Mohammed Boucadair, Jean-Luc Grimault, Alain Villefranque, 4-Mar-09, This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion. It would be valuable to assess IPv4 address shortage solutions with all these issues, to check to what degree they are concerned, how they handle each issue, and to what extent they resolve the pending problems. "On the problem of long delays between connection-establishment attempts in TCP", Fernando Gont, 28-Jan-09, This document discusses a number of solutions to the problem of long delays between connection establishment attempts in TCP. "P2MP traffic protection in MPLS-TP ring topology", Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, Telecom Italia, Andrea Giglio, 29-Jan-09, Purpose of this ID is to describe requirements and possible solutions for point to multipoint (P2MP) traffic distribution over interconnected MPLS-TP rings. The rationale for an ID on such a specific application is illustrated in the rest of the document. "An EAP Authentication Method Based on the EKE Protocol", Yaron Sheffer, Glen Zorn, Hannes Tschofenig, Scott Fluhrer, 10-Feb-09, The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", Russ Housley, Morris Dworkin, 24-Mar-09, This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped is a multiple of 64 bits, allowing a key of any practical length to be wrapped. "Translation of SMIv2 MIB Modules to YANG Modules", Juergen Schoenwaelder, 30-Jan-09, YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. This document describes the translation of SMIv2 MIB modules into YANG modules. "Access Network Service Discovery Function discovery", Telemaco Melia, Yacine Mghazli, 30-Jan-09, This document specifies extensions to RADIUS to convey to the network authentication server information about the Access Network Discovery Service Function. "Delay-Tolerant Networking Bundle Diversion", Susan Symington, Robert Durst, Keith Scott, 2-Feb-09, This document defines two extensions to the capabilities of a Bundle Protocol Agent (BPA) (as defined in [refs.DTNBP]) that is processing bundles within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines an operation called "diversion", which is the act of a bundle protocol agent moving an entire bundle from some point in bundle processing in the BPA to a DTN application agent. This diversion of a bundle from the BPA to an application agent is distinct from delivery of the bundle at that application agent. This document defines a second operation, called "injection", which is the inverse of diversion. Injection is the act of an application agent moving an entire bundle from the application agent into some point in bundle processing in the BPA. This injection of a bundle from an application agent to the BPA is distinct from bundle transmission. "The Common Log File (CLF) format for the Session Initiation Protocol (SIP)", Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor, 9-Mar-09, Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly for proxies, registrars, redirect servers as well as back-to-back user agents. "Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen, Mohammed Boucadair, Pierre Levis, 9-Mar-09, When IPv6 was designed, the assumption was that the transition from IPv4 to IPv6 will occur way before the exhaustion of the available IPv4 address pool. The unexpected growth of the IPv4 Internet and the hesitation and technical difficulties to deploy IPv6 indicates that the transition may take much longer than originally anticipated. It is expected that communication using IPv6 addresses will increase during the next few years to come at the expense of communication using IPv4 addresses. The Internet should reach a safety point in the future, where the number of IPv4 public addresses in use at a given time begins decreasing. It is very likely that the IPv4 public address pool currently available at IANA will be exhausted before the internet reaches this safety point. This creates a need to prolong the lifetime of the available IPv4 addresses. This document defines methods to allocate the same IPv4 address to multiple hosts, with the aim to prolong the availability of public IPv4 addresses, possibly for as long as it takes for IPv6 to take over the demand for IPv4. "Salted Challenge Response Authentication Mechanism (SCRAM) as a GSS-API Mechanism", Abhijit Menon-Sen, Alexey Melnikov, Chris Newman, 9-Mar-09, The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes an authentication mechanism called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, SCRAM could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. The purpose of this document is to describe the general SCRAM protocol, and how it is used in the GSS-API environment. Through GS2, this makes the protocol available in the SASL environment as well. "Linden Lab Structured Data", Aaron Brashears, Meadhbh Hamrick, Mark Lentczner, 4-Feb-09, This document describes the Linden Lab Structured Data (LLSD) abstract type system, interface description and serialization formats. LLSD is a language-neutral facility for maintaining and transporting structured data. It provides dynamic data features for loosely-coupled collections of software components, even in statically-typed languages. LLSD includes an abstract type system, an interface description language (LLIDL) and three canonical serialization schemes (XML, JSON and Binary). "Classification of SDP", Gao yang, Wang Libo, 4-Feb-09, Generally, next SDP is alternative descriptions for the previous one of the same session. But there is other type of SDP which describe part of the session, not all aspects of the session. It must be combined with the previous one(or ones) to show the effects. There has been such usage of SDPs in RFC3108. But there is no such guidance for that extension and usage. This text is aimed for that. "PMIPv6 Localized Routing Problem Statement", Marco Liebsch, 5-Feb-09, Proxy Mobile IPv6 is the IETF standard for network-based localized mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and support for localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without traversing an LMA, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. "Port Range Configuration Options for PPP IPCP", Mohammed Boucadair, Pierre Levis, Jean-Luc Grimault, Alain Villefranque, 5-Feb-09, This memo defines two IPCP (IP Configuration Protocol, [RFC1332]) Options to be used in the context of Port Range solutions. IPCP is the configuration protocol used when PPP (Point-to-Point Protocol, [RFC1548]) is deployed. "Session State Analysis", Gao yang, 9-Feb-09, Session state on unsuccessful re-INVITE is an open issue[1]. Many people interested in this topics and there has been a lot of discussion in the mail list publicly or among participants privately. This text tried to analyse incorrectness or drawback of some of the methods to reveal the imortance of precise definition of session state. "Proxy Mobile IPv6 Mobility Session Redirection Problem Statement", Jouni Korhonen, 9-Feb-09, This document discusses a Proxy Mobile IPv6 mobility session redirection functionality at the Proxy Mobile IPv6 base protocol level. The redirection functionality would allow a Local Mobility Anchor to redirect the Mobile Access Gateway during the Proxy Binding Update and Acknowledgement exchange to an alternative Local Mobility Anchor. The benefit of redirection at the protocol level is that it removes the dependence on having such functionality provided by the Authentication, Authorization and, Accounting elements or the Domain Name System in a Proxy Mobile IPv6 Domain. Furthermore, doing the redirection at the base protocol level reduces the amount of signaling, unnecessary costly setup of mobility sessions and unnecessary costly interactions with backend systems. "The Accumulated IGP Metric Attribute for BGP", Rex Fernando, Pradosh Mohapatra, Eric Rosen, James Uttaro, 9-Feb-09, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. "Issues with network based inter-technology handovers", Suresh Krishnan, Hidetoshi Yokota, Telemaco Melia, 9-Feb-09, Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol enables IP mobility for a host without requiring its participation in any mobility-related signaling. While the PMIPv6 protocol itself supports handover across interfaces and between access types, there are several issues with effectively performing inter-technology handovers with network based mobility protocols. This document aims to enumerate some known issues with such handovers. "MPLS-TP Proactive Continuity and Connectivity Verification", Italo Busi, Annamaria Fulignoli, Huub Helvoort, Nurit Sprecher, 9-Feb-09, The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for proactive Continuity Check and Connectivity Verification functionality as defined in [3]. Note: this version of the draft is focused on analyzing possible solutions and evaluating their pros&cons as well as issues. In the next version of the draft the solution to be standardized will be proposed using the analysis done in this version to motivate the selection. "Setup of Asymmetric Media with SDP", Ingemar Johansson, 10-Feb-09, This draft proposes an extension to the SDP Capability Negotiation framework for the setup of asymmetric sessions. One example of an asymmetric session is a conversational video session between a handset with a small screen (high-resolution camera) and a home- entertainment set-top box connected to a wide-screen TV. Another example is tightly coupled conferences with different number of in and outgoing streams for each client. "Location Information Server (LIS) Discovery From Behind Residential Gateways", Martin Thomson, 11-Feb-09, The residential gateway is an ubiquitous device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of aquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes the problem of discovering a LIS in the presence of a residential gateway. The current version includes two proposed solutions to this problem, which will be evaluated. "FIB Suppression with Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 24-Apr-09, The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "GRE and IP-in-IP Tunnels for Virtual Aggregation", Xiaohu Xu, Paul Francis, 11-Feb-09, The document "FIB Suppression with Virtual Aggregation" [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for GRE and IP-in-IP tunnels. "MPLS Tunnels for Virtual Aggregation", Paul Francis, Xiaohu Xu, 11-Feb-09, The document "FIB Suppression with Virtual Aggregation" [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for MPLS Label Switched Paths (LSP), without tag stacking. "Simple Tunnel Endpoint Signaling in BGP", Xiaohu Xu, Paul Francis, 11-Feb-09, Virtual Aggregation (VA) is a mechanism for shrinking the size of the DFZ FIB in routers [I-D.francis-intra-va]. VA can result in longer paths and increased load on routers within the ISP that deploys VA. This document describes a mechanism that allows an AS that originates a route to associate a tunnel endpoint terminating at itself with the route. This allows routers in a remote AS to tunnel packets to the originating AS. If transit ASes between the remote AS and the originating AS install the prefixes associated with tunnel endpoints in their FIBs, then tunneled packets that transit through them will take the shortest path. This results in reduced load for the transit AS, and better performance for the customers at the source and destination. "DKIM Reputation Hint Extension", Jim Fenton, 12-Feb-09, This document defines an extension to the DomainKeys Identified Mail (DKIM) specification to provide an identifier that may be used as a "hint" by reputation services using DKIM wanting to maintain reputation information at a finer level of granularity than that of the signing domain itself. "DHCPv6 MRC Clarification", Evan Hunt, 13-Feb-09, The definition of the Maximum Retransmission Count (MRC) variable described in RFC 3315 is clarified to resolve an ambiguity. "Preliminary Recommendation for a Routing Architecture", Tony Li, 29-Mar-09, It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multi-homing, and inter-domain traffic engineering. This document reports the Routing Research Group's prelimnary findings from its efforts towards developing a recommendation for a scalable routing architecture. This document is a work in progress. "Authentication-Results Header Field Appeal", Douglas Otis, David Rand, 16-Feb-09, The proposed [I-D.kucherawy-sender-auth-header] defines a header field used to capture email verification results obtained at border receptions has been approved for publication. However, serious deficiencies remain in its secure use and has prompted an appeal of the publication decision. This new header field is to convey to Mail User Agents (MUA) and downstream processes the verification results that are intended to augment handling decisions and message annotations that might be made visible to recipients. For such use, it is crucial to include within an "authenticated-results" header, a truly authenticated identity. The draft acknowledges that it confuses authorization with authentication in section 1.5.2. This confusion has lead the draft to incorrectly elevate the authorization of an SMTP client into the authentication of an email-address domain. Elevating the *authorization* of the SMTP client into the *authentication* of an email-address domain incorrectly assumes current email practices adequately restrict the use of an email-address domain based upon the originating IP address of the SMTP client. In an era of carrier grade NATs, virtual servers, aggregated services, and other techniques that overload the IP address, this assumption is neither safe nor practical. Although the draft explicitly declares Sender-ID and SPF as the authorization of the transmitting SMTP client, it fails to offer the authenticated identity being trusted. A truly authenticated identity is essential for reputation assessments which section 4.1 indicates should be made prior to results being revealed. A reputation check of a truly authenticated identifier is often a necessary step needed to mitigate fraud and abuse. In addition, it is unfair to attribute fraud or abuse to the unauthenticated identifiers. Even so, the header offers no assurance that any reputation check has been made, nor does it ensure that an authenticated identity, the IP address of the SMTP client, can be determined by the MUA or downstream process. The goal of the appeal is to ensure adequate information is available when annotating email. "A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, Jani Hautakorpi, 16-Feb-09, REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. RELOAD provides an abstract interface to the overlay layer that allows implementing different structured and unstructured overlay algorithms by using different topology plugins. This document defines a new topology plugin for RELOAD. This topology plugin implements a self- tuning DHT (Distributed Hash Table), which adapts to changing operating conditions (e.g., churn and network size). "ECN Nonces for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Neil Spring, 16-Feb-09, This document describes the addition of the ECN-nonce RFC 3540 [RFC3540] to the Stream Control Transmission Protocol (SCTP) RFC 2960 [RFC2960]. 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. "DHCPv6 Route Option", Wojciech Dec, Richard Johnson, 3-Mar-09, This document describes the DHCPv6 Route Option for provisioning static IPv6 routes on a DHCPv6 client..This improves the ability of an operator to configure and influence the client to pick an appropriate route to a destination when the client is multi-homed to routers and where other means of route configuration may be impractical. It is primarily envisaged for implementation on a DHCP client stack of a broadband Residential Gateway (RG) node. "A Security Framework for Routing over Low Power and Lossy Networks", Tzeta Tsao, Roger Alexander, Mischa Dohler, Vanesa Daza, Angel Lozano, 17-Feb-09, This document presents a security framework for routing over low power and lossy networks. The development of the framework builds upon previous work on routing security and adapts the security assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and assessing the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. "DNSSEC Key Timing Considerations", Stephen Morris, Johan Ihren, John Dickinson, 17-Feb-09, RFC 4641 gives a detailed overview of the operational considerations involved in running a DNSSEC-secured zone, including key rollovers. This document expands on the previous work, and discusses timing considerations in greater depth. It explicitly identifies the relationships between the various time parameters, and gives a suggested algorithm for key rollover in a DNSSEC-secured zone. "BGP routing information in XML format", Peichun Cheng, He Yan, Kevin Burnett, Dan Massey, Lixia Zhang, 17-Feb-09, This document describes the XML format for BGP routing information (XFB). It can be used to describe both BGP messages and BGP control information. Compared with MRT, XFB is more extensible, human and machine-readable and can serve as a common interface for a variety of tools. "Reverse Binding for Proxy Mobile IPv6", Youn-Hee Han, Pyung-Soo Kim, 17-Feb-09, This memo proposes a scheme that utilizes only pre-established bi- directional tunnels between LMA and MAGs to support a fast handover effectively in Proxy Mobile IPv6. To expedite the handover procedure, we define new signaling messages, Fast PBU/PBA and Reverse PBU/PBA, exchanged by LMA and MAGs. Because any signaling messages exchanged by two MAGs are neither created nor utilized and thus bi- directional tunnel between MAGs is not created, the proposed scheme put less overload upon network than the existing fast handover scheme for PMIPv6. It can also tackle effectively with the so-called ping- pong movement of mobile nodes. "DHCP options for MANET prefix in connected MANET", Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, Yuseon Kim, 18-Feb-09, The mobile ad hoc network (MANET) is a wireless network composed of mobile nodes which can communicate with each other via multiple wireless links. The modified MANET architecture is now standardizing that can resolve the multi-link subnet issue. In this draft, we define two DHCP options in order that a MANET Router (MR) gets the network prefix assigned to the connected MANET. The one is the MANET prefix request option used by a MR when it wants to know the network presix allocated to the MANET. The other is the MANET prefix option that DHCP server provides the MANET prefix to the requesting MR. "The atypes media feature tag for Session Initiation Protocol (SIP)", Mohammed Boucadair, Yoann Noisette, Andrew Allen, 9-Mar-09, This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. "Problems with IPv6 source address selection and IPv4 NATs", Remi Denis-Courmont, 18-Feb-09, This memo details a problem and potential solution, when using the IPv6 source address selection algorithm with private IPv4 address space. "Flow Binding in Proxy Mobile IPv6", Frank Xia, 18-Feb-09, This document introduces extensions to Proxy Mobile IPv6 that allows networks dynamically binding IP flows to different interfaces of a mobile node. "DNS Server Selection on Multi-Homed Hosts", Teemu Savolainen, 19-Feb-09, A multi-homed host may receive DNS server configuration information from multiple physical and/or virtual network interfaces. In split DNS scenarios not all DNS servers are able to provide the same information. When the multi-homed host needs to utilize DNS, it has to select which of the servers to contact to. This document describes problems of split DNS for multi-homed hosts and also a method for selecting the DNS server with help of DNS suffix information received dynamically for each network interface. The method is useful in split DNS scenarios where private names are used and where correct DNS server selection is mandatory for successful DNS resolution. "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Servers", Theo Zourzouvillys, 2-Mar-09, This document addresses a vulnerability in publicly accessible SIP servers (servers includes both UASes and proxies) that enables them to be used as an amplifier in an untracable reflected denial of service attack. The amplification ratio is between 1:10 to over 1:350 in both packets and bytes. As a proposed solution, a mechanism for stateless cookie exchange between a SIP server and client to ensure that a public SIP server that wishes to accept SIP requests from hosts over datagram can not be used as an amplifier for a denial of service attack. This brings SIP over datagram transports (such as UDP) in line with TCP in terms of routability to the source IP address. "Reclassification of Sender ID and SPF to Historic Status", S Moonesamy, 20-Feb-09, This memo reclassifies RFC 4405, SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message, RFC 4406, Sender ID: Authenticating E-Mail, RFC 4407, Purported Responsible Address in E-Mail Messages and RFC 4408, Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 to Historic status. This memo also obsoletes RFC 4405, RFC 4406, RFC 4407, and RFC 4408. "A Packet Distribution Scheme for Bandwidth Aggregation on Network Mobility", Pyung-Soo Kim, Youn-Hee Han, 20-Feb-09, This draft considers a packet distribution scheme for bandwidth aggregation on the mobile network with a multi-interfaced mobile router (MMR). In the proposed scheme, the MMR with multiple heterogeneous wireless network interfaces effectively and fairly distributes packets over end-to-end multi-path through multiple network interfaces. Each network interface is considered to have a distribution counter associated with corresponding end-to-end path. This distribution counter varied by both weighted capacity and distributed packets is used to determine if a network interface has enough credits to distribute incoming packets on multiple paths. The capacity unit is shown to be a useful design parameter to make the performance of the proposed scheme as good as possible. "Xcast6 Treemap: An extension of Xcast6", Khoa Phan, Nam Thoai, Eiichi Muramoto, Ettikan Kandasamy, 20-Feb-09, Xcast6 (Explicit Multi-unicast for IPv6) is a new multicast scheme that supports very large number of small multicast sessions. Xcast6 sends data via optimal route without traffic redundancy when Xcast- aware routers exist; otherwise, data will be sent in daisy-chain form. In this document, we propose Xcast6 Treemap - an extension of Xcast6. Using Xcast6 Treemap, data can be branched not only at source but also at remote hosts, solving the limitation of daisy-chain connection. Xcast6 Treemap utilizes existing multicast infrastructure (Xcast-aware routers) to improve application performance and reduce traffic redundancy on network; also, it automatically switches to end-host multicast operation mode in the absence of Xcast-aware router. For widely deployment of Xcast6, routers must be upgraded gradually. This requires a long term strategy and Xcast6 Treemap is a good choice for incremental deployment. "Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers", Spencer Dawkins, 3-Mar-09, This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. "Nominating Committee Process: Open Disclosure of Willing Nominees", Spencer Dawkins, 26-Feb-09, This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Commitee to disclose the list of nominees who are willing to serve in positions the NomCom is responsible for filling. "Translating IPv4 to IPv6 based on source IPv4 address", Charles Perkins, 20-Feb-09, A method is proposed to enable communications between an IPv4-only node in today's Internet and an IPv6-only node, initiated by the IPv4-only node. The communication depends on allocation of a flow record and address triggered by a DNS query received for the target v6-only node. DNS query conventions can be agreed upon to provide a natural model for resolving IPv4 queries for IPv6-only nodes. The NAT mechanism proposed demultiplexes multiple sessions through the same dynamically allocated IP address, using flow records matching the source address of incoming packets. This is in contrast to the use of ports in NAT-PT boxes, which inhibits the support of incoming traffic towards a node behind the NAT-PT. "Security Assessment of the Transmission Control Protocol (TCP)", Fernando Gont, 20-Feb-09, This document contains a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), and of a number of mechanisms and policies in use by popular TCP implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). "Constrained Shortest Path First", Manayya KB, 17-Apr-09, Constrained Shortest Path First (CSPF) is an advanced version of shortest path algorithms used in OSPF and IS-IS route computations. It is used in computing shortest path for label-switched paths (LSPs) based upon multiple constraints. While computing path for LSPs it considers topology of network, attributes of LSP and links. The path is computed using traffic engineering database which takes the extensions of OSPF(open shortest path first) and IS-IS (Intermediate system to Intermediate system) as input. Manayya KB Expires October 16, 2009 [page 1] "Peer-to-peer (P2P) Architectures", Gonzalo Camarillo, 18-Apr-09, In this document we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and a taxonomy of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural tradeoffs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. "Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs)", Tony Cheneau, Maryline Laurent-Maknavicius, Sean Shen, Michaela Vanderveen, 21-Feb-09, This document defines an extension field for the CGA Parameter data structure specified in RFC 3972. This extension field carries a Public Key that is used in Cryptographically Generated Address (CGA) generation. This extension enables protocols using CGAs, such as SEND, to use multiple Public Key signing algorithms and/or multiple Public Keys. "Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol", Tony Cheneau, Maryline Laurent-Maknavicius, Sean Shen, Michaela Vanderveen, 21-Feb-09, This draft describes a mechanism to enable the Secure Neighbor Discovery (SEND) protocol to select between different signature algorithms to use with Cryptographically Generated Addresses (CGA). It also provides optional support for interoperability between nodes that do not share any common signature algorithms. "An IPTV Usage for RELOAD", Seok-Kap Ko, Young-Han Kim, Byoung-Tak Lee, 21-Feb-09, This document defines a distributed IPTV Usage for Resource Location And Discovery (RELOAD). The IPTV Usage provides lookup service for IPTV channel information and IPTV metadata stored in the overlay. The Attach method is used to establish a direct connection between a distributed channel manager and a viewer. IPTV control messages are exchanged through this connection. "MPLS-TP Control Plane Framework", Lou Berger, Luyuan Fang, 22-Feb-09, The MPLS Transport Profile (MPLS-TP) supports both static provisioning of transport paths via an NMS/OSS, and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane signaling, routing, addressing, traffic engineering, path computation, and recovery in the event of network failures. The document focuses on the control of Label Switched Paths (LSPs) as the Pseudowire (PW) control plane is not modified by MPLS-TP. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. Backwards compatibility to MPLS is required. Management plane, manual configuration, the triggering of LSP setup, label allocation schemes, and hybrid services are out of scope of this document. "UDP Checksums for Tunneled Packets", Marshall Eubanks, 23-Feb-09, We address the problem of computing the UDP checksum on tunneling IPv6 packets when using lightweight tunneling protocols. "Civic Location Format Extension for Utility and Lamp Post Numbers", Robins George, Qian Sun, Henning Schulzrinne, 23-Feb-09, This document describes an extension to civic location format and adds new element PN (pole number). PN carries pole number information which can identify a civic location. "DHCP option to transport Protocol Configuration Options", Telemaco Melia, Yacine Mghazli, 23-Feb-09, This document specifies how to convey Protocol Configuration Options (PCO) [24008] from/to the access network to/from the Mobile Node (MN). There are scenarios defined in 3GPP (TS 23.402) and WiMax forum NWG where the mobile node accessing the non-3GPP trusted system needs to convey such information to the Mobility Access Gateway (MAG) functionality implemented in the serving gateway (S-GW). The MAG requires the PCO field to send such information to the Local Mobility Agent (LMA) (implemented in the PDN gateway, P-GW) in a Proxy Binding Update (PBU) message. PCO options are exchanged between the MN and the LMA to transport information such as P-CSCF address, DNS server address. "Problem Statement of P2P Streaming Protocol (PPSP)", Ning Zong, James Seng, Hui Zhang, Yunfei Zhang, 9-Mar-09, This draft proposes to develop an open p2p streaming protocol, namely PPSP. We survey the current practice of p2p streaming applications, analyze the incentive to develop PPSP and its applying scenarios. Then we introduce the PPSP interaction process and state the problem of PPSP and its scope. In the last section we also analyze the relationship between PPSP and P2PSIP as well as RTSP. "IPv6 Services for UPnP Residential Networks", Mark Baugher, Erwan Nedellec, Mika Saaranen, Barbara Stark, 8-Mar-09, This paper considers some IPv6 issues for residential networks, including address scoping and firewalls. The paper describes IPv6 usage in the UPnP Forums's Device Architecture standard; some clarifications and changes are considered. The paper seeks comments on IPv6 address usage, address selection, and the need to develop best practices for IPv6 firewall traversal. "Mobile Multicasting Support in Proxy Mobile IPv6", Seil Jeon, Younghan Kim, 7-Mar-09, To support IP-based group mobile communication, such as mobile IPTV, IP multicasting is required. Two major constraints in mobile multicasting are the tunnel convergence problem and high handover latency. To reduce the constraints, several mobile multicasting schemes based on Mobile IP have been proposed. To meet requirements, we present a multicasting architecture and fast handover scheme for Proxy Mobile IPv6 (PMIPv6). "Authentication Between Mobile Node and Home Agent", Ying Qiu, Jianying Zhou, 10-Mar-09, Mobile IPv6 relies on IPsec for securing the signaling between the MN and HA. However, the tight coupling of the mobility protocol with IPsec is detrimental to broader implementation and deployment. This document proposes a scheme based on Identity-Based Cryptography mechanism to authenticate the mobile node and signaling of home biding update to home agent. Hence, the use of IPsec could be avoided. "IANA IPv4 Special Purpose Address Registry", Geoff Huston, Michelle Cotton, Leo Vegoda, 27-Feb-09, This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. "Using EAP-GTC for Simple User Authentication in IKEv2", Yaron Sheffer, 24-Feb-09, Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user. IKEv2 uses EAP as a sub-protocol for user authentication. This provides a well-specified and extensible architecture. To this day EAP does not provide a simple password- based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP). This document codifies the common practice of using EAP-GTC for this type of authentication, with the goal of achieving maximum interoperability. The various security issues are extensively analyzed. "P2PSIP Security Requirements", Judy Zhu, Minpeng Qi, 24-Feb-09, This draft discusses the security requirements in Peer-to-Peer (P2P) SIP system. As the P2P SIP is distributed and each peer is equal in it, it should face the extra security threat from traditional system. This draft introduces these security threats at first. After that, the security requirements of P2P SIP system were brought up. "Hierarchical IPv4 Framework", Patrick Frejborg, 5-Mar-09, This draft describes a framework how the current IPv4 address structure can be extended towards a similar hierarchical numbering structure as used in the Public Switched Telephone Network and bring hierarchy to the routing architecture of Internet. The framework requires extensions to the existing Domain Name System architecture, the existing IPv4 stack of the end systems (hosts) and to routers in the Internet. The framework can be implemented incrementally to the hosts, databases, routers and for some applications that transport IPv4 addresses in their payload. "MPLS-TP Linear Protection", Yaacov Weingarten, Nurit Sprecher, Annamaria Fulignoli, Huub Helvoort, 9-Mar-09, This document describes mechanisms for linear protection of Multi- Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) and Pseudowires (PW) on multiple layers. Linear protection provides a fast and simple protection switching mechanism, that is especially optimized for a mesh topology. It provides a clear indication of the protection status. The mechanisms are described both at the architectural level as well as providing a protocol that is used to control and coordinate the protection switching. "Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", Kohei Shiomoto, Adrian Farrel, 24-Feb-09, The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and links to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. End points of the LSP need to know when it is safe to start sending data so that it is not misdelivered and so that safety issues specific to the data plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to programme their data planes relative to sending control plane messages. This document clarifies and summarises the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidireciotnal and bidirecitonal LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. "MANET Router Configuration Recommendations", Thomas Clausen, Ulrich Herberg, 25-Feb-09, This document describes a pragmatic set of configuration recommendations for MANETs, as well as provides a rationale for why these recommendations are sound. While there may be other equally valid ways of configuring a MANET, the recommendations in this document have the merit of being supported by an existence proof (there're running networks in existence, configured according to these recommendations), and they require neither modifications to the IP stack nor to upper-layer protocols or applications. "Transmission of SYSLOG message over DTLS", Hongyan Feng, 10-Apr-09, This document describes a Transport for the Syslog Protocol, that uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides authentication and privacy services for SYSLOG applications. This document describes how using DTLS to transport SYSLOG messages makes this protection possible in an interoperable way. This transport is designed to meet the security and operational needs of network administrators, operate in environments where a datagram transport is preferred, and integrates well into existing public keying infrastructures. "Using HTTP GET with HTTP-Enabled Location Delivery (HELD)", Martin Thomson, 25-Feb-09, This document describes how an HTTP GET request to an HTTP-Enabled Location Delivery (HELD) resource is handled by the server responsible for that resource. This ensures that requests generated by user agents that are unaware of the special status of a URI do not result in unhelpful responses and enables the use of HTTP GET for location configuration and dereference. "Multiprotocol Label Switching Transport Profile Backward Notify Message Packet", Guoman Liu, Jian Yang, Lili Jiang, 23-Feb-09, This document specifies an extension to MPLS BDI packet to form a new type of OAM packet BNM(Backward Notify Message) , this BNM packet will not only have the function of informing source MEP about existing fault in the back of path like MPLS BDI packet, but also it may response or feedback to performance and test aspect. And these response or fault indication information will be encapsulated in BNM packet by the way of TLV packet. So it may decrease the number of OAM type and keep compatibility with MPLS network. on the other hand, this encapsulating these feedback or response information by the way of TLV packet will be easy to extend OAM function to operate an MPLS Transport profile(MPLS-TP) label switched path (LSP). "Link Bundle in Wavelength Switched Optical Networks", Xihua Fu, 2-Mar-09, [RFC4201] provides a link bundle mechanism to improve routing scalability by reducing the amount of information that has to be handled by IGP (OSPF and/or IS-IS). This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of important information. In WSON and MRN, this lost information is very important for the path computation entity to calculate an accurate path. This document discusses some requirements of link bundle for the new GMPLS networks (e.g., WSON and MRN). The draft gives some routing and signaling analysis for this issue. "Mythbustering Peer-to-peer Traffic Localization", Enrico Marocco, Ivica Rimac, Vijay Gurbani, 26-Feb-09, Peer-to-peer traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study (or studies) that have addressed facts pertaining to the myth. Using these studies, we hope to either confirm or refute each specific myth. "Robust Configuration Management within NETCONF", Robert Cole, Dan Romascanu, 26-Feb-09, The IETF has developed a new configuration management protocol, NETCONF. NETCONF has defined a capability called ':confirmed-commit' which allows a management application time to build confidence in desired configuration changes prior to the managed device committing to the changes. However, NETCONF does not define methods to build this confidence in configuration changes, nor does it afford the remote managed device the opportunity to actively participate in the test and evaluation phase of the ':confirmed-commit' capability. We believe that this capability should be further developed to afford network management applications and managed devices a more robust and resilient configuration management capability, which is of value to commercial enterprise and public networks as well as wireless emergency and military networks. We explore the alternatives for enhancing this capability within the context of the existing NETCONF protocol, the YANG modeling language and existing related IETF standards. "Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport Profile process", Loa Andersson, David Ward, Malcolm Betts, 20-Apr-09, The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile in cooperation between IETF and ITU-T does not fully defines and document process for development the required RFCs. This document complements the process as documented in the JWT decision with a couple of separate elements o An adaptation of the IETF working group process. o Identifies the expected participation in the process by the ITU-T. o A clarification of the decision rules regarding MPLS-TP documents. This document does not intend specify any ITU-T process, to the extent that is necessary it will be done according to ITU-T processes. "Syslog Sending Policy Messages", Washam Fan, 26-Feb-09, This document defines special syslog messages called Sending Policy messages for indicating how syslog senders process syslog messages before sending them. The information Sending Policy messages convey is of interest to syslog receivers and helpful for audit. "Flexible IPv6 Migration Scenarios in the Context of IPv4 Address Shortage", Mohammed Boucadair, Pierre Levis, Jean-Luc Grimault, Alain Villefranque, Mohamed Kassi-Lahlou, 6-Mar-09, This memo presents a solution to solve IPv4 address shortage and ease IPv4-IPv6 interworking. The document presents a set of incremental steps for the deployment of IPv6 as a means to solve IPv4 address exhaustion. Stateless IPv4/IPv6 address mapping functions are introduced and IPv4-IPv6 interconnection scenarios presented. This memo advocates for a more proactive approach for the deployment of IPv6 into operational networks. This document provides both the specification of the solution and deployment scenarios together with migrations paths. "NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS", Stefan Winter, Mike McCauley, 26-Feb-09, This document specifies a means to find authoritative AAA servers for a given NAI realm. It can be used in conjunction with RADIUS over TLS and RADIUS over DTLS. "Definitions of Managed Objects for lock via network management protocols", Tony Meng, Washam Fan, 1-Apr-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It describes managed objects used for monitoring locks on a device, in paticularly, acquired or released by NETCONF and COPS-PR entities. "Packet Pseudowire Encapsulation over an MPLS PSN", Stewart Bryant, Sami Boutros, Luca Martini, Siva Sivabalan, George Swallow, David Ward, Andrew Malis, 27-Feb-09, This document describes a pseudowire that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. For correct operation these clients require a multi-protocol interface with fate sharing between the client protocol suite. The packet pseudowire may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. "Service Identifiers for HIP", Tobias Heer, Hanno Wirtz, Samu Varjonen, 27-Feb-09, The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables HIP end-hosts and HIP-aware middleboxes to announce services to HIP hosts during a HIP Base EXchange (BEX) or HIP update. Service providers are able to specify the type and requirements of a service; clients can then decide to agree on the terms of service. This allows the service provider to verify the accordance of the client with the service conditions while the client is able to verify the authenticity of the used service. "Negotiating IPv6 Encapsulating Security Payload (ESP) Security Association (SA) with Cryptographically Generated Addresses (CGA)", Dong Zhang, 27-Feb-09, This memo specifies a new approach of Encapsulating Security Payload (ESP) Security Association (SA) negotiation. Because of the existing of the Cryptographically Generated Addresses (CGA) extension header and the key pair in CGA, it is convenient and feasible to negotiate ESP SA under the protection of key pair. "Multi-interface Network Connection Manager in Arena Platform", Yan Zhang, Tao Sun, Hua Chen, 27-Feb-09, This document presents a "Connection Manager" model implemented in the platform Arena, a mobile OS based on Linux. The introduction of Connection Manager brings two major benefits in Arena. First, it logically decouples the underlining connection approach with the connection management. Second, it plays a central role which executes the policy of OS, especially for multiple interfaces. "Extension of DHCPv4 for policy routing of multiple interfaces terminal", Min Hui, Hui Deng, 27-Feb-09, Current multiple interfaces terminal causes the problem of selecting a proper interface for a specific application, and this is a new question which will change the previous internet model. This document proposes a solution which uses policy routing to map the IP flows to multiple interfaces. "An Analysis of Scaling Issues for Point-to-Multipoint Label Switched Paths in MPLS-TE Core Networks", Olufemi Komolafe, Adrian Farrel, Daniel King, 28-Feb-09, Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks, and the scaling properties have been analyzed to show how much control state must be maintained to support a full mesh of edge-to-edge point-to-point (P2P) Label Switched Paths (LSPs) in various network topologies and with several different scaling techniques. Point-to-multipoint (P2MP) MPLS-TE LSPs are very interesting to service providers as a means to provide multicast services (such as TV distribution, or multicast VPN connectivity) across core MPLS networks. P2MP LSPs have different scaling properties than P2P LSPs, and service providers need to understand whether existing protocols and implementations can support the network sizes and service levels that they are planning in their P2MP MPLS-TE networks. This document presents an analysis of the scaling properties MPLS-TE core networks that support P2MP LSPs. "OCSP Algorithm Agility", Phillip Hallam-Baker, 27-Feb-09, The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. "Extensible Messaging and Presence Protocol (XMPP) End-to-End Encryption Using Transport Layer Security ("XTLS")", Dirk Meyer, Peter Saint-Andre, 8-Mar-09, This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic via an application-level usage of Transport Layer Security (TLS). XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, thus enabling XMPP entities to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. The protocol can be used for secure end-to-end messaging as well as any others application such as file transfer. "Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP)", Dirk Meyer, Peter Saint-Andre, 8-Mar-09, This document defines methods for managing and using client certificates in the Extensible Messaging and Presence Protocol (XMPP). These methods, which make use of the EXTERNAL mechanism of the Simple Authentication and Security Layer (SASL) protocol, enable an XMPP client to log in to an XMPP server without providing a password. "HIP and Strong Password Authentication of Users", Samu Varjonen, 28-Feb-09, This document specifies how to use Secure Remote Password (SRP) protocol in conjunction with Host Identity Protocol (HIP). In order to conceive this conjunction this document specifies three new parameters to be used with HIP control packets. These parameters are used to transport values related to the SRP protocol. This document also specifies how peers should act when these SRP parameters are found from HIP control packets and how this affects middleboxes. "Tunnel Negotiation for Proxy Mobile IPv6", Frank Xia, Hidetoshi Yokota, Suresh Krishnan, 4-Mar-09, Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic between a Local Mobility Anchor(LMA) and a Mobile Access Gateway (MAG) to be tunneled using IPv6, IPv4 ,IPv4-UDP, or GRE encapsulation headers. In this document, a new mobility option is specified for tunnel negotiation between the LMA and MAG. "Access Node Control Protocol for Source Adress Validation", John Kaippallimalil, Frank Xia, 28-Feb-09, This document specifies an extension of Access Node Control Protocol to provide source address validation for IPv4 and IPv6 networks. An access router uses the proposed mechanism to provision source address validation states on a layer 2 device which a host may directly connects to. The solution proposed here can be used in either public access networks or enterprise networks. "Verified-Hello SMTP extension", Alessandro Vesely, 24-Apr-09, This memo defines an extension to the SMTP service whereby an SMTP client can know beforehand the reputation and whitelisting treatment for the messages that it is about to transmit. SMTP level support for anti-spam protocols implies that the sending part does its best to ease checking, possibly at the expense of some flexibility. In exchange, the receiving part lets the sender know whether its message is whitelisted, thereby recovering reliability. "The Extension of Subtree Filtering of NETCONF", Bin Zhang, Zhichao Yang, Yan Li, 28-Feb-09, The NETCONF protocol defines a subtree filtering mechanism to allow an client to select particular XML subtrees to be included in the for a or operation. In some aspects, subtree filtering has some disadvantages. This document defines an extended subtree filtering to solve these disadvantages. "Requirements on multiple Interface (MIF) of simple IP", Peng Yang, Pierrick Seite, Carl Williams, Jacni Qin, 1-Mar-09, This draft makes a summary on the requirements of supporting multiple interfaces (MIF) in hosts with simple IP. These requirements result from examining scenarios for multiple interface host usages. The differentiation between MIF and other related IETF works are interpreted as well. "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng Jiang, Dayong Guo, 1-Mar-09, Global IPv6 deployment was slower than originally expected in the last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 transition issues become more critical and complicated. Host-based transition mechanisms are not able to meet the requirements while most end users are not sufficiently expert to configure or maintain these transition mechanisms. Carrier Grade NAT with integrated transition mechanisms can simplify the operation of end users during the IPv4/IPv6 migration or coexistence period. This document proposes an incremental Carrier-Grade NAT (CGN) solution for IPv6 transition. It can provide IPv6 access services for IPv6-enabled end hosts and IPv4 access services for IPv4 end hosts while remaining most of legacy IPv4 ISP networks unchanged. It is suitable for the initial stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and encourages transition towards dual-stack or IPv6-only ISP networks. "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", Anna Charny, Fortune Huang, Michael Menth, Tom Taylor, 1-Mar-09, Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in ID.PCNArch. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for three-state measurement-based load control, known informally as CL. The requirement for three encoding states means that CL is for experimental use only pending further standards action. "Analysis and scenarios of multiple interfaces in a host", Yong-Geun Hong, Joo-Sang Youn, 1-Mar-09, This document is an analysis of multiple interfaces in a host and description of scenarios of multiple interfaces with the respect of TCP/IP layer. The current TCP/IP mechanism and networking methods are suitable for a single network interface. When a host has multiple interfaces, the current TCP/IP mechanism and networking methods cannot directly be used for them. In this document, we describe some problems for a host which has multiple network interfaces as an aspect of host's operations and some usage scenarios of multiple interfaces in a host. "Virtual network interface model for multiple network interfaces in a host", Yong-Geun Hong, Joo-Sang Youn, 1-Mar-09, The use of multiple interfaces in a host with existing TCP/IP stack may have some problems. This document discusses how to solve the problems of multiple interfaces in a host and proposes a virtual network interface model which describes the use of original TCP/IP stack to support multiple network interfaces in a host. "OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)", Fatai Zhang, Greg Bernstein, Young Lee, Dan Li, Jianrui Han, 1-Mar-09, Wavelength switched optical networks (WSONs) are based on Wavelength Division Multiplexing (WDM) in which user traffic is carried by data channels of different optical wavelengths. In traditional WDM Networks, each wavelength path is statically configured. With the deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), photonic cross-connects (PXCs), and tunable laser, WSONs have become more dynamic, and operators can flexibly set up wavelength paths to carry user traffic. In WSONs where there are no or a limited number of switches capable of wavelength conversion paths must be set up subject to the "wavelength continuity" constraint. This leads to a path computation problem known as routing and wavelength assignment (RWA). In order to perform such computations, it is necessary to collect information about the available wavelengths within the network. This document describes OSPF routing protocols extensions to support Wavelength Switched Optical Networks (WSON) under the control of Generalized MPLS (GMPLS). "ALTO H1/H2 Protocol", Martin Stiemerling, Sebastian Kiesel, 2-Mar-09, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This memo proposes one possible way of implementing the ALTO protocol, called H1H2. The H1H2 protocol is a client/server protocols between end hosts and ALTO servers that allows two different ways of exchanging data between the server and the client. "SAVAH: Source address validation architecture with Host Identity Protocol", Dmitriy Kuptsov, Andrei Gurtov, 6-Mar-09, This document describes an architecture for the source address validation with help of Host Identity Protocol (HIP), SAVAH. The architecture utilizes the properties of cryptographically strong protocol to authenticate an originator of a network communication. In addition this architecture offers network access control, data protection, host mobilty and multihoming features and is suitable for the wireless networks. The proposed, architecture is the first-hop router solution, meaning that it should be deployed on the router placed on the edge of a local network topology. "RTSP 2.0 Bitrate Notification", Hiroyuki Hatano, Kunihiro Taniguchi, Akira Kobayashi, Martin Stiemerling, 9-Mar-09, Typically, there is no use for providing bandwidth information from an RTSP 2.0 server to RTSP 2.0 clients. The bandwidth of the medias played out by the server is different from the available bandwidth in the network (which is also changing) and there is anyhow the need to perform congestion control during media playout. This is true for Internet deployments, or similar, but conveying information about bandwidth of the medias can be required in other deployments of RTSP 2.0. It might necessarily for RTSP 2.0 clients to obtain information about the by medias used bandwidth in networks that rely on bandwidth reservation initiated by the end host. An example is the Next Generation Network (NGN) standardized by ETSI TISPAN, where RTSP 2.0 clients must indicate the required bandwidth to the network. This memo discusses how to provide bandwidth information from RTSP 2.0 servers to clients and how to introduce it in RTSP 2.0. "RSVP-TE extensions to GMPLS Calls", Fatai Zhang, Dan Li, Jianhua Gao, 1-Mar-09, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain case). This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit nodes (besides the Call-initiator and Call-terminator) are involved in these Calls. "Requirements for PCE applied in Time-Division Multiplexing (TDM) Networks", Fatai Zhang, Dan Li, Jianhua Gao, 2-Mar-09, This document describes the special requirements for applying the Path Computation Element (PCE) in Time-Division Multiplexing (TDM) networks, including Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Digital Wrapper (G.709 ODUk). The material presented in this document is collected here for analysis. The intention is to separate this material into separate documents on generic GMPLS requirements, generic GMPLS extensions, and TDM-specific requirements and extensions. "A Session Initiation Protocol (SIP) Reason Header extension for dynamic Incoming Communication Barring", Ranjit Avasarala, Subir Saha, Victor Pascual, 2-Mar-09, The 3GPP, as part of the MITE work item, is defining the Multimedia Telephony service and other Supplementary services using the IP Multimedia Core Network framework. Supplementary services include Incoming and Outgoing Communication Barring. This document describes a new set of procedures for Incoming Communication Barring to allow terminating users to dynamically block unwanted incoming communications. A new extension to SIP reason header is also described. "Re-ECN: The Motivation for Adding Congestion Accountability to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 2-Mar-09, This document describes the motivation for a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. Re-ECN allows accurate congestion monitoring throughout the network thus enabling the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. As well as giving the motivation for re-ECN this document 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 use the protocol honestly. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. "P2PSIP Event Notification Extension", Jun Wang, Zhifeng Chen, 2-Mar-09, The p2p technology is data centric, where the data objects are distributed in the p2p overlay according to the routing algorithm. Applications access the data objects via peer/client protocol or gateways, and some of them require data replicas to be synchronized in real time, such as a data object stored in overlay and its cache copy in client memory. This can be achieved by introducing an event notification extension to p2p protocol. This document describes the subscribe/notify mechanism for p2psip and define several new methods to implement such extension. "Requirement of Impairment Compensation Control in WSON", Shoichiro Seno, Yoshimasa Baba, Eiichi Horiuchi, Kazuo Kubo, 2-Mar-09, This memo describes requirements of compensation control of optical impairments such as chromatic dispersion for dynamic optical paths, as well as automatic discovery of fiber-related impairments over links by collaboration of a pair of adjacent nodes upon installation. It is intended as a supplement to the wavelength switched optical networks (WSON) framework with impairments, because GMPLS-based automatic adjustment of impairment compensation and automatic discovery of link impairments will improve usability of WSON. "Deriving Keys From TLS for Kerberos V5", Simon Josefsson, 6-Mar-09, This document describes how clients can use the Kerberos V5 over TLS protocol together with its long term key to 1) avoid having to validate the server certificate, 2) securely learn a KDC's server certificate, and 3) learn the trust anchors used by the KDC. We also describe how the Kerberos V5 over TLS protocol can be used to 4) avoid the need for a long term shared key between the client and the KDC by instead using TLS client authentication. These goals are achieved by introducing a new Kerberos V5 pre- authentication type that modify how the Kerberos V5 reply key is derived. "Status of Normative References in RFC3261", Robert Sparks, 2-Mar-09, This document captures the current status of the normative references in RFC3261. It is intended to inform continuing discussions on how to maintain the SIP protocol. "RFC3261 Interop Statement", Robert Sparks, 2-Mar-09, This document captures an outline of the interoperability statements that will be collected to construct an interoperability report for RFC 3261. The outline is stil under review and should not be treated as complete, but will drive data collection at upcoming interoperability events. "MPLS TP Network Management Framework", Scott Mansfield, Kam Lam, Eric Gray, 23-Apr-09, This document provides the network management framework the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Mansfield, et al Expires October 23, 2009 [page 2] Internet-Draft MPLS-TP NM Framework April 23, 2009 "The RPKI/Router Protocol", Randy Bush, Rob Austein, 19-Apr-09, In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. "Rethinking TCP Friendly", Matt Mathis, 2-Mar-09, The current Internet fairness paradigm mandates that all protocols have equivalent response to packet loss, such that relatively simple network devices can attain a weak form of fairness by sending uniform signals to all flows. This "TCP-friendly" paradigm has been the policy of the IETF for nearly two decades. Although it was only an informal policy in the beginning, it progressively became more formal following the publication of RFC 2001 in 1997. However we observe two trends that differ from this policy: an increasing number of environments where applications and other circumstances create situations that are "unfair", and ISPs that are responding to these situation by imposing traffic control in the network itself. This note explores the question of whether TCP-friendly paradigm is still appropriate for the huge breadth of technology and scale encompassed by today's global Internet. It considers the merits and difficulties of changing IETF policy to embrace these changes by progressively moving the responsibility for capacity allocation from the end-system to the network. Ultimately this policy change might eliminate or redefine the requirement that all protocols be "TCP- Friendly". This note is intended foster discussion in the community and eventually become input to the IESG and IAB, where it might evolve into a future architecture statement. "Information Encoding for Impaired Optical Path Validation", Greg Bernstein, 2-Mar-09, This document provides an information encoding for the optical impairment characteristics of optical network elements for use in path computation and optical path impairment validation. This encoding is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This encoding is intentionally compatible with a previous impairment free optical information encoding used in optical path computations and wavelength assignment. "The PROXIDOR Service", Obi Akonjang, Anja Feldmann, Stefano Previdi, Bruce Davie, Damien Saucez, 2-Mar-09, Several applications, such as peer-to-peer (P2P), content distribution and realtime services rely on selection mechanisms in order to select the peer or server from which to request the service. Examples of such services are: file sharing, media streaming and voice gateways. Application-layer selection algorithms do not typically take into account network-layer topology information; either that information is unavailable to them, or when such information is available (e.g., from BGP Looking Glass servers), it does not include sufficient information about the local topology in the neighbourhood of the application client(s). Therefore, most applications today make their selection decisions based on performance measurements (combined with some amount of random selection) and largely ignore network layer routing. It has been demonstrated that by keeping the traffic local (e.g., within the same Autonomous System) both infrastructure utilization and application performance may be improved. By enhancing selection algorithms through the use of accurate network-layer topology, applications may improve performance while network operators are also able to reduce the utilization of infrastructure resources by application traffic. At the same time, exchange of information between the application and the network should not be allowed to compromise confidentiality for either party. Detailed routing information owned by the service provider should not be made publicly available, while detailed information about the application should also not be made known to the service provider. This draft introduces a signaling protocol which we call "PROXIDOR". The PROXIDOR protocol is a request-response protocol in which a PROXIDOR Client (PxC) issues requests to and receives responses from a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS and how a PxS acquires network-layer topology information are beyond the scope of this document. "Multicast only Fast Re-Route", Apoorva Karan, Clarence Filsfils, Dino Farinacci, 2-Mar-09, As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This draft describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast only Fast Re- Route (MoFRR) works by making simple enhancements to multicast routing protocols such as PIM. "IUA Extension for Rate Control Message", Nick Stewart, Geoff Hunt, Dal Chohan, 2-Mar-09, This document describes a new message, its associated acknowledgement message, and a new parameter to extend the ISDN Q.921-User Adaptation (IUA) protocol (RFC4233). The protocol extension is to support the use of an Overload Control Agent in a Signaling Gateway (SG). The Overload Control Agent is able to restrict the admission of new originating ISDN calls (sessions) messages from the ISDN End Point to each Application Server Process (ASP). Both messages defined here contain a single mandatory parameter, the Call (Session) Admission Rate. An ASP is able to use this protocol extension to control the rate of new calls admitted towards that ASP by the Overload Control Agent. The new message and its acknowledgement message are added to the Application Server Process Traffic Maintenance (ASPTM) message class. As the DPNSS1/DASS2 Extension to IUA (DUA, RFC4129) also uses the ASPTM message class, the IUA protocol extension described in this document also applies to DUA. For backward compatibility, a Signaling Gateway which does not support the new message is expected to follow standard IUA behaviour by discarding the message, and returning an error code of "Unsupported Message Type" to the sender. "Local Forwarding in Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury, 2-Mar-09, With bidirectional tunneling in Proxy Mobile IPv6, the communication between any two Mobile Nodes is required to traverse the Local Mobility Anchor (LMA). This is the case even when the communicating Mobile Nodes are attached to the same Mobility Anchor Gateway (MAG). This document introduces two messages between the LMA and the MAG enabling local forwarding by the MAG. Such forwarding avoids the delay due to bidirectional forwarding, and reduces the traffic load on the LMA. "Modular RELAX NG Schema of NETCONF RPC and Protocol Operations", Ladislav Lhotka, 2-Mar-09, This memo presents a schema for NETCONF RPC and protocol operations expressed in RELAX NG (compact syntax). The schema is modular and cleanly separates the server and client part of the NETCONF vocabulary and also the schema extensions provided by optional capabilities. The modular structure improves readability but also enables selecting certain modules and assembling them into a grammar that can be used for validation of NETCONF protocol data units. "A Batch Notification Extension for the Session Initiation Protocol (SIP)", Alan Johnston, Bill Mertka, 2-Mar-09, This memo specifies the requirements and mechanism for a SIP events extension where bulk SIP event information can be shared between two peers both with the ability and authority to act as notifiers for this information. An example application use case is the transition of event state information during a backup/recovery sequence between event state servers. This document is targeted at addressing server overflow conditions that include the possibilities of the size of individual notification messages getting excessive and the processing of state information by both the subscriber and notifier also becoming excessive. "Default Router and Prefix Advertisement Options for DHCPv6", Ralph Droms, Thomas Narten, 2-Mar-09, In some IPv6 deployments, there is a requirement to communicate a list of default routers and advertised prefixes to a host through DHCP. This document defines DHCP options to carry that information. "Recommendations for Processing Mechanism for Checksum Error LSP in Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", Xiaodong Duan, Lianyuan Li, Zhenqiang Li, 2-Mar-09, This document discusses the processing mechanism for the Link State Protocol Data Unit (LSP) with an incorrect LSP Checksum in the interoperable networks using IS-IS. It is suggested to add a configurable switch to control the processing mechanism of checksum error LSP. This document clarifies the processing mechanism for zero checksum LSP and zero remaining lifetime LSP, and gives advices to calculate the checksum of all kinds of LSPs as well. "CJK local mapping in IDNA2008", Yoshiro Yoneya, Yungjin Suh, Erin Chen, XiaoDong Lee, 9-Mar-09, Development of IDNA2008 is now in final stage. It will cause incompatibilities for Chinese, Japanese and Korean (CJK) scripts and languages. To avoid incompatibilities with IDNA2008 and current IDNA (IDNA2003), definition of specific local mapping (pre process of IDNA to be performed to IDN candidate string) for CJK is recommended. "SIP digest authentication relay attack", R State, O Festor, Humberto Abdelnur, Victor Pascual, J Kuthan, 2-Mar-09, The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism for creating, modifying, and terminating sessions with one or more participants. This document describes a vulnerability of SIP combined with HTTP Digest Access Authentication [RFC2617] through which an attacker can leverage the victim's credentials to send authenticated requests on his behalf. This attack is different from the man-in-the-middle (MITM) attack and does not require any eavesdropping, DNS or IP spoofing. "Live Entity State Stream (LESS) protocol description", Jon Watte, 4-Mar-09, Virtual worlds, typically implemented as multi-user shared simulations, are becoming increasingly used for serious work in addition to the traditional uses of research and entertainment. Whereas previous distributed simulation protocols have been designed with narrow, time-definite scope, the LESS (Live Entity State Stream) protocol is designed to allow open-ended join and leave for a multitude of simulation peers. The LESS protocol specifies how peers of a simulation collaborate and share state to achieve a mutually agreed "collective hallucination," leading to a user-perceivable shared state of a simulated worlds. "LISP Map Server", Dino Farinacci, Vince Fuller, 2-Mar-09, This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. "Dual Homed Access in Virtual Private Multicast Service", Wu Bo, Zhang Xinquan, Luo Jian, Chen Ran, 2-Mar-09, Virtual Private Multicast Service (VPMS) is defined as a Layer 2 VPN service. It provides point-to-multipoint connectivity for a variety of Layer 2 technologies, including Frame Relay, ATM, Ethernet, PPP, etc, across an IP or MPLS-enabled IP Packet Switch Network (PSN). It is often required for redundant access between two VPMS PEs to which a CE is attached, called "dual-homed". This document describes how dual-homed access can be achieved in the context of BGP-based VPMS. "Problem Statement for Route Optimization in dual stack environments", Desire Oulai, Suresh Krishnan, Hesham Soliman, 2-Mar-09, Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 mobility for mobile hosts. While route optimization is well defined for IPv6 traffic, this features is not defined for IPv4. This document looks at the different scenarios where IPv4 route optimization is desirable and highlights some problems. "DSMIPv6 Route Optimization", Desire Oulai, Suresh Krishnan, Hesham Soliman, 2-Mar-09, Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 mobility for mobile hosts. While route optimization is well defined for IPv6 traffic, this feature is not defined for IPv4. However, Route Optimization has many advantages as reduced delays and lower load for the Home Agent. This document proposes solutions for the different scenarios where IPv4 route optimization is performed. "A Survey of Lower-than-Best Effort Transport Protocols", Michael Welzl, 2-Mar-09, This document provides a survey of transport protocols which are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for low-priority "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best effort service. "Multiple Passwords per User in XMPP", Kurt Zeilenga, 2-Mar-09, This document discusses use of multiple passwords (per user) in XMPP. "SIP-Specific Event Notification", Adam Roach, 3-Mar-09, This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. "Rapid Multicast Synchronization Report Block Type for RTCP XR", Ali Begen, 3-Mar-09, In most RTP-based multicast applications, the RTP source sends inter- related data. Due to the dependency in the multicast data, randomly joining RTP receivers may not be able to start usefully consuming the data upon joining the multicast session, thus, they often experience a random synchronization delay. In order to reduce this delay, an auxiliary unicast RTP session that facilitates rapid synchronization with the multicast session may be used between a retransmission server and RTP receivers. Yet, due to various random components pertaining to the RTP data and networking infrastructure, the performance of rapid synchronization may vary. For quality reporting and diagnostics, it is important to collect detailed information from the RTP receivers about their rapid synchronization experiences. This document addresses this issue by defining a new report block type, called Rapid Multicast Synchronization Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). This document also defines the necessary signaling of the new report block type in the Session Description Protocol (SDP). "ALTO H12", Sebastian Kiesel, Martin Stiemerling, 3-Mar-09, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This memo proposes one possible way of implementing the ALTO protocol, called H12. "IPSEC_API requirements", Daniel Migault, 2-Mar-09, IPsec suite has been designed to secure communication between two nodes. Security is performed at the network layer, and there are almost no interactions between applications and the IPsec layer. The main motivation of this API is to enable any applications to interact with the IPsec layer and to take advantage of the security deployed in IPsec suite. This draft lists applications requirements with regard to the IPsec suite, and we tried not to limit the requirements to today's application requirements, but also to consider future applications' requirements. Applications are associated to different privileges, and IPsec layer MUST be protected from nasty IPsec manipulations. This draft is not considering applications privileges management. This draft lists any possible requirements on the IPsec layer an application might require. "MIP Extension for Ethernet Service transport Support", Wenson Wu, Shah Rahman, Hui Deng, 11-May-09, The IP Mobility Protocol [RFC3344] enables a mobile node maintain IP connectivity when it changes its location. However, it is not enough to enable the node to maintain L2 connectivity between mobile node and Ethernet service provider in order to support Ethernet service transport. This document describes "Ethernet Service Transport" mobility option for mobile IPv4 that is intended to assist home agent tunnel Ethernet packets from the home link to the FA on the foreign link during the datagram delivery process. "6to4 Qualification", Nathan Ward, 3-Mar-09, A deployment problem exists with existing self-configuring 6to4 implementations making often incorrect assumptions about the state of their IPv4 network connectivity. This document describes the problem, and proposes a qualification mechanism by which nodes can validate that their connectivity to the global IPv6 network is suitable for use with the 6to4 protocol. "Issues with ISP Responses to IPv4 Address Exhaustion", Alain Durand, Mat Ford, Phil Roberts, 3-Mar-09, The looming completion of IPv4 address allocations from IANA and the RIRs is already causing ISPs around the world to start to question how they will continue providing IPv4 service to IPv4-speaking customers when there are no longer sufficient IPv4 addresses to allocate them one per customer. Several possible solutions to this problem are now emerging and this memo identifies important criteria to be borne in mind when evaluating these solutions. We also seek to identify serious issues that remain even when mechanisms meeting our criteria are adopted. We wish to stress that these solutions have a number of common, and potentially serious, issues. "Runtime LMA Assignment Support for Proxy Mobile IPv6", Jouni Korhonen, Sri Gundavelli, Hidetoshi Yokota, 11-May-09, This document describes a redirect functionality and corresponding mobility options for Proxy Mobile IPv6. The redirect functionality allows a dynamic runtime assignment of a Local Mobility Anchor and redirecting the mobility session to the assigned Local Mobility Anchor. "Re-INVITE Handling in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 3-Mar-09, In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target refresh requests. "Media State under Preconditions in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 3-Mar-09, In this document, we describe how a UAS (User Agent Server) involved in a session modification can explicitly signal the point where the new session parameters start being used. Explicitly signalling such a change in the session parameters can be useful so that network intermediaries such as B2BUAs (Back-to-back User Agents) have a clear picture of the session's state at every point. "Clarification of RRO Node-Id Sub-Object", Harish Sitaraman, Yuji Kamite, 3-Mar-09, This document clarifies the RRO format and usage of the node-id sub- object as defined in [RFC4561]. The RRO stacking order and allowed formats when including the node-id sub-object is specified. "Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option", Gregory Lebovitz, 3-Mar-09, The TCP Authentication Option, TCP-AO, relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithm(s). This document specifies the algorithms and attributes that can be used in TCP-AO manual key mode. It also defines a UI labels framework that will be used across implementations to aid administrators in quickly achieving successful TCP-AO connections, something that will become far more important once a key management protocol (KMP) is defined for TCP-AO. "LISP Mapping Versioning", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 3-Mar-09, The present document sketches an alternative approach to provide information about changes to EID-to-RLOC mappings in the context of LISP. The proposed approach is based on a versioning system for the EID-to-RLOC mapping itself. When there is a change in the mapping (where change could mean adding/removing an RLOC or just a modification in the priority or weight of one or more RLOCs) a new version number is generated and propagated in the LISP data packet. In the LISP context, ETRs do not keep state that allows to know when an ITR changes a mapping. The versioning system is a data-driven mechanism to annonce those changes. In order to support such an approach, the LISP encapsulation need to be modified. In particular LISP-encapsulated data packets have to contain the version number of the mapings used to select the RLOCs in the outer header. These version numbers are contained in a "new" LISP header. The mappings are distributed as usual through the mapping distribution system (e.g., CONS, ALT); versioning is only a mean to announce that something has changed in the mapping. The infrastructure built by each specific mapping protocol does not change anyhow. Nevertheless, two modifications are needed. The first modification consist in including version number in the Map- Reply messages. The second modification consist in the introduction of a new message, the "Map-Update-Notification" message used by ETRs to notify ITRs that the mapping used to encapsulate the packet is old and needs to be updated. This message does not contain the mapping, it just suggests ITRs to perform a Map-Request in order to retrieve the updated mapping. "Extensible Authentication Protocol Method for Trusted Computing Groups (TCG) Trusted Platform Modules", Carolin Latze, Ulrich Ultes-Nitsche, Florian Baumgartner, 3-Mar-09, This document describes an Extensible Authentication Protocol (EAP) [RFC3748] method for identity distribution, authentication and session key distribution using the Trusted Computing Group's (TCG) Trusted Platform Module (TPM). The TPM has been defined by the TCG in order to establish a root of trust and measurements in (consumer) computers. It provides several cryptographic functions and a secure storage for keys and hashes. There is also a TPM specification for mobile devices called Mobile Trusted Module (MTM), which can also be used for EAP-TPM. This new EAP method allows network authentication, which also supports user anonymity, the usage of different user identities for the authentication with different network operators, result indication, and a fast re-authentication. "SIP Tracing Facility", Dale Worley, 3-Mar-09, This document defines a SIP option tag, "trace", to be used within SIP messages to request that SIP elements (both proxies and UASs) that receive the message reflect to the UAC the request they received and the response they gave by encapsulating the request and response in a provisional response. A new provisional response code "170" is defined to carry the request and response. This option tag is expected to be used solely for diagnostic purposes. "LEDBAT Practices and Recommendations", Reinaldo Penno, Satish Raghunath, Janardhan Iyengar, 3-Mar-09, Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent download from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. But this practice also has impacts to the host and the network as a whole. For example, an application can obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. This documents clarifies the current practices of application design and reasons behind them, and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. "Diameter NAT Control Application", Frank Brockners, Cisco Systems, Cisco Systems, 3-Mar-09, This document describes the framework, messages, and procedures for the Diameter NAT Control Application (DNCA), allowing for per- endpoint control of large scale NAT devices, which are put in place to cope with IPv4-address space completion. The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT device. This includes, for example, the control of the total number of NAT-bindings allowed or the allocation of a specific NAT-binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes. "Running Code Considerations Section in RFCs", Marc Petit-Huguenin, Henry Sinnreich, 3-Mar-09, This document provides guidelines to IETF authors on the text that must be included in documents to reference running code and measurements. "RADIUS attributes for IPv6 Access Networks", Benoit Lourdelet, Wojciech Dec, Glen Zorn, 3-Mar-09, This document specifies new IPv6 attributes for RADIUS that complement [RFC3162]. Its goal is to offer more IPv6 deployment options when StateLess Address Auto Configuration (SLAAC) or DHCP are involved. "Open Grid Protocol: Foundation", Mark Lentczner, 3-Mar-09, The Open Grid Protocol documents define the protocols by which a vast, Internet wide virtual world can operate. This protocol enables different regions of the virtual world to be operated independently, yet interoperate to form a cohesive experience. This document specifies the foundation upon which various suites of virtual world functionality are built. It describes the basic structure of OGP interaction and common methodology and terminology for protocols. "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.", Huub Helvoort, Loa Andersson, Nurit Sprecher, 3-Mar-09, MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. "Export of Structured Data in IPFIX", Benoit Claise, Gowri Dhandapani, Stan Yates, Paul Aitken, 3-Mar-09, This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Access Network Discovery and Selection Function(ANDSF) Discovery", Subir Das, Gabor Bajko, 3-Mar-09, This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that allow clients to discover the IP address or the domain name of Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in 3GPP (Release-8) and provides inter-system mobility policies and access network specific information to the mobile nodes [3GPPTS23.402]. "MPLS-TP OAM Alarm Suppression Tools", Annamaria Fulignoli, Nurit Sprecher, Yaacov Weingarten, 3-Mar-09, The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for Alarm Suppression functionality as required in [3]. One packet format with two different function codes is here defined in order to distinguish among packets with Alarm Indication information and packets with Lock Indication Information. "Top Level Domain Name Specification", Lars-Johan Liman, 3-Mar-09, RFC 1123 is ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. This document clarifies the specification, and aligns it with current praxis, including the use of Internationalized Domain Name (IDN) Labels in TLD names. "A Load Balancing Mechanism for REsource LOcation And Discovery", Saumitra Das, Ashwin Swaminathan, Vidya Narayanan, 3-Mar-09, Load balancing is essential to effectively manage data and provide services on overlays. This draft presents a solution for load balancing the default topology plugin in RELOAD. "ALTO Discovery Protocols", Gustavo Garcia, Marco Tomsu, Yu-Shun Wang, 3-Mar-09, The Application-Layer Traffic Optimization service aims to provide applications with information to perform better-than-random initial peer selection when multiple peers in the network are available to provide a resource or service. This document discusses the discovery protocols for the service. "Protocol Analysis and Comparison of PPlive and PPstream by Internet Measurement", Yunfei Zhang, 3-Mar-09, In this draft we introduce an Internet measurement work for both pplive and ppstream. First, we give a brief introduction about our motivation and target of this measurement. We then introduce the methodology, platform, data and modeling of our measurement. Finally we outline the p2p media streaming protocols by the measurement. Zhang Expires September 3,2009 [page 2] Internet-Draft Protocol Analysis and Comparison of PPlive and PPstream by Internet Measurement March 2009 "vCard Format Extension : To Represent the Social Network Information of an Individual", Robins George, Alexey Melnikov, 3-Mar-09, This document defines extension for the vCard data format for representing and exchanging a variety of social network information of an individual. "MAC Flush Loop Detection in VPLS", Mountain View, Pranjal Dutta, 3-Mar-09, MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned for faster convergence. Failure of mechanisms that control loop free connectivity among VPLS PE nodes may cause MAC Address Withdrawal messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE node. "Multiple Interface Support with Proxy Mobile IPv6", Vijay Devarapalli, Nishi Kant, Heeseon Lim, Christian Vogt, 3-Mar-09, Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 mobile node with no mobility management protocol. It makes it appear to the mobile node that its IP address does not change as the mobile node moves across the Proxy Mobile IPv6 domain. There have been some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. This document describes and analyzes some of the scenarios associated with this. It also describes the requirements for a handover across interfaces using Proxy Mobile IPv6. "Partial Handoff Support in PMIPv6", Mohana Jeyatharan, Chan-Wah Ng, Sri Gundavelli, Kent Leung, Vijay Devarapalli, 3-Mar-09, Proxy Mobile IPv6 (PMIPv6) only supports session continuity for one basic scenario of vertical handoff -- the transfer of all prefixes assigned from one interface to another. However, there are some other advanced scenarios associated with vertical handoff that involves only transferring one (or some, but not all) of the prefixes that are allocated to an existing interface to a newly powered on interface. This draft outlines extensions to PMIPv6 protocol in order for a multiple interfaced mobile node to achieve such partial vertical handoff of selected prefix(es). "Targeted LDP Hello Reduction", Pranjal Dutta, 3-Mar-09, Targeted LDP Hellos are used for establishing adjacencies with non- directly connected peers. After an LDP session is established to a targeted peer, the session Keepalives are sufficient to notify the intent of an LSR to maintain its adjacency with the peer. This document proposes a mechanism to turn off Targeted LDP Hellos after LDP session is established to a peer. "A Pragmatic Approach for Reducing Delays in Publishing Documents within the Real-time Applications and Infrastructure (RAI) Area", Hannes Tschofenig, Henning Schulzrinne, Markus Isomaki, 3-Mar-09, During the last year, participants in the Real-time Applications and Infrastructure (RAI) area have been quite active in discussing proposals that could improve their way of working. This document is a contribution to that discussion and focuses on the reduction of delays experienced in producing specifications. We believe that this is one of the main problems in the RAI area (and quite likely in other areas of the IETF as well) and it requires attention. A number of side effects, caused by the long specification work, are illustrated in this document. "P2P Streaming Protocol (PPSP) Requirements", Ning Zong, Yunfei Zhang, Victor Pascual, 3-Mar-09, The Peer to Peer Streaming Protocol (PPSP) is a distributed real-time data retrieval protocol in one-to-many communication. This document describes the requirements for the PPSP. "Extension of DHCP Relay Agent Information Option", Lu Huang, Xu Cheng, Lin Lin, 3-Mar-09, This Internet draft describes an extension of DHCP Relay Agent Information option for the IP address assignment diversity and the server-to-client replies forwarding convenience. "Marking of Calls initiated by Public Safety Answering Points (PSAPs)", Henning Schulzrinne, Hannes Tschofenig, 3-Mar-09, After an emerency call is completed it is possible that the need for further communication between the call-taker and the emergency caller arises. For example, further assistance may be needed but the communication previously got interrupted. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback would then be treated like any other call. As a consequence, it may get blocked by authorization policies configured by the person seeking help or may get forwarded to his answering machine. The current ECRIT framework document addresses callbacks in a limited fashion and thereby covers a few scenarios. This document discusses shortcomings and raises the question whether additional solution techniques are needed. "LDP IGP Synchronization for broadcast networks", Sriganesh Kini, Wenhu Lu, 4-Mar-09, [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic (e.g. VPN) when IGP is operational on a link but LDP is not. If this mechanism is applied to broadcast links that have more than one LDP/IGP peer, the cost-out procedure can only be applied to the link as a whole but not an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol changes. "SIP extensions for media control", Shanmugalingam Sivasothy, Gyu Myoung Lee, Noel Crespi, 4-Mar-09, This draft presents a requirement and proposes a solution to integration of Session Initiation Protocol (SIP), to the Real Time Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP] especially in the context of converged media services or IPTV services. The document develops a rationale for using SIP with streaming media applications. One service on top of IPTV service is sketched out, which required SIP optimally. "Basic HTTP API interface for ACH", Theo Zourzouvillys, 8-Mar-09, This document defines a RESTful HTTP API that enables a SIP device (or agent activing on behalf of) a way to configure, enable, or disable services provided by the network. "Benchmarking Methodology for Content-Aware Network Devices", Mike Hamilton, 4-Mar-09, The purpose of this document is to define a series of test scenarios which may be used to generate statistics that should help to better understand the performance of network devices under realistic loading conditions. Additionally, this document provides suggestions on which statistics may be the most useful for determining network device performance under realistic deployment scenarios. "A Secure Call-ID for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 4-Mar-09, Many SIP devices generate Call-ID values which contain their system IP Address, due to examples and normative text in RFC 3261. This Kaplan Expires September 1, 2009 [page 1] SIP Secure Call-ID March 2009 has led to some middleboxes, such as SBC's, to change the Call-ID for security reasons. This draft updates RFC 3261 to require SIP User Agents to generate benign Call-IDs, in such a manner that they can be detected as secure and not need to be changed. "Evolution Towards Global Routing Scalability", Beichuan Zhang, Lixia Zhang, 9-Mar-09, Internet routing scalability has long been considered a serious problem. Over the years many efforts have been devoted to address this problem, however the IETF community as a whole is yet to achieve a shared understanding on what is the best way forward. We step up a level to re-examine the problem and the ongoing efforts, and conclude that, to effectively solve the routing scalability problem, we first need a clear understanding on how to introduce solutions to the Internet, which is a global scale deployed system. In this draft we sketch out our reasoning on the need for an evolutionary path towards scaling the global routing system, instead of attempting a new design. "Multi-interface Connection Manager Implementation and Requirements", Jian Yang, Tao Sun, Shunan Fan, 4-Mar-09, This document presents the current implementation and problems encountered in practice of the "Connection Manager." The problems to be addressed exist within an operating system (OS) and platforms above OS. This document focuses on levels above OS and presents the solutions, especially for terminals with multiple interfaces. The scenarios of interface selections are described. "Proxy MIP extension for local routing optimization", Wenson Wu, Behcet Sarikaya, 4-Mar-09, Proxy Mobile IPv6 allows the Mobility Access Gateway (MAG) to optimize the media delivery by locally routing the packets within one MAG, However it does not support optimization of the media delivery by locally routing the packets between MAGs sharing the same LMA. This document specifies extensions for Proxy MIP to support local routing optimization through the interaction between the MAG and the LMA. "Open Grid Protocol: Authentication", Tess Chu, Meadhbh Hamrick, Mark Lentczner, 4-Mar-09, Authentication in the Open Grid Protocol establishes an application layer association between a client application and a remote service responsible for managing the end user's identity. The objective of authentication is to verify the user of a client application possesses appropriate credentials before granting capabilities sufficient to assert control over the user's agent and digital assets. "IPv6 Autoconfig Filtering on Ethernet Switches", Nathan Ward, 4-Mar-09, Many ethernet switch vendors provide features for filtering IPv4 address assignment services - i.e. DHCP, Bootp. This document describes what is necessary for a switch to provide the same level of filtering for IPv6, as a standard on which operators can base equipment selection decisions. "A Transition Mechanism for Routing Architecture for the Next Generation Internet (RANGI)", Xiaohu Xu, One Drive, 4-Mar-09, The Routing Architecture for the Next Generation Internet (RANGI) is a proposal for solving routing scalability, mobility, multihoming, traffic engineering and other issues facing the current Internet. RANGI is described in a separate document [RANGI]. This document describes a transition mechanism for RANGI. With this mechanism, legacy IPv4 or IPv6 hosts can communicate with RANGI hosts, and vice versa. This allows RANGI to be deployed incrementally in the current Internet. "Routing Architecture for the Next Generation Internet (RANGI)", Xiaohu Xu, One Drive, 4-Mar-09, IRTF Routing Research Group (RRG) is exploring a new routing and addressing architecture to meet the challenges that current Internet is facing, especially in terms of routing scalability. This internet draft describes a new routing and addressing architecture, called Routing Architecture for the Next Generation Internet (RANGI) as a solution to the problems of scalability, mobility, multihoming, and traffic engineering. RANGI is a hybrid proposal that combines and enhances the ideas from several proposals particularly those based on identifier/locator split approach. It introduces a hierarchical and cryptographic host identifier and adopts a hierarchical routing mechanism to support routing across multiple independent address spaces. To allow smooth transition from IPv4 to IPv6, it adopts an IPv6 address with an IPv4 embedded in the last four bytes as locator. This also simplifies renumbering in case of change of service providers. RANGI allows traffic engineering by allowing border routers to overwrite the source addresses. It allows policy control on ID to address translation by having a hierarchical resolution mechanism. "Low Extra Delay Background Transport (LEDBAT)", Stanislav Shalunov, 4-Mar-09, LEDBAT is an alternative experimental congestion control algorithm. LEDBAT enables an advanced networking application to minimize the extra delay it induces in the bottleneck while saturating the bottleneck. It thus implements an end-to-end version of scavenger service. LEDBAT has been been implemented in BitTorrent DNA, as the exclusive congestion control mechanism, and in uTorrent, as an experimental mechanism, and deployed in the wild with favorable results. "Simultaneous Multi-Access and Flow Mobility Support for PMIPv6", Conny Larsson, Michael Eriksson, Petter Arvidsson, 4-Mar-09, This document specifies how flow mobility can be realized for a mobile node with multiple network interfaces, for which the network provides mobility support by means of Proxy Mobile IPv6 (PMIPv6). By introducing a "Primary Prefix", the mobile node is able to maintain IP data sessions when moving between different network interfaces. This document introduces a new set of ICMP and Mobility Header messages. It requires modifications of the mobile node. However, since support for simultaneous multi-access and flow mobility requires modifications of the mobile node anyway, the modifications suggested in this document are considered to be modest. The suggested enhancement is fully backwards compatible with the base Proxy Mobile IPv6 specification. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack node. "An Extension to the Session Initiation Protocol (SIP) for Request History Information", Mary Barnes, Francois Audet, 4-Mar-09, This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. "BGP Advisory Message", Tom Scholl, John Scudder, 4-Mar-09, The BGP routing protocol is used with external as well as internal neighbors to propagate route advertisements. In the case of external BGP sessions, there is typically a demarcation of administrative responsibility between the two entities. Provisioning, maintenance and administrative actions are communicated via off-line methods such as email or telephone calls. While these methods have been used for many years, it can be troublesome for an operator to correlate a BGP- related event in the network with a notice that was transmitted in email. This document proposes a new BGP message type, the Advisory message, which can be used to convey advisory information to a BGP speaker's peer. A capability is used to ensure that the recipient of the Advisory message is capable of supporting it. "Current Practices for Multiple Interface Hosts", Margaret Wasserman, 25-Mar-09, An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document describes how some common operating systems cope with the related challenges. "Peer to Peer Localization Services and Edge Caches", Nicholas Weaver, 4-Mar-09, Without caches in the infrastructure, peer to peer content delivery's primary effect is cost shifting rather than cost savings. Even with perfect localization, depending on the relative cost of last-mile uplink bandwidth verses transport bandwidth, P2P may substantially increase aggregate cost. Yet the addition of edge caches, caches located in the ISPs near the customers, radically change the economics of P2P content delivery. Edge caches interact very strongly with localization services for P2P content delivery, and any localization service must be tightly integrated into edge-cache operation. "Forcerenew Key Authentication", David Miles, Wojciech Dec, James Bristow, Roberta Maglione, 8-Mar-09, DHCP Forcerenew allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Key Authentication the server exchanges a key with the client on the initial DHCP ACK that is used for subsequent validation of a Forcerenew message. "BGP based Multi-homing in Virtual Private LAN Service", Wim Henderickx, Florin Balus, 4-Mar-09, Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how multi-homing can be offered in the context of LDP-based VPLS using BGP-AD. "Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, Amine Bouabdallah, Kazuhisa Matsuzono, 4-Mar-09, This document describes four fully-specified FEC schemes for Reed- Solomon codes that can be used to protect media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of sparse parity check based FEC codes. However, this complexity remains compatible with software codecs. The first scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, a global FEC encoding and arbitrary packet flows. The second scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, the general case FEC encoding, and arbitrary packet flows. The third (resp. fourth) scheme is similar to the first (resp. second) scheme, with the exception that it is for a single sequenced flow. "Optimized Local Routing for PMIPv6", Desire Oulai, Suresh Krishnan, 4-Mar-09, Base Proxy Mobile IPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, local routing has been defined to allow mobile nodes attached to the same or different mobile access gateways to exchange traffic by using local forwarding or a direct tunnel between the gateways. This document proposes an initiation method and fast handover mechanisms for local routing. The solutions aim at reducing handover delay and packet loss. "Potential Elements of Session Establishment Data", Alexander Mayrhofer, 4-Mar-09, This document provides a list of potential Session Establishment Data Elements in the Scope of SPEERMINT/DRINKS work. The list is provided to seek input from the community, and with the intent to aid in the definition of DRINKS requirements/protocols. "SNMP optimizations for 6LoWPAN", Hamid Mukhtar, Seong-Soon Joo, Juergen Schoenwaelder, 2-Apr-09, This draft proposes SNMPv3 optimizations for its use in 6LoWPANs. The draft presents optimization goals, issues, and the optimization approaches to enable the use of SNMP under the given memory, processing, and message size constraints imposed by 6LoWPANs. "Application-Layer Traffic Optimization (ALTO): Discover ALTO Servers", Haibin Song, Roni Even, Victor Pascual, Yunfei Zhang, 4-Mar-09, A set of mechanisms are required to discover an Application-Layer Traffic Optimization (ALTO) Server. These mechanisms enable applications to find a reliable information source which provides them with information regarding the underlying network. By providing this information it would be possible to greatly increase application performance, reduce congestion and optimize the overall traffic across different networks. This document specifies the use of general means such as DHCP, DNS or static configuration for ALTO server discovery. "Operation of the Nominating and Recall Committees", James Galvin, 4-Mar-09, <1> The IETF uses two committees to manage the selection, confirmation, and recall of some or all of the individuals who serve terms of membership on the bodies that support its operation. As of the publication of this document the list of bodies includes the IESG, IAB, and the IAOC. This document is a self-consistent, organized compilation of the process as it was known at the time of publication.Discussion of this Draft <2> Please direct all comments, suggestions, and questions regarding this draft to the following mailing list: <3> ietf-nomcom@ietf.org "Local Mobility Anchor Resolution for PMIPv6", Marco Liebsch, Paulo Loureiro, Jouni Korhonen, 4-Mar-09, The IETF is specifying a new Diameter Application to support mobility service authorization and home network prefix allocation for Proxy Mobile IPv6. The protocol operates between a Local Mobility Anchor and a AAA server. Furthermore, the associated specification extends the existing protocol for network access service to support dynamic assignment and discovery of a Local Mobility Anchor during the authentication procedure. The AAA server maintains mobile nodes' profile in a policy store, which includes information about the assigned Local Mobility Anchor as well as the home network prefix. This document proposes an extension to the Diameter PMIPv6 Application to allow Local Mobility Anchors benefit from the AAA server's policy store and resolve an unknown mobile node's IP address into a routable address of its assigned Local Mobility Anchor. "MPLS-TP OAM based on Y.1731", Italo Busi, Huub Helvoort, Jia He, 30-Mar-09, This document specifies how to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [6]. In particular, this document specifies the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. "Addition of the new values to use the SEED Cipher Algorithm in the Multimedia Internet KEYing (MIKEY)", Seokung Yoon, Hyuncheol Jeong, Yoojae Won, 4-Mar-09, This document proposes the addition of new values to use the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the Real-time Transport Control Protocol (RTCP) in Multimedia Internet KEYing (MIKEY). "Use cases to guide chartering MMOX interoperability work", Jon Watte, 4-Mar-09, Virtual worlds, typically implemented as multi-user shared simulations, are becoming increasingly used for serious work in addition to the traditional uses of research and entertainment. Based on actual need identified by interaction with various customers when working on virtual world interoperability over the last four years, this draft summarizes the main interoperability functions required to satisfy those needs. From these use cases, requirements for the MMOX virtual world interoperability charter can be derived. "Burst Loss Metrics for IPPM", Nick Duffield, Al Morton, Joel Sommers, 4-Mar-09, The IPPM Working Group has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the burst properties of packet loss are required to understand the impact of packet loss on applications. This draft defines one-way burst packet loss metrics that express the frequency and duration of loss episode, i.e., maximal sets of consecutively lost probe packets. The draft also defines a probing methodology under which the burst loss metrics are to be measured. "P4P Protocol Specification", Yu-Shun Wang, Richard Alimi, Doug Pasko, Laird Popkin, Yang Yang, 4-Mar-09, Provider Portal for Network Applications (P4P) is a framework that enables Internet Service Providers (ISPs) and network application software developers to work jointly and cooperatively to optimize application communications. The goals of this cooperation are to reduce network resource consumption and to accelerate applications. To achieve these goals, P4P allows ISPs to provide network information and guidance to network applications, allowing clients to exchange data more effectively. This document specifies the P4P protocol operations and message formats. The goal is provide a formal specification for developers to create inter-operable implementations. "Mobile Node Group Identifier option", Sri Gundavelli, Kent Leung, Basavaraj Patil, 4-Mar-09, This document specifies a new mobility option for use in Proxy Binding Update and Proxy Binding Acknowledgement messages. This option can be used by the mobility entities in a Proxy Mobile IPv6 domain for carrying the group affiliation of a mobile node in any of the mobility signaling messages. "draft-king-pce-brpc-app-00.txt", Daniel King, Adrian Farrel, 4-Mar-09, Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply- connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used. "IAB Thoughts on IPv6 Network Address Translation", Dave Thaler, Lixia Zhang, 4-Mar-09, There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. "Dynamic Host Configuration Protocol (DHCP) Location Shapes Option for Geopriv for IPv4 and IPv6", James Polk, Allan Thomson, Marc Linsner, 4-Mar-09, This document defines the Dynamic Host Configuration Protocol (DHCP) Option for downloading a location shape to a client, from a server. This is commonly called Location Configuration Information (LCI). Servers that provide this information to a client are doing so by communicating via a Location Configuration Protocol, or LCP. "Threat Analysis for Peer-to-Peer Overlay Networks", Yinian Mao, Vidya Narayanan, Ashwin Swaminathan, 4-Mar-09, This document provides a threat analysis for peer-to-peer networks, where the system relies on each individual peer to route message, store data, and provide services. The threats against P2P network include those that target individual peers, those that target routing protocol, those that target identity management, and those that target stored data. Focusing on distributed hash table based P2P network, we first establish a threat model and perform a triage of various assets in a P2P system. We then describe each individual threat in details, including threat description, impact of attack, and possible mitigations. The threats and mitigations are discussed under the context of feasibility and practicality, with the ultimate goal of achieving better understanding of the threats for secure P2P system design. "Address Selection Policy Configuration by DHCPv6 Option", Tao Sun, Hui Deng, Xiaodong Duan, 9-Mar-09, For hosts with multiple interfaces, the problem is how to make it run several applications simultaneously on variant interfaces such as GPRS, Wifi etc. To achieve this, one way is to select appropriate IP address so that the packets can be sent to the corresponding interface for forwarding. RFC 3484 defines a ''policy table'' for default IP address selection. This document extends the DHCPv6 option message so that the policy table can be dynamically updated. "Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces", Tao Sun, Hui Deng, 9-Mar-09, For hosts with multiple interfaces, the problem is how to make it run several applications simultaneously on variant interfaces such as GPRS, Wifi etc. To achieve this, one key issue here is to select appropriate route according to RFC 1122. The approach presented in this document is extending DHCPv6 option to configure route tables of the hosts. "PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths", Quintin Zhao, David Amzallag, Daniel King, 4-Mar-09, Point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths must first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. "Relentless Congestion Control", Matt Mathis, 4-Mar-09, Relentless congestion control is a simple modification that can be applied to almost any AIMD style congestion control: instead of applying a multiplicative reduction to cwnd after a loss, cwnd is reduced by the number of lost segments. It can be modeled as a strict implementation of van Jacobson's Packet Conservation Principle. During recovery, new segments are injected into the network in exact accordance with the segments that are reported to have been delivered to the receiver by the returning ACKs. This algorithm offers a valuable new congestion control property: the TCP portion of the control loop has exactly unity gain, which should make it easier to implement simple controllers in network devices to accurately control queue sizes across a huge range of scales. Relentless Congestion Control conforms to neither the details nor the philosophy of current congestion control standards. These standards are based on the idea that the Internet can attain sufficient fairness by having relatively simple network devices send uniform congestion signals to all flows, and mandating that all protocols have equivalent responses to these congestion signals. To function appropriately in a shared environment, Relentless Congestion Control requires that the network allocates capacity through some technique such as Fair Queuing, Approximate Fair Dropping, etc. The salient features of these algorithms are that they segregate the traffic into distinct flows, and send different congestion signals to each flow. This alternative congestion control paradigm is described in a separate document, also under consideration by the ICCRG. The goal of the document is to illustrate some new protocol features and properties might be possible if we relax the "TCP-friendly" mandate. A secondary goal of Relentless TCP is to make a distinction between the bottlenecks that belong to protocol itself, vs standard congestion control and the "TCP-friendly" paradigm. "The Use of the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward Applications", Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman, 4-Mar-09, This memo describes the use of so called store-and-forward cryptographic transforms within the Secure Real-time Transport Protocol (SRTP). The motivation is to support use cases when two end-points communicate via one (or more) store-and-forward middleboxes that are not fully trusted to access the media content. One of the main aspects of the transform is to make the confidentiality and message authentication independent of the RTP header. Another central aspect is to make identification of the cryptographic context (keys etc.) independent of RTP transport parameters. Besides the security of the end-points, also trust assumptions regarding the store-and-forward middleboxes are addressed. "Layer2-Aware NAT", David Miles, Mark Townsley, 4-Mar-09, This document describes a "Layer2-Aware" IPv4-to-IPv4 (NAT44) Service Provider NAT function that identifies subscriber traffic based on IP- independent methods such as a link-layer address, VLAN, PPP session, tunnel, etc. in order to allow one to either avoid "double-NAT" (NAT444) of subscriber IP traffic altogether, the need for additional "Shared Service-Provider" IPv4 address space, or partitioning of RFC 1918 space between subscribers. While the mechanisms described in this document may be applicable to a variety of network architectures, the primary focus is on residential "fixed-line" Internet access. "Trunk Group Use in ENUM", Daryl Malas, Tom Creighton, 4-Mar-09, This document concludes that incorporating trunk group parameters into an Electronic Number (ENUM) response for the Session Initiation Protocol (SIP) [RFC3261] service URI is a more effective approach compared to defining a new ENUM service type for a 'trunk'. Upon further review of the existing ENUM trunk group draft [I-D.ietf-enum-trunkgroup] and practical operator experience, this draft recommends the use of the current trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. "Proxy Mobile IPv6 indication and discovery", Damjan Damic, 4-Mar-09, Proxy Mobile IPv6 (PMIPv6) is a network-based mobility protocol that enables mobility management for an IP host as it moves across different points of attachment within the mobility domain. An IP host whose mobility is being managed by the network is unaware of the access networks capability providing PMIPv6 mobility management on its behalf. This draft proposes mechanisms by which the host is informed of PMIPv6, as well as means to actively discover such capability in the network the host is attaching to. The ability of the host to discover or be aware of PMIPv6 support in the access network enables better decision making in terms of the network selection, attach procedure, choice of mobility management, as well as the service/session and even application configuration abilities. "Guidelines and Protocol Extensions for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service.", Simo Veikkolainen, Markus Isomaki, 4-Mar-09, This memo defines guidelines and protocol extensions for combining Session Initiation Protocol (SIP) based real-time media sessions with Extensible Messaging and Presence Protocol (XMPP) based instant messaging and presence services in a seamless manner. This is accomplished by integration and protocol extension support in the endpoints, without requiring any changes in the SIP or XMPP server infrastructure. It is even possible that SIP and XMPP services are offered by different service providers. "An Architecture of ALTO for P2P Applications", Yang Yang, Laird Popkin, Reinaldo Penno, Stanislav Shalunov, 4-Mar-09, ALTO enables Internet Service Providers (ISPs) and network application software distributors to work jointly and cooperatively to reduce network resource consumption and to improve application performance. In this document, we specify an architecture for integrating ALTO into peer-to-peer (P2P) applications. "IPv6 Deployment and Statistics at a Conference", Eric Vyncke, Gunter Van de Velde, 8-Mar-09, During the Cisco [Cisco] European networkers Conference 2009 that ran from 26th to 29th January in Barcelona native IPv6 was added to the traditional IPv4 infrastructure. During this conference the 3500 attendees had dual stack access to both IPv4 and IPv6 simultaneously. The goal of this IPv6 deployment project was to gather usage statistics in a situation where the end-user just wants to access his/her enterprise VPN or simply get onto the Internet. The collected statistics are not only useful per se but this document presents easy ways to measure the quality of the IPv6 connectivity offered on such events. In essence the users were not conducting IPv6 technology tests, but were just using Internet services. The statistics collected give some pieces of information on the size and impact of IPv6 onto the normal userbase and will also derive the importance of IPv6 onto the infrastructiure and end-user operating systems and firewall technologies. The experiment ran in collaboration with Google [Google] and Tata-Communications [Tata]. "Referrals Across a NAT64", Dan Wing, 4-Mar-09, This document describes several scenarios where an IP address is referred across a NAT64 translator. "MMOX Architecture Discussion", Christian Scholz, 4-Mar-09, This document tries to summarize the different problem areas in the MMOX field and proposed an approach to build interoperability from the bottom up starting with a flexible foundation. It also aims at identifying problem spaces which are more general than the virtual worlds field and also touch on problems found in today's social networks. "Reverse HTTP", Mark Lentczner, Donovan Preston, 4-Mar-09, This memo explains a method for making HTTP requests to a host that cannot be contacted directly. Typically, such a host is behind a firewall and/or a network address translation system. "Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation", Ilpo Jarvinen, Markku Kojo, 4-Mar-09, This document describes a TCP sender algorithm to trigger loss recovery based on the information gathered on a SACK scoreboard instead of simply counting the number of arriving duplicate acknowledgements in the traditional way. The given algorithm is more robust to ACK losses, ACK reordering, missed duplicate acknowledgements due to delayed acknowledgements, and extra duplicate acknowledgements due to duplicated segments and out-of- window segments. The algorithm allows not only a timely initiation of TCP loss recovery but also reduces false fast retransmits. It has a low implementation cost on top of the SACK scoreboard defined in RFC 3517. "Mobile DTLS", Michael Williams, Jeremey Barrett, 4-Mar-09, Mobile DTLS (Mobi-D) is an extension to DTLS that provides host mobility support. After obtaining a new IP address or port, a DTLS client mobile host can continue sending to its DTLS server correspondent host. The mobile host continues to use the existing set of security parameters, from the new address, without re- negotiation. The correspondent host accepts packets from the new IP address or port, also without re-negotiation. After receiving any valid DTLS packet from the mobile host's new address or port, the correspondent host uses the new address or port to send to the mobile host. "The Diameter Capabilities Update Application", Glen Zorn, Jiao Kang, 12-Apr-09, This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state. "draft-hancock-sip-interconnect-guidelines-00", David Hancock, Daryl Malas, 4-Mar-09, As Session Initiation Protocol (SIP) peering becomes more widely accepted by service providers the need to define an interconnect guideline becomes of greater value. This document takes into consideration the SIP and commonly used SIP extensions, and it defines a fundamental set of requirements for SIP Service Providers (SSPs) to implement within their signaling functions (SFs) or Signaling Path Border Elements (SBEs) for peering. "IP Router Alert Option Extension", Ashok Narayanan, Francois Le Faucheur, David Ward, Reshad Rahman, 4-Mar-09, The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM and IGMP are some of the protocols which make use of the IP Router Alert option. The current specification for the IP Router Alert Option does not define mechanisms to facilitate discriminating across different users of Router Alert. As a result, networks using router Alert may have more secuity exposure than necessary and/or may unnecessarily block some transit Router Alert packets. This document describes new rules for the IP Router-Alert Option that aid routers to process these packets more selectively. "Multicast User Authentication", William Atwood, Salekul Islam, 4-Mar-09, RFC 1112 offers no facilities for participant control or accounting. This document explores the requirements for such facilities, and offers a potential solution, based on extending the IGMP and MLD "join" operations to carry EAP and/or ERP packets. "DHCPv6 Extension for Configuring Hosts with multiple Interfaces", Behcet Sarikaya, Frank Xia, Pierrick Seite, 6-Mar-09, This document defines a DHCPv6 option to help configure a multi-homed host's routing table with new entries when the host attaches to a new network on a new interface. "TLS Cached Certificates Extension", Stefan Santesson, 4-Mar-09, This document defines a Transport Layer Security (TLS) extension for cached certificates. This extension allows the TLS client to inform a server of a previously cached server certificate path, allowing the server to omit sending an identified certificate chain to the client during the TLS handshake protocol exchange. "Qualifying the Harmfulness of Address Translation", Christian Vogt, 30-Mar-09, Address translation is widely considered harmful because it conflicts with design principles highly regarded within the Internet engineering community. Still, address translation has become common practice despite technical problems because it constitutes an easy- to-deploy solution to a set of common operational needs. Since some of these needs will continue to exist in IP version 6, there is concern within the Internet engineering community about the potential proliferation of harmful technology from IP version 4 to IP version 6. This document investigates this concern. It compares feasible address translator designs with respect to the harmful impact they may have, explains why the problems of address translation, as used today, are to a significant extent entailed by the shortage of global addresses in IP version 4, and shows how the problems can be mitigated in IP version 6. "ALTO Protocol", Reinaldo Penno, Yang Yang, 9-Mar-09, The ALTO Service enables an Internet Service Provider (ISP) to convey cost preferences to network applications in order to modify network resource consumption patterns while maintaining or improving application performance. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. Applications already have access to great amount of underlying topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to download to every client. What is missing is the cost information -- what does an ISP or Content Provider actually prefer? This document describes a very simple protocol that allows a ISP to convey such information to applications. While such service would primarily be provided by the network (i.e., the local ISP). Content Provider and third parties could also operate this service. "HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks", Arsalan Tavakoli, Stephen Dawson-Haggerty, Jonathan Hui, David Culler, 9-Mar-09, HYDRO is a hybrid routing protocol for Lossy and Low power Networks (L2Ns) that embraces centralized and distributed routing mechanisms. Through the use of standard ICMP Route Advertisements and Route Solicitations, Node Routers build Default Routes to Border Routers. These routes, which maintain multiple options per each Node Router when available, are maintained through data-driven link estimation. Node Routers periodically report a high-quality subset of their Default Route Table to Border Routers, which then form a global view of the topology. When a Node Router attempts to route to another Node Router in the network, if no matching entry exists in the Node Router's Flow Table, it forwards the packet to a Border Router, which then installs the correct Flow Table Entries in the network to enable more efficient subsequent routing. "BRPC Extensions for Point-to-Multipoint Path Computation", Zafar Ali, Cisco Systems, 4-Mar-09, The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement [PCEP-P2MP-REQ]. This document addresses this requirement by extending backward recursive path computation (BRPC) technique proposed for Point-to-Point (P2P) LSPs in [P2P-BRPC] for P2MP LSP path computation in a multiple domains network. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Session-Specific Explicit Diameter Request Routing", Tina Tsou, Glen Zorn, 9-Mar-09, This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. "Extensions to VPLS PE model for Provider Backbone Bridging", Ali Sajassi, Florin Balus, Raymond Zhang, 9-Mar-09, IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. "Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Colin Perkins, 4-Mar-09, This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. "Integrated Services (IntServ) Extension to Allow Multiple TSPECs", James Polk, Subha Dhesikan, 4-Mar-09, This document defines how Integrated Services (IntServ) includes multiple TSPECs in the same Resource Reservation Protocol (RSVPv1) reservation. This ability to send multiple TSPECs during reservation set up helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. "RTP Payload Format for MPEG2-TS Preamble", Ali Begen, 4-Mar-09, Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS) requires the knowledge of specific information about the transport stream, which we refer to as the MPEG2-TS Preamble. While this information is spread over different locations throughout the transport stream and can be eventually assembled after some time a receiver started receiving the MPEG2-TS, the time it takes to retrieve all this information (especially in multicast environments) may be long. Instead, having this information readily available as a Preamble and sending the Preamble to a receiver that will shortly start receiving the transport stream will virtually eliminate the waiting time and let the receiver start processing/decoding the MPEG2-TS sooner. In this document, we give an overview of the MPEG2-TS and the delay components in video systems, and motivate the need for constructing and using the MPEG2-TS Preamble for rapidly synchronizing with the source stream in RTP multicast sessions. We also define and register the RTP payload format for the MPEG2-TS Preamble. "Best Current Practices for SIP Interoperability", Hadriel Kaplan, 8-Mar-09, This document identifies several commonly found interoperability issues with SIP, and provides guidance to implementers for how to avoid them. This is an initial set of commonly found problems. "A Client to Service Query Response Protocol for ALTO", Saumitra Das, Vidya Narayanan, 4-Mar-09, ALTO aims to improve the peer selection in applications that have a choice to transfer data from multiple data resources. This draft presents a protocol for a flexible and extensible query response protocol between an ALTO aware client and ALTO service provider. "Retrieving Specific Location from a Remote Entity using Session Initiation Protocol (SIP) Subscription Filters and Notifications", James Polk, 4-Mar-09, This document creates and describes the SIP subscription filters necessary to acquire the desired location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) from a remote SIP user agent (UA). "Multiple Interfaces on Windows", Gabriel Montenegro, Dave Thaler, Shyam Seshadri, 4-Mar-09, Increasingly, hosts have more than one network interface active at any given point in time. Such multiplicity of interfaces leads to multiple and potentially conflicting (or overlapping) sets of configuration information and policies. How these are arbitrated and managed influence how the host resolves DNS queries, and-with respect to outgoing packets-how it selects a source address and an outgoing interface. "Group Management Protocol Operation Over Wireless Problem Statement", Behcet Sarikaya, Dirk von Hugo, 5-Mar-09, Multicast mobility using existing IETF protocols is inefficient. This document looks at the principal shorcomings in IGMP/MLD that arise from operating over three wireless links, IEEE 16e used in Mobile WiMAX, IEEE 802.11 used in Wi-Fi networks and 3GPP. "Introduction of Distributed Services Network", Yunfei Zhang, 5-Mar-09, This draft briefly introduces DSN,a Distributed Service Network proposed by China Mobile in ITU-T as the evolution of NGN.PPSP is a protocol DSN plans to develop to support streaming services in future Internet. "Virtual Presence Identity", Heiner Wolf, 5-Mar-09, A virtual presence client needs information to display people who meet. It needs a name, an image, maybe an animated avatar, and more. This document describes the storage and exchange of public user identity data. The virtual presence identity data format is optimized for VP applications, where many people need the public data of their peers, some only once, some repeatedly, where changes happen frequently and must be propagated quickly with minimum bandwidth. "Atom Export Format", Geoffrey Sneddon, 23-Mar-09, This document specifies a method of using the Atom Syndication Format as an export format. "6LoWPAN Management Information Base", Ki-Hyung Kim, Hamid Mukhtar, Seung Yoo, Soohong Daniel Park, 23-Mar-09, This draft defines a portion of the Management Information Base (MIB), the lowpan MIB for use with network management protocols. In particular it defines objects for managing functions related to a 6LoWPAN entity. "Policy for defining new service-identifying labels", Andrea Forte, Henning Schulzrinne, 23-Mar-09, In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. "IANA Allocation Guidelines for the IPv6 Routing Header", Jari Arkko, Scott Bradner, 23-Mar-09, This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. "SNMP ERROR STATUS MIB", Ban Shimin, Hao Liu, 24-Mar-09, This memo defines a portion of the Management Information Base (MIB), the SNMP Error Status MIB, for use with network management protocols. In particular, the SNMP Error Status MIB will be used to get the detailed error information of the SNMP request. "Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)", University Malaga, 3-May-09, This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC). This namespace is for naming persistent resources defined by the SCHAC international activity participants, their working groups and other designated subordinates. The namespace main use will be the creation of controlled vocabulary values for attributes in the SCHAC schema. This values will be associated to particular instances of persons or objects belonging to any of the SCHAC object classes. "Border Gateway Protocol(BGP) AS_PATH Fragmenting", Zhifeng Zhang, Jacni Qin, 24-Mar-09, This document discusses the issues of processing the AS_PATH attribute which provides sufficient information for constructing a graph of AS connectivity, and defines the detailed procedure of fragmenting or merging a sequence of AS PATH segments. This is necessary for the robust implementation of Border Gateway Protocol (BGP) and the interoperation of vendors. "DHCP Authentication Analysis", John Jason Brzozowski, Ted Lemon, Geoffrey Holan, 25-Mar-09, This document analyzes and technically evaluate the techniques proposed to support end-user authentication using extensions to DHCP. "Defining a centerpoint element for use in the Presence Information Data Format - Location Object (PIDF-LO)", James Polk, Allan Thomson, Marc Linsner, 25-Mar-09, This document creates a centerpoint element for use in the Presence Information Data Format - Location Object (PIDF-LO). "Definition of IANA Registry for Timezone Names", Barry Leiba, 25-Mar-09, VCards need a stable, well defined list of timezone names, so that users can create VCards that refer to timezones. There is no common list of such names, and other standards need timezone names also. This document creates an IANA registry of timezone names, and initially populates the list.Initial version o Define timezone registry. o Defer initial population with Olsen database until we like the basic document. "Binary Syntax for SIP Common Log Format", Adam Roach, 7-May-09, This document proposes a binary syntax for the SIP common log format (CLF). It does not cover semantic issues, and is meant to be evaluated in the context of the other efforts discussing SIP CLF. "A Profile for Endpoint Identifier Origin Authorizations (IOA)", Roque Gagliano, 25-Mar-09, This document defines a standard profile for End-Point Identifiers Origin Authorizations (IOAs). An IOA is a digitally signed object that provides a means of verifying that the EID IP address block holder has authorized a set of Router Locators (RLOCs) as its de- encapsulation point in a Map & Encap mapping service. "A Recommendation for IPv6 Address Text Representation", Seiichi Kawamura, Masanobu Kawashima, 21-Apr-09, As IPv6 network grows, there will be more engineers and also non- engineers who will have the need to use an IPv6 address in text. While the IPv6 address architecture [RFC4291] section 2.2 depicts a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators ,system engineers, and customers. The following draft will describe the problems that a flexible text representation has been causing. This document also recommends a canonical representation format that best avoids confusion. "An Extension to the Session Initiation Protocol (SIP) for Endpoint Session View", Chris Boulton, 26-Mar-09, This document defines a standard mechanism for capturing and providing important session information associated with the Session Initiation Protocol (SIP). Certain properties of a SIP protocol exchange are essential for further independent signalling interactions. In certain environments this information can be lost when traversing entities such as Back-to-Back User Agents (B2BUA). This document defines a new optional SIP header, Endpoint-View, for capturing appropriate information. "Tunneling Header Compression (TuCP) for Tunneling over IP", Priyanka Rawat, J-M Bonnin, Ana Minaburo, Eun Paik, 26-Mar-09, The IP tunneling mechanisms have important applications in network solutions and are widely used in numerous contexts such as security (VPN), IPv4 to IPv6 transition, and mobility support (MobileIP and NEMO). However, these tunneling mechanisms induce a large overhead resulting from adding several protocol headers in each packet. This overhead deteriorates performance on wireless links which are scarce in resources. Header compression methods are often used on connection oriented communication (e.g., UMTS networks) to reduce the overhead on the wireless part. These header compression methods can be used on tunnel headers to reduce the protocol header overheads, independent of the payload type. Although, several header compression methods exist, the header compression profiles defined by them are not adapted to the characteristics of IP tunneling. This document specifies a tunneling header compression protocol for IP tunneling mechanisms. "An Endpoint Control Package for the Session Initiation Protocol (SIP)", Chris Boulton, 26-Mar-09, This document defines a Session Initiation (SIP) Control Package for controlling endpoints. This Control Package provides a basic set of related operations and events that can occur between an endpoint and an authorised controlling entity. "Defines Message media sub-type 'Disclaimer' to organize and handle Disclaimers in Email messages effectively", Ravishankar Nandagopalan, 28-Mar-09, This memo defines a new media subtype of Disclaimer to the media type 'Message'. Disclaimers are being used as a legal and commercial message that is intended to protect the interest of the sender and the recipient. At present form the disclaimers are messy to handle with multiple appends to an Email message conversation, making the Email bulky and difficult comprehend. "The DTN URI Scheme", Kevin Fall, Scott Burleigh, Avri Doria, Jörg Ott, 31-Mar-09, This document describes the "dtn" Uniform Resource Identifier (URI) scheme. DTN URIs are used as DTN endpoint identifiers (EIDs). "LLN Routing Fundamentals", Pascal Thubert, Thomas Watteyne, Zach Shelby, Dominique Barthel, 8-Apr-09, This document describes a basic set of fundamental mechanisms for routing on a Low-power and Lossy Network (LLN). It does not intend to specify a full-blown protocol. It is rather offered as a basis to support the discussion while designing the ROLL protocol. "NFS Server-side Copy", James Lentini, Mike Eisler, Rahul Iyer, Deepak Kenchammana, Anshul Madan, 15-Apr-09, This document describes a set of NFS operations for offloading a file copy to a file server or between two file servers. "Additive-Routes-Wanted Outbound Route Filter for BGP-4", Yuanchao Su, 1-Apr-09, This document describes a solution for overcoming the limitations of existing route reflect mechanism:even there are equal routes,route reflector(RR) would use the nexthop router ID to break tie and only reflect the route with lower router ID to its clients,so RR clients send all the traffic for the destination to only one nexthop which leads to traffic unbalanced in an AS. Additive-Routes-Wanted ORF extends ORF to not only filter BGP routes but also give RR client the ablility to ask RR for additive BGP routes in its BGP database. With the additive routes, RR clients could make inner-AS native IP and VPNV4 load sharing easier. "Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 5-May-09, 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. This document is intended to obsolete RFC 4930. "Using Trust Anchor Constraints During Certification Path Processing", Sam Ashmore, Carl Wallace, 3-Apr-09, This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. "Tunneling Header Compression (TuCP) for Tunneling over IP", Priyanka Rawat, J-M Bonnin, Ana Minaburo, Eun Paik, 5-Apr-09, The IP tunneling mechanisms have important applications in network solutions and are widely used in numerous contexts such as security (VPN), IPv4 to IPv6 transition, and mobility support (MobileIP and NEMO). However, these tunneling mechanisms induce a large overhead resulting from adding several protocol headers in each packet. This overhead deteriorates performance on wireless links which are scarce in resources. Header compression methods are often used on connection oriented communication (e.g., UMTS networks) to reduce the overhead on the wireless part. These header compression methods can be used on tunnel headers to reduce the protocol header overheads, independent of the payload type. Although, several header compression methods exist, the header compression profiles defined by them are not adapted to the characteristics of IP tunneling. This document specifies a tunneling header compression protocol for IP tunneling mechanisms. "Addition of Camellia Elliptic Curve Cipher Suites with SHA-1 and SHA-2", Satoru Kanno, Masayuki Kanda, 5-Apr-09, This document specifies a set of elliptic curve cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document describes sixteen new cipher suites for TLS that specify HMAC-SHA1 and HMAC- SHA2. "The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its Use with IPsec", Satoru Kanno, Masayuki Kanda, 5-Apr-09, This memo specifies two new algorithms. One is the usage of XCBC mode with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-XCBC-96. Latter is pseudo-random function based on XCBC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- 128. "The Camellia Algorithm and Its Use wiht the Secure Real-time Transport Protocol(SRTP)", Satoru Kanno, Masayuki Kanda, 5-Apr-09, This document describes the use of the Camellia block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). "Extensible Provisioning Protocol (EPP) Host Mapping", Scott Hollenbeck, 6-Apr-09, 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 is intended to obsolete RFC 4932. "Extensible Provisioning Protocol (EPP) Contact Mapping", Scott Hollenbeck, 6-Apr-09, 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 is intended to obsolete RFC 4933. "Extensible Provisioning Protocol (EPP) Transport over TCP", Scott Hollenbeck, 23-Apr-09, 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 is intended to obsolete RFC 4934. "An FTP Application Layer Gateway for IPv6-to-IPv4 translation", Iljitsch van Beijnum, 27-Apr-09, The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive, introduced in 1998. However, many existing FTP servers don't support this mode, making it impossible to support the File Transfer Protocol through an IPv6-to-IPv4 translator without an Application Layer Gateway. This document describes the behavior of such an ALG. "Extensible Provisioning Protocol (EPP) Domain Name Mapping", Scott Hollenbeck, 6-Apr-09, 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 is intended to obsolete RFC 4931. "NEtwork MObility (NEMO) Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, Yuankui Zhao, 6-Apr-09, This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility. The solution leverages the extensions defined in [RFC3963], [ID-DHCPPD-NEMO] and [RFC3633] specification for achieving this. "A Simple Way of DHCP Authentication Extension For DSL Connection", Li Hongyu, 7-Apr-09, This document defines option extension of Dynamic Host Configuration Protocol (DHCP) to provide a simple EAP-based authentication for DSL connection. The DHCP client is triggered by short lease time for EAP message exchanges. "The Babel routing protocol", Juliusz Chroboczek, 30-Apr-09, Babel is a loop-free distance vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. "Validation of the root trust anchor for the DNS", Patrik Faltstrom, Jakob Schlyter, 8-Apr-09, This document describes practical requirements and needs for automatic validation of the root trust anchor for the DNS. It also proposes a mechanism using PGP and/or S/MIME that can be used to fulfil the requirements. "Multicast-Based Rapid Acquisition of Multicast RTP Sessions", Ingemar Johansson, 8-Apr-09, This document proposes an improvement to the unicast based Rapid Acquisition for Multicast based Streaming discussed in [ID-Versteeg]. The outline of the improvement is to gather up Rapid Acquisition requests for many users and transmit them in dedicated multicast streams. With this technique the peak load on the retransmission server and on the outgoing link from the retransmission server can be reduced. For a problem description of the channel change problem in multicast based IPTV the reader is encouraged to read [ID-Versteeg]. "WiMAX Diameter Applications", Avi Lior, Alper Yegin, 8-Apr-09, This document registers a set of IANA Applications and Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Worldwide Interoperability for Microwave Access (WiMAX). These new Diameter applications are defined for the interaction of the Access Serving Network Gateway (ASNGW) with the AAA and the Policy and Charging Control infrastructure in the Connectivity Serving Network (CSN) and between the Home Agent (HA) and AAA servers. Applications and related commands are also defined to support Location Based Services. "Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Vasily Dolmatov, Artem Chuprina, Igor Ustinov, 8-Apr-09, This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). "A Try and Error type approach for multihoming", Hirotaka Matsuoka, 8-Apr-09, [RFC5220] describes the possible problems which an end host may experience, if the end host has multiple prefixes in a single physical link. This document proposes a solution of so-called "try and error" type about these problems originated in "Source Address Selection" which is described in [RFC5220]. A new mechanism to settle almost all of these problems is described in this document, but actually it is not effective in some particular cases. Thus it is necessary for every end user/host to be able to select on/off of this mechanism. "Control Packet Snooping Based Binding", Jun Bi, Jianping Wu, Guang Yao, Fred Baker, 9-Apr-09, This document specifies the Control Packet Snooping (CPS) mechanism for IP version 4 and IP version 6. This mechanism is used to set up binding between source IP address and corresponding anchor on the access device. This binding is always used to perform source address validation. "TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms", Nicolas Williams, 17-Apr-09, This document specifies an extension to Transport Layer Security (TLS) for carrying application data which is suitable for delayed integrity protection and does not require privacy protection. In particular we describe how to use this extension to reduce the number of round trips needed for application-layer authentication, specifically Simple Authentication (SASL), and through it, Generic Security Services (GSS-API). The use of this extension to optimize SASL/GSS-API authentication is termed "TLS/SA". This extension can also be used to optimize application protocols. "OAuth Request Body Hash", Brian Eaton, Eran Hammer-Lahav, 11-Apr-09, This specification extends the OAuth signature to include integrity checks on HTTP request bodies with content types other than "application/x-www-form-urlencoded". "The UDP Tunnel Transport mode", Gorry Fairhurst, 13-Apr-09, This document proposes a standards track protocol called the the UDP Tunnel Transport. This protocol updates the UDP processing of RFC 2460 for hosts and routers. The update enables a sender to generate a UDP datagram where the UDP checksum is replaced by a header check determined only by the protocol header information. The document also updates the way the IPv6 UDP length field is interpreted. The use of this mode is intended to minimise the processing cost for the transport of tunnel packets using UDP. "A Hybrid ISP Platform (or Architecture) for IPv6: Problem Statement", Jiangfeng Xu, Sheng Jiang, 14-Apr-09, Global IPv6 deployment is inevitable. There are many solutions have been specified in order to provide IPv6 connectivity services. In order to provide IPv6 connectivity services to all kinds of host/client devices, ISP networks need to support as many as possible IPv6 connectivity solutions. This document proposes a hybrid ISP platform that supports the coexistence of variable IPv6 connectivity solutions and analyses the configuration requirements raised by this platform. Additionally, the applicability of different configuration mechanisms for performing this configuration is discussed. "Indication of support for keep-alive", Christer Holmberg, 16-Apr-09, This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. "Discussion of Controversial PMIP Extensions", George Tsirtsis, 16-Apr-09, This document discusses the recent controversy regarding PMIP extensions for inter-technology handoffs and multihoming. Many of the arguments presented below have been discussed in NETEXT BOF and subsequent discussions on the mailing list. They are written here in an attempt to explain why some of the proposed PMIP extensions are so controversial. "TCP Opportunistic Security (OPSEC) Option", Michael Paddon, Greg Rose, 27-Apr-09, The TCP Opportunistic Security (OPSEC) option enables cooperating peers to opportunistically negotiate the use of an end to end security protocol on a per connection basis. The negotiated protocol is used to transparently secure application data for the life of the connection, providing protection against all passive and some active attacks. Security protocols may operate anonymously or make opportunistic use of available key material. Backwards compatibility with non-OPSEC-aware hosts is maintained, thereby permitting incremental deployment of this mechanism.Comments and Discussion Please send feedback on this draft to tsv-area@ietf.org. "A SIP/SIPS URI parameter for passing subscription data", Keith Drage, 19-Apr-09, This document provides a SIP/SIPS URI parameter to enable subscription data related to a SIP/SIPS URI to accompany that SIP/ SIPS URI when required by other entities in the same system. This can then be used by the receiving entity to assist in the provision of capabilities associated with that SIP/SIPS URI, either in this request or in other subsequent requests. "Multiplexing Single-Application Multiple-Connection over TLS", Mohamad Badra, Ibrahim Hajjeh, James Blaisdell, 20-Apr-09, The Transport Layer Security (TLS) is the most widely deployed protocol for securing network traffic. It provides mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex single-application multiple-stream applications that commonly use parallel connections to the same logical and/or physical server application data. This document describes a mechanism to multiplex single-application multiple-stream over TLS. It extends TLS to multiplex parallel connections of a given application over a single TLS session, avoiding additional delay related to the TLS/TCP session/connection setup. "IPv4 and IPv6 Greynets", Fred Baker, Warren Harrop, Grenville Armitage, 20-Apr-09, This note discusses a feature to support building Greynets for IPv4 and IPv6. "Internet X.509 Public Key Infrastructure: Certificate Image", Stefan Santesson, Russ Housley, Siddharth Bajaj, Leonard Rosenthol, 21-Apr-09, This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a [RFC5280] public key certificate by defining a new otherLogos image type according to [RFC3709]. "IPv6 Firewall Routing Header", Tony Hain, 22-Apr-09, This document specifies a routing header for use by firewalls to enforce routing symmetry. The draft is being discussed on the ipv6@ietf.org list. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. "Home Agent Initiated Flow Binding for Mobile IPv6", Frank Xia, Behcet Sarikaya, 22-Apr-09, This document defines two new Mobility Headers for a home agent to control flow binding in a mobile node. "IPv4/IPv6 Translation Prefix Recommendation", Congxiao Bao, Fred Baker, Xing Li, 22-Apr-09, This document is part of a series of the IPv4/IPv6 translation documents. In this document, the address format and the corresponding prefix are recommended for representing IPv4 addresses in IPv6 and/or for representing IPv6 addresses in IPv4. "In-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria Napierala, 23-Apr-09, When an IP multicast tree needs to pass through an MPLS domain, it is advantageous to map the tree to a Point-to-Multipoint or Multipoint- to-Multipoint Label Switched Path. This document specifies a way to provide a one-one mapping between IP multicast trees and Label Switched Paths. The IP multicast control messages are translated into MPLS control messages when they enter the MPLS domain, and are translated back into IP multicast control messages at the far end of the MPLS domain. The IP multicast control information is coded into the MPLS control information in such a way as to ensure that a single Multipoint Label Switched Path gets set up for each IP multicast tree. "NewReno Modification for Smooth Recovery After Fast Retransmission", Yoshifumi Nishida, 23-Apr-09, This memo describes a feeble point in Fast Recovery algorithm in NewReno defined in RFC3782 and proposes a simple modification to solve the problem. "LIP: Label Information Protocol", Richard Kelsey, 23-Apr-09, LIP is an extension of MPLS for use in Lossy and Low power Networks (LLN). Use of MPLS allows rapid response to local topology changes within an LLN, while still using full IP routing both within the LLN and for packets that cross into other domains. LIP has optional RIP commands for discovering and maintaining label switched tree routes. To support local route repair, labeled packets include a path metric used to detect loops in label-switched paths. Labeled messages may optionally include a source route or route record at the label level in order to allow their use without losing the advantages of label switching. "An Update to the Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", James Polk, Allan Thomson, Marc Linsner, 23-Apr-09, This document updates RFC 3825 (Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information) to allow versioning, and proposes changes that enable the ability to express confidence and uncertainty values as an alternative to expressing bits of resolution. "NomCom Chair's Report: 2008-9", Joel Halpern, 24-Apr-09, This document reports on the work of the 2008-2009 IETF nominating committee (NomCom). This draft summarizes the process steps that were used this year, and the work that was done. This is followed by a discussion of process issues which caused difficulties for the committee, but which require community agreement to before changes can be made. Finally, there are some observations about things which can help future committees, and which may help the community to understand. "Security Issues and Solutions in Peer-to-peer Systems for Realtime Communications", Henning Schulzrinne, Enrico Marocco, Emil Ivov, 26-Apr-09, Peer-to-peer (P2P) networks offer higher robustness against failure, easier configuration and are generally more economical than their client-server counterparts. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. "Definition of Managed Objects for Reporting Performance Counters' Statistics", Robert Cole, Joseph Macker, Al Morton, 28-Apr-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. "Redundancy and Load Balance Mechanism of NAT64", Xiaohu Xu, 29-Apr-09, NAT64 [NAT64], a simplified NAT-PT [RFC2766] without DNS-ALG, provides a method for IPv6 hosts to initiate communications with IPv4 hosts. This memo defines several mechanisms supporting redundancy and load balance amongst NAT64 boxes. "Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment", Mohammed Boucadair, Christian Jacquenet, Jean-Luc Grimault, Mohamed Kassi-Lahlou, Pierre Levis, 29-Apr-09, This memo describes a proposal to enhance DS-lite solution with an additional feature to ease interconnection between IPv4 and IPv6 realms. When deployed, no dual-stack-enabled network is required for the delivery of both IPv4 and IPv6 connectivity to customers. Only IPv6 is required to be deployed in core and access networks. Particularly, IPv6 transfer capabilities are used for the transfer of IPv4-addressed packets in a completely stateless scheme between the interconnection segment and the DS-lite CGN node(s). This memo proposes an IPv4-inferred scheme to build IPv6 addresses. The proposed solution allows Service Providers to maintain an IPv6- only network. "Mobile IPv6 Home Link Detection Mechanism Security considerations", Arnaud Ebalard, 30-Apr-09, MIPv6 defines the concept of Home Network for a MN, in opposition to the foreign network where this entity may find itself. A ``Home Link Detection'' mechanism is also specified to allow the MN to detect when it is at home. MIPv6 specification mandates the use of IPsec for protecting main signaling traffic and also defines how IPsec can be used to protect data traffic between the MN and its HA. Even if optional, it is expected that many deployments of MIPv6 will use it by default for MN which may roam outside a trusted infrastructure (e.g. outside a mobile operator network). When a MN detects it is at home, it is expected to stop IPsec protection for data traffic exchanged with its Home Agent. That event is the result of the Home Return procedure, triggered by the Home Link Detection mechanism. This document discusses the possible threats and security impacts associated with the use of this insecure NDP-based mechanism as a trigger to drop IPsec protection of data traffic for the MN. It also provides some results on the implementation of the attacks against an existing MIPv6 module. Possible solutions are suggested. "Definition of Binary Filter Description", George Tsirtsis, Gerardo Giaretta, Hesham Soliman, Nicolas Montavont, 1-May-09, This document defines binary formats for IPv4 and IPv6 flow descriptors to be used in conjuction with flow bindings for Mobile IPv6. "HTTP Live Streaming", Roger Pantos, 1-May-09, This document describes a protocol for transmitting unbounded streams of multimedia data over HTTP. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 1.0 of this protocol. "LISP Internet Groper (LIG)", Dino Farinacci, Dave Meyer, 7-May-09, A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. "Third Party Authorization in the Session Initiation Protocol", Scott Lawrence, 3-May-09, This draft describes some circumstances that are common in SIP deployments which lack a rigorous authorization model, and points out some ways in which this has resulted in poor security characteristics. The purpose of this document is to stimulate discussion of the identified problem and proposed requirements for any solution. Comments are solicited, and should be directed to the DISPATCH working group list at 'dispatch@ietf.org'. ""Son of 1036": News Article Format and Transmission", Henry Spencer, 3-May-09, By the early 1990s it had become clear that RFC 1036, the then specification for the Interchange of USENET Messages, was badly in need of repair. This "INTERNET DRAFT to be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews. It is being published now in order to provide the Historical Background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. "Source FEC Payload Mapping Information for Sequence Flow", Zixuan Zou, 3-May-09, Per FEC framework, FEC source packet carries source FEC payload ID for FEC protection of arbitrary packet flow. This document specifies a FEC payload header and a source FEC payload mapping information unit (MIU) to enable carrying source FEC payload ID(s) in separate packet flow for FEC protection of sequence flow over unreliable transport. The FEC payload MIU consists of flexible source FEC payload ID(s) to be compatible with different FEC schemes. "The Network Trouble Ticket Data Model", Dimitris Zisiadis, Spyros Kopsidas, Matina Tsavli, Leandros Tassiulas, Chrysostomos Tziouvaras, Guillaume Cessieux, Xavier Jeannin, 30-Apr-09, Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format for presentation and storing at the central NOC is mandatory. In the present document we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). "BGP-4 message transport over SCTP", Kevin Fang, Feng Cai, 4-May-09, This memo defines using SCTP for BGP-4 transport routing message. SCTP has many benefit for Signaling/Message transportation , BGP-4 transport over SCTP will enhance the link stability and efficiency. "Hierarchy Extensions to Atom Feeds", Colm Divilly, Nikunj Mehta, 5-May-09, This specification defines a mechanism to create and remove AtomPub collections using the AtomPub protocol as well as to express hierarchies of feeds within the Atom Syndication Format.Editorial Note To provide feedback on this Internet-Draft, join the atom-protocol mailing list (http://www.imc.org/atom-protocol/) [1]. "Experiment: Hash functions with parameters in CMS and S/MIME", Jim Schaad, 5-May-09, New hash algorithms are being developed and these algorithms may include parameters. CMS has not currently defined any hash algorithms with parameters, but anecdotic evidence suggests that defining one could cause major problems. In this document we define just such an algorithm and describe how to use it so that we can run experiments to find out how bad including hash parameters will be. "Signer Info Algorithm Protection Attribute", Jim Schaad, 5-May-09, A new signed attribute is defined that allows for protection of the algorithm structures in an authenticated data or a signer info structure. By placing the information into a signed or authenticated attribute its value is then covered by the validation process. "Extensions to Proxy Mobile IPv6 - Motivation", Sri Gundavelli, 5-May-09, Proxy Mobile IPv6 is a network-based mobility management protocol standardized in IETF and is being specified in various system architectures as a protocol for building a common and access independent mobile core. Currently, there are number of proposals and a huge amount of interest in NETEXT working group for extending the protocol to support various mobility extensions. This document identifies some of the critical extensions that are absolutely required and builds a case as why these extensions have to be supported. "TCP-over-UDP", Salman Baset, Henning Schulzrinne, 6-May-09, We present TCP-over-UDP (ToU), an instance of TCP on top of UDP. It provides exactly the same congestion control, flow control, reliability, and extension mechanisms as offered by TCP. It is intended for use in scenarios where applications running on two hosts may not be able to establish a direct TCP connection but are able to exchange UDP packets. "Additional S/MIME Capabilities", Sean Turner, 6-May-09, This document lists values for the S/MIME Capabilities Attribute. The attribute itself is defined in RFC TBD1, but the values for each are defined in separate algorithm documents and in some cases not at all. The SMIME Capability values can be included in S/MIME messages as a signed attribute and in public key certificates as an extension. //RFC EDITOR: Replace TBD1 with the # assigned to draft-ietf-smime- 3851bis-10.txt. "One-ended multipath TCP", Iljitsch van Beijnum, 6-May-09, Normal TCP/IP operation is for the routing system to select a best path that remains stable for some time, and for TCP to adjust to the properties of this path to optimize throughput. A multipath TCP would be able to either use capacity on multiple paths, or dynamically find the best performing path, and therefore reach higher throughput. By adapting to the properties of several paths through the usual congestion control algorithms, a multipath TCP shifts its traffic to less congested paths, leaving more capacity available for traffic that can't move to another path on more congested paths. And when a path fails, this can be detected and worked around by TCP much more quickly than by waiting for the routing system to repair the failure. This memo specifies a multipath TCP that is implemented on the sending host only, without requiring modifications on the receiving host. "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Sebastien Barre, 7-May-09, Often endpoints are connected by multiple paths, but the nature of TCP/IP restricts communications to a single path per socket. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through higher throughput and improved resilience to network failure. This document presents extensions to TCP in order to transparently provide this multi-path functionality at the transport layer, if at least one endpoint is multi-addressed. "Multiplexing of Connections between Extensible Messaging and Presence Protocol (XMPP) Servers Using Transport Layer Security (TLS)", Joe Hildebrand, Peter Saint-Andre, 8-May-09, This document specifies requirements for multiplexing of connections between Extensible Messaging and Presence Protocol (XMPP) servers using Transport Layer Security (TLS). "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng Jiang, Dayong Guo, Brian Carpenter, 8-May-09, Global IPv6 deployment was slower than originally expected in the last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 transition issues become more critical and complicated. Host-based transition mechanisms are not able to meet the requirements while most end users are not sufficiently expert to configure or maintain these transition mechanisms. Carrier Grade NAT with integrated transition mechanisms can simplify the operation of end users during the IPv4/IPv6 migration or coexistence period. This document proposes an incremental Carrier-Grade NAT (CGN) solution for IPv6 transition. It can provide IPv6 access services for IPv6-enabled end hosts and IPv4 access services for IPv4 end hosts while remaining most of legacy IPv4 ISP networks unchanged. It is suitable for the initial stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and encourages transition towards dual-stack or IPv6-only ISP networks. "A Generic Referral Object for Internet Entities", Brian Carpenter, Mohammed Boucadair, Scott Brim, Joel Halpern, Sheng Jiang, Keith Moore, 10-May-09, The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application- independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals, a new notion of scope identifiers is introduced. "Configuring Cryptographically Generated Addresses (CGA) using DHCPv6", Sheng Jiang, Zhongqi Xia, 10-May-09, A Cryptographically Generated Address (CGA) is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of CGA generation. Administrators should be able to configure parameters used to generate CGA. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), which enables network management to dynamically configure hosts, can be used in the CGA configuration. Furthermore, CGA generation consumes large computation power. This computational burden can be delegated to the DHCPv6 server. A new DHCPv6 options are also defined in this document to enable hosts delegate CGA generation to a DHCPv6 server. "Classification of traffic using Application Tags", Jagannathan Pathra B, Prabhuraj K, 11-May-09, This document describes a solution to classify Application-Layer traffic on switches using Application Tags. The Application Tags can be passed on to other switches in the Enterprise Network and also to switches in the Service Provider Network. Thus it provides a mechanism to classify and apply Quality of Service based on the Application-Layer Traffic. The advantage of this solution is that it requires no hardware upgrade on switch nor any Deep Packet Inspection (DPI) function on the switch. 1. Conventions "A Dedicated RPSL Interface Identifier for Operational Testing", Brian Haberman, 11-May-09, The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons which are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language object that allows a network to advertise an IP address which is reachable and can be used as a target for diagnostic tests (e.g., pings). "An Adaptation Model for Mobile IPv6 support in lowPANs", Ricardo Silva, University Coimbra, 11-May-09, Real deployments of wireless sensor networks (WSN) are rare, and virtually all have considerable limitations when node mobility is concerned. On one hand, research in WSNs tends to favour complex multi-hop routing protocols and, on the other hand, IP and mobility are considered too demanding for these environments. In this document we contradict this general belief by proposing an adaptation model for Mobile IPv6 in 6lowPANs. "The Eternal Non-Existence of SINK.ARPA (and other stories)", Joe Abley, Olafur Gudmundsson, 11-May-09, This document specifies a fully-qualified domain name in the Domain Name System (DNS) that can be relied upon never to exist. The availability of a name in the DNS which is guaranteed not to exist has useful operational applications. This document also provides a procedural framework for other names that have special characteristics to be reserved, and for those special characteristics to codified as modifications to the normal ARPA administration process. "draft-valin-celt-rtp-profile-01 RTP Payload Format for the CELT Codec", Jean-Marc Valin, Gregory Maxwell, 11-May-09, CELT is an open-source voice codec suitable for use in very low delay audio communication applications, including Voice over IP (VoIP). This document describes the payload format for CELT generated bit streams within an RTP packet. Also included here are the necessary details for the use of CELT with the Session Description Protocol (SDP). At the time of this writing, the CELT bit-stream has NOT been finalized yet, and compatibility is usually broken with every new release of the codec. Next Steps in Signaling (nsis) ------------------------------ "NSLP for Quality-of-Service Signaling", Jukka Manner, Georgios Karagiannis, Andrew McDonald, 7-Feb-08, This specification describes the 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 specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Martin Stiemerling, Hannes Tschofenig, Cedric Aoun, Elwyn Davies, 3-Nov-08, This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. "GIST: General Internet Signalling Transport", Henning Schulzrinne, Martin Stiemerling, 23-Mar-09, This document specifies protocol stacks for the routing and transport of per-flow signalling 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 Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling 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 Signalling" framework. "QoS NSLP QSPEC Template", Attila Bader, Cornelia Kappler, David Oran, 29-Nov-08, 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 document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. "Applicability Statement of NSIS Protocols in Mobile Environments", Takako Sanda, Xiaoming Fu, Seong-Ho Jeong, Jukka Manner, Hannes Tschofenig, 9-Mar-09, 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 protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. "RMD-QOSM - The Resource Management in Diffserv QOS Model", Attila Bader, Lars Westberg, Georgios Karagiannis, Cornelia Kappler, Hannes Tschofenig, Thomas Phelan, Attila Takacs, Andras Csaszar, 5-Mar-09, 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 pre-emption 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. "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", Gerald Ash, Al Morton, Martin Dolly, Percy Tarapore, Chuck Dvorak, Yacine Mghazli, 27-Oct-08, This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related signaling requirements. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. "General Internet Signaling Transport (GIST) over SCTP and Datagram TLS", Xiaoming Fu, Christian Dickmann, Jon Crowcroft, 8-Mar-09, 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) and Datagram Transport Layer Security (DTLS). The use of SCTP can take advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, the support of multi-homing to provide network level fault tolerance, as well as partial reliability extension for partially reliable data transmission. This document also specifies how to establish GIST security over datagram transport protocols using an extension to DTLS. "Using and Extending the NSIS Protocol Family", Jukka Manner, Roland Bless, John Loughney, Elwyn Davies, 9-Mar-09, This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS working group during the period 2001-2009 together with suggestions on how the industry can make use of the new protocols, and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. Network Time Protocol (ntp) --------------------------- "Network Time Protocol Version 4 Protocol And Algorithms Specification", Jack Burbank, 5-Sep-08, The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP Version 4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3) described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol Version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms which extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. "Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)", Heiko Gerstung, Chris Elliott, 28-Aug-08, The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations and other networked equipment. As time synchronization is more and more a mission critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to setup a monitoring system that is platform- and vendor-independant. This Internet draft provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP Version 4 standardization effort. "Network Time Protocol Version 4 Autokey Specification", Brian Haberman, David Mills, 18-Aug-08, This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPSEC schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, PKI schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions. This memo includes the Autokey requirements analysis, design principles and protocol specification. A detailed description of the protocol states, events and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested and documented in the NTP Version 4 (NTPv4) software distribution for Unix, Windows and VMS at http://www.ntp.org. "Network Time Protocol (NTP) Server Option for DHCPv6", Richard Gayraud, Benoit Lourdelet, 6-Mar-09, The NTP Server Option for DHCPv6 provides NTP (Network Time Protocol version 4) configuration information to DHCPv6 hosts. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", David Harrington, 11-May-09, New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents defining new protocols or protocol extensions, about covering aspects of operations and management that should be considered. "Expressing SNMP SMI Datatypes in XML Schema Definition Language", Bob Natale, 27-Mar-09, This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", Juergen Schoenwaelder, Alex Clemm, Anirban Karmakar, 9-Mar-09, 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 mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", Vladislav Marinov, Juergen Schoenwaelder, 26-Mar-09, This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. "Survey of IETF Network Management Standards", David Harrington, 2-Mar-09, This document provides a survey of existing IETF standards-track network management protocols and data models. The purpose of this document is to help protocol designers, implementers, and users to select appropriate standard management protocols and data models to address relevant management needs. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 13-Apr-09, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Remote Triggered Black Hole filtering with uRPF", Warren Kumari, Danny McPherson, 30-Mar-09, Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. "Security Assessment of the Internet Protocol version 4", Fernando Gont, 28-Jan-09, This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). Open Shortest Path First IGP (ospf) ----------------------------------- "Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, 2-Apr-09, 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 (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). Please send comments to ospf@ietf.org. "OSPF Link-local Signaling", Alex Zinin, Abhay Roy, Liem Nguyen, Barry Friedman, Derek Yeung, 9-Mar-09, OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features which need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC4813 to bring it on the Standards Track. "Advertising a Router's Local Addresses in OSPF TE Extensions", Rahul Aggarwal, Kireeti Kompella, 4-May-09, OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. "OSPF Version 2 MIB for Multi-Topology (MT) Routing", Namita Rawat, 18-Nov-08, This memo defines an extension to the Open Shortest Path First version 2 Management Information Base (OSPFv2 MIB) for use with network management protocols in the Internet community. In particular it describes objects and lists considerations for the management of OSPF Multi-Topology routing. "OSPF HMAC-SHA Cryptographic Authentication", Vishwas Manral, M Fanto, Russ White, Tony Li, Michael Barnes, Manav Bhatia, 6-May-09, This document describes how the NIST Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. "Extensions to OSPF to Support Mobile Ad Hoc Networking", Madhavi Chandra, Abhay Roy, 21-Sep-08, This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. Chandra, Roy et al. Expires March 2009 [page 1] Internet-Draft Extensions to OSPF to Support MANETs September 2008 "MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo, 28-Jan-09, This document specifies an extension of OSPFv3 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 link state advertisements (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. "Dynamic Hostname Exchange Mechanism for OSPF", Subbaiah Venkata, Sanjay Harwani, Carlos Pignataro, Danny McPherson, 3-Apr-09, Currently, there does not exist a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like for routers running IS-IS. This document defines a new OSPF Router Information (RI) TLV which allows the OSPF routers to flood their hostname-to-Router ID mapping information across the OSPF network. This mechanism is applicable to both OSPFv2 and OSPFv3. "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 2-May-09, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "OSPF Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 27-Feb-09, OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 7-Mar-09, This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. "REsource LOcation And Discovery (RELOAD) Base Protocol", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 7-Mar-09, In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC 3979 respectively. They refer only to those RFCs and not any documents that update or supersede them. This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. "Diagnose P2PSIP Overlay Network", Song Yongchao, XingFeng Jiang, 22-Jan-09, This document describes P2PSIP diagnostics. It describes the usage scenarios and defines several simple methods for the diagnostics in P2PSIP overlay network. It also describes types of diagnostic information which are useful for the connection and node status monitoring. The methods and message formats are specified as extensions to P2PSIP base protocol RELOAD. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "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. "State Machines for Protocol for Carrying Authentication for Network Access (PANA)", Victor Fajardo, Yoshihiro Ohba, Rafa Lopez, 23-Apr-09, 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 with the EAP state machines. 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, 13-Apr-09, This document defines an extension to the Protocol for carrying Authentication for Network Access (PANA) for proactively establishing a PANA security association between a PANA client in one access network and a PANA authentication agent in another access network to which the PANA client may move. Path Computation Element (pce) ------------------------------ "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Eiji Oki, Jean-Louis Le Roux, Kenji Kumaki, Adrian Farrel, Tomonori Takeda, 5-Jan-09, 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 client/server 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". Generic requirements for PCE discovery protocol are presented in "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Tomonori Takeda, Jean-Louis Le Roux, Adrian Farrel, 26-Mar-09, A network may comprise multiple layers. It is important to globally optimize network resource 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 a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (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). "Definitions of Textual Conventions for Path Computation Element", Emile Stephan, 4-Mar-09, 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 Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. "Inclusion of Manageability Sections in PCE Working Group Drafts", Adrian Farrel, 4-Jan-09, It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization", Young Lee, Jean-Louis Le Roux, Daniel King, Eiji Oki, 29-Mar-09, The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", Jean-Louis Le Roux, JP Vasseur, Young Lee, 27-Dec-08, The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks, is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g. minimum cost path, widest path, etc.). In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions, therefore it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE. This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and so that a PCE can report in a path computation reply the objective function that was used for path computation. This document defines objective function code types for six objective functions previously listed in the PCE requirments work, and provides the definition of four new metric types that apply to a set of synchronized requests. "A set of monitoring tools for Path Computation Element based Architecture", JP Vasseur, Jean-Louis Le Roux, Yuichi Ikejiri, 20-Jan-09, A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where 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). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Jean-Louis Le Roux, Adrian Farrel, 5-Jan-09, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol 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 through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS) Traffic Engineering (TE)", Seisho Yasukawa, Adrian Farrel, 13-Feb-09, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths, and examines which of the PCE architectural models are appropriate. "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian Farrel, 13-Feb-09, The Path Computation Element (PCE) provides path computation functions 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 point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (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 MPLS/GMPLS traffic engineering. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", Quintin Zhao, Daniel King, Fabien Verhaeghe, Tomonori Takeda, Jean-Louis Le Roux, Zafar Ali, 9-Mar-09, Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. "The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations", Itaru Nishioka, Daniel King, 9-Mar-09, A Path Computation Element (PCE) performing dependent path computations, for instance calculating a diverse working and protected path do not share common network points, would need to synchronize the computations in order to increase the probability of meeting the working and protected path disjoint objective and network resource optimization objective. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. SVEC is also applicable to end-to-end diverse path computation across multiple domains. This document describes the usage of SVECs in the SVEC list and diverse path computation guideline, for the synchronized computation of dependent paths. "PCE communication protocol(PCEP) Management Information Base", Kiran Koushik, Emile Stephan, 21-Jan-09, 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 Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. "PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, Adrian Farrel, 24-Mar-09, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol 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 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 "Path Computation Element (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. Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ "Pre-Congestion Notification (PCN) Architecture", Philip Eardley, 7-Apr-09, This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single Diffserv domain. Status "Baseline Encoding and Transport of Pre-Congestion Information", T Moncaster, Bob Briscoe, Michael Menth, 7-Apr-09, The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether t o admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the ECN codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, unmarked and marked. "Metering and marking behaviour of PCN-nodes", Philip Eardley, 8-May-09, The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable and robust fashion. This document specifies the two metering and marking behaviours of PCN-nodes. Threshold- metering and -marking marks all PCN-packets if the PCN traffic rate is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the traffic rate in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. "A PCN encoding using 2 DSCPs to provide 3 or more states", T Moncaster, Bob Briscoe, Michael Menth, 8-Apr-09, Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme additionally provides limited end-to-end support for ECN. Status (to be removed by RFC Editor) This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. The PCN Working Group will be asked to adopt this memo as a Working Group document describing one of several possible experimental PCN encoding schemes. The intention is that the title of this document will change to avoid confusion with the three state marking scheme. Changes from previous drafts From draft-moncaster-pcn-3-state-encoding-01: o Changed to WG draft. Title changed from "A three state extended PCN encoding scheme" o Imposed new structure on document. This structure is intended to be followed by all extensions to the baseline PCN encoding scheme. o Extensive changes throughout to ensure consistency with the baseline PCN encoding scheme. From 00 to 01: o Checked terminology for consistency with [I-D.ietf-pcn-baseline-encoding] o Minor editorial changes. Protocol Independent Multicast (pim) ------------------------------------ "Authentication and Confidentiality in PIM-SM Link-local Messages", William Atwood, Salekul Islam, Maziar Siami, 14-Apr-09, RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional support for automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. "PIM Multi-Topology ID (MT-ID) Join-Attribute", Yiqun Cai, Heidi Ou, 7-Jan-09, This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", Denis Pinkas, 6-Feb-09, This document describes the format of a request sent to a Time Stamping Unit (TSU) in order to get a time-stamp token and of the response that is returned. It also establishes several security- relevant requirements for the operation of a time-stamping service, with regards to processing requests to generate responses. "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Quynh Dang, 6-Mar-09, This document supplements RFC 3279. It specifies algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). "New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 6-Apr-09, The PKIX certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. "Update for RSAES-OAEP Algorithm Parameters", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 9-Mar-09, This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. "Traceable Anonymous Certificate", Sanghwan Park, Haeryong Park, Yoojae Won, Jaeil Lee, Stephen Kent, 31-Mar-09, Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers(e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 [3]and CMC[4]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymous Issuer). The end-entity(EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). "Trust Anchor Management Requirements", Raksha Reddy, Carl Wallace, 4-Mar-09, A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. "PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 8-Dec-08, One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols. "Other Certificates Extension", Stephen Farrell, 14-Apr-09, Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates belonging to the same end entity that can safely be considered to be equivalent for the purposes of referencing that application state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. "Trust Anchor Format", Russ Housley, Sam Ashmore, Carl Wallace, 20-Apr-09, This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. "Trust Anchor Management Protocol (TAMP)", Russ Housley, Sam Ashmore, Carl Wallace, 20-Apr-09, This document describes a transport independent protocol for the management of trust anchors and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate or TrustAnchorInfo objects. "An Internet Attribute Certificate Profile for Authorization", Russ Housley, Stephen Farrell, Sean Turner, 27-Apr-09, This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. "Clearance Attribute and Authority Clearance Constraints Certificate Extension", Santosh Chokhani, Sean Turner, 26-Mar-09, This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject. "OCSP Algorithm Agility", Phillip Hallam-Baker, 4-Mar-09, The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. Performance Metrics for Other Layers (pmol) ------------------------------------------- "SIP End-to-End Performance Metrics", Daryl Malas, Al Morton, 6-Mar-09, This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) based services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. "Framework for Performance Metric Development", Alan Clark, 9-Mar-09, This memo describes a framework and guidelines for the development of performance metrics that are beyond the scope of existing working group charters in the IETF. In this version, the memo refers to a Performance Metrics Entity, or PM Entity, which may in future be a working group or directorate or a combination of these two. Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- "Pseudowire (PW) Management Information Base (MIB)", Thomas Nadeau, David Zelig, 9-Jan-08, 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 Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. "Pseudowire (PW) over MPLS PSN Management Information Base (MIB)", David Zelig, Thomas Nadeau, 9-Jan-08, 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 MIB module for PW operation over Multi- Protocol Label Switching (MPLS) Label Switch Router (LSR). "Definitions of Textual Conventions for Pseudowires (PW) Management", Thomas Nadeau, David Zelig, Orly Nicklass, 23-Feb-09, This memo defines a Management Information Base (MIB) module which contains Textual Conventions (TCs) to represent commonly-used Pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2", David Zelig, Ron Cohen, Thomas Nadeau, 9-Jan-08, 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 SONET/SDH circuits over a Packet Switch Network (PSN). "Ethernet Pseudowire (PW) Management Information Base (MIB)", David Zelig, Thomas Nadeau, 20-Feb-09, 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 of Ethernet Pseudowire (PW) services. "Managed Objects for ATM over Packet Switched Network (PSN)", Orly Nicklass, Senthilkumar Sathappan, Marichetty Venkatesan, Thomas Nadeau, 21-Oct-08, 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 ATM Pseudowire (PW) carrying ATM cells over Packet Switch Network (PSN). "Managed Objects for TDM over Packet Switched Network (PSN)", Orly Nicklass, 21-Oct-08, 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). "Pseudo Wire (PW) OAM Message Mapping", Luca Martini, Monique Morrow, 15-Apr-09, This document specifies the mapping and notification 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 [RFC3985] such that a homogenous PW service can be constructed. "Segmented Pseudowire", Luca Martini, Thomas Nadeau, Chris Metz, Michael Duckett, Matthew Bocci, Florin Balus, Mustapha Aissaoui, 18-Feb-09, This document describes how to connect pseudowires (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. "Dynamic Placement of Multi Segment Pseudo Wires", Luca Martini, Matthew Bocci, Nabil Bitar, Himanshu Shah, Mustapha Aissaoui, Florin Balus, 9-Mar-09, There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet 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 (PE) routers. "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", Matthew Bocci, Stewart Bryant, 25-Feb-09, This document describes an architecture for extending pseudowire 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 pseudowires, defines "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, Munefumi Tsurusawa, Ronen Solomon, David Zelig, 16-Jan-09, 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 common procedures for using a PW to provide a Fibre Channel service. The mechanisms controlling the reliable transport of Fibre Channel PW over MPLS networks are specified in a companion document [FC-flow]. "Application of Ethernet Pseudowires to MPLS Transport Networks", Stewart Bryant, Monique Morrow, George Swallow, Thomas Nadeau, Neil Harrison, Ben Niven-Jenkins, 27-Feb-09, A requirement has been identified by the operator community for the transparent carriage of the MPLS(-TP) network of one party over the MPLS(-TP) network of another party. This document describes a method of satisfying this need using the existing PWE3 Ethernet pseudowire standard RFC4448. "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Thomas Nadeau, Carlos Pignataro, 18-Feb-09, This document describes new Connectivity Verification (CV) types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. "LDP extensions for AII reachability", Simon DeLord, Frederic JOUNAY, Philippe Niger, Mustapha Aissaoui, Matthew Bocci, 10-Feb-09, The dynamic End-to-End Multisegment pseudowire setup requires PEs to maintain a pseudowire routing table when using FEC129. There is a requirement to automatically advertise Attachment Individual Identifiers to enable the pseudowire routing tables to be populated. Two mechanisms already exist, a BGP reachability information distribution mechanism and an IGP based one. Here we define a third solution relying on LDP. It allows for automatic advertisement of the Attachment Individual Identifier prefixes provisioned on a T-PE when this node does not run BGP or IGP. The mechanism described here runs on the T-LDP (Targeted LDP) session between the T-PE and S-PE, and is intended to complement existing PW routing mechanisms using BGP or OSPF. "Reliable Fibre Channel Transport Over MPLS Networks", Moran Roth, Ronen Solomon, Munefumi Tsurusawa, 15-Jan-09, 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 mechanisms controlling the reliable transport of Fibre Channel PW over MPLS networks. The encapsulation of Fibre Channel PDUs within a pseudowire and the procedures for using a PW to provide a Fibre Channel service are specified in [FC-encap]. "MPLS and Ethernet OAM Interworking", Dinesh Mohan, Nabil Bitar, Simon DeLord, Philippe Niger, Ali Sajassi, 28-Feb-09, This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture [RFC3985] to realize an end-to-end emulated Ethernet service. This document augments the mapping of defect states between a PW and associated AC of the end-to-end emulated service in [PW-OAM-MSG- MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack of Ethernet OAM maturity. However, since then, [Y.1731] and [802.1ag] have been completed, and this document specifies the mapping of defect states between Ethernet ACs and corresponding Ethernet PWs. RADIUS EXTensions (radext) -------------------------- "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", David Nelson, Greg Weber, 10-Oct-08, This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for management access over a secure transport protocol. "RADIUS Design Guidelines", Greg Weber, Alan DeKok, 5-Mar-09, This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). "Extended Remote Authentication Dial In User Service (RADIUS) Attributes", Yong Li, Avi Lior, Glen Zorn, 30-Mar-09, For the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications, the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with the existing protocol. This document defines a mechanism to accomplish that task, along with standard methods to group together related attributes and to encode values that don't fit into 253 octets. "Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)", David Nelson, 19-Nov-08, This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). "TLS encryption for RADIUS over TCP (RadSec)", Stefan Winter, Mike McCauley, Stig Venaas, Klaas Wierenga, 6-Mar-09, This document specifies security on the transport layer (TLS) for the RADIUS protocol [RFC2865] when transmitted over TCP [I-D.dekok-radext-tcp-transport]. This enables dynamic trust relationships between RADIUS servers. "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", Alan DeKok, 2-Mar-09, RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. "New Tunnel-Type Values", Abhishek Tiwari, 25-Nov-08, This document defines a set of values for the Tunnel-Type RADIUS Attribute. "RADIUS Over TCP", Alan DeKok, 1-Mar-09, The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as it's underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (TCP). Reliable Multicast Transport (rmt) ---------------------------------- "Layered Coding Transport (LCT) Building Block", Michael Luby, Mark Watson, Lorenzo Vicisano, 27-Mar-09, 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. This document obsoletes RFC3451 "Asynchronous Layered Coding (ALC) Protocol Instantiation", Michael Luby, Mark Watson, Lorenzo Vicisano, 1-Nov-08, 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. This document obsoletes RFC3450. "FLUTE - File Delivery over Unidirectional Transport", Michael Luby, Rami Lehtonen, Vincent Roca, Toni Paila, 25-Sep-08, 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. "NACK-Oriented Reliable Multicast Protocol", Brian Adamson, Carsten Bormann, University London, Joseph Macker, 24-Apr-09, 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. This document obsoletes RFC 3940. "Simple Authentication Schemes for the ALC and NORM Protocols", Vincent Roca, 9-Mar-09, This document introduces four schemes that provide a per-packet authentication and integrity service in the context of the ALC and NORM protocols. The first scheme is based on digital signatures. Because it relies on asymmetric cryptography, this scheme generates a high processing load at the sender and to a lesser extent at a receiver, as well as a significant transmission overhead. It is therefore well suited to low data rate sessions. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). If this approach also relies an asymmetric cryptography, the processing load and the transmission overhead are significantly reduced compared to traditional digital signature schemes. It is therefore well suited to medium data rate sessions. The third scheme relies on a group Message Authentication Code (MAC). Because this scheme relies on symmetric cryptography, MAC calculation and verification are fast operations, which makes it suited to high data rate sessions. However it only provides a group authentication and integrity service, which means that it only protects against attackers that are not group members. Finally, the fourth scheme merges the digital signature and group group schemes, and is useful to mitigate DoS attacks coming from attackers that are not group members. Robust Header Compression (rohc) -------------------------------- "Integration of Robust Header Compression (ROHC) over IPsec Security Associations", Emre Ertekin, Rohan Jassani, Chris Christou, Carsten Bormann, 2-Feb-09, IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). "IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)", Emre Ertekin, Chris Christou, Rohan Jassani, Tero Kivinen, Carsten Bormann, 2-Feb-09, In order to integrate ROHC with IPsec [ROHCOIPSEC], a mechanism is needed to signal ROHC channel parameters between end-points. Internet Key Exchange (IKE) is a mechanism which can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 [IKEV2] that will allow ROHC and its associated channel parameters to be signaled for IPsec security associations (SAs). "IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)", Emre Ertekin, Chris Christou, Carsten Bormann, 2-Feb-09, Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the SPD and SAD are required. This document describes the IPsec extensions required to support ROHCoIPsec. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "Urban WSNs Routing Requirements in Low Power and Lossy Networks", Mischa Dohler, Thomas Watteyne, Tim Winter, Dominique Barthel, Christian Jacquenet, Giyyarpuram Madhusudan, Gabriel Chegaray, 30-Mar-09, The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless Routing Over Low power and Lossy networks (ROLL) solution to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs tailored characteristics. "Industrial Routing Requirements in Low Power and Lossy Networks", Dust Networks, Pascal Thubert, Sicco Dwars, Tom Phinney, 21-Apr-09, The wide deployment of lower cost wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low power and Lossy Networks (LLN) of field devices. "Home Automation Routing Requirements in Low Power and Lossy Networks", Giorgio Porcu, 19-Nov-08, This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Arsalan Tavakoli, Stephen Dawson-Haggerty, P Levis, 24-Apr-09, Low-power wireless devices, such as sensors, actuators and smart objects, present difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks introduces requirements that existing routing protocols may not fully address. Using existing application requirements documents, this document derives a minimal and not exhaustive set of criteria for routing in low-power and lossy networks. It provides a brief survey of the strengths and weaknesses of existing protocols with respect to these criteria. From this survey it examines whether existing and mature IETF protocols can be used without modification in these networks, or whether further work is necessary. It concludes that no existing IETF protocol meets the requirements of this domain. "Terminology in Low power And Lossy Networks", JP Vasseur, 7-May-09, The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. "Building Automation Routing Requirements in Low Power and Lossy Networks", Jerry Martocci, Nicolas Riou, Pieter Mil, Wouter Vermeylen, 4-Feb-09, The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", JP Vasseur, Dust Networks, 29-Apr-09, This document specifies routing metrics to be used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link attributes, this document specifies a set of routing metrics suitable to LLNs. Routing Area Working Group (rtgwg) ---------------------------------- "IP Fast Reroute Framework", Mike Shand, Stewart Bryant, 27-Feb-09, 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. "A Framework for Loop-free Convergence", Mike Shand, Stewart Bryant, 5-Mar-09, 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. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon Josefsson, Nicolas Williams, 18-Apr-09, 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. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding are supported. See for more information. "Simple Authentication and Security Layer (SASL)", Alexey Melnikov, Kurt Zeilenga, 14-Apr-09, 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. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 4422 [[when approved]]. "CRAM-MD5 to Historic", Kurt Zeilenga, 24-Nov-08, This document recommends the retirement of the CRAM-MD5 authentication mechanism, and discusses the reasons for doing so. This document recommends RFC 2195 and its predecessor, RFC 2095, be moved to Historic status. [[Note to RFC Editor: please publish at same time that [SCRAM] is published.]] "SASL And Channel Binding", Nicolas Williams, 21-Apr-09, This document specifies the semantics of channel binding for the Simple Authentication and Security Layers (SASL) framework, mechanisms and applications. This includes negotiation of channel binding, and negotiation of channel binding types. Source Address Validation Improvements (savi) --------------------------------------------- "SAVI Threat Scope", Danny McPherson, Fred Baker, 21-Jan-09, This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats. "A Solution Space Analysis for First-Hop IP Source Address Validation", Christian Vogt, 22-Jan-09, The IETF working group on Source Address Validation Improvements, SAVI, is chartered to design methods for IP source address validation that complement ingress filtering with finer-grained protection. This document summarizes the discussion in the SAVI working group and design-related conclusions. The purpose of this is two-fold: First, to guide the design process in the working group with written documentation of decisions and their rationale. Second, to provide a measure for assessing the IP source address validation methods that the working group will eventually deliver. "First-Come First-Serve Source-Address Validation Implementation", Erik Nordmark, Marcelo Bagnulo, 4-Mar-09, This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. "SeND-based Source-Address Validation Implementation", Marcelo Bagnulo, 22-Jan-09, This memo describes SeND SAVI, a mechanism to provide source address validation using the SeND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Jari Arkko, Iljitsch van Beijnum, 24-Jun-08, This document specifies how the level 3 multihoming shim protocol (SHIM6) detects failures between two communicating hosts. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same hosts if a failure occurs and an operational pair can be found. "Hash Based Addresses (HBA)", Marcelo Bagnulo, 22-Dec-07, 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. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant 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 to each other. "Shim6: Level 3 Multihoming Shim Protocol for IPv6", Erik Nordmark, Marcelo Bagnulo, 6-Feb-09, This document defines the Shim6 protocol, 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. "Socket Application Program Interface (API) for Multihoming Shim", Miika Komu, Marcelo Bagnulo, Kristian Slavov, Shinta Sugimoto, 7-May-09, This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration. This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter "shim") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are SHIM6 and HIP. Secure Inter-Domain Routing (sidr) ---------------------------------- "A Profile for X.509 PKIX Resource Certificates", Geoff Huston, George Michaelson, Robert Loomans, 25-Feb-09, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the issued certificate. "Certificate Policy (CP) for the Resource PKI (RPKI)", Stephen Kent, Derrick Kong, Karen Seo, Ronald Watro, 6-Mar-09, This document describes the certificate policy for a PKI used to support applications that make use of attestations about Internet resource holdings. The principle application that motivated creation of this PKI is routing security, but other applications that rely on such attestations also may make use of this PKI, e.g., resource transfer. Each organization that allocates IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this allocation. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. The PKI in which the certificates issued under this policy are employed, in conjunction with ancillary digitally signed data structures, will provide critical inputs for routing security mechanisms. "An Infrastructure to Support Secure Internet Routing", Matt Lepinski, Stephen Kent, 9-Mar-09, This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. "A Protocol for Provisioning Resource Certificates", Geoff Huston, Robert Loomans, Byron Ellacott, Rob Austein, 6-Feb-09, This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. "Securing RPSL Objects with RPKI Signatures", Robert Kisteleki, Jos Boumans, 18-Dec-08, This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. "A Profile for Trust Anchor Material for the Resource Certificate PKI", George Michaelson, Stephen Kent, Geoff Huston, 26-Feb-09, This document defines a standard profile for the publication of Trust Anchor material for the Resource Certificate Public Key Infrastructure. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure", Tony Hansen, Cyrus Daboo, 20-Nov-08, This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. Note This document is being discussed on the MTA-FILTERS mailing list, ietf-mta-filters@imc.org. "Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions", Ned Freed, 23-Mar-09, This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification and deliver-by SMTP extensions. The "redirect-dsn" and "redirect- deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and deliver-by parameters, respectively. "A Protocol for Remotely Managing Sieve Scripts", Alexey Melnikov, Tim Martin, 17-Jan-09, 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 "ManageSieve" 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. "Sieve Notification Mechanism: SIP MESSAGE", Alexey Melnikov, Henning Schulzrinne, Qian Sun, 7-Mar-09, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the SIP MESSAGE. "Sieve Email Filtering: Include Extension", Cyrus Daboo, Aaron Stone, 4-May-09, The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. Change History (to be removed prior to publication as an RFC) Changes from ietf-01 to ietf-02: a. Require that script names must be constant strings, not subject to variable expansion. b. Try the phrase immediate script instead of current script. c. Clarify that "global 'varname'" and "global.varname" refer to the same variable. d. Drop the requirement the global keywords come after require and before anything else. Changes from ietf-00 to ietf-01: a. Replaced import/export with global. b. Added :once modifier to include. c. Added global namespace to see if it holds water. Changes from daboo-06 to ietf-00: a. None Changes from -05 to -06: a. Aaron Stone joins as author. b. Removed | characters from the script examples. c. Updated draft references to published RFCs. Changes from -04 to -05: a. Fixed examples. b. Relaxed requirement that imported/exported variables be set before being used. Changes from -03 to -04: a. Fixed missing 2119 definitions. b. Defined interaction with variables through use of import and export commands. Changes from -02 to -03: a. Refreshing expired draft (updated for nits). b. Syntax -> Usage. c. Updated to 3028bis reference. Changes from -01 to -02: a. Minor formatting changes only - refreshing expired draft. Changes from -00 to -01: a. Added IPR boiler plate. b. Re-ordered sections at start to conform to RFC style. c. Moved recursion comment into General Considerations section. d. Switched to using optional parameter to indicate personal vs global. e. Explicitly state that an error occurs when a missing script is included. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, Jari Urpalainen, 5-May-08, 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. This format allows also indications of element and attribute content of an XML document. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. "Presence Interdomain Scaling Analysis for SIP/SIMPLE", Avshalom Houri, Edwin Aoki, Sriram Parameswar, Tim Rang, Vishal Singh, Henning Schulzrinne, 22-Oct-08, The document analyzes the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyzes the affects of a large presence system on the memory footprint and the CPU load. Current approved and in work optimizations to the SIP protocol are analyzed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia, Geir Arne Sandbakken, 9-Mar-09, 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 chat sessions, or chat rooms, using MSRP. "SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 9-Mar-09, The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. "Models for Intra-Domain Presence and Instant Messaging (IM) Bridging", Jonathan Rosenberg, Avshalom Houri, Colm Smyth, Francois Audet, 9-Mar-09, Presence and Instant Messaging (IM) bridging involves the sharing of presence information and exchange of IM across multiple systems within a single domain. As such, it is a close cousin to presence and IM federation, which involves the sharing of presence and IM across differing domains. Presence and IM bridging can be the result of a multi-vendor network, or a consequence of a large organization that requires partitioning. This document examines different use cases and models for intra-domain presence and IM bridging. It is meant to provide a framework for defining requirements and specifications for presence and IM bridging. "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", Christer Holmberg, Staffan Blau, 30-Jan-09, This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976 in the following ways: it uses COMEDIA for TCP connection establishment, and it allows the usage of SDP in a more conventional way for conveying endpoint address information. Because of this, the model also allows for the usage of generic mainstream mechanisms for NAT traversal, instead of using MSRP relays. Session Initiation Protocol (sip) --------------------------------- "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 11-Oct-07, 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 registrar and for communicating a GRUU to a peer within a dialog. "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", Francois Audet, 25-Nov-08, This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 19-Jun-07, This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. "Framework for Establishing an SRTP Security Context using DTLS", Jason Fischl, Hannes Tschofenig, Eric Rescorla, 9-Mar-09, This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using 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 key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. Session Initiation Protocol Core (sipcore) ------------------------------------------ "Scaling Requirements for Presence in SIP/SIMPLE", Avshalom Houri, Sriram Parameswar, Edwin Aoki, Vishal Singh, Henning Schulzrinne, 20-Apr-09, The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", Aki Niemi, 22-Apr-09, 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 provide no tools to avoid replaying event notifications that have already been received by a user agent. 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 is true, either the body of a resulting event notification or the entire notification message is suppressed. "Response Code for Indication of Terminated Dialog", Christer Holmberg, 26-Apr-09, This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. "Indication of support for keep-alive", Christer Holmberg, 4-May-09, This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. "Example call flows using Session Initiation Protocol (SIP) security mechanisms", Cullen Jennings, Kumiko Ono, Robert Sparks, Brian Hibbard, 4-May-09, 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. "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control", Aki Niemi, Krisztian Kiss, Salvatore Loreto, 11-May-09, This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "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. "IPv6 Transition in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 17-Aug-07, 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. "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", Paul Kyzivat, 9-Jul-07, RFC 3680 defines a Session Initiation Protocol (SIP)[5] event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact. However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC YYYY [3], is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. S/MIME Mail Security (smime) ---------------------------- "Use of the RSA-KEM Key Transport Algorithm in CMS", James Randall, Burton Kaliski, 10-Nov-08, The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and ISO/IEC 18033-2. "Multiple Signatures in S/MIME", Sean Turner, Jim Schaad, 11-Mar-08, Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. "Using SHA2 Algorithms with Cryptographic Message Syntax", Sean Turner, 20-Jan-09, This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", Sean Turner, Blake Ramsdell, 27-Apr-09, This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", Blake Ramsdell, Sean Turner, 27-Apr-09, This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. "New ASN.1 Modules for CMS and S/MIME", Paul Hoffman, Jim Schaad, 6-Apr-09, The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", Sean Turner, Daniel R. L. Brown, 6-May-09, This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180- 3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. Softwires (softwire) -------------------- "Softwire Hub & Spoke Deployment Framework with L2TPv2", Bill Storer, Carlos Pignataro, Maria Santos, Bruno Stevant, Jean-Francois Tremblay, 13-Apr-09, This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. "Softwire Security Analysis and Requirements", Shu Yamamoto, Carl Williams, Florent Parent, Hidetoshi Yokota, 10-Mar-09, This document describes the security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with the discussion of the softwire deployment scenarios, the vulnerability to the security attacks is analyzed to provide the security protection mechanism such as authentication, integrity and confidentiality to the softwire control and data packets. "Softwire Mesh Framework", Jianping Wu, Yong Cui, Chris Metz, Eric Rosen, 16-Feb-09, The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single protocol" networks. One kind of single protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "Softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single protocol network of the other protocol. The document is careful to specify when this can be done with existing technology, and when it requires the development of new or modified technology. "BGP IPsec Tunnel Encapsulation Attribute", Lou Berger, Russ White, Eric Rosen, 6-Apr-09, The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) provides a method for the dynamic exchange of encapsulation information, and the indication of encapsulation protocol types to be used for different next hops. Currently support for GRE, L2TPv3 and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. "Load Balancing for Mesh Softwires", Clarence Filsfils, Pradosh Mohapatra, Carlos Pignataro, 8-May-09, Payloads carried over a Softwire mesh service as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange often carry a number of identifiable, distinct flows. It can in some circumstances be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus the load balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. "Dual-stack lite broadband deployments post IPv4 exhaustion", Alain Durand, Ralph Droms, Brian Haberman, James Woodyatt, 3-Mar-09, The common thinking for more than 10 years has been that the transition to IPv6 will be based on the dual stack model and that most things would be converted this way before we ran out of IPv4. It has not happened. The IANA free pool of IPv4 addresses will be depleted soon, well before any significant IPv6 deployment will have occurred. This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6. Dual-stack lite will provide the necessary bridge between the two protocols, offering an evolution path of the Internet post IANA IPv4 depletion. Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Saravanan Shanmugham, Daniel Burnett, 5-May-09, 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 other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. 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 for SIP-based Session Peering", Jean-Francois Mule, 17-Oct-08, This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. It is based on the use cases that have been described in the SPEERMINT working group. This informational document is intended to link the session peering use cases to protocol solutions. "SPEERMINT Peering Architecture", Reinaldo Penno, Sohel Khan, 2-Mar-09, This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. It also describes the steps taken to establish a session between two peering domains in the context of the functions defined. "SPEERMINT Routing Architecture Message Flows", Hadriel Kaplan, Daryl Malas, Sohel Khan, Reinaldo Penno, Adam Uzelac, 9-Mar-09, This document describes example message flows associated with the SPEERMINT routing architecture, relative to various peering scenarios. "Use of DNS SRV and NAPTR Records for SPEERMINT", Tom Creighton, Jason Livingood, 5-Mar-09, The objective of this document is to specify the Best Current Practice (BCP) adopted by a service provider or other organization providing multimedia communication services such as Voice over Internet Protocol(VoIP) in order to locate another service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. This document attempts to fill the gaps in information from RFC 3261, RFC 3263, and other documents, in order to more assist service providers in more easily performing SIP peering. [EDITORIAL NOTE: XREF ERROR GENERATED IN ABSTRACT, XREFS REMOVED] "VoIP SIP Peering Use Cases", Adam Uzelac, Yiu Lee, 17-Nov-08, This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. "SPEERMINT Security Threats and Suggested Countermeasures", Saverio Niccolini, Eric Chen, Jan Seedorf, Hendrik Scholz, 17-Nov-08, This memo presents the different security threats related to SPEERMINT classifying them into threats to the Location Function, to the Signaling Function and to the Media Function. The different instances of the threats are briefly introduced inside the classification. Finally the existing security solutions in SIP and RTP/RTCP are presented to describe the countermeasures currently available for such threats. The objective of this document is to identify and enumerate the SPEERMINT-specific threat vectors in order to specify security-related requirements. Once the requirements are identified, methods and solutions how to achieve such requirements can be selected. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "Signed syslog Messages", John Kelsey, Jon Callas, Alex Clemm, 30-Mar-09, 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 is intended to be used in conjunction with the work defined in [RFC5424], "The syslog Protocol". TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Improving TCP's Robustness to Blind In-Window Attacks", Anantha Ramaiah, Randall Stewart, Mitesh Dalal, 2-Nov-08, TCP has historically been considered protected against spoofed off- path 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 longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", Sally Floyd, 2-Apr-09, The proposal in this document is experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ECN in TCP SYN/ACK packets. This draft describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies 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 describes 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 the initial TCP SYN/ACK packet 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 TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN- Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmit timer). "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", Pasi Sarolahti, Markku Kojo, Kazunori Yamamoto, Max Hata, 30-Oct-08, The purpose of this document is to move the F-RTO functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F- RTO support for SCTP in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138. Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. "The TCP Authentication Option", Joseph Touch, Allison Mankin, Ronald Bonica, 9-Mar-09, This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key configuration or an external, out-of-band master key management mechanism; in either case, TCP-AO also protects connections when using the same master key across repeated instances of a connection, using traffic keys derived from the master key, and coordinates key changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. "TCP Extensions for High Performance", David Borman, Robert Braden, Van Jacobson, 4-Mar-09, This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC 1323. "Early Retransmit for TCP and SCTP", Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Ethan Blanton, Per Hurtig, 14-Jan-09, This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. "TCP Options and MSS", David Borman, 4-Mar-09, This memo discusses what value to use with the TCP MSS option. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Extensions: Extension Definitions", Donald Eastlake 3rd, 20-Apr-09, This document provides specifications for existing TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. "Keying Material Exporters for Transport Layer Security (TLS)", Eric Rescorla, 7-Mar-09, A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. "Datagram Transport Layer Security version 1.2", Eric Rescorla, Nagendra Modadugu, 7-Mar-09, This document specifies Version 1.2 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 Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "Rbridges: Base Protocol Specification", Donald Eastlake 3rd, Dinesh Dutt, Silvano Gai, Anoop Ghanwani, Radia Perlman, 9-Mar-09, RBridges provide optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows forwarding tables to be sized according to the number of RBridges (rather than the number of end nodes), which allows internal forwarding tables to be substantially smaller than in conventional bridges. "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", Joseph Touch, Radia Perlman, 5-Mar-09, Current IEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, 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). This document addresses these concerns and suggests that they can be addressed by applying modern network layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. "RBridge VLAN Mapping", Radia Perlman, Donald Eastlake 3rd, Dinesh Dutt, 21-Jan-09, Some bridge products perform a feature known as "VLAN mapping", in which a bridge translates a data frame's VLAN ID from one VLAN to another when it forwards a frame from one port to another. This feature facilitates scenarios such as combining two bridged LANs with overlapping VLAN IDs into one bridged LAN without merging two communities just because they have been given the same VLAN ID in the original two clouds. This document describes how RBridges can achieve the same functionality. Transport Area Working Group (tsvwg) ------------------------------------ "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Kacheong Poon, Michael Tuexen, Vladislav Yasevich, Peter Lei, 16-Feb-09, This document describes a mapping of the Stream Control Transmission Protocol SCTP 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. "Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services", Francois Le Faucheur, James Polk, Ken Carlberg, 18-Feb-09, An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. The mechanisms defined in this document are applicable to controlled environments. "DSCP for Capacity-Admitted Traffic", Fred Baker, James Polk, Martin Dolly, 2-Nov-08, This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for real-time traffic classes similar to voice conforming to the Expedited Forwarding Per Hop Behavior, and admitted using a call admission procedure involving authentication, authorization, and capacity admission. This document also recommends that certain classes of video traffic described in RFC 4594 and which have similar requirements be changed to require admission using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. "RSVP Extensions for Path-Triggered RSVP Receiver Proxy", Francois Le Faucheur, Hemant Malik, Jukka Manner, Ashok Narayanan, Allan Guillou, Le Faucheur, 4-May-09, RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. "RSVP Proxy Approaches", Francois Le Faucheur, Jukka Manner, Dan Wing, Allan Guillou, 31-Oct-08, The Resource ReSerVation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP- capable. This document presents RSVP Proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP Proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP Proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP Proxy are described. "Port Randomization", Michael Larsen, Fernando Gont, 11-Mar-09, Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five- tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the connection, the described port number obfuscation algorithms provide improved security/obfuscation with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed, and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. "Applicability of Keying Methods for RSVP Security", Michael Behringer, Francois Le Faucheur, 24-Mar-09, The Resource reSerVation Protocol (RSVP) allows hop-by-hop authentication of RSVP neighbors. This requires messages to be cryptographically signed using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The present document also discusses applicability of group keying to RSVP encryption. "Support for RSVP in Layer 3 VPNs", Bruce Davie, Francois Le Faucheur, Ashok Narayanan, 1-Nov-08, RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to use RSVP to perform admission control on the links between CE and PE routers. This document specifies procedures by which RSVP messages travelling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. "Tunnelling of Explicit Congestion Notification", Bob Briscoe, 24-Mar-09, This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP in IP tunnel. On encapsulation it brings all IP in IP tunnels (v4 or v6) into line with the way RFC4301 IPsec tunnels now construct the ECN field. On decapsulation it redefines how the ECN field in the forwarded IP header should be calculated for two previously invalid combinations of incoming inner and outer headers, in order that these combinations may be usefully employed in future standards actions. It includes a thorough analysis of the reasoning for these changes and the implications. Usenet Article Standard Update (usefor) --------------------------------------- "Netnews Article Format", Charles Lindsey, 9-Jan-07, This document specifies the syntax of Netnews articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. "Netnews Architecture and Protocols", Russ Allbery, Charles Lindsey, 3-Mar-09, This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.Internet Draft Comments Comments are solicited and should be addressed to the Usenet Format Working Group at ietf-usefor@imc.org. IPv6 Operations (v6ops) ----------------------- "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 17-Apr-09, This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. "IPv6 RA-Guard", Eric Levy-Abegnoli, Gunter Van de Velde, Chip Popoviciu, Janos Mohacsi, 5-Mar-09, It is particularly easy to experience "rogue" routers on an unsecured link. Devices acting as a rougue router may send illegitimate RAs. Section 6 of SeND [RFC3971] provides a full solution to this problem, by enabling routers certification. This solution does, however, require all nodes on an L2 network segment to support SeND, as well as it carries some deployment challenges. End-nodes must be provisioned with certificate anchors. The solution works better when end-nodes have access to a Certificate Revocation List server, and to a Network Time Protocol server, both typically off-link, which brings some bootstrap issues. When using IPv6 within a single L2 network segment it is possible and sometimes desirable to enable layer 2 devices to drop rogue RAs before they reach end-nodes. In order to distinguish valid from rogue RAs, the L2 devices can use a spectrum of criterias, from a static scheme that blocks RAs received on un-trusted ports, or from un-trusted sources, to a more dynamic scheme that uses SeND to challenge RA sources. This document reviews various techniques applicable on the L2 devices to reduce the threat of rogue RAs. "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 25-Mar-09, This document recommends IPv6 behavior for Customer Premises Equipment (CPE) routers in Internet-enabled homes and small offices. The CPE Router may be a standalone device. The CPE Router may also be embedded in a device such as a cable modem, DSL modem, cellular phone, etc. This document describes the router portion of such a device. The purpose behind this document is to provide minimal functionality for interoperability and create consistency in the customer experience and satisfy customer expectations for the device. Further, the document also provide some guidance for implementers to expedite availability of IPv6 CPE router products in the marketplace. It is expected that standards bodies other than the IETF developing standards for specific products in this area (e.g. CableLabs eRouter, Broadband Forum, Home Gateway Initiative, etc.) may reference this work for basic functionality and provide value-added or linktype-specific customizations and enhancements which are beyond the scope of this document. vCard and CardDAV (vcarddav) ---------------------------- "vCard Format Specification", Simon Perreault, Pete Resnick, 6-May-09, This document defines the vCard data format for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). "vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 8-Mar-09, This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. "Extended MKCOL for WebDAV", Cyrus Daboo, 8-Mar-09, This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6", Stephen Nadas, 15-Apr-08, This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt. 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 IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, 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 Discover (RFC 4861) mechanisms. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, Jason Crawford, Julian Reschke, Jim Whitehead, 25-Feb-09, 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. Centralized Conferencing (xcon) ------------------------------- "Conference Information Data Model for Centralized Conferencing (XCON)", Oscar Novo, Gonzalo Camarillo, David Morgan, Jari Urpalainen, 6-Apr-09, This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", Gonzalo Camarillo, Srivatsa Srinivasan, Roni Even, Jari Urpalainen, 3-Sep-08, This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. "Centralized Conferencing Manipulation Protocol", Mary Barnes, Chris Boulton, Simon Romano, Henning Schulzrinne, 9-Mar-09, The Centralized Conferencing Manipulation Protocol (CCMP) can create, retrieve, change and delete objects describing a centralized conference, such as state and capabilities of the conference, participants, and their roles. The conference information is contained in XML documents and fragments conforming to the centralized conferencing data model schema. CCMP is a state-less client-server protocol based on a request/response model. Conferencing clients send requests to conference servers, which respond to the client with the conference information. This document also discusses options for using existing notification protocols to inform conference client about the changes in the state of a conference during its entire lifetime.