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", HongSeok Jeon, 18-Nov-08, 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. "Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer", Syam Madanapalli, Soohong Daniel Park, Samita Chakrabarti, Gabriel Montenegro, 2-Nov-08, IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service specific convergence sublayers for transmitting upper layer protocols. The packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as Internet Protocol (IP), IEEE 802.3 (Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MAC. This document specifies the frame format, the Maximum Transmission Unit (MTU) and address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, Pascal Thubert, 17-Nov-08, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. 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, 3-Nov-08, This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). "Neighbor Discovery for 6LoWPAN", Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Erik Nordmark, 18-Nov-08, This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new mechanism allowing efficient Duplicate Address Detection over entire 6LoWPAN networks. In addition it specifies prefix and context dissemination for use with router advertisements, allows for stateless address assignment, and the use of Neighbor Discovery Proxy. This document is an identical replacement of draft-shelby-6lowpan-nd-01. This document was now submitted as a 6lowpan working group document. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 18-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. IPv6 Maintenance (6man) ----------------------- "Solution approaches for address-selection problems", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 18-Jun-08, In response to address selection problem statement and requirement documents, this document describes approaches to solutions and evaluates proposed solution mechanisms in line with requirements. It also examines the applicability of each solution mechanism from the viewpoint of practical application. Matsumoto, et al. Expires August 2, 2008 [page 1] "IPv6 Node Requirements RFC 4294-bis", John Loughney, 3-Nov-08, This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. "Reserved IPv6 Interface Identifiers", Suresh Krishnan, 14-Jul-08, Interface Identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. "IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes", Hemant Singh, Wes Beebee, Erik Nordmark, 6-Oct-08, 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 invalidates (partially due to security concerns) a part of the definition of on-link from [RFC4861]. "Handling of overlapping IPv6 fragments", Suresh Krishnan, 4-Nov-08, 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. "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, Narendranath Nair, 1-Sep-08, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. 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, 3-Nov-08, 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, 7-Oct-08, 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, 3-Nov-08, 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. "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 24-Jun-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- "Mobile Ad hoc Network Architecture", Ian Chakeres, Joseph Macker, Thomas Clausen, 7-Nov-07, This document discusses Mobile Ad hoc NETworks (MANETs). It presents the initial motivation for MANET and describes unaccustomed characteristics and challenges. It also defines a MANET, other MANET entities, and MANET architectural concepts. Audio/Video Transport (avt) --------------------------- "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Joerg Ott, 7-Jan-08, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Ott et al. Internet Draft - Expires July 2008 [page 1] RTCP with Unicast Feedback "RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family", Jun Matsumoto, Mitsuyuki Hatanaka, 4-Sep-08, 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. "Associating Time-codes with RTP streams", David Singer, 3-Nov-08, This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 22-Aug-08, 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, Aymeric Moizard, 16-Feb-08, 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, 11-Sep-08, 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. "Transmission Time offsets in RTP streams", David Singer, HariKishan Desineni, 11-Mar-08, This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. "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, 3-Nov-08, 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. For single-session transmission the packetization modes of [I-D.ietf-avt-rtp- rfc3984bis] are used. For multi-session transmission four different modes are defined in this memo. The modes differ depending on whether the SVC data are allowed to be interleaved, i.e., to be transmitted in an order different than the intended decoding order, and they also differ in the mechanisms provided in order to recover the correct decoding order of the NAL units across the multiple RTP sessions. Specifically, decoding order recovery is performed using either timestamp alignment or Cross-Session Decoding Order Numbers (CS-DON), although in one of the modes both schemes are used in order to allow receivers to use their preferred method. The multi- session transmission modes use the packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] as each individual session still uses a packetization mode defined in [I-D.ietf-avt-rtp-rfc3984bis]. The packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] are slightly extended such that the three new NAL unit types defined in this memo can be included in the RTP packet streams. 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 Copyright Notice..................................................1 Abstract..........................................................2 "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, Intellectual Property, 6-Aug-08, 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 mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 25-Feb-08, 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, 2-Oct-08, 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, 29-Oct-08, 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. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 7-Oct-08, This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). "The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)", Intellectual Property, 17-Nov-08, 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). "Support for Reduced-Size RTCP, Opportunities and Consequences", Ingemar Johansson, Magnus Westerlund, 18-Nov-08, This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC3550 are removed or changed. Based on that analysis this memo defines certain changes to the rules to allow feedback messages to be sent as reduced-size RTCP packets under certain conditions when using the RTP AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] and [RFC4585]. "RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 22-May-08, 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. "G.729.1 RTP Payload Format update: DTX support", Aurelien Sollaud, 26-Sep-08, This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. "RTP Payload Format for ITU-T Recommendation G.711.1", Aurelien Sollaud, 28-Apr-08, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.711.1 audio codec. Two media type registrations are also included. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 7-Jul-08, 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, 20-Oct-08, 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. "RTP Payload format for G.719", Magnus Westerlund, Ingemar Johansson, 17-Nov-08, This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. "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, 4-Nov-08, 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, 3-Nov-08, 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 intends to obsolete RFC 3984. Changes from RFC 3984 are summarized in section 17. Issues on backward compatibility to RFC 3984 are discussed in section 16. "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 23-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, 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, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Concealed Seconds metrics primarily for audio applications of RTP. "RTCP XR Report Block for QoE Metrics Reporting", Alan Clark, Geoff Hunt, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of QoE metrics for use in voice, audio and video services. "RTCP XR Report Block for Signal Level Metrics Reporting", Alan Clark, Geoff Hunt, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of metrics related to signal levels for use in voice, audio and video services. 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, 29-Oct-08, 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 IPv4/IPv6 Transition", Gonzalo Camarillo, Oscar Novo, 29-Oct-08, This document defines the REQUESTED-ADDRESS-TYPE attribute for Traversal Using Relays around NAT (TURN). The REQUESTED-ADDRESS-TYPE 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). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). "NAT Behavioral Requirements for ICMP protocol", Pyda Srisuresh, Bryan Ford, Senthil Sivakumar, Saikat Guha, 22-Nov-08, This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. "NAT Behavior Discovery Using STUN", Derek MacDonald, Bruce Lowekamp, 3-Nov-08, 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", Jonathan Rosenberg, Rohan Mahy, 4-Nov-08, 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, 28-Oct-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. Developing NATs that 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, 22-Oct-08, 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. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya, 31-Oct-08, 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, 24-Mar-08, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. "BFD for Multihop Paths", Dave Katz, David Ward, 16-Jan-08, 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, 24-Mar-08, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. "Generic Application of BFD", Dave Katz, David Ward, 16-Jan-08, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. 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, 3-Nov-08, 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, 3-Nov-08, This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP). This work is being discussed on the bliss@ietf.org mailing list. "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Denis Alexeitsev, 20-Jun-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, 2-Nov-08, 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 (SA) 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) ------------------------------- "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Intellectual Property, 15-Oct-08, 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, Intellectual Property, 15-Oct-08, 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, Intellectual Property, 15-Oct-08, 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 "Benchmarking Terminology for Protection Performance", Scott Poretsky, 3-Nov-08, 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). "Methodology for Benchmarking MPLS Protection Mechanisms", Rajiv Papneja, Samir Vapiwala, Jay Karthik, Scott Poretsky, Shankar Rao, Jean-Louis Roux, 3-Nov-08, Protection Mechanisms 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 test bed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time services bound to MPLS based traffic engineered tunnels. The terms used in the procedures included in this document are defined in [TERM-ID]. "MPLS Forwarding Benchmarking Methodology", Aamer Akhter, Rajiv Asati, 3-Nov-08, This document describes a methodology specific to the benchmarking of MPLS forwarding devices, limited to various types of packet- forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. Better-Than-Nothing Security (btns) ----------------------------------- "IPsec Channels: Connection Latching", Nicolas Williams, 3-Nov-08, 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. "An abstract interface between applications and IPsec", Michael Richardson, 2-Nov-08, This document explains in the abstract (no language bindings are provided) how an application may learn that IPsec has been applied to a conversation or specify that IPsec should be used. Though this is useful in general it is particularly useful for applications that wish to use BTNS (Better Than Nothing Security -- a mode of IPsec keying), either in conjunction with channel binding or otherwise. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 9-Jun-08, This document, iCalendar Message-Based Interoperability Protocol (iMIP), specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCAL) are composed using constructs from RFC 2822, RFC 2045, RFC 2046, RFC 2047 and RFC 2049. This document is a product of Calendaring and Scheduling Standards Simplification (calsify) working group. More information about the IETF CALSIFY working group activities can be found on the IETF web site at . The issue tracker for the Calsify WG is located at: "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 3-Nov-08, 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, 31-Oct-08, 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 Specification", Michael Montemurro, Dorothy Stanley, Pat Calhoun, 1-Nov-08, This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP working group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. "CAPWAP Protocol Binding for IEEE 802.11", Michael Montemurro, Dorothy Stanley, Pat Calhoun, 1-Nov-08, Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. "CAPWAP Threat Analysis for IEEE 802.11 Deployments", Scott Kelly, Charles Clancy, 10-Sep-08, Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP) which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning for Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. "CAPWAP Access Controller DHCP Option", Pat Calhoun, 14-Oct-08, The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers it is to connect to. This document describes the DHCP options to be used by the CAPWAP protocol. "CAPWAP Protocol Base MIB", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 1-Nov-08, 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, 27-Oct-08, 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, 17-Oct-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, Intellectual Property, 1-Nov-08, 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, Intellectual Property, 29-Oct-08, 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 April 2009 [page 1] draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt October 2008 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, Jonathan Newton, 29-Oct-08, 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. Ali et al. Expires April 2009 [page 1] draft-ietf-ccamp-mpls-graceful-shutdown-08.txt "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, 18-Nov-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", Thomas Nadeau, 4-Aug-08, 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. "draft-ietf-ccamp-pc-and-sc-reqs-06.txt", Diego Caviglia, Dino Bramanti, Dan Li, Dave McDysan, 15-Sep-08, From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. "OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 27-Jul-08, This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. "Description of the RSVP-TE Graceful Restart Procedures", Dan Li, 19-May-08, The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. "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 Roux, Eiji Oki, Ichiro Inoue, Emmanuel Dotaro, Gert Grammel, 3-Nov-08, There are requirements for the support of networks comprising LSRs with 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. "ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 4-Sep-08, This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. "GMPLS Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 27-Oct-08, 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 SONET/SDH TDM and ATM. This document defines an architecture and framework for a 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.Contents "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", Adrian Farrel, Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar, 27-May-08, Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", Lou Berger, Attila Takacs, Diego Caviglia, Don Fedyk, Julien Meuric, 17-Nov-08, This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. "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, 24-Jun-08, 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, 2-Nov-08, 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. "RSVP Extensions for Path Key Support", Richard Bradford, JP Vasseur, Adrian Farrel, 1-Nov-08, 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. This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. "draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt", Diego Caviglia, Daniele Ceccarelli, Dino Bramanti, Dan Li, Snigdho Bardalai, 31-Oct-08, We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. Failure conductions and subsequent roll back are also illustrated taking into account that an handover failure must not impact the already established data plane connections. "GMPLS control of Ethernet PBB-TE", Don Fedyk, David Allan, Himanshu Shah, Nabil Bitar, Attila Takacs, Diego Caviglia, Alan McGuire, Nurit Sprecher, Lou Berger, 13-Jul-08, This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridging 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, 8-Aug-08, 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 service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)", Lou Berger, Don Fedyk, 8-Aug-08, 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 to 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. 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. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", Greg Bernstein, 31-Oct-08, 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. "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers", Tomohiro Otani, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia, 14-Jul-08, 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, Nabil Bitar, 11-Jun-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, 8-Aug-08, 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-Nov-08, 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 currently does not include optical impairments. Cga & Send maIntenance (csi) ---------------------------- "SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 3-Nov-08, 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 SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc3280] 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, 20-Oct-08, Neighbor Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to Neighbor advertise 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. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, 4-Nov-08, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally Floyd, Arjuna Sathiaseelan, Intellectual Property, 14-Jul-08, TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. This document introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with TFRC and with TFRC-SP, the Small Packet variant of TFRC. We present Faster Restart in general terms as a congestion control mechanism, and further discuss Faster Restart for Datagram Congestion Control Protocol (DCCP) Congestion Control IDs 3 and 4. "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, 29-Sep-08, 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. "DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", Gorry Fairhurst, 8-Oct-08, 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, 5-Sep-08, 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 and CCID-3. Quick-Start enables a DCCP sender to cooperate with any Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start 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, 8-Jul-08, 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, 8-Jul-08, 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. "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. "Guidelines for Creating New DHCP Options", David Hankins, 14-Oct-08, 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, 17-Nov-08, 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, 1-Oct-08, 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 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 Layer 2 Relay Agent is in use and also how it handles DHCP messages. "DHCPv6 Bulk Leasequery", Mark Stapp, 16-Oct-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 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 Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. "Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund Kamath, Stefaan De Cnodder, 14-Jun-08, 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, 30-Sep-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, 18-Nov-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes a new option for DHCPv6 to convey information, required for network booting, to the nodes. "DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 20-Oct-08, 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. Diameter Maintenance and Extensions (dime) ------------------------------------------ "The Diameter API", Pat Calhoun, David Frascone, 28-Jul-08, 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, 27-Oct-08, 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 (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of 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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", Jouni Korhonen, Julien Bournelle, Hannes Tschofenig, Charles Perkins, Kuntal Chowdhury, 19-Nov-08, A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 2-Nov-08, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. "Diameter Quality of Service Application", Dong Sun, Peter McCann, Hannes Tschofenig, Tina Tsou, Avri Doria, Glen Zorn, 13-Jul-08, 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, 13-Jul-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 the AAA Framework", Jouni Korhonen, Hannes Tschofenig, 3-Nov-08, This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. "Quality of Service Attributes for Diameter", Jouni Korhonen, Hannes Tschofenig, Mayutan Arumaithurai, Mark Jones, Avi Lior, 28-Oct-08, 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. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Service Overview", Tony Hansen, Dave Crocker, Phillip Hallam-Baker, 11-Jul-08, 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 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. "DKIM Author Domain Signing Practices (ADSP)", agent Local-part, Eric Allman, Jim Fenton, Mark Delany, John Levine, 19-Sep-08, 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, Phillip Hallam-Baker, Dave Crocker, Ellen Siegel, 3-Nov-08, DomainKeys Identified Mail (DKIM) allows an organization to take 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. Detecting Network Attachment (dna) ---------------------------------- "Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 Design)", Sathya Narayanan, James Kempf, Erik Nordmark, Brett Pentland, JinHyeock Choi, Greg Daley, Nicolas Montavont, 11-Jul-08, Efficient detection of network attachment in IPv6 needs the following three components: a method for hosts to detect link change in the presence of unmodified (non-DNAv6) routers, a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes it difficult to receive an RA quickly. In this memo, a mechanism that was developed for detection of network attachement is documented for future reference. This memo is an informational document and thus does not define a new standard. The mechanism proposed in this informational RFC requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link- identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministically is also presented. "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", Greg Daley, Erik Nordmark, 13-Jul-08, 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, 3-Nov-08, 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, 14-Jul-08, 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. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, Peter Koch, Jakob Schlyter, 14-Jul-08, This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. It is a snapshot of the DNSEXT working group discussion of June 2004. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 14-Jul-08, This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 14-Jul-08, Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", Jelte Jansen, 23-Oct-08, 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, 16-Jul-08, 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. "Measures for making DNS more resilient against forged answers", Bert Hubert, Remco Mook, 17-Nov-08, The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. "Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records", Francis Dupont, 19-Nov-08, The main goal 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). Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 14-Jul-08, With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. "Locally-served DNS Zones", Mark Andrews, 10-Jul-08, Experience has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should, unless configured otherwise, automatically serve. 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. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, 14-Jul-08, This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. "DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 14-Jul-08, 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, 3-Sep-08, Management of name servers for the Domain Name Service (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 a 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 DNS name servers. A management solution that is designed to manage the DNS can use this document as a shopping list of needed features. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Consolidated Provisioning Problem Statement", David Schwartz, Rohan Mahy, Alan Duric, Edward Lewis, 7-Jul-08, This document describes the type of data provisioned among Voice Service Providers and underscores the need for clearly defined structures and interfaces to facilitate this provisioning. This work is in support of the service provider peering as defined by the SPEERMINT WG. Email Address Internationalization (eai) ---------------------------------------- "Downgrading mechanism for Email Address Internationalization", Kazunori Fujiwara, Yoshiro Yoneya, 16-Sep-08, Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. "IMAP Support for UTF-8", Pete Resnick, Chris Newman, 3-Nov-08, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. "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. "Displaying Downgraded Messages for Email Address Internationalization", Kazunori Fujiwara, 16-Oct-08, This document describes how to display downgraded messages which originally contain internationalized E-mail addresses or internationalized header fields. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne, 29-Sep-07, 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, 3-Nov-08, 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, 10-Jul-08, The IETF has several efforts targeted at standardizing 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) Servers", Henning Schulzrinne, Hannes Tschofenig, 3-Nov-08, The LoST (Location-to-Service Translation) protocol is used to map locations to service URLs. This document defines a set of LoST extensions that allow LoST servers to synchronize their lists of mappings. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 27-Oct-08, 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) ----------------------- "EAP Generalized Pre-Shared Key (EAP-GPSK) Method", Charles Clancy, Hannes Tschofenig, 19-Nov-08, This Internet Draft defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. "Requirements for an Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna, Hao Zhou, Joseph Salowey, 31-Oct-08, 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. Telephone Number Mapping (enum) ------------------------------- "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 20-Nov-08, This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. It does not revise the standards, but it is intended to provide technical input to future revisions of those documents. "IANA Registration for IAX Enumservice", Ed Guy, 17-Jun-08, 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, 21-Nov-08, 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. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", Jason Livingood, 3-Dec-07, This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa" as defined in RFC3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). "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. "Combined User and Infrastructure ENUM in the e164.arpa tree", Michael Haberler, Otmar Lendl, Richard Stastny, 22-Oct-07, This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after approval and implementation of the long-term solution. "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, 31-Mar-08, 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. "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". "IANA Registration for an Enumservice Trunkgroup", Richard Shockey, Tom Creighton, 7-Jul-08, This document registers the Enumservice 'trunk' and subtypes 'sip' and 'tel' using the URI schemes 'sip:' and 'tel:' as per the IANA registration process defined in the ENUM specification RFC 3761 [RFC7761]. RFC 4904 [RFC4904] defines a technique for the conveyance of carrying trunking information in SIP [RFC3261] and or TEL [RFC3966] URI's. This Enumservice provides a mechanism for ENUM databases residing in service provider networks a mechanism to query for that data. FEC Framework (fecframe) ------------------------ "Forward Error Correction (FEC) Framework", Mark Watson, 24-Oct-08, This document describes for a framework for using forward error correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. "SDP Elements for FEC Framework", Ali Begen, 3-Nov-08, This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. "Methods to convey FEC Framework Configuration Information", Rajiv Asati, 3-Nov-08, FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 27-Oct-08, 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 as a part of the DVB Application- layer FEC Specification. "DVB Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer, 29-Aug-08, 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. "Raptor FEC Schemes for FECFRAME", Mark Watson, 24-Oct-08, This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor code and its application to reliable delivery of media streams in the context of FEC Framework. The Raptor code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor code offers a close to optimal protection against arbitrary packet losses at a low computational complexity. Two FEC Schemes are defined, one for protection of arbitrary packet flows and another for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. An RTP Payload Type is defined for this latter case. "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", Ulas Kozat, Ali Begen, 26-Oct-08, 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 Non-Interleaved and Interleaved Parity FEC", Ali Begen, 27-Oct-08, This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, 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 non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. 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, 18-Nov-08, 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, 14-Jul-08, 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. 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, 26-Jun-08, 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, 3-Nov-08, 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 PIDF-LO Usage Clarification, Considerations and Recommendations", James Winterbottom, Martin Thomson, Hannes Tschofenig, 17-Sep-08, The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that is mandatory to implement by applications involved in location based routing. "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", Rohan Mahy, Brian Rosen, 3-Nov-08, This document describes filters which limit asynchronous location notifications to compelling events. The resulting location information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO) "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 29-Jun-08, 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, 29-Oct-08, 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, 3-Nov-08, 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, 30-Oct-08, A method is described for the discovery of a Location Information Server. The method uses a Dynamic Host Configuration Protocol (DHCP) option. DHCP options are defined for both IPv4 and IPv6 DHCP. A URI-enabled NAPTR (U-NAPTR) method is described for use where the DHCP option is unsuccessful. This document defines a U-NAPTR Application Service for a LIS, with a specific Application Protocol for the HTTP Enabled Location Delivery (HELD) protocol. "Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform Resource Identifier (URI)", James Polk, 3-Nov-08, 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, 26-Oct-08, 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", Karl Wolf, Alexander Mayrhofer, 27-Oct-08, This document provides a guideline for creating civic address consideration documents for individual countries, as required by RFC 4776. Since civic addresses may have a different format in individual countries, such address considerations are necessary in order to map the civic address fields to the PIDF Location Object (PIDF-LO) elements. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 14-Jul-08, 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, 19-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. Host Identity Protocol (hip) ---------------------------- "Basic HIP Extensions for Traversal of Network Address Translators", Miika Komu, Tom Henderson, Philip Matthews, Hannes Tschofenig, Ari Keraenen, 31-Oct-08, 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. "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Miika Komu, Tom Henderson, 14-Jul-08, This document defines extensions to the current sockets API for Host Identity Protocol (HIP). The extensions focus on the use of public- key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in document are experimental and provide basic tools for futher experimentation with policies. "HIP Certificates", Tobias Heer, Samu Varjonen, 21-Oct-08, This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates. It is used for carrying these certificates in HIP control messages. Additionally, this document specifies the representations of Host Identity Tags in SPKI and X.509.v3 certificates. "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment", Gonzalo Camarillo, Pekka Nikander, Jani Hautakorpi, Alan Johnston, 27-Oct-08, 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) ----------------------- "Derivation, delivery and management of EAP based keys for handover and re-authentication", Yoshihiro Ohba, 19-Oct-08, This document describes a mechanism for delivering a usage-specific root key (USRK), a domain-specific root key (DSRK) and a usage- specific domain-specific root key (USDSRK) using RADIUS. The root keys are derived as part of an Extended Master Session Key (EMSK) hierarchy in Extensible Authentication Protocol (EAP), and delivered from a server to an intended third-party key holder. The mechanism supports different scenarios for key delivery, depending on the type of keys being delivered. The mechanism description includes the definition for a key distribution exchange (KDE) protocol. "EAP Pre-authentication Problem Statement", Yoshihiro Ohba, 9-Sep-08, 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, 17-Nov-08, 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 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, 17-Nov-08, 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, 17-Nov-08, 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, 17-Nov-08, 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, 17-Nov-08, 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, 17-Nov-08, 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 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, 17-Nov-08, 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, 13-Jul-08, 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, 29-Aug-08, This document registers those Hypertext Transfer ProtocolHypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. Internet Architecture Board (iab) --------------------------------- "Defining the Role and Function of IETF Protocol Parameter Registry Operators", Geoff Huston, 22-Oct-08, Many IETF protocols make use of commonly defined values that are passed within protocol objects. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intent. For each IETF protocol parameter it is current practice for the IETF to delegate the role of protocol parameter registry operator to a nominated entity. This document provides a description of and the requirements for these delegated functions. "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, Peter Koch, 11-Aug-08, 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, 19-Nov-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, 3-Nov-08, 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, 2-Nov-08, This document supplies the protocol definition for a revised and updated specification for internationalized domain names (IDNs). The rationale for these changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalizing Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. "An updated IDNA criterion for right-to-left scripts", Harald Alvestrand, Cary Karp, 30-Jul-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 criterion for IDNA labels. "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", John Klensin, 18-Nov-08, 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, 2-Nov-08, 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, Danny McPherson, 20-Nov-08, 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. "Capabilities Advertisement with BGP-4", John Scudder, Ravi Chandra, 18-Nov-08, This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. "Textual Representation of AS Numbers", Geoff Huston, George Michaelson, 22-Sep-08, A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS Number. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. "AS Number Reservation for Documentation Use", Geoff Huston, 3-Oct-08, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. IP over Cable Data Network (ipcdn) ---------------------------------- "Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices", Sumanth Channabasappa, Intellectual Property, 17-Aug-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 defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. De Ketelaere/Nechamkin/Channabasappa Expires - February 2009 [page 1] PacketCable/IPCablecom Event management MTA MIB August 2008 IP over DVB (ipdvb) ------------------- "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Prashant Pillai, Michael Noisternig, 23-Aug-08, The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a range of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. IP Flow Information Export (ipfix) ---------------------------------- "Architecture for IP Flow Information Export", Ganesh Sadasivan, 10-Sep-06, This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP flows, and for the export of measured IP flow information from an IPFIX device to a collector. "IPFIX Applicability", Tanja Zseby, 3-Jul-07, In this document we describe the applicability of the IP Flow Information Export (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant information elements (IEs) for those applications and present opportunities and limitations of the protocol. We furthermore describe relations of the IPFIX framework to other architectures and frameworks. "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", Elisa Boschi, 21-May-07, This document describes a bandwidth saving method for exporting flow or packet information using the IP Flow Information Export (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several flow records from information specific to an individual flow record. Common flow information is exported only once in a data record defined by an option template, while the rest of the specific flow information is associated with the common information via a unique identifier. "Guidelines for IP Flow Information eXport (IPFIX) Testing", Carsten Schmoll, Paul Aitken, Benoit Claise, 16-Apr-08, This document presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, 3-Nov-08, 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-Jul-08, This document describes an extension to IPFIX 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, facilitating interoperability and reusability among a wide variety of applications and tools. "IPFIX Mediation: Problem Statement", Atsushi Kobayashi, Haruhiko Nishida, Christoph Sommer, Falko Dressler, Emile Stephan, Benoit Claise, 26-Sep-08, Flow-based measurement is currently a popular method for various network monitoring usages. The sharing of flow-based information among orthogonal monitoring applications raises open issues in terms of scalability, reliability and flexibility that IPFIX Mediation may help resolve. IPFIX Mediation reroutes, replicates, filters, aggregates, correlates or modifies Flow Records or Packet Reports, or changes a transport protocol. This document describes the applicability of IPFIX Mediation and the problems that IPFIX Mediation might encounter. "IPFIX Mediation: Framework", Atsushi Kobayashi, Haruhiko Nishida, Benoit Claise, 3-Nov-08, This document describes a framework for an IPFIX Mediation. This framework details an IPFIX Mediation reference model and the components of the IPFIX Mediation device (IPFIX Mediator). "IPFIX Export per SCTP Stream", Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, 3-Nov-08, 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, 3-Nov-08, This document specifies a data model for the configuration of caches, selection processes, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data model 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. A YANG-to-XSD converter is available which allows generating an XML Schema Definition (XSD) of the data model. IP Performance Metrics (ippm) ----------------------------- "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, Lei Liang, Al Morton, 15-Oct-08, 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, 13-Jul-08, This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. "Framework for Metric Composition", Al Morton, 29-Oct-08, This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics which are useful in practice. "Reporting IP Performance Metrics to Users", Stanislav Shalunov, Martin Swany, 14-Jul-08, 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. "Information Model and XML Data Model for Traceroute Measurements", Saverio Niccolini, Sandra Tartarelli, Juergen Quittek, Thomas Dietz, Martin Swany, 23-Oct-08, This document describes a standard way to store the configuration and the results of traceroute measurements. This document first of all describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined dividing the information elements in two semantically separated groups (configuration elements and results elements). Moreover an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model a data model based on XML is defined to store the results of traceroute measurements. "A One-Way Packet Duplication Metric", Henk Uijterwaal, 7-Oct-08, 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. "Packet Delay Variation Applicability Statement", Al Morton, Benoit Claise, 13-Jul-08, Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions. Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. "More Features for TWAMP", Al Morton, Kaynam Hedayat, 20-Oct-08, The IETF has completed its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a simple extension to TWAMP, the option to use different security modes in the TWAMP- Control and TWAMP-Test protocols. "TWAMP Reflect Octets Feature", Al Morton, Len Ciavattone, 26-Oct-08, 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, 27-Oct-08, 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 their 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, 30-Oct-08, 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. "Re-direct Mechanism for IKEv2", Vijay Devarapalli, Kilian Weniger, 3-Nov-08, IKEv2 is a popular 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 to re- direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. "Wrapped ESP for Traffic Visibility", Ken Grewal, Gabriel Montenegro, 22-Oct-08, This document describes an ESP encapsulation for IPsec, allowing 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. "IKEv2 Session Resumption", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 17-Nov-08, 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 (SA) 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 uses a IKEv2 state (or a reference into a state store). to store state information that is later made available to the IKEv2 responder for re-authentication. Restoring state information by utilizing a ticket is one possible way. 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 Policy (ipsp) ------------------------- "IPsec Security Policy IPsec Action MIB", Wesley Hardaker, 10-Nov-06, This document defines an SMIv2 Management Information Base (MIB) module for configuring IPsec actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IPSec protocol actions on that device. The IPsec Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. "IPsec Security Policy IKE Action MIB", Wesley Hardaker, 10-Nov-06, This document defines a SMIv2 Management Information Base (MIB) module for configuring Internet Key Exchange (IKE) actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IKE protocol actions on that device. The IPsec IKE Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. IS-IS for IP Internets (isis) ----------------------------- "IPv6 Traffic Engineering in IS-IS", Jon Harrison, 26-Jun-08, 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. "Simplified Extension of LSP Space for IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, Danny McPherson, 18-Nov-08, This draft describes a simplified method for extending the LSP space beyond the 256 Link State PDU (LSP) limit defined in [IS-IS]. This method is intended as a preferred replacement for the method defined in [RFC 3786]. "IS-IS Generic Cryptographic Authentication", Manav Bhatia, 18-Nov-08, This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. "Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, 20-Jun-08, This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and defines guidelines which SHOULD be used when flooding such information. "IS-IS Multi-Instance", Stefano Previdi, Les Ginsberg, Mike Shand, David Ward, Abhay Roy, 29-Oct-08, This draft describes a mechanism that allows a single router to share one or more links among multiple IS-IS routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies, exchange instance specific routing updates and compute paths utilizing instance specific LSDB information. Each PDU will contain a new TLV identifying the instance to which the PDU belongs. This allows a network operator to deploy multiple IS-IS instances in parallel, using the same set of links when required and still have the capability of computing instance specific paths. This draft does not address the forwarding paradigm that needs to be used in order to ensure data PDUs are forwarded according to the paths computed by a specific instance. Integrated Security Model for SNMP (isms) ----------------------------------------- "Secure Shell Transport Model for SNMP", David Harrington, Joseph Salowey, Wesley Hardaker, 3-Nov-08, 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, 31-Oct-08, 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, 31-Oct-08, 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, 12-Oct-08, This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by 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, 3-Nov-08, 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. "Portable Symmetric Key Container", Mingliang Pei, Salah Machani, Philip Hoyer, 3-Nov-08, 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. This work is based on earlier work by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "Symmetric Key Package Content Type", Sean Turner, Russ Housley, 14-Jul-08, 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. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- "Generic Security Service API Version 2 : Java Bindings Update", Mayan Upadhyay, Seema Malkani, 8-Jul-08, 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). "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 23-Sep-08, 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 Naming Extensions", Nicolas Williams, Leif Johansson, 13-Jul-08, 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) ----------------- "Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals", Kenneth Raeburn, Larry Zhu, 14-Jul-08, The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. "Kerberos Set/Change Key/Password Protocol Version 2", Nicolas Williams, 3-Nov-08, This document specifies an extensible protocol for setting keys and changing the passwords of Kerberos V principals. "A Generalized Framework for Kerberos Pre-Authentication", Larry Zhu, Sam Hartman, 13-Jul-08, 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 secret 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. "Anonymity Support for Kerberos", Larry Zhu, Paul Leach, 10-Oct-08, This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions which allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFC 4120, RFC 4121, and RFC 4556. "Additional Kerberos Naming Constraints", Larry Zhu, 12-Aug-08, This document defines new naming constraints for well-known Kerberos principal name and well-known Kerberos realm names. "PK-INIT algorithm agility", Love Astrand, Larry Zhu, 5-Aug-08, The PK-INIT defined in RFC 4556 is examined and updated to remove protocol structures tied to specific cryptographic algorithms. The affinity to SHA-1 as the checksum algorithm in the authentication request is analyzed. The PK-INIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide protection preemptively against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. "Kerberos Version 5 GSS-API Channel Binding Hash Agility", Shawn Emery, 3-Nov-08, Currently, channel bindings are implemented using a MD5 hash in the Kerberos Version 5 Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC4121]. This document updates RFC4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. "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, 15-Sep-08, 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. "Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)", Larry Zhu, Jeffrey Altman, 3-Nov-08, This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. "An information model for Kerberos version 5", Leif Johansson, 2-Nov-08, 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. Layer 1 Virtual Private Networks (l1vpn) ---------------------------------------- "OSPFv3 Based Layer 1 VPN Auto-Discovery", Lou Berger, 8-Aug-08, This document defines an Open Shortest Path First (OSPF) version 3 based Layer-1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)", Carlos Pignataro, 10-Jul-08, This document describes the use of "version 3" of Layer Two Tunneling Protocol (L2TPv3) to tunnel Point-to-Point Protocol (PPP) packets. This document defines the control protocol and encapsulation specifics for tunneling PPP over L2TPv3, and is a companion document to the L2TPv3 base specification. "Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur, Alexander Vainshtein, 29-Oct-08, This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for support of structure-agnostic and structure-aware TDM pseudowires. "L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro, 19-Nov-08, 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 Access Circuits and Pseudowires. It also deprecates the use of the New bit in the "Circuit Status" AVP, updating RFC3931. 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. "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, Yuichiro Wada, Yetik Serbest, Thomas Morin, Luyuan Fang, 5-Aug-08, This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. "Multicast in VPLS", Rahul Aggarwal, Yuji Kamite, Luyuan Fang, Yakov Rekhter, Intellectual Property, 2-Jun-08, This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSs are also described. "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. "Virtual Private Lan Services (VPLS) Management Information Base", Rohit Mediratta, Thomas Nadeau, Kiran Koushik, 15-Jul-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 Virtual Private LAN services. It needs to be used in conjunction with Pseudo Wire (PW) Management Information Base [PWE3-PW-MIB]. 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, 10-Jul-08, 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, Intellectual Property, 16-Jun-08, 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]. "Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", Kenji Kumaki, Yuji Kamite, Raymond Zhang, 3-Nov-08, Some service providers want to build a service which guarantees QoS or bandwidth from a local CE to a remote CE through the network. Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. As a result, their requirements for end-to-end QoS of applications are increasing. Depending on the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end native RSVP path and/or an end-to-end MPLS TE LSP are required, and they need to meet some constraints. This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS VPN. "Four-octet AS Specific BGP Extended Community", Yakov Rekhter, Srihari Sangli, Dan Tappan, 27-Oct-08, 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, 29-Sep-08, Current specifications of BGP Extended Communities [BGP-EXTCOMM] 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. "BGP ACCEPT_OWN Standards Action Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, Intellectual Property, 5-Oct-08, Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 2-Nov-08, Many Service Providers (SPs) offer the 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. "Considerations about Multicast for BGP/MPLS VPN Standardization", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 18-Nov-08, The current proposal for multicast in BGP/MPLS includes multiple alternative mechanisms for some of the required building blocks of the solution. The aim of this document is to leverage previously documented requirements to identify the key elements and help move forward solution design, toward the definition of a standard having a well defined set of mandatory procedures. The different proposed alternative mechanisms are examined in the light of requirements identified for multicast in L3VPNs, and suggestions are made about which of these mechanisms standardization should favor. Issues related to existing deployments of early implementations are also addressed. 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, 30-Sep-08, This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. "Internet Message Store Events", Randall Gellens, Chris Newman, 2-Nov-08, One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. This document describes events and event parameters which are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. "Streaming Internet Messaging Attachments", Neil Cook, 26-Sep-08, 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 IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). "IMAP4 extension for named searches (filters)", Alexey Melnikov, Curtis King, 22-Sep-08, The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criteria as a parameter. "The IMAP NOTIFY Extension", Arnt Gulbrandsen, Alexey Melnikov, Curtis King, 19-Aug-08, This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. [[Add Updates: RFC-CONTEXT to the headers]] "LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail", Eric Burger, Glenn Parsons, 3-Nov-08, This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) work group in the IETF. This document also describes how the LEMONADE architecture meets the OMA's requirements for their Mobile Email (MEM) service. "Extended URLFETCH for binary and converted parts", Dave Cridland, 4-Sep-08, The URLFETCH command defined as part of URLAUTH provides a mechanism for third-parties to gain access to data held within messages in a user's private store, however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. "IMAP4 Extensions for Quick Mailbox Resynchronization", Alexey Melnikov, Dave Cridland, Corby Wilson, 19-Oct-08, This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-term Archive Protocol (LTAP)", Aleksej Jerman-Blazic, Peter Sylvester, Carl Wallace, 2-Nov-08, This document describes a service operated as a trusted third party to securely archive electronic documents called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)", Thomas Kunz, Susanne Okunick, Ulrich Pordesch, 3-Nov-08, In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability of cryptographic algorithms. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 31-Oct-08, 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, 1-Nov-08, 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. Multicast & Anycast Group Membership (magma) -------------------------------------------- "Multicast Group Membership Discovery MIB", Julian Chesterfield, 16-Sep-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 objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic MANET On-demand (DYMO) Routing", Ian Chakeres, Charles Perkins, 17-Nov-08, 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. "Simplified Multicast Forwarding for MANET", Joseph Macker, SMF Team, 3-Nov-08, This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF specifies techniques for multicast duplicate packet detection (DPD) to assist the forwarding process. SMF also specifies DPD maintenance and checking operations for with both IPv4 and IPv6. SMF also specifies the optional use of reduced relay sets for efficient MANET multicast data distribution within a mesh topology. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, 10-Jul-08, 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). The key optimization in OLSRv2 is that of multipoint relays (MPRs), providing an efficient mechanism for network-wide broadcast of link state information (i.e. reducing the cost of performing a network- wide link state broadcast). A secondary optimization is that OLSRv2 employs partial link state information; each node maintains information about all destinations, but only a subset of links. Consequently, only selected nodes flood link state advertisements (thus reducing the number of network-wide link state broadcasts) and these advertisements contain only a subset of links (thus reducing the size of network-wide link state broadcasts). The partial link state information thus obtained still allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements on the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works best in this context. "Generalized MANET Packet/Message Format", Thomas Clausen, Christopher Dearlove, Justin Dean, Cedric Adjih, 18-Nov-08, This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. "MANET Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, Christopher Dearlove, Justin Dean, 10-Jul-08, This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). "IANA Allocations for MANET Protocols", Ian Chakeres, 18-Nov-07, This document enumerates several common IANA allocations for use by MANET protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. "Representing multi-value time in MANETs", Thomas Clausen, Christopher Dearlove, 26-Sep-08, This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized MANET packet/message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. "Definition of Managed Objects for the DYMO Manet Routing Protocol", Sean Harnedy, Robert Cole, Ian Chakeres, 3-Nov-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 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. MBONE Deployment (mboned) ------------------------- "Automatic IP Multicast Without Explicit Tunnels (AMT)", Dave Thaler, Mohit Talwar, Amit Aggarwal, Lorenzo Vicisano, Tom Pusateri, 27-Jun-08, Automatic Multicast Tunneling (AMT) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure and does not require any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers. "IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton, Dave Meyer, 3-Nov-08, This document obsoletes RFC 3171. It provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. "Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)", Haixiang He, 20-Jun-08, 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", Hiroaki Satou, 2-Jul-08, 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. "Lightweight IGMPv3 and MLDv2 Protocols", Hui Liu, Wei Cao, Hitoshi Asaeda, 6-Sep-08, This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. "Multicast Ping Protocol", Stig Venaas, 3-Nov-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 like multicast tree setup time etc. 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, 3-Nov-08, 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, 27-Oct-08, 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 useful and easy to use, but difficult to control the SAP message transmission in a wide area network. This document describes the several 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, 31-Oct-08, This document describes a Framework and protocol for application deployment where the application programming logic and 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, 17-Apr-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-Jul-08, 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, 3-Nov-08, 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", Tim Melanchuk, Scott McGlashan, Chris Boulton, 3-Nov-08, This document defines a Mixer Control Package for the Media Control Channel Framework. This Control Package aims to fulfill Conferencing requirements using the SIP Control Framework. Mobility EXTensions for IPv6 (mext) ----------------------------------- "Multiple Care-of Addresses Registration", Ryuji Wakikawa, Vijay Devarapalli, Thierry Ernst, Kenichi Nagami, 3-Nov-08, 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. "Home Agent Reliability Protocol", Ryuji Wakikawa, 14-Jul-08, The home agent can be a single point of failure when Mobile IPv6 is operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. "RADIUS Mobile IPv6 Support", Avi Lior, Kuntal Chowdhury, Hannes Tschofenig, 3-Nov-08, This document defines new attributes to facilitate Mobile IPv6 operations using RADIUS infrastructure. The operations include bootstrapping of information required by the Mobile Node and the interface between the Network Access Server, Home Agent and the RADIUS server used to assist MIP6 operations. "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, 3-Nov-08, 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. "NEMO Management Information Base", Sri Gundavelli, Glenn Mansfield, Kazuhide Koide, Kenichi Nagami, 20-Nov-08, This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. "Automotive Industry Requirements for NEMO Route Optimization", Roberto Baldessari, Thierry Ernst, Andreas Festag, Massimiliano Lenardi, 14-Jul-08, 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). "Mobility Support in IPv6", David Johnson, Charles Perkins, Jari Arkko, 1-Oct-08, 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, 3-Nov-08, 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, 28-Aug-08, This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client 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. "Mobile IPv6 Generic Signaling Message", Brian Haley, Sri Gundavelli, 14-Aug-08, This document specifies two new Mobility Header message types that allow Mobile IPv6 entities to send and receive generic signaling messages. Haley Expires - January 2008 [page 1] Mobile IPv6 Generic Signaling Message August 2008 "Guidelines for firewall administrators regarding MIPv6 traffic", Suresh Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko, 10-Oct-08, This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. "Guidelines for firewall vendors regarding MIPv6 traffic", Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko, 10-Oct-08, This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6. Mobility for IPv4 (mip4) ------------------------ "The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised", Kent Leung, Ravindra Rathi, Hans Sjostrand, 7-Aug-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 used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. "IP Mobility Support for IPv4, revised", Charles Perkins, 2-Nov-08, This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. "Dual Stack Mobile IPv4", George Tsirtsis, Vincent Park, Hesham Soliman, 18-Nov-08, This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. "Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz, Vijay Devarapalli, Sri Gundavelli, Brian Haley, 3-Nov-08, 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. "Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, Vincent Park, Vidya Narayanan, Kent Leung, 29-Aug-08, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. "The Definitions of Managed Objects for Mobile IP UDP Tunneling", Hans Sjostrand, 11-Aug-08, 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. "Why Authentication Data suboption is needed for MIP6", Basavaraj Patil, Gopal Dommety, 2-Nov-08, Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism was needed for Mobile IPv6 deployment in certain environments. "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, 3-Nov-08, 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. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Server (MoS) discovery", Gabor Bajko, Subir Das, 18-Nov-08, This document defines a number of Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of domain names or IP addresses that can be mapped to servers providing IEEE 802.21 type of Mobility Services [MSFD]. These Mobility Services are used to assist an 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, 27-Oct-08, 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, 27-Oct-08, 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. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 3-Nov-08, This memorandum defines RTSP version 2.0 which is a revision of the Proposed Standard RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "An Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg, Magnus Westerlund, Thomas Zeng, 14-Jul-08, This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. "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", Kaynam Hedayat, 4-Aug-08, 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, 24-Oct-08, 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. "TCP Candidates with Interactive Connectivity Establishment (ICE)", Jonathan Rosenberg, 14-Jul-08, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Miguel Garcia, Markus Isomaki, Gonzalo Camarillo, Salvatore Loreto, Paul Kyzivat, 3-Nov-08, This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. "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, 14-Jul-08, 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. "The evaluation of different NAT traversal Techniques for media controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 11-Jul-08, This document describes several NAT traversal techniques that could be used by RTSP. Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP solution to standardize in the MMUSIC WG. "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", James Polk, Subha Dhesikan, Gonzalo Camarillo, 18-Nov-08, The offer/answer model for SDP assumes that endpoints establish somehow the QoS required for the media streams they establish. Endpoints in closed environments typically agree out of band (e.g., using configuration information) which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. "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, 20-Nov-08, 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 streamsas 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, 9-Jun-08, 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, 14-Jul-08, 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, 6-Jul-08, 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. Multiprotocol Label Switching (mpls) ------------------------------------ "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, Thomas Nadeau, Kiran Koushik, 29-Sep-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 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, 17-Nov-08, 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. "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", Seisho Yasukawa, Adrian Farrel, Zafar Ali, Bill Fenner, George Swallow, Thomas Nadeau, 10-Sep-08, Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. "Component Link Recording and Resource Control for TE Link Bundles", Intellectual Property, 6-Jul-08, 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 Janury 2009 [page 1] Component Link Record. & Resource Control for TE Link Bundles Jul.2008 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, 30-Jun-08, 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. "MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 8-Jul-08, This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. "MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux, 8-Jul-08, This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. "Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module", Adrian Farrel, Seisho Yasukawa, Thomas Nadeau, 30-Apr-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 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. "Proxy LSP Ping", George Swallow, Vanson Lim, 3-Nov-08, This document defines a means of remotely initiating Multiprocal Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to root tracing.Contents "LDP Capabilities", Bob Thomas, 26-Mar-08, 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. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document provides guidelines for advertising LDP enhancements at session initialization time. It also defines 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, 18-Aug-08, 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, 2-Nov-08, 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. Fang, et al. Informational [page 1] MPLS/GMPLS Security framework November 2008 "Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", Zafar Ali, George Swallow, 19-Jun-08, Expires December 2008 [page 1] Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt 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. "An Analysis of Scaling Issues in MPLS-TE Core Networks", Seisho Yasukawa, Adrian Farrel, Olufemi Komolafe, 19-Jun-08, Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies, and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study. "LDP IGP Synchronization", Luyuan Fang, 3-Nov-08, In certain networks there is a dependency on edge-to-edge LSPs setup by LDP, e.g. networks that are used for MPLS VPN applications. For such applications it is not possible to rely on IP forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the IGP is operational on a link but LDP is not operational on that link. While the link could still be used for IP forwarding, it is not useful for MPLS M. Jork, A. Atlas, and L. Fang [page 1] LDP IGP Synchronization November 2008 forwarding, for example, MPLS VPN; BGP route free core; or IP address carried in the packet is out of the RFC1918 space. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. ""EXP field" renamed to "Traffic Class field"", Loa Andersson, Rajiv Asati, 17-Nov-08, The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. . To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field".) In doing so it also updates documents that define the current use of the EXP this field. "Mechanism for performing LSP-Ping over MPLS tunnels", Nitin Bahadur, Kireeti Kompella, George Swallow, 21-Sep-08, 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, Bob Thomas, Emily Chen, 15-Sep-08, 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, 19-Sep-08, 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) 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, 20-Nov-08, This document specifies the requirements for a MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union (ITU)-IETF effort to include a MPLS Transport Profile within the IETF MPLS architecture 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 architecture as defined by IETF and packet transport networks as defined by ITU-T. Multicast Security (msec) ------------------------- "Multicast Extensions to the Security Architecture for the Internet Protocol", Brian Weis, George Gross, Dragan Ignjatic, 6-Jun-08, The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. "Use of TESLA in the ALC and NORM Protocols", Vincent Roca, Aurelien Francillon, Sebastien Faurite, 22-Oct-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, 9-Jun-08, 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, 3-Nov-08, 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, Paul Sangster, 9-Oct-08, 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) ------------------------------- "NETCONF over Transport Layer Security (TLS)", Mohamad Badra, Ibrahim Hajjeh, 22-Oct-08, The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. "Partial Lock RPC for NETCONF", Balazs Lengyel, Martin Bjorklund, 31-Oct-08, 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, 3-Nov-08, This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this monitoring data provides clients with standardized content to describe supported schema. Today, NETCONF capabilities exchange is the only standardized method a client can use to discover the functionality supported by a NETCONF server. This works well for static protocol capabilities but is not well suited for capabilities which could change during a session. Considerations such as different schema formats, feature optionality and access controls can all impact the applicability and level of detail the NETCONF server sends to a client during session setup. Through updated monitoring data NETCONF clients can adjust their capabilities throughout a session. Specifically the details returned can be used by a client to determine whether retrieval of new schema information is required and includes the information required to facilitate the retrieval. A new RPC (get-schema) is also defined to support explicit schema retrieval via NETCONF. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "IPv4 Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, 23-Sep-08, This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) extending 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, 21-Nov-08, This document defines a new Mobility Option for allowing the mobile access gateway and the local mobility anchor to negotiate GRE 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 mobile node session or a specific flow. "Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Rajeev Koodli, Heeseon Lim, Nishi Kant, Suresh Krishnan, Julien Laganier, 30-Sep-08, 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 and take appropriate action. "Interactions between PMIPv6 and MIPv6: scenarios and related issues", Gerardo Giaretta, 17-Nov-08, 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 reccomendations to enable these scenarios are also described. NETCONF Data Modeling Language (netmod) --------------------------------------- "YANG - A data modeling language for NETCONF", Martin Bjorklund, 3-Nov-08, 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, 3-Nov-08, This document introduces a collection of common data types to be used with the YANG data modeling language. Network File System Version 4 (nfsv4) ------------------------------------- "RPC: Remote Procedure Call Protocol Specification Version 2", Robert Thurlow, 30-Oct-08, This document describes the ONC (Open Network Computing) Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. This document obsoletes [RFC1831]. "NFS RDMA Problem Statement", Thomas Talpey, Chet Juszczak, Intellectual Property, 21-Feb-08, This draft addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead. The potential benefits of RDMA to these implementations are explored, and the reasons why RDMA is especially well-suited to NFS and network file protocols in general are evaluated. "Remote Direct Memory Access Transport for Remote Procedure Call", Thomas Talpey, Brent Callaghan, Intellectual Property, 16-Apr-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, Intellectual Property, 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, 5-Sep-08, This Internet-Draft describes NFS version 4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version one include: Sessions, Directory Delegations, and parallel NFS (pNFS). "pNFS Block/Volume Layout", David Black, Stephen Fridella, Jason Glasgow, 11-Jun-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, 19-Jun-08, This Internet-Draft provides a description of the object-based pNFS extension for NFSv4. This is a companion to the main pnfs specification in the NFSv4 Minor Version 1 Internet Draft, which is currently draft-ietf-nfsv4-minorversion1-23. "NFSv4 Minor Version 1 XDR Description", Spencer Shepler, Mike Eisler, David Noveck, 5-Sep-08, This Internet-Draft provides the XDR description for NFSv4 minor version one. "RPCSEC_GSS Version 2", Mike Eisler, 9-Oct-08, This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as Version 1 but adds support for channel bindings. "IANA Considerations for RPC Net Identifiers and Universal Address Formats", Mike Eisler, 19-Aug-08, 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. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, Andy Adamson, Jiaying Zhang, 26-Sep-08, The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. DNS SRV can be used to join these organization-wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. This document refreshes the draft. "Administration Protocol for Federated Filesystems", Daniel Ellard, Craig Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08, 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", Daniel Ellard, Craig Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08, This draft describes and lists the functional requirements of a federated file system and defines related terms. Our intent is to use this draft as a starting point and refine it, with input and feedback from the file system community and other interested parties, until we reach general agreement. We will then begin, again with the help of any interested parties, to define standard, open federated file system protocols that satisfy these requirements and are suitable for implementation and deployment. "NSDB Protocol for Federated Filesystems", Daniel Ellard, Craig Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08, 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 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. Individual Submissions (none) ----------------------------- "Salted Challenge Response (SCRAM) SASL Mechanism", Abhijit Menon-Sen, Alexey Melnikov, Chris Newman, 19-Nov-08, 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", Xiaoyi Liu, 26-Jun-08, 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. "LDAP Administrators Address Attribute", Mark Wahl, 6-Sep-07, Organizations with multiple or outsourced directory servers need the ability for administrators to determine who is responsible for a particular directory server. This document defines an attribute with contact information for a directory server's responsible party, conceptually similar to the 'sysContact' object of SNMP, which can be retrieved from the directory server using the Lightweight Directory Access Protocol. "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, 14-Jul-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. "Multicast in MPLS/BGP IP VPNs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 3-Jul-08, This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems. "The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers, 22-May-08, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [http://NMAH/]ark:/NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending a single question mark (`?'), returns a brief metadata record that is both human- and machine- readable. When the ARK is inflected by appending dual question marks (`??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. "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. "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. "URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 4-Sep-08, This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. "Analysis of Inter-Domain Routing Requirements and History", Elwyn Davies, Avri Doria, 8-Aug-08, 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.] "IMAP METADATA Extension", Cyrus Daboo, 18-Nov-08, The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. "An IPv4 Flowlabel Option", Thomas Dreibholz, 11-Jul-08, 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. "Advertisement of Multiple Paths in BGP", Daniel Walton, 14-Jul-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. "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, 4-Aug-08, 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). "Guidelines for Specifying the Use of IPsec Version 2", Steven Bellovin, 3-Aug-08, The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. "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. "DNS-Based Service Discovery", Stuart Cheshire, Marc Krochmal, 11-Sep-08, This document describes a convention for naming and structuring DNS resource records. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of that desired service, using standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 11-Jul-08, 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. "Early Retransmit for TCP and SCTP", Mark Allman, 25-Jun-08, 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. "The LDAP No-Op Control", Kurt Zeilenga, 14-Jul-08, This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 3-Nov-08, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "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. "A Set of Possible Requirements for a Future Routing Architecture", Avri Doria, Elwyn Davies, Frank Kastenholz, 15-Jun-08, 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. "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. "A Bound End-to-End Tunnel (BEET) mode for ESP", Pekka Nikander, Jan Melen, 5-Aug-08, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, Peter Lei, Michael Tuexen, 22-Oct-08, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. "Example call flows using SIP security mechanisms", Cullen Jennings, Kumiko Ono, 7-Jul-08, This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementers build interoperable SIP software. It is purely informational. To help facilitate interoperability testing, it includes certificates used in the example call flows and a CA certificate to create certificates for testing. This work is being discussed on the sip@ietf.org mailing list. "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", Aki Niemi, Krisztian Kiss, Salvatore Loreto, 22-Oct-08, 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). "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. "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", Hannes Tschofenig, Alper Yegin, Dan Forsberg, 14-Jul-08, The DHCP authentication extension (RFC 3118) cannot be widely deployed due to lack of a key agreement protocol. This document outlines how EAP-based network access authentication mechanisms can be used to establish bootstrap keying material that can be used to subsequently use RFC 3118 security. "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. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 21-Aug-08, 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. "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. "Nested Nemo Tree Discovery", Pascal Thubert, Caroline Bontoux, Nicolas Montavont, Ben McCarthy, 1-Aug-08, This paper describes a simple distance vector protocol that exposes only a default route towards the infrastructure in a nested NEMO configuration. The draft extends the Neighbor Discovery Protocol [1] in order to carry information and metrics which will help a Mobile Router select its Attachment Router(s) in an autonomous fashion and provides generic rules which guarantee that the interaction of different selection processes will not create loops. "Internet Mail Architecture", Dave Crocker, 31-Oct-08, 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. "RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, 17-Apr-07, 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. "IPv6 Label Switching Architecture", Sham Chakravorty, Jeff Bush, Jim Bound, 9-Jul-08, This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet transmission technique that uses the IPv6 packet header Flow Label to establish IPv6-based label switched paths. The label switched paths, called 6LSPs, provide application and user specified routes for efficient transport of packets and as means for quality of service (QoS) delivery, IPv4 tunneling, VPN and other mechanisms. Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses, the architecture may provide potential memory and processing savings, the latter through significantly reduced address fetches for the low- powered, handheld devices. The label has two components comprising Global Label value and Local Label value. The Global Label value from the source is delivered to the destination unmodified. However, the intermediate network nodes in 6LSA are allowed to temporarily replace the Local Label value with a value of local significance. This enables 6LSA flows to be hop-specific although session-based and as such a unique QoS delivery technique for bandwidth constrained media. 6LSA also enhances security since label generation and assignment algorithms can be modified periodically. Finally, it must be pointed out that the 6LSA concept of temporary flow label assignment is applicable to the 6LSA domain only. The concept is not applicable to domains outside the 6LSA. "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)". "Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 24-Oct-08, This memo defines a new message header field for use with electronic mail messages to indicate the results of message authentication efforts. Mail user agents (MUAs) may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 14-Jul-08, 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 HIP to host protocol stack, Internet infrastructure, and applications. The perspective of the network operator, as well as a list of HIP experiments are presented as well. "Common Intrusion Detection Signatures Standard", Adam Wierzbicki, Jacek Kalinski, Tomasz Kruszona, 4-Sep-08, The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided. "Network-Layer Signaling: Transport Layer", Melinda Shore, David McGrew, Kaushik Biswas, 13-Jul-08, The RSVP model for communicating requests to network devices along a datapath has proven useful for a variety of applications beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ. Network Layer Signaling uses the RSVP on-path communication model and provides a lightweight transport layer for non-QoS signaling applications, such as discovery or diagnostics. It is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol. "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 "Bounding Longer Routes to Remove TE", Susan Hares, 31-Jul-08, Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP [RFC1771] longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. "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. "Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont, Jean-Michel Combes, 2-Jun-08, This document defines a procedure which performs a "care-of address test" using a state cookie for routing optimization in Mobile IPv6 not protected by the routing routability procedure, i.e., protected by some alternative mechanisms like pre-shared secret or pre- established IPsec security associations. "Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 14-Jul-08, 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). "IPFIX Flow Aggregation", Falko Dressler, Christoph Sommer, Gerhard Muenz, Atsushi Kobayashi, 14-Jul-08, IPFIX Flow Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX Exporters) and analyzers (IPFIX Collectors). Aggregation techniques represent a necessary enhancement in order to cope with increasing amounts of monitoring data that accrue with the ever- growing network capacities. Using Flow Selection Criteria and Compound Flow creation techniques, measurement information of multiple Flows that are sharing some common criteria is merged to be exported in one Compound Flow. Subsets of Flows eligible for aggregation, as well as the desired degree of similarity, can be customized using a set of Aggregation Rules. "VoIP Configuration Server Address Option", Richard Johnson, 8-Jul-08, 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 [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. "Transmitting Confidential Data in RADIUS", Glen Zorn, Hao Zhou, Joseph Salowey, 28-Oct-08, This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes, are designed to allow the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers. "The LDAP Don't Use Copy Control", Kurt Zeilenga, 13-Jul-08, This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. "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. "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Magnus Westerlund, Per Frojdh, 7-Jul-08, The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. "Complications from Network Address Translator Deployment Topologies", Pyda Srisuresh, Bryan Ford, 18-Oct-08, 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 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 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 ensure these real scenarios can funtion. "P3P Policy Attributes for LDAP", Mark Wahl, 12-Dec-06, This document defines attributes for use in the Lightweight Directory Access Protocol (LDAP) which contain URIs for privacy policy documents. These documents describe the privacy policy concerning access to a directory server, and the privacy policies that apply to the contents of the directory (a subtree of entries). "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, 16-Jun-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, Paul Hoffman, Murray Kucherawy, 16-Jun-08, 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. "CalDAV Scheduling Extensions to WebDAV", Cyrus Daboo, Bernard Desruisseaux, 3-Nov-08, This document defines extensions to the CalDAV calendar-access feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. "Bundle Security Protocol Specification", Susan Symington, Stephen Farrell, Howard Weiss, Peter Lovell, 2-Nov-08, 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, 3-Jun-08, 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. "Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand, 31-Oct-08, This draft describes the applicability of loop free convergence technologies to a number of network applications. "Using non-ASCII Characters in RFCs", Tim Bray, Paul Hoffman, 3-Nov-08, 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. "Security Extension for Unidirectional Lightweight Encapsulation Protocol", Prashant Pillai, 14-Jul-08, This document describes the header extension for Unidirectional Encapsulation Protocol (ULE) that secures the IP traffic transported using ULE to provide security features like data confidentiality, data integrity, data origin authentication and mechanisms to prevent replay attacks. The format of the header extension and processing at the Receiver and Transmitter are described in detail. "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, 11-Jul-08, 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, 31-Oct-08, 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. "Use of the Reason header filed in Session Initiation Protocol (SIP) responses", Roland Jesske, Martin Huelsemann, 7-Oct-08, This document proposes the use of the Reason header field in SIP responses. "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. "Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, David McGrew, Joseph Salowey, Hao Zhou, 31-Oct-08, The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 11-Jul-08, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC2960, it is designed to integrate cryptographic functions into SCTP. "General Area Review Team (GenART) Experiences", Mary Barnes, Avri Doria, Harald Alvestrand, Brian Carpenter, 14-Aug-08, The General Area Review team has been doing Reviews of Internet Drafts since 2004. This draft discusses the experience and the lessons learned over the past 4+ years of this process. The review team initially did reviews before each of the IESG telechats. Beginning in late 2005, review team members have been assigned to review documents during IETF Last Call, unless no IETF Last Call is necessary for the document. The same reviewer then reviews any updates when the document is placed on an IESG telechat agenda. "Survey of IP address autoconfiguration mechanisms for MANETs", Carlos Bernardos, Maria Calderon, Hassnaa Moustafa, 1-Nov-08, This Internet Draft provides a detailed description of most of the existing IP autoconfiguration solutions proposed so far. The main aim of this document is to serve as a general reference for the AUTOCONF solution space. We present most of the previously proposed IP AUTOCONF mechanisms in MANETs, showing their key characteristics, conforming to the AUTOCONF problem statement draft and the MANET architecture draft. Furthermore, each solution is analysed based on a number of evaluation considerations. "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 draft-duker-as2-reliability-04.txt", Intellectual Property, 4-Sep-08, 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, 7-Oct-08, 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, 27-Oct-08, 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, 2-Nov-08, 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. "Password-Authenticated Diffie-Hellman Exchange (PAK)", Igor Faynberg, Zachary Zeltsan, Alec Brusilovsky, 9-Oct-08, This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password-authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. The use of Diffie-Hellman exchange ensures Forward Secrecy. "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. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage, 14-Jul-08, This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.1. Overall Applicability The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanisms specified here were designed to satisfy the requirements specified in the 3GPP Release 5 requirements on SIP [RFC4083] for which either no general-purpose solution was planned, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. For more details about the assumptions made about these extensions, consult the Applicability subsection for each extension.2. Conventions "Privacy Aspects Terminology", Wassim Haddad, Erik Nordmark, 25-Jun-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, 4-Aug-08, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. It enbales the 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. 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 also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to set the extended ECN field honestly. "Considerations for Having a Successful BOF", Thomas Narten, 12-Oct-07, This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. "Carrying Attached Addresses in IS-IS", David Ward, Russ White, Dino Farinacci, Ayan Banerjee, Radia Perlman, 3-Nov-08, 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.1. Overview There are a number of systems (for example, [RBRIDGES]) which have proposed using layer 2 addresses carried in a link state routing protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing in specific environments. This draft proposes a set of TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU types, to support these proposed systems. This draft does not propose new forwarding mechanisms using this additional information carried within IS-IS. There is a short section included on two possible ways to build a shortest path first tree including this information, to illustrate how this information might be used. "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. "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, 9-Sep-08, IPv6 fragmentation allows fragments to be sent only by the source of a packet. The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. Firewalls generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document specifies where tiny fragments can be issues. "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. "Key Management through Key Continuity (KCM)", Peter Gutmann, 29-Sep-08, This memo provides advice and Best Current Practice for implementors and deployers of security applications that wish to use the key continuity method of key management. "Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 28-May-08, 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, 7-Aug-08, 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. "LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark, 14-Jul-08, IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. "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. "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, 4-Aug-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)", Adnan Saleem, 14-Aug-08, 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. "PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, Adrian Farrel, Intellectual Property, 15-Oct-08, 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. "Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Seisho Yasukawa, Adrian Farrel, 15-Oct-08, Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses Resource Reservation Protocol traffic engineering extensions (RSVP-TE) as the signaling protocol to establish Label Switched Paths (LSPs). Although the Resource Reservation Protocol (RSVP) on which RSVP-TE is built supports the convergence of traffic flows toward a common destination, this concept has not been exploited in MPLS-TE which has been limited to point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. This document describes extensions to RSVP-TE procedures and protocol elements to support multipoint-to-point (MP2P) LSPs. "Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli, 2-Nov-08, 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 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. "Authorization for NSIS Signaling Layer Protocols", Jukka Manner, Martin Stiemerling, Hannes Tschofenig, Roland Bless, 2-Jul-08, Signaling layer protocols in the NSIS working group may rely on GIST to handle authorization. Still, the signaling layer protocol itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. "Enhanced validation of domains for HTTP State Management Cookies using DNS", Yngve Pettersen, 3-Nov-08, HTTP State Management Cookies are used for a wide variety of tasks on the Internet, from preference handling to user identification. An important privacy and security feature of cookies is that their information can only be sent to a servers in a limited namespace, the domain. The variation of domain structures that are in use by domain name registries, especially the country code Top Level Domains (ccTLD) namespaces, makes it difficult to determine what is a valid domain, e.g. example.co.uk and example.no, which cookies should be permitted for, and a registry-like domain (subTLDs) like co.uk where cookies should not be permitted. This document specifies an imperfect method using DNS name lookups for cookie domains to determine if cookies can be permitted for that domain, based on the assumption that most subTLD domains will not have an IP address assigned to them, while most legitimate services that share cookies among multiple servers will have an IP address for their domain name to make the user's navigation easier by omitting the customary "www" prefix. "The TLD Subdomain Structure Protocol and its use for Cookie domain validation", Yngve Pettersen, 3-Nov-08, This document defines a protocol and specification format that can be used by a client to discover how a Top Level Domain (TLD) is organized in terms of what subdomains are used to place closely related but independent domains, e.g. commercial domains in country code TLDs (ccTLD) like .uk are placed in the .co.uk subTLD domain. This information is then used to limit which domains an Internet service can set cookies for, strengthening the rules already defined by the cookie specifications. "ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 24-Oct-08, 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. "Definition of an Internet Research Task Force (IRTF) Document Stream", Aaron Falk, 22-Sep-08, This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. "DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 27-May-08, 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 detailed 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. "Channel Bindings for TLS based on PRF", Simon Josefsson, 12-Aug-08, This document specify how to compute data, "channel bindings", that is cryptographically bound to a specific Transport Layer Security (TLS) session. The intention is to use this data as a name of the secure channel for the purpose of a channel binding. The channel bindings can be used by authentication protocols to avoid tunneling attacks and security layer re-use. The data is derived using the TLS Pseudo-Random Function (PRF). "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 11-Jul-08, 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. "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, 11-Jul-08, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "MPLS Benchmarking Methodology", Aamer Akhter, Rajiv Asati, 7-Jul-08, The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. "Requirements for Web Authentication Resistant to Phishing", Sam Hartman, 18-Aug-08, This memo proposes requirements for protocols between web browsers and relying parties at websites; these requirements also impact third parties involved in the authentication process. These requirements minimize the likelihood that criminals will be able to gain the credentials necessary to impersonate a user or be able to fraudulently convince users to disclose personal information. To meet these requirements browsers must change. Websites must never receive information such as passwords that can be used to impersonate the user to third parties. Browsers should authenticate the website to the browser as part of authenticating the user to the website. Browsers MUST flag situations when this authentication fails and flag situations when the target website is not authorized to accept the identity being offered as this is a strong indication of fraud. These requirements may serve as a basis for requirements for preventing fraud in environments other than the web. "The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)", Jani Hautakorpi, Gonzalo Camarillo, 12-Nov-07, This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Pust to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI-list that have embedded URI-lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI-list that caused the rejection and the individual URIs that form such a URI-list. "Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 3-Nov-08, 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. "A Profile for Resource Certificate Repository Structure", Geoff Huston, Robert Loomans, George Michaelson, 22-Jun-08, This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a possible internal structure of a Repository Cache that is intended to facilitate synchronization across a distributed collection of repositories and facilitate certificate path construction. "Virtual Enterprise Traversal (VET)", Fred Templin, 17-Nov-08, Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Nodes in enterprise networks must have a way to automatically provision IP addresses/prefixes and other information, and must also support post- autoconfiguration operations even for highly-dynamic networks. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. "Diameter Routing Extensions", Tina Tsou, Victor Fajardo, Jouni Korhonen, Tolga Asveren, 29-Jul-08, This document describes two(2) extensions to the current diameter routing scheme. The first extension describes an explicit routing mechanism that MAY be employed by Diameter nodes to allow specific stateful Diameter proxies to remain in the path of all messages exchanges constituting a Diameter session. The second extension describes a realm based redirection scheme as an alternative to host based redirection described in [RFC3588]. "Modes of Operation for Camellia for Use With IPsec", Akihiro Kato, Masayuki Kanda, 5-Aug-08, This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode, as an IKEv2 and Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. "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. "The LDAP Relax Rules Control", Kurt Zeilenga, 14-Jul-08, This document defines the Lightweight Directory Access Protocol (LDAP) Relax Rules Control which allows a directory user agent (a client) to request the directory service temporarily relax enforcement of various data and service model rules. "HTTP Header Linking", Mark Nottingham, 2-Jul-08, This document clarifies the status of the Link HTTP header and attempts to consolidate link relations in a single registry. "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", Flemming Andreasen, Bernie McKibben, Bill Marshall, 3-Nov-08, In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) [RFC3261] for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. "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, 3-Jul-08, A framework for the exchange of capabilities in HELD is described. Capabilities for enabling device-based measurements and device-based location generation are described. "Delay-Tolerant Networking Custodial Multicast Extensions", Susan Symington, Robert Durst, Keith Scott, 31-Oct-08, This document defines optional extensions to the Bundle Protocol [2] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", Susan Symington, Robert Durst, Keith Scott, 31-Oct-08, This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [6]. When included as part of a given bundle B, this extension block, called a Bundle-in-Bundle Encapsulation Block, indicates that one or more other bundles have been placed inside of the payload field of B's Bundle Payload Block according to the format defined in this document. Hence, the Bundle-in-Bundle Encapsulation Block provides a mechanism for bundle-in-bundle encapsulation by indicating that one or more bundles are being transmitted as the payload of a bundle. This extension block is expected to be of general utility in DTN. It may be used, for example, to encapsulate a multicast bundle inside of a unicast bundle, or to encapsulate a bundle with one type of security protection inside of a bundle with a different type of security protection. This document defines the format and processing of this new Bundle-in-Bundle Encapsulation Block and the contents of the Bundle Payload Block accompanying it. "Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 15-Sep-08, This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide information to its next- hop receiving node. This block is always removed from the bundle by the receiving node so that it's duration within the bundle lasts for exactly one hop. It provides a general insertion capability to enable any node that forwards a bundle to insert an arbitrary record (or records) of information into the bundle. While this block is defined to provide an arbitrary insertion capability, this specification also defines two specific, mandatory, information record formats for the information that may be carried in the Previous Hop Insertion block. Using these mandatory information record formats, an insertion block may be used to indicate the inserting/forwarding node's endpoint ID (EID), which may be required in some circumstances to support certain routing protocols (e.g., flood routing). This document defines the format and processing of this Previous Hop Insertion Block. "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). "SPEERMINT Security Threats and Suggested Countermeasures", Saverio Niccolini, Eric Chen, Jan Seedorf, Hendrik Scholz, 31-Oct-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. "LDAP Subtree Data Source URI Attribute", Mark Wahl, 12-Dec-06, This document defines an attribute that enables administrative clients using the Lightweight Directory Access Protocol (LDAP) to determine the source of directory entries. "Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Singh Vishal, Henning Schulzrinne, Hannes Tschofenig, 30-Oct-08, 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. It defines five elements, namely speed, bearing, acceleration elevation and directionOfObject. "Transporting User to User Call Control Information in SIP for ISDN Interworking", Alan Johnston, Joanne McMillen, 31-Oct-08, 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 the information to/from ISDN for end-to-end transparency. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. This document discusses requirements and approaches and recommends a new header field User-to-User be standardized. Example use cases include an exchange between two User Agents, retargeting by a proxy, and redirection. An example application is in 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, 17-Nov-08, 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, 12-Jun-08, 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. "Design Considerations for Protocol Extensions", Brian Carpenter, Bernard Aboba, 27-Oct-08, This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved. Concrete case study examples are included. It is intended to assist designers of both base protocols and extensions. "Atom Bidirectional Attribute", James Snell, 11-Apr-08, This document adds a new attribute to the Atom Syndication Format used to indicate the base directionality of directionally-neutral characters. "Requirements for vertical handover of multimedia sessions using SIP", Saverio Niccolini, Stefano Salsano, Haruki Izumikawa, Ross Lillie, Luca Veltri, Yoji Kishi, 3-Nov-08, A vertical handover occurs in heterogeneous networks when a session media is moved among different access network technologies within the same device. This document analyses the issue of handling the vertical handover using the Session Initiation Protocol (SIP) [1]. "GSSAPI authentication for HTTP", Leif Johansson, 2-Nov-08, 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, 16-Oct-08, 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, 24-Oct-08, 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, David McDonald, Michael Montemurro, 1-Oct-08, 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 are both 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", Sharon Boeyen, Michael Grandcolas, Siddharth Bajaj, David M'Raihi, 25-Aug-08, 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. "Simple SIP Usage Scenario for Applications in the Endpoints", Henry Sinnreich, Alan Johnston, Eunsoo Shim, 21-Nov-08, 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 for example can be combined with rich Internet applications (RIA). However, 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, 13-Jul-08, 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. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 14-Jul-08, 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. "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 "HELD Identity Extensions", Martin Thomson, Hannes Tschofenig, Richard Barnes, James Winterbottom, 3-Nov-08, 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 an Target's location can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, the source IP address in the request is not the only identifier for the Target. 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 additional identifiers assisting the location determination process. It defines a set of URIs for Target identifiers and an XML containment schema. This extension is used in conjunction with HELD to provide Target identification, and set of criteria of when to use this extensions are provided. Examples and usage in HELD message syntax are also shown. "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Keith Drage, 2-Jul-08, The Session Initial Protocol (SIP) defined in RFC 3261 and a large number of extensions forms a considerable body of work, which through sheer size has a number of errors that require correction. This document explains the process for managing essential corrections to SIP. "The SIEVE mail filtering language - extension for accessing mailbox metadata", Alexey Melnikov, 20-Nov-08, This memo defines an extension to the SIEVE mail filtering language (RFC 5228) for accessing mailbox and server annotations (variables). "HTTP State Management Mechanism v2", Yngve Pettersen, 3-Nov-08, This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three HTTP headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from both Netscape's Cookie proposal [Netscape], and [RFC2965], but it can, provided some requirements are met, interoperate with HTTP/1.1 user agents that use Netscape's method. (See the HISTORICAL section.) This document defines new rules for how cookies can be shared between servers within a domain. These new rules are intended to address security and privacy concerns that are difficult to counter for clients implementing Netscape's proposed rules or the rules specified by RFC 2965. This document reflects implementation experience with RFC 2965 and obsoletes it. "An uniform format for IPv6 extension headers", Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, 14-Oct-08, In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers. "The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions", Arnt Gulbrandsen, Intellectual Property, 21-Oct-08, 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. "Diameter Congestion Signaling", Tolga Asveren, Victor Fajardo, 15-Jul-08, Diameter base protocol defines the network layer functionality to be used by applications. This document adds hop-to-hop congestion notification mechanism to that functionality. "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Ibrahim Hajjeh, 6-Oct-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. "Calendar Availability", Cyrus Daboo, Bernard Desruisseaux, 3-Nov-08, This document specifies a new iCalendar calendar component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including iTIP free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed. This document also defines extensions to CalDAV calendar-access and calendar-auto-schedule which specify how this new calendar component should be used when doing free busy time evaluation in CalDAV.Editorial Note (To be removed by RFC Editor before publication) Discussion of this specification is taking place on the mailing list http://lists.osafoundation.org/mailman/listinfo/ietf-caldav. "Real-time Inter-network Defense", Kathleen Moriarty, 21-Oct-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. "Dynamic Host Configuration Protocol Option for Geodetic Location Information", Martin Thomson, James Winterbottom, 3-Jul-08, 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. "Suite B Profile for Transport Layer Security (TLS)", Margaret Salter, Eric Rescorla, Russ Housley, 17-Nov-08, The United States Government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of TLS version 1.2 which is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 employ Suite B algorithms to the greatest extent possible. "Fast Macro Mobility Handovers in HMIPv6", Youngsong Mun, 27-Oct-08, 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 support fast macro mobility handover. These fast handover schemes can reduce both the handover latency and the pakcet loss. The schemes described in this document adopt the fast handover of FMIPv6 protocol to the edge access routers in MAP domains. The schemes support two fast handover modes for macro mobility handover in HMIPv6. "FTP EXTENSION ALLOWING IP FORWARDING (NATs)", Martin Rosenau, 18-Sep-08, The FTP protocol [1] needs two connections. A control and a data connection. Using networks with "port forwarding" (eg. SSH, DSL routers, VPN etc.) there is often only the possibility for the server to listen on only one TCP port. In such networks the traditional FTP protocol cannot be used. This memo describes an extension to the FTP protocol that allows the use of FTP using only one TCP port number for both control connections and passive-mode data connections. The extension can also be used to use the FTP protocol over network protocols that do not have a "port" concept (such as the NetBIOS protocol). "A Conference List Information Event Package for the Session Initiation Protocol (SIP)", Michael Fortinsky, Ilan Ravid, Oded Koren, 3-Jul-08, This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications related to conference lists. A new conference list event package is specified. This event package allows a user to subscribe to a single event (the conference-list) and receive notifications that contain the list of conferences to which the user belongs and the status of each conference. The notifications sent from the conference server can contain either the entire list of the user's conferences or a partial list with the updates since the previous notification. "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, 23-Jun-08, 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, David Oran, Dave Meyer, Scott Brim, 10-Oct-08, 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, 25-Jun-08, 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, 25-Jun-08, This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement. "Progress notifications for HTTP", Andrien de Croy, 23-Jul-08, This document specifies an extension to HTTP to allow the sending of progress messages to user-agents during lengthy processing which could otherwise cause users or user-agents to abandon requests. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 20-Jun-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, 20-Jun-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, 20-Jun-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, 31-Oct-08, 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. "Service Selection for Mobile IPv4", Jouni Korhonen, Ulf Nilsson, 3-Nov-08, In some Mobile IPv4 deployments identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection Extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for the mobility service subscription during the registration procedure. "Common Architecture Label IPv6 Security Option (CALIPSO)", Michael StJohns, 25-Aug-08, 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. "Secure Media Recording and Transcoding with the Session Initiation Protocol", Dan Wing, Francois Audet, Steffen Fries, Hannes Tschofenig, Alan Johnston, 31-Oct-08, Call recording is an important feature in enterprise telephony applications. Some industries such as financial traders have requirements to record all calls in which customers give trading orders. This poses a particular problem for Secure RTP systems as many SRTP key exchange mechanisms do not disclose the SRTP session keys to intermediate SIP proxies. As a result, these key exchange mechanisms cannot be used in environments where call recording is needed. This document specifies a secure mechanism for a cooperating endpoint to disclose its SRTP master keys to an authorized party to allow secure call recording. "DHCP Vendor-specific Message", Bernie Volz, 7-Jul-08, This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes. "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Larry Zhu, Jeffrey Altman, Nicolas Williams, 3-Nov-08, This document defines a Generic Security Services Application Program Interface (GSS-API) mechanism based on Public Key Infrastructure (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the Kerberos V GSS-API mechanism, but without requiring a Kerberos Key Distribution Center (KDC). "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-Jul-08, 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). To implement MPR well, 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, 3-Jul-08, 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, 3-Jul-08, 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. "Vouch By Reference", Paul Hoffman, John Levine, Arvel Hathcock, 9-Oct-08, This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. "FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 2-Oct-08, 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, 3-Jul-08, 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. "SIP URI Service Discovery using DNS-SD", Jae Woo Lee, Henning Schulzrinne, Wolfgang Kellerer, Zoran Despotovic, 12-Jul-08, This document describes how to use the DNS-based Service Discovery (DNS-SD), better known as Apple Bonjour, for advertising Session Initiation Protocol (SIP) URIs in local area networks. Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. "IP Tunneling Optimization in a Mobile Environment", Wassim Haddad, Mats Naslund, Pekka Nikander, 13-Jul-08, 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. "MANET Position and Mobility Signaling: Problem Statement", Jerome Haerri, Christian Bonnet, Fethi Filali, 14-Jul-08, This document states the problem of optimizing the structures created by mobile network or MANET protocols to a mobile network topology. It also justifies the use and the transmission of position information to mitigate this problem. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, 14-Jul-08, The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB is in the process of being standardized as IEEE 802.1ah, which is an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes how IEEE 802.1ah functionality can be used in the H-VPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. This 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. "MANET Position and Mobility Signaling Format", Jerome Haerri, Christian Bonnet, Fethi Filali, 14-Jul-08, This document describes an extension to the node metric TLV defined in the MetricTLV document to specify a configurable structure to exchange position and mobility information for MANET protocols. "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", Vladislav Marinov, 1-Oct-08, This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. "Media Description for IKE in the Session Description Protocol (SDP)", Makoto Saito, Dan Wing, 27-Jul-08, 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. "The Multiple Appearance Feature using the Session Initiation Protocol (SIP)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, Anil Kumar, 13-Jul-08, 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 Multiple Appearances (MA) since SIP does not have lines. This feature is commonly offered in the 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. "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. "PCE communication protocol(PCEP) Management Information Base", Emile Stephan, Kiran Koushik, 3-Nov-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 Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. "A context mechanism for controlling caching of HTTP responses", Yngve Pettersen, 3-Nov-08, A common problem for sensitive web services is informing the client, in a reliable fashion, when a password protected resource is no longer valid because the user is logged out of the service. This is, in particular, considered a potential security problem by some sensitive services, such as online banking, when the user navigates the client's history list, which is supposed to display the resource as it was when it was loaded, not as it is at some later point in time. This document presents a method for collecting such sensitive resources into a group, called a "Cache Context", which permits the server to invalidate all the resources belonging in the group either by direct action, or according to some expiration policy. The context can be configured to invalidate not just the resources, but also specific cookies, HTTP authentication credentials and HTTP over TLS session information. "Security requirements in Peer-to-Peer Session Initiation Protocol (P2PSIP)", Song Yongchao, Marcin Matuszewski, Dan York, 3-Nov-08, This document outlines the security requirements for a Peer-to-Peer Session Initiation Protocol (P2PSIP) overlay network. It compares security difference between client/server (C/S) and P2P implementations of SIP, partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers. This draft also describes the different security requirements related to different application scenarios as well as a minimal set of security requirements valid for all applications. It also discusses open issues related to certain security threats for the P2PSIP architecture and its components. "Network In Node Advertisement", Pascal Thubert, Carlos Bernardos, 12-Sep-08, The Internet is evolving to become a more ubiquitous network, driven by the low prices of wireless routers and access points and by the users' requirements of connectivity anytime and anywhere. For that reason, a cloud of nodes connected by wireless technology is being created at the edge of the Internet. We refer to this cloud as a Fringe Stub (FS). It is expected that networking in the FS will be highly unmanaged and ad-hoc, but at the same time will need to offer excellent service availability. The NEMO Basic Support protocol could be used to provide global reachability for a mobile access network within the FS and the Tree-Discovery mechanism could be used to avoid the formation of loops in this highly unmanaged structure. Since Internet connectivity in mobile scenarios can be costly, limited or unavailable, there is a need to enable local routing between the Mobile Routers within a portion of the FS. This form of local routing is useful for Route Optimization (RO) between Mobile Routers that are communicating directly in a portion of the FS. Network In Node Advertisement (NINA) is the second of a 2-passes routing protocol; a first pass, Tree Discovery, builds a loop-less structure -- a tree --, and the second pass, NINA, exposes the Mobile Network Prefixes (MNPs) up the tree. The protocol operates as a multi-hop extension of Neighbor Discovery (ND), to populate TD-based trees with prefixes, and establish routes towards the MNPs down the tree, from the root-MR towards the MR that owns the prefix, whereas the default route is oriented towards the root-MR. The NINA protocol introduces a new option in the ND Neighbor Advertisement (NA), the Network In Node Option (NINO). An NA with NINO(s) is called a NINA (Network In Node Advertisement). NINA is designed for a hierarchical model, and by using this NA based approach it abstracts the embedded network of a Mobile Router as a host to the upper level of network abstraction. With NINA, a Mobile Router presents its sub-tree to its parent as an embedded network and hides the inner topology and movements. "A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Dan Wing, Henning Schulzrinne, Thomas Froment, Geoffrey Dawirs, 12-Jul-08, SPAM, defined as sending unsolicited messages to someone in bulk, might be a problem on SIP open-wide deployed networks. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various factors. This document defines an authorization based policy language that allows end users to upload anti-SPIT policies to intermediaries, such as SIP proxies. These policies mitigate unwanted SIP communications. It extends the Common Policy authorization framework with additional conditions and actions. The new conditions match a particular Session Initiation Protocol (SIP) communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by SIP itself, by the SIP identity mechanism, by information carried within SAML assertions. "LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire", Frederic JOUNAY, 31-Oct-08, This document provides a solution to extend 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 leaf- initiated P2MP PW setup and maintenance. The processing for setting up a P2MP MS-PW is built on the processing for setting up a P2MP LSP with LDP. "LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire", Frederic JOUNAY, 31-Oct-08, 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. "Considerations about Multicast for BGP/MPLS VPN Standardization", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 11-Jul-08, The current proposal for multicast in BGP/MPLS includes multiple alternative mechanisms for some of the required building blocks of the solution. The aim of this document is to leverage previously documented requirements to identify the key elements and help move forward solution design, toward the definition of a standard having a well defined set of mandatory procedures. The different proposed alternative mechanisms are examined in the light of requirements identified for multicast in L3VPNs, and suggestions are made about which of these mechanisms standardization should favor. Issues related to existing deployments of early implementations are also addressed. "Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", Michael Procter, 21-Oct-08, 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. "Authentication Protocol for Mobile IPv6", Alpesh Patel, Kent Leung, Mohamed Khalil, Haseeb Akhtar, Kuntal Chowdhury, 14-Jul-08, IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6. Mobile IPv6 signalling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing Mobile IPv6 signaling messages between a Mobile Nodes and Home Agents. The alternate method defined here consists of a Mobile IPv6 specific authentication option that can be added to Mobile IPv6 signalling messages. "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 Minger Email Address Verification Protocol", Arvel Hathcock, Jonathan Merkel, 9-Jul-08, This document describes the Minger protocol. Minger is a protocol which allows a mail handling entity to query a remote service and ask the question "do you accept mail for this email address?" It includes security in the form of a hashed shared secret but can also be used anonymously if desired. "The DVB-RCS MIB", Petter Amundsen, Micheline Lambert, Hans-Peter Lexow, Stephane Combes, 4-Sep-08, his 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. "Extensible Supply-chain Discovery Service Concepts", Michael Young, 29-Aug-08, This document is intended to seed discussion about the Extensible Supply-chain Discovery Service (ESDS), an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. Specified initially as a web service interface, the protocol defines event tracking and tracing operations as well as core object management operations. This document obsoletes "Extensible Supply-chain Discovery Service Concepts draft-young-esds-concepts-03". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "Extensible Supply-chain Discovery Service Commands", Frank Thompson, 29-Aug-08, The Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. This document describes the details of the command interface of the ESDS. A full outline of all primary and support commands is included in this document along with examples. Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "Extensible Supply-chain Discovery Service Schema", Frank Thompson, 29-Aug-08, The Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. This document outlines the schema of the ESDS application layer protocol. This is the formal syntax of the web service interface specification in Web Service Description Language (WSDL) and XML Schema (XSD). Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "Adding Acknowledgement Congestion Control to TCP", Sally Floyd, Intellectual Property, 14-Jul-08, This document adds an optional congestion control mechanism for acknowledgement traffic (ACKs) to 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 and 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 proposed as an experimental mechanism for TCP for evaluation by the network community. "The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", Hans Erik van Elburg, 18-Nov-08, This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Subsystem Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. "VoIP Peering: Background and Assumptions", Otmar Lendl, 28-Oct-08, This documents provides background for the work on VoIP peering and tries to provide guidance on what kind of work is needed to facilitate widespread SIP-based peering of telephony networks. It is intended to spur discussion on the work about peering (in the SPEERMINT and DRINKS WGs) and should also serve as input to the ongoing discussions on reducing Spam for Internet Telephony (SPIT). "Campus/Building Relative Location for Civic Location Format", Marc Linsner, Allan Thomson, 14-Jul-08, 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. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "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, 20-Oct-08, 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 to identify services within the SIP header fields defined in this document, and also within the framework defined for caller preferences and callee capabilities in 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, 31-Oct-08, This document defines an optional extension block, called a Retransmission Block, that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. The Retransmission Block (RB) is designed to be inserted by a custodian when re-forwarding a bundle, so as to mark the bundle as a legitimate custody-based retransmission rather than an unauthorized bundle duplicate. By providing a way for nodes that receive the re- forwarded bundle to distinguish it from an unauthorized duplicate, the RB enables those nodes whose local security policies do not permit them to forward unauthorized duplicate bundles to detect and delete unauthorized bundle duplicates but forward legitimate custody- based bundle retransmissions. This document defines the format and processing of this new Retransmission Block. "Application Listener Discovery (ALD) for IPv6", James Woodyatt, 31-Jul-08, This document specifies the protocol used by IPv6 nodes comprising stateful packet filters to discover the transport addresses of listening applications (that is, application endpoints for which incoming traffic may be administratively prohibited). Comments are solicited and should be sent to the author and the V6OPS Residential CPE Design Team mailing list at . "An XCON Client Conference Control Package for the Media Control Channel Framework", Chris Boulton, Mary Barnes, 20-Aug-08, 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. "Using Saratoga with a Bundle Agent as a Convergence Layer for Delay-Tolerant Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 31-Oct-08, Saratoga is a simple, lightweight, UDP-based transfer protocol. This describes how to use Saratoga as a Delay-Tolerant Networking (DTN) "convergence layer" with the Bundle Protocol and its Bundle Agents, building on the Saratoga specification in draft-wood-tsvwg-saratoga. "802.1ah Ethernet Pseudowire", Luca Martini, Ali Sajassi, 25-Jul-08, An Ethernet Pseudowire (PW) is used to carry Ethernet/802.1ah frames over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of 802.1ah Ethernet Frames within a pseudo wire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. "LC-PCN: The Load Control PCN Solution", Lars Westberg, Anurag Bhargava, Attila Bader, Georgios Karagiannis, Hein Mekkes, 3-Nov-08, There is an increased interest of simple and scalable resource provisioning solution for Diffserv network. The Load Control PCN (LC-PCN) addresses the following issues: o Admission Control for real time data flows in stateless Diffserv Domains o Flow Termination: Termination of flows in case of exceptional events, such as severe congestion after re-routing. Admission control in a Diffserv stateless domain can be performed using two methods: o Admission Control based on data marking, whereby in congestion situations the data packets are marked to notify the PCN-egress- node that a congestion occurred on a particular PCN-ingress-node to PCN-egress-node path. o Probing, whereby a probe packet is sent along the forwarding path in a network to determine whether a flow can be admitted based upon the current congestion state of the network The scheme provides the capability of controlling the traffic load in the network without requiring signaling or any per-flow processing in the PCN-interior-nodes. The complexity of Load Control is kept to a minimum to make implementation simple. LC-PCN can support the ingress-egress-aggregate (i.e., trunk/pipe) bandwidth management model as well as the HOSE bandwidth management model. "Performance Analysis of Inter-Domain Path Computation Methodologies", Sukrit Dasgupta, Jaudelice Oliveira, JP Vasseur, 14-Jul-08, This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE) Architecture based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. "Multiple Packetization Times in the Session Description Protocol (SDP): Problem Statement, Requirements & Solution", Marc Willekens, Miguel Garcia, Peili Xu, 13-Jul-08, This document provides a problem statement and requirements with respect to the presence of a single packetization time (ptime/ maxptime) attribute in SDP media descriptions that contain several media formats (audio codecs). Furthermore, a best common practice solution for the use of 'ptime/maxptime' is proposed based on 'static', 'dynamic' and 'indicated' values. Some methods already proposed as ad-hoc solutions and background information is included in an appendix. "Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions", Vince Mammoliti, Carlos Pignataro, Peter Arberg, John Gibbons, Paul Howard, 18-Nov-08, This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with LAC functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3. "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", Gorry Fairhurst, Thomas Schmidt, Matthias Waehlisch, 18-Nov-08, 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. "IPv6 Configuration in IKEv2", Pasi Eronen, Julien Laganier, Cheryl Madson, 28-Oct-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. "Timezone Information in HTTP", Stefanos Harhalakis, 1-Oct-08, This document defines a HTTP header for clients to provide timezone information to web servers. An ABNF description of the corresponding header is provided. "Handle Resolution Option for ASAP", Thomas Dreibholz, 4-Oct-08, This document describes the Handle Resolution option for the ASAP protocol. "Media Resource Brokering", Chris Boulton, 28-Oct-08, 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, Hannes Tschofenig, Peter Gutmann, 8-Jul-08, 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. "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Nicolas Chevrollier, Dominik Kaspar, JP Vasseur, 14-Jul-08, This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). "Use of the Identity-Based Cryptographic Algorithms in CMS", Zhaohui Cheng, Bo Dan, 19-Oct-08, This document describes the conventions for using identity-based cryptography algorithms in the Cryptographic Message Syntax (CMS). "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, 11-Jul-08, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "A Framework to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Henning Schulzrinne, Dan Wing, Jonathan Rosenberg, David Schwartz, 14-Jul-08, Spam, defined as sending unsolicited messages to someone in bulk, is likely to become a problem on SIP open-wide deployed networks. A number of solutions have been proposed for dealing with Spam for Internet Telephony (SPIT) and unwanted communication, such as content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others. This document describes the big picture that illustrates how the different building blocks fit together and can be deployed incrementally. "Requirements for Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Geoffrey Dawirs, Thomas Froment, Dan Wing, Henning Schulzrinne, 11-Jul-08, Spam over Internet Telephony (SPIT) is one of the foreseen future forms of spamming that SIP open-wide networks may have to handle. SPIT also has more impact on users than email spam since it is more intrusive. Email as a store-and-forward communication mechanism allows for several filtering mechanisms to be applied to the full content before being presented to the user. Session Initiation Protocol (SIP) interaction is, in contrast, real-time communication and therefore does not provide much information prior to the transmission of the content, making it both harder to filter and more annoying to users. The responsibility for filtering, blocking calls, or taking any other preventive action can belong to different elements in the call flow and may depend on various factors. This document discusses the requirements to define authorization policies that should allow end users or other parties to setup anti-SPIT policies for triggering these actions. These policies typically match a particular SIP communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by the SIP protocol itself, by the SIP identity mechanism, by information carried within SAML assertions or by reputation systems of social networks. "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. "Commissioning in 6LoWPAN", Ki-Hyung Kim, Chae-Seong Lim, Seung Yoo, Soohong Daniel Park, Geoffrey Mulligan, 17-Jul-08, The commisioning process defines the startup procedure executed by any 6LoWPAN device. This document defines the startup procedure that should be followed by a 6LoWPAN device in any open or secured network. "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, 4-Aug-08, 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). "REsource LOcation And Discovery (RELOAD)", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 10-Jun-08, 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 which do not need to route traffic or store data for others. "Header Protection for S/MIME", Lijun Liao, Joerg Schwenk, 6-Oct-08, In the current S/MIME Version 3.1 specification, the header protection is achieved by encoding the whole message as a message/rfc822 MIME object. Since this approach poses some practical problems, we propose to use signed attributes to implement a fully backward compatible S/MIME header protection scheme. "HELD Protocol Context Management Extensions", James Winterbottom, Hannes Tschofenig, Martin Thomson, 29-Sep-08, 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, 3-Jul-08, 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. "Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local Mobility Anchor to Diameter Server Interaction", Jouni Korhonen, Julien Bournelle, Ahmad Muhanna, Kuntal Chowdhury, Ulrike Meyer, 15-Sep-08, 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 roams into a Proxy Mobile IPv6 Domain and performs access authentication. "Delay Tolerant Networking TCP Convergence Layer Protocol", Michael Demmer, Jörg Ott, 3-Nov-08, This document describes the protocol for the TCP-based Convergence Layer for Delay Tolerant Networking (DTN). "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, 3-Aug-08, 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. "The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations", Itaru Nishioka, Daniel King, 4-Jul-08, 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. This document describes the usage of multiple SVECs in the SVEC list and its processing guideline, for the synchronized computation of dependent paths. "MIPv4 Authentication Using a New Diameter MIPv4 Application", Ahmad Muhanna, Mohamed Khalil, Avi Lior, 14-Jul-08, Current Mobile IPv4 deployments use RADIUS based MIPv4 user authentication and authorization. Diameter Mobile IPv4 Application [RFC4004] offers another method for MIPv4 authentication, authorization, and dynamic mobility security association allocation, e.g. MN-HA SA allocation. Some SDOs are considering the use of Diameter Mobile IPv4 Application to replace RADIUS based mechanism. However, these SDos use a link layer access authentication mechanism, e.g., using an EAP application, to derive the related MIP4 shared keys and security association. This document an overview of these respected architectures and their handling to MIP4 security association and keys derivation and distribution. It presents an analysis of the performance and impact of Diameter MIPv4 Application and RADIUS based solutions on the time the mobile node uses during the initial session setup. Some common MIPv4 scenarios which require the mobile node to retransmit its initial RRQ message have been identified and used. The set of assumptions and requirements used for this study has been clearly documented under section 5. "ANCP Multicast Handling Sessions", Roberta Maglione, Angelo Garofalo, Francois Le Faucheur, Toerless Eckert, Tom Taylor, 11-Jul-08, This memorandum aims at presenting ANCP Multicast handling. It proposes updated description of the Multicast Use cases and corresponding updated ANCP requirements. It also presents the corresponding Message Flows. "Layered Encapsulation of Congestion Notification", Bob Briscoe, 14-Jul-08, This document redefines how the explicit congestion notification (ECN) field of the outer IP header of a tunnel should be constructed. It brings all IP in IP tunnels (v4 or v6) into line with the way IPsec tunnels now construct the ECN field. It includes a thorough analysis of the reasoning for this change and the implications. It also gives guidelines on the encapsulation of IP congestion notification by any outer header, whether encapsulated in an IP tunnel or in a lower layer header. Following these guidelines should help interworking, if the IETF or other standards bodies specify any new encapsulation of congestion notification. "Emulating Border Flow Policing using Re-PCN on Bulk Data", Bob Briscoe, 13-Sep-08, Scaling per flow admission control to the Internet is a hard problem. The approach of combining Diffserv and pre-congestion notification (PCN) provides a service slightly better than Intserv controlled load that scales to networks of any size without needing Diffserv's usual overprovisioning, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It provides a sufficient emulation of per-flow policing at borders but with only passive bulk metering rather than per-flow processing. Measurements are sufficient to apply penalties against cheating neighbour networks. "RADIUS Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri Gundavelli, 3-Nov-08, This document defines a RADIUS based interface between the Mobile Access Gateway and the RADIUS server that is used to download the per Mobile Node Policy Profile from the remote Policy Store. 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. "OpenToken", Dave Smith, Peter Motykowski, Yasir Faruqi, Peter Saint-Andre, 11-Aug-08, This document describes OpenToken (OTK), a format for the lightweight, secure, cross-application exchange of key-value pairs. The format is designed primarily for use as an HTTP cookie or query parameter, but can also be used in other scenarios that require a compact, application-neutral token. "Applicability Issues of IPsec in NAT-PT", Sangjin Jeong, Myung-Ki Shin, Sangdo Lee, 3-Nov-08, NAT-PT (Network Address Translation - Protocol Translation) mechanism that has been deprecated in [RFC4966] comes into spotlight again. The use-cases that NAT-PT addresses still need to be discussed and the requirements persist in IPv6 transition work. This document discusses the applicability issues when applying IPsec protocol to NAT-PT mechanism. "IPv4 Mobility Extension for Multicast and Broadcast Packets", Samita Chakrabarti, Ahmad Muhanna, Gabriel Montenegro, Yingzhe Wu, Basavaraj Patil, 30-Oct-08, This document define a new Mobile IPv4 extension which is used with Mobile IPv4 signaling to negotiate the Multicast-Broadcast Encapsulation Delivery style in the case of Foreign Agent Care-of- Address mode registration. This mechanism allows the mobile node to negotiate which type of traffic to be delivered encapsulated to the foreign agent while delivering other types of IP packets using direct delivery style. In particular, this mechanism will give flexibility to eliminate tunnel overhead in the (typically) wireless medium between the mobile node and the foreign agent. "VPLS Extensions for Provider Backbone Bridging", Matthew Bocci, John Hoffmans, Geraldine Calvignac, Raymond Zhang, Florin Balus, 15-Jul-08, IEEE 802.1ah draft 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. 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 model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. "Fast Handovers for PMIPv6", Hidetoshi Yokota, Kuntal Chowdhury, Rajeev Koodli, Basavaraj Patil, Frank Xia, 13-Jul-08, This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is applied for the mobility management protocol. Necessary amendments are shown for FMIPv6 to work under the condition that the mobile node does not have IP mobility functionality and it is not involved with either MIPv6 or FMIPv6 operations. "Additional Location Privacy Considerations", Richard Barnes, Matt Lepinski, Hannes Tschofenig, Henning Schulzrinne, 14-Jul-08, This document discusses security and privacy concerns related to the distribution of location information over the Internet. We clarify how privacy rules can be enforced by a location server, and how privacy rules should be interpreted in store and forward networks. We also describe general mechanisms for providing end-to-end assurances about a location object. "Requirements for Authority-to-Individuals Communication for Emergency Situations", Steve Norreys, 14-Jul-08, 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, 12-Jul-08, 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). "Membership Event Package", Vishal Singh, Henning Schulzrinne, Piotr Boni, 14-Jul-08, This document defines a new event membership package that allows to track changes in membership in groups. Groups can represent entities contained within a physical space, such as a room or vehicle, or a logical group of entities, such as a call center team. Each member of a group can support a different set of event packages. "Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based approaches", Sheng Jiang, 11-Jul-08, This document analyzes the requirements for the configuration Cryptographically Generated Addresses and Multi-key CGAs. The applicability of Router Advertisement and DHCPv6 for this configuration is also discussed. "An Evaluation Framework for Data Modeling Languages in Network Management Domain", Hui Xu, Debao Xiao, 3-Nov-08, 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, readability, conformance, data representation, extensibility and security considerations. "File Transfer Protocol HOST Command", Paul Hethmon, Robert McMurray, 14-Jul-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. "Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions", Minpeng Qi, Haitao Li, Peng Yang, Hui Deng, Yuanchen Ma, 14-Jul-08, This draft discusses the issues associated with interfacing between IKEv2/IPsec and MIPv6. When mobile nodes bootstrap in foreign network or handover to a new network, IKEv2/IPsec can not probe the changing of care-of-address, which is related security associations. One simple extension to the SADB_ACQUIRE in PF_KEY framework is proposed to support this interfacing. And the operation modification of IKEv2 and MIPv6 are described in this proposal based on the SADB_ACQUIRE extension. A new mobility security reference database is created to store the temporary mobility parameters. "Open Research Issues in Internet Congestion Control", Dimitri Papadimitriou, 8-Aug-08, 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. "PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 30-Jun-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. "A Solution For Source Address Validation in Local Subnet Environment", Jianping Wu, Gang Ren, Jun Bi, Xing Li, Mark Williams, 14-Jul-08, This document describes a solution for preventing source address spoofing in the local subnet of the Internet. The main idea of the solution is to get a dynamic binding between IP address and access switch port. "Administrative Specific Elements for Civic Location Format", Marc Linsner, Subha Dhesikan, Hannes Tschofenig, 14-Jul-08, 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. "Ivip (Internet Vastly Improved Plumbing) Architecture", Robin Whittle, 19-Aug-08, Ivip (Internet Vastly Improved Plumbing) is a proposed global system of routers and either collection of databases which control the tunneling of some of these routers. Database changes affect all Ingress Tunnel Routers (ITRs) within a few seconds, controlling which Egress Tunnel Router (ETR) they tunnel each packet to, depending on the packet's destination address. The ETR used by a host with an Ivip-mapped address is typically located in the same network as this destination host. The ETR decapsulates packets and forwards them to the destination host. A second type of ETR known as a Translating Tunnel Router (TTR) is used for mobile-IP, with the mobile node creating two-way tunnels to one or more nearby TTRs. Ivip enables a subset of IPv4 and IPv6 address space to be portable (used via any ISP which has an ETR) and to be suitable for multihoming (connection to the Net via two or more ISPs) - without involving BGP and without requiring any changes to host operating systems or applications. This is a form of "locator-ID separation" and is based on some principles derived from LISP (Locator/ID Separation Protocol). IP addresses in the subset of address space which is subject to being tunneled by ITRs are known as Destination Identifiers (DIDs). ITRs and ETRs are located on ordinary BGP Reachable IP (BRIP) addresses. The databases and ITRs map DID addresses to an ETR's BRIP address with a granularity of a single IPv4 address or a /64 prefix for IPv6. These two granularities are 256 and 64k times finer than is typically possible with BGP. This proposal is intended to resolve many of the problems discussed in the October 2006 Amsterdam IAB Routing and Addressing Workshop (RAWS). Ivip's primary goals include the more efficient utilisation of IPv4 space and enabling millions of end- users to achieve portability and multihoming without involving BGP, without fuelling the growth of the global BGP routing table, and without requiring these end users to have ASNs or to acquire conventional prefixes of PI (Provider Independent) BGP reachable address space. "Link Metrics for OLSRv2", Christopher Dearlove, Thomas Clausen, Philippe Jacquet, 16-Sep-08, This document describes how link metrics may be added, in a relatively straightforward manner, to the specification of OLSRv2, in order to allow routing by other than minimum hop count routes. In addition to metric signaling and use, the most significant change is a separation of the routing and flooding functions of MPRs. "EAP Fast Re-Authentication Protocol (EAP-FRAP)", Saber Zrelli, Yoichi Shinoda, 3-Jun-08, This document specifies an extension to the AAA/EAP authentication and key management framework that allows an EAP peer to perform fast re-authentications with the local EAP server after an initial full EAP authentication using a legacy EAP method with the same or another EAP server. EAP-FRAP eliminates the need for exchanges between the local EAP server and the home EAP server each time the EAP peers is authenticated. In wireless networks, this allows the mobile device to reduce hand-off delays. The EAP-FRAP extension does not require changes in underlying layer protocols. Which makes is back-ward compatible with existing infrastructures and easily deployable with minimal costs. "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. "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. "Redesignation of 240/4 from "Future Use" to "Private Use"", Paul Wilson, George Michaelson, Geoff Huston, 29-Sep-08, This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for Private Use. "RAN Synchronization Requirements", LinLang Zhou, 7-Jul-08, This Internet draft describes RAN synchronization requirements, mainly about synchronization description and requirements, also includes some applications and problem description. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, 3-Nov-08, The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, the device does not have credentials for network access, does not have a VoIP provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. ""RTP Payload Format for apt-X"", Gregory Massey, 24-Jun-08, This document describes an RTP payload format for transporting apt-X encoded audio. It details the RTP encapsulation mechanism for standard, enhanced apt-X and apt-X Live data. Also included within this memo are media type registrations, and the details necessary for the use of apt-X, enhanced apt-X and apt-X Live with the Session Description Protocol. "Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs", Hassnaa Moustafa, Carlos Bernardos, Maria Calderon, 1-Nov-08, This Internet Draft aims at providing general guidelines for the AUTOCONF solution space, through providing a set of evaluation considerations for IP autoconfiguration mechanisms in MANETs. These evaluation considerations conform to the AUTOCONF problem statement draft and the MANET architecture draft. The main objective of this draft is to illustrate some key features and highlight some important behaviours for the different autoconf mechanisms, and thus aiming to help solution developers during mechanisms' design and to help implementers in the choice of the autoconf mechanism that fits better their particular requirements, taking into consideration a number of important factors that are discussed in this draft. "A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization", Ashutosh Dutta, Victor Fajardo, Yoshihiro Ohba, Kenichi Taniuchi, Henning Schulzrinne, 2-Nov-08, 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. "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, Hao Zhou, 2-Nov-08, The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel a basic password exchange, based on the generic token card method (EAP-GTC), may be executed to authenticate the peer. "CUBIC for Fast Long-Distance Networks", Injong Rhee, Lisong Xu, Sangtae Ha, 26-Aug-08, CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. We expect this document to be eventually published as an experimental RFC. "OSPF Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 21-Sep-08, 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. "Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti Mäkelä, Jouni Korhonen, 31-Oct-08, 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, 31-Oct-08, 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. 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 lengthily discusses the pros and cons of this approach and the existing constraints that combined to drive this design. "Diameter Support for EAP Re-authentication Protocol", Lakshminath Dondeti, 14-Jul-08, An EAP extension, called "EAP Re-authentication Protocol (ERP)", has been specified that supports an EAP method-independent protocol for efficient re-authentication between the peer and the server through an authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP Initiate and EAP Finish messages specified in the ERP specification. AVPs for request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER server are also specified. Additionally, this document also specifies Diameter processing rules relevant to ERP. "Connection setup negociation for the Message Session Relay Protocol", Remi Denis-Courmont, 27-Jul-08, This document extends the MSRP connection model to negotiate the direction of the TCP connection setup. This provides a partial yet simple solution for scenarios whereby either, but not both, party to an MSRP session is located behind a NAT or firewall, and cannot serve as the passive endpoint for TCP connection setup. "H.248/MEGACO Package Registration Procedures", Christian Groves, Yangbo Lin, 31-Jul-08, 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. "Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, Loa Andersson, 4-Oct-08, 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. "IPsec Gateway Failover Protocol", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 12-Jul-08, 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 is used for authentication, which adds several more round trips and therefore latency. To re-establish security associations (SA) 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 many failure cases it would be useful to provide an efficient way to resume an interrupted 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, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. The encrypted ticket can only be decrypted by the VPN gateway in order to restore state for faster session setup. "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 28-Oct-08, 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. "Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Preethi Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar, 27-Aug-08, 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. "Saratoga: A Scalable File Transfer Protocol", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 31-Oct-08, This document specifies the Saratoga transfer protocol. Saratoga was originally developed to efficiently transfer remote-sensing imagery from a low-Earth-orbiting satellite constellation, but is useful for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have only sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. "Instant Messaging Sessions within a Centralized Conferencing (XCON) System", Chris Boulton, Mary Barnes, 30-Oct-08, 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 Instant Messaging (IM) chat sessions. In addition, the document describes additional functionality and requirements necessary to provide feature rich chat functionality. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, 31-Oct-08, This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). These extensions build on previous work for the control of G.709 based networks. "Mobility Support Using MPLS and MP-BGP Signaling", Oleg Berzin, Andrew Malis, 29-Oct-08, This document describes a new approach to handling user mobility at the network layer in the context of Multi-Protocol Label Switched Networks (MPLS). This approach does not rely on the existing IP mobility management protocols such as Mobile IP, and is instead based on the combination of Multi-Protocol BGP (MP-BGP) and MPLS. This document proposes to introduce new protocol elements to MP-BGP to achieve Mobility Label distribution at the network control plane and the optimal packet delivery to the mobile node by the network forwarding plane using MPLS. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Young Lee, Dan Li, Wataru Imajuku, Greg Bernstein, 7-Jul-08, This document provides an information model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of information described in this model is to facilitate constrained lightpath computation in WSONs. In particular in cases where there are no or a limited number of wavelength converters available in the WSON. This model currently does not include optical impairments. "Distributed Universal Resource Name Resolution based on Distributed DNS", Lican Huang, 4-Aug-08, This file is a proposal for Universal Resource Name resolution based on P2P DNS. "Evaluation of Possible Interior Gateway Protocol Extensions for Wavelength Switching Optical Networks", Dan Li, Jianhua Gao, Young Lee, Jianrui Han, Baoquan Rao, Xinghua Shi, 12-Jul-08, Wavelength Division Multiplexing (WDM) is a technology for optical communications, in which the 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 the Reconfigurable Optical Add-Drop Multiplexer (ROADM) and the Wavelength Selective Switch (WSS), WDM networks have become more dynamic, and operators can flexibly set up wavelength paths to carry user traffic. This document discusses the set of Interior Gateway Protocol (IGP) requirements that would enable distributed light path computation in Wavelength Switched Optical Networks (WSON). An IGP impact analysis is also provided. According to the analysis, there is no significant impact on the IGP performance. "OCSP Algorithm Agility", Phillip Hallam-Baker, 2-Jul-08, The behavior of an OCSP server is specified for cases in which the OCSP server is capable of supporting more than one signature algorithm. "PCEP Requirements and Extensions for WSON Routing and Wavelength Assignment", Young Lee, Greg Bernstein, 27-Oct-08, This memo provides application-specific requirements and protocol enhancements 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. Different computational architectures for the RWA process are given and the PCEP extensions needed to support these architectures are defined. "A lightweight security extension for the Unidirectional Lightweight Encapsulation (ULE) protocol", Michael Noisternig, Bernhard Collini-Nocker, 14-Jul-08, The Unidirectional Lightweight Encapsulation (ULE) protocol is an efficient and extensible transport mechanism for IP over MPEG-2 networks. Such networks are often operated on broadcast wireless channels, and are thus specifically vulnerable to attacks. Passive attacks, such as eaves-dropping, are simple to perform and emphasize the importance of security support within ULE. This document defines a mandatory security extension for the ULE protocol that is designed with the aim of being conservative in bandwidth consumption and lightweight in the sense that it allows for implementation in low-cost, resource-scarce (mobile) receiver devices. The extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses the same extension header mechanism. The document describes the format of the security extension header, specifies default security algorithms to be used with this extension, and gives detailed processing descriptions for devices implementing the security extension. Conventions used in this document The following DVB specific terms are taken from [RFC4326] and recapitulated here for easy lookup: DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 standard [MPEG2]. MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organization (ISO/IEC 13818-1) [MPEG2] and ITU-T [H222]. NPA: Network Point of Attachment. In this document, refers to a 48- bit destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual receivers or groups of receivers. PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. PID: Packet Identifier [MPEG2]. A 13-bit field carried in the header of TS cells. This is used to identify the TS Logical Channel to which a TS cell belongs [MPEG2]. SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 payload unit. TS: Transport Stream [MPEG2]. A method of transmission at the MPEG-2 level using TS cells; it represents layer 2 of the ISO/OSI reference model. TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [MPEG2]. All packets sent over a TS Logical Channel carry the same PID value. ULE: Unidirectional Lightweight Encapsulation [RFC4326]. A protocol that encapsulates PDUs into SNDUs that are sent in a series of TS cells using a single TS Logical Channel. Terms and abbreviations from cryptography are explained when they first appear within this document. All numbers encoded in protocols are to be interpreted in network byte order. "Call on hold for telephony applications of SIP protocol", Daniele Giordano, 20-Aug-08, Many RFCs and Internet Drafts describe call on hold methods adopted in SIP signaling protocol. The actual implementation may not always be ideal for telephony applications (reasons are explained below). This draft proposes a revision of call on hold method for SIP protocol. Giordano [page 1] Internet-Draft Call on hold for telephony applications of SIP protocol "Certificate profile and certificate management for SEND", Suresh Krishnan, Ana Kukec, Khaja Ahmed, 3-Nov-08, Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND including extended key usage values, revocation details and supported extensions. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, 6-Jun-08, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Don Fedyk, Dinesh Mohan, 3-Nov-08, 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].Changes from previous version Technology independent extensions were moved to a separate framework document leaving only the Ethernet specific extensions in this document. "Multiple Interfaced Mobile Nodes in NetLMM", Mohana Jeyatharan, Chan-Wah Ng, Vijay Devarapalli, Jun Hirano, 30-Oct-08, The specific mechanism described in the current PMIPv6 draft to support multihoming is such that a unique prefix is given to each interface of a Mobile Node (MN) that is attached to the PMIPv6 domain. However, multihoming can also be provided using same unique prefix for all interfaces of MN similar to the MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) concept. This memo explores and highlights lack of advanced multihoming support and other hand-off related issues where appropriate in three different mobility management protocol models for multiple interfaced mobile nodes. Firstly, when single prefix is allocated for all interfaces of MN in the PMIPv6 domain. Secondly, when unique prefix is allocated for each interface as in PMIPv6 standard protocol model. Thirdly, when a multiple interfaced node uses different mobility management mechanisms for each of its interfaces. "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 25-Sep-08, 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, 28-Aug-08, 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. "SMTP Service Extension for Indicating Message Authentication Status", Murray Kucherawy, 29-Sep-08, 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. "Problem Statement and Requirement: Mobile Multicast", Hui Deng, Peng Yang, 13-Jul-08, This document discusses the problem and requirement of multicast solution in the mobile networks. One current issue in mobile multicast solution has been raised and requirements of mobile IPTV on multicast mobility will also be summarized especially for some mechanisms such as the tunneling, service capability and security discussion which is basis of supporting the mobile IPTV applications. "Requirement for Multicast MPLS/BGP VPN Partitioning", Maria Napierala, 24-Jun-08, This document describes a requirement for Multicast IP VPN solutions to allow the same multicast stream to flow simultaneously on multiple inter-PE paths without duplicates being sent to receivers. It is intended that existing and new solutions to MPLS/BGP Multicast IP VPN's will support this requirement. "Load Balancing Fat MPLS Pseudowires", Stewart Bryant, Clarence Filsfils, Ulrich Drafz, 9-Jul-08, 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 that exist in the packet switched network. 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, 14-Jul-08, 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. "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 3-Nov-08, This document provides with a list of more or less detailed Media Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] call flows. It aims at being a simple guide throughout the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a hopefully helpful base reference documentation for both implementors and protocol researchers. "MVPN Profiles Using PIM Control Plane", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 3-Jul-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. "Teredo Security Updates", Dave Thaler, Suresh Krishnan, James Hoagland, 14-Oct-08, The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. "End-Host Authentication for HIP Middleboxes", Tobias Heer, Klaus Wehrle, Miika Komu, 7-Jul-08, The Host Identity Protocol [RFC2119]is a signaling protocol for secure communication, mobility, and multihoming by introducing 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 enables middleboxes to verify the liveness and freshness of a HIP association and, thus, enables reliable and secure access control in middleboxes. "An HTTPS Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 14-Jul-08, This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference into 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. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), BGP Community Extension", Jeffrey Haas, 2-Nov-08, 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's Community extension. "Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 4-Jun-08, The key concepts of uncertainty and confidence as they pertain to location information are defined. A form for the representation of confidence in Presence Information Data Format - Location Object (PIDF-LO) is described, optionally including the form of the uncertainty. Suggested methods for the manipulation of location estimates that include uncertainty information are outlined. "Automatic Generation of Site IDs for Virtual Private LAN Service", Bhupesh Kothari, Kireeti Kompella, Thomas Spencer IV, 29-Oct-08, This document defines procedures that allow for Virtual Private LAN Service (VPLS) provider edge (PE) devices that use BGP in the control plane to automatically generate VE ID values in a consistent manner. "Proxy Mutual Authentication in SIP", Steve Dotson, Stuart Hoggan, Sumanth Channabasappa, 10-Jun-08, This document defines the Proxy-Authentication-Info header field for the Session Initiation Protocol (SIP). When a UA is required to authenticate to a proxy using digest authentication specified in SIP this header field allows for the UA to authenticate the proxy, enabling mutual authentication. This header field can also provide integrity checks over the bodies. "What Makes For a Successful Protocol?", Dave Thaler, Bernard Aboba, 27-May-08, The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. "Extension to the ua-profile Event Package to Support the Application Profile Type", Martin Dolly, Sumanth Channabasappa, Joshua Littlefield, Salvatore Loreto, 2-Nov-08, The Framework for Session Initiation Protocol User Agent Profile Delivery specifies an event package (ua-profile) that can be used by user agents to retrieve profile data. The framework also allows for optional notification of changes to the retrieved profiles. Three profile types are specified: local-network, device, and user. This document extends that event package to support an additional profile type, application. This would enable User Agents to retrieve profile data specific to one or more applications. "DTLS-SRTP Key Transport", Dan Wing, 14-Jul-08, 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 RTP 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. "Multicast tunneling optimization for Mobile IPv6", Peng Yang, 14-Jul-08, This document provides the solution to optimize the multicast tunneling in mobile IPv6. This solution will not break the basic bi- directional tunneling multicast solution of MIPv6. A new Mobile Multicast Agent works as a proxy node for multiple mobile nodes within one limit scope. Single tunnel is set up between one Home Agent and one Mobile Multicast Agent for single multicast stream. A new notification message is created for the communication between home agent and mobile multicast agent. There is no modification on mobile nodes. "On Mobile IPv6 Optimization and Multihoming", Chan-Wah Ng, Keigo Aso, 8-Jul-08, This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651. "Multiple Interface Support with Proxy Mobile IPv6", Vijay Devarapalli, Nishi Kant, Heeseon Lim, Christian Vogt, 22-Aug-08, 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. "Using and Extending the NSIS Protocol Family", Jukka Manner, Roland Bless, John Loughney, Elwyn Davies, 3-Nov-08, 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-2008 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. "Multi-homing in BGP-based Virtual Private LAN Service", Kireeti Kompella, Bhupesh Kothari, Thomas Spencer IV, 3-Nov-08, 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 BGP-based VPLS. "Definition of Master Key between PANA Client and Enforcement Point", Yoshihiro Ohba, 24-Oct-08, This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points across different types of lower-layers. "Performance Evaluation of PCN-Based Algorithms", Michael Menth, Frank Lehrieder, 4-Jul-08, This document presents a summary of performance studies for PCN-based admission control and flow termination. The numerical results were obtained by simulation or mathematical analysis. "Ad-Hoc IP Autoconfiguration Solution Space Analysis", Carlos Bernardos, Maria Calderon, Hassnaa Moustafa, 1-Nov-08, This draft aims at analysing the solution space for the ad hoc IP autoconfiguration problem, based on the problem statement draft and the MANET architecture draft. Some evaluation considerations, are also taken into account. This draft classifies, at a generic level, the solution space of the possible approaches that could be followed to solve the IPv6 autoconfiguration for MANETs problem. The various approaches of IPv6 autoconfiguration for MANETs are illustrated, and the benefits and tradeoffs in different aspects of IPv6 autoconfiguration are explored. "Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless Mesh Network scenarios", Carlos Bernardos, Maria Calderon, Ignacio Soto, 2-Nov-08, This Internet Draft presents the multi-hop Backbone Wireless Mesh Network scenario, summarising its basic characteristics and describing the requirements and desired properties of an IP Autoconfiguration mechanism aimed at being used in this kind of networks. Once that the AUTOCONF WG has almost finalised the documents that describe the general architecture of MANETs and the IP autoconfiguration problem statement in MANETs, the WG is expected to start working on solutions. This document describes an ad-hoc scenario that is getting a lot of attention from both telecommunication operators and end-users: Backbone/infrastructure Wireless Mesh Networking. This document identifies and explains the requirements posed by this particular scenario to an IP autoconfiguration mechanism. The goal is to help the AUTOCONF WG identify the requirements that need to be taken into account when designing IP autoconfiguration solution(s) suitable for this Wireless Mesh environment. "IANA Registration for Encrypted ENUM", Ben Timms, Jim Reid, Jakob Schlyter, 12-Jul-08, This document requests IANA registration of the "X-Crypto" Enumservice. This Enumservice indicates that its NAPTR holds a Uniform Resource Identifier that carries encrypted content from the fields of another (unpublished) Protected NAPTR, for use in E.164 Number Mapping (ENUM). "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, 11-Aug-08, 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. "IGMP/MLD Error Feedback", Thomas Morin, Brian Haberman, 3-Nov-08, This document describes messages and procedures that can optionally be implemented in IGMP/MLD Queriers and Hosts, to provide information to multicast receivers on the reason why the IGMP/MLD Querier didn't take into account a Membership Report message. "The Zone Status (ZS) DNS Resource Record", Jim Reid, 4-Jul-08, A Domain Name System (DNS) resource record which provides status information about a zone is described in this document. "Rogue IPv6 Router Advertisement Problem Statement", Tim Chown, Stig Venaas, 3-Nov-08, 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. However, unintended misconfigurations 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. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. "Mediator-Specific Extensions to IPFIX Protocol and Information Model", Christoph Sommer, Falko Dressler, Gerhard Muenz, 14-Jul-08, IPFIX supports the concept of a Mediator, a device that receives, transforms, and exports data streams using IPFIX. One of the most important requirements is the reduction of the volume of IPFIX traffic by aggregating and discarding received information. This document introduces a number of extensions to the IPFIX Information Model that support the export of aggregated IPFIX data, introducing abstract data types and Information Elements that optimize the transport of descriptive information in terms of flow records' amount and size. All extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well. "MPLS and Ethernet OAM Interworking", Dinesh Mohan, Nabil Bitar, Simon Delord, Philippe Niger, 8-Jul-08, 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. "Problem Statement: Transport Protocols Don't Have To Do Fairness", Bob Briscoe, T Moncaster, Anne-Louise Burness, 14-Jul-08, The Internet is an amazing achievement - any of the thousand million hosts can freely use any of the resources anywhere on the public network. At least that was the original theory. Recently issues with how these resources are shared among these hosts have come to the fore. Applications are innocently exploring the limits of protocol design to get larger shares of available bandwidth. Increasingly we are seeing ISPs imposing restrictions on heavier usage in order to try to preserve the level of service they can offer to lighter customers. We believe that these are symptoms of an underlying problem: fair resource sharing is an issue that can only be resolved at run-time, but for years attempts have been made to solve it at design time. In this document we show that fairness is not the preserve of transport protocols, rather the design of such protocols should be such that fairness can be controlled between users and ISPs at run-time. "Network Scaling with Aggregate LSPs", George Swallow, Jim Guichard, Intellectual Property, 7-Jul-08, This document defines a means for an Multiprotocol Label Switched network to summarize routes while maintaining end-to-end LSP connectivity thereby reducing the number of host routes that need to be carried within the interior gateway protocol.Contents "LISP Alternative Topology (LISP+ALT)", Vince Fuller, Dave Meyer, Dino Farinacci, 22-Oct-08, 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. "Point-to-Multipoint Pseudowire Signaling and Auto-Discovery in Layer 2 VPNs", Rahul Aggarwal, 13-Jul-08, A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). [RFC4664] describes a number of different ways in which sets of PWs may be combined together into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. P2MP PWs enable a L2VPN to provide a Virtual Private P2MP unidirectional service (VPMS), which may be in addition to the Virtual Private Wire Service (VPWS) offered by the L2VPN. This document describes how procedures outlined in [VPLS-MCAST] can be used to signal P2MP PWs and enable a P2MP unidirectional service in a L2VPN. "VPLS OAM", Dinesh Mohan, Ali Sajassi, Deborah Brungard, Henry Fowler, Simon Delord, Philippe Niger, 12-Jul-08, This document provides a comprehensive end-to-end solution for VPLS Operation, Administration and Maintenance (OAM). This solution is based on the L2VPN OAM framework [L2VPN-OAM-REQ-FRMK] and specifies how to meet the requirements set therein. "BGP protocol extensions using attribute for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 28-Oct-08, It is highly desirable for Path Computation Clients (PCCs) to be able to dynamically discover a set of Path Computation Elements (PCEs) when PCCs/PCEs request a path computation to PCEs within an AS and across ASs. In such a scenario, specifically 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, 21-Aug-08, 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. "Mobile Multicast Requirements on IGMP/MLD Protocols", Hui Liu, Hitoshi Asaeda, 13-Oct-08, This document presents the requirements for IGMP/MLD protocols to allow the deployment of mobile multicast service. It is intended to provide useful guideline when adapting current IGMP/MLD protocols to support terminal mobility. "IGMP and MLD Extensions for Mobile Hosts and Routers", Hitoshi Asaeda, Thomas Schmidt, 14-Jul-08, 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, an optional "Listener Hold" function for the IGMP and MLD protocol is introduced, which requires an extended signaling. "Camellia Counter mode and Camellia Counter with CBC Mac mode algorithms", Akihiro Kato, Masayuki Kanda, 16-Sep-08, This document describes the algorithms and test vectors of Camellia block cipher algorithm in Counter mode and Counter with Cipher Block Chaining MAC mode. The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. "A Session Description Protocol (SDP) Control Package Attribute", Chris Boulton, 20-Aug-08, 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. "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 7-Oct-08, 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. "Providing guidance for Session Initiation Protocol (SIP) services", Arnaud Ligot, Thomas Froment, 11-Jul-08, Implementing Session Initiation Protocol (SIP) advanced features and services requires to use numerous specifications. Today, for each service in the scope of BLISS, one can already find references to many possible specifications which do not cover the same things. Some of them are primitive operations, requirements or call flow examples, some have a scope larger than the others, or can not be compared at the same level. Very often, architecture hypothesis are hidden behind the same service name, either assuming that an intermediary; like an application server, has an active role in the service, or, as opposed, assuming a pure end-to-end model where only endpoint implementations are involved. The goal of this document is not to present the best solutions or give recommendations; but to give an overview of every standard specification related to these services, centralizing and categorizing them as input to the working group. "Service Identfiers Option for DHCPv6", Hui Deng, Hong Liu, Bernie Volz, 3-Nov-08, This document describes a new option for DHCPv6 [RFC3315] that provides a mechanism for specifying a list of service identifer which this connection support or don't support. "Verification of Care-of Addresses in Multiple Bindings Registration", Benjamin Lim, Chan-Wah Ng, Keigo Aso, Suresh Krishnan, 10-Jul-08, Using multiple care-of address registration, there is a possibility that a malicious mobile node could create multiple care-of address bindings that does not belong to the mobile node at its home agent. The home agent would accept these bindings without verifying them due to the trust relationship it has with the mobile node. With these bindings, the mobile node can launch attacks by asking the home agent to flood the victims of these care-of addresses with useless packets. To mitigate such a problem, this memo introduces a few possible verification mechanisms that the home agent would use in order to verify the care-of addresses for the mobile node before using them for packet routing. "An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol", Roland Bless, 8-Jul-08, The standard operation of the General Internet Signaling Transport (GIST) Protocol uses a path-coupled message routing method (PC-MRM) to find nodes interested in signaling message exchanges. This specification proposes an Explicit Signaling Target Message Routing Method (EST-MRM) in order to allow sending of signaling messages to explicit targets. "Reporting of DKIM Verification Failures", Murray Kucherawy, 10-Jul-08, 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. "Roaming Mechanism between PMIPv6 Domains", Jee-Hyeon Na, Soochang Park, Jung-Mo Moon, Sangho Lee, Euisin Lee, Sang-Ha Kim, 10-Jul-08, Proxy Mobile IPv6 (PMIPv6) is designed to provide mobility service to mobile nodes in the network domain which does not require the mobile nodes to be involved in IP mobility management. In other words, the PMIPv6 can transparently support roaming within a PMIPv6 domain, i.e. intra-domain roaming, to mobile nodes. However, if the mobile nodes move to other PMIPv6 domains, the nodes should have additional protocols for the inter-domain roaming although the domains also provide the transparent mobility. Hence, an inter-domain roaming solution would be needed for providing transparent mobility to mobile nodes that only move around among PMIPv6 domains. This document specifies the inter-domain roaming controlled by the networks adopting the PMIPv6. "DHCP Segmentation/Reassembly using SEAL", Fred Templin, 30-Jul-08, IP fragmentation has been shown to be problematic through operational experience and through studies conducted over the course of many years. Some transports (e.g., TCP) have the abilitiy to adjust their message sizes to avoid IP fragmentation, however no such capability is built into the UDP transport. UDP applications such as DHCP must therefore have a means to perform their own segmentation prior to submitting their data to UDP/IP in order to avoid IP fragmentation. This document specifies a segmentation/reassembly capability for DHCP using SEAL. "An overload control package for the Session Initiation Protocol (SIP).", Youssef Chadli, Xavier Marjou, 11-Jul-08, 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. "UDP Traceroute Message Extension", Naiming Shen, Carlos Pignataro, Rajiv Asati, Enke Chen, 7-Jun-08, This document specifies an extension to UDP traceroute messages that allows the UDP traceroute probe packets to be authenticated by the intermediate nodes and the destination node. This extension can also include requests for node specific information that the sender is interested to receive from one or more nodes via the traceroute replies. "Proactive Bindings for FMIPv6", Faqir Yousaf, Christian Wietfeld, 14-Jul-08, Usually in FMIPv6, the MN will start the binding process with its home agent and the correspondent nodes after it has attached to NAR. Till the binding is completed, the mobile node continues to receive packets via a reverse tunnel established between PAR and NAR. The duration of this tunnel will depend on the time it takes for the mobile node to complete its binding, till which time the tunnel will continue to consume buffer and processing resources related to maintaining the tunnel and forwarding packets through this tunnel in both PAR and NAR. This document specifies an extension to FMIPv6 to enhance its performance, in terms of resource management, by reducing the duration of the tunnel existence. This is achieved by enabling the NAR to act as a proxy for the MN for FMIPv6 handover. Additional message(s) and message options along with modifications to existing FMIPv6 messages and message options and definitions of new messages and message options to achieve the desired functionality is also described in this document. "Diagnose P2PSIP Overlay Network Failures", Song Yongchao, Hewen Zhang, XingFeng Jiang, 3-Nov-08, This document describes P2PSIP diagnostics. It extends the methods defined in the base protocol for the diagnostics in P2PSIP overlay network. A new method Echo is an efficient method used in the trusted overlays for retrieving useful diagnostic information. The methods and message formats are consistent with P2PSIP base protocol RELOAD, and the diagnostic information mainly comes from the previous version-02 of this document. "Interworking LISP with IPv4 and IPv6", Darrel Lewis, Dave Meyer, Dino Farinacci, Vince Fuller, 11-Jul-08, 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. "Clearance Attribute and Authority Clearance Constraints Certificate Extension", Sean Turner, Santosh Chokhani, 1-Nov-08, 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. "Specifying Location Quality Constraints in Location Protocols", Martin Thomson, James Winterbottom, 26-May-08, 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 the desired constraints on the quality of the location information provided. 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 constraints were met is defined to be provided by the Location Server alongside location information. "Other Certificates Extension", Stephen Farrell, 8-Jul-08, 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 supports such linkage that can allow applications to establish the required linkage without introducing a new application protocol data unit. "Retriving MIB Information based on NGI", JinXiang Zhang, 8-Oct-08, An important task of network management is to collect and analyze MIB information of various object combinations based on the Simple Network Management Protocol (SNMP) with proper frequency. The purpose of this document is to propose two algorithms to retrieve MIB information for a large (up to exponential) number of managed objects using SNMP in Next Generation Internet (NGI). "L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro, 25-Jun-08, 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 Access Circuits and Pseudowires. It also deprecates the use of the New bit in the "Circuit Status" AVP, updating RFC3931. "XESP for Traffic Visibility", Ken Grewal, 23-Jun-08, This document describes an ESP encapsulation for IPsec, allowing 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. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 5-Aug-08, 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): One-to-One Text Chat", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 10-Jul-08, 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). "On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", Wassim Haddad, Mats Naslund, 13-Jul-08, This document introduces a simple mechanism which enables a host using IPv6 cryptographically generated address to delegate the task of secure neighbor discovery proxying to another node by means of establishing a "symbiotic" relationship with that node. "On Using 'Symbiotic Relationship' to Repel Network Flooding Attack", Wassim Haddad, Mats Naslund, 26-Oct-08, This memo describes a simple defense mechanism against a specific type of network flooding attacks. The suggested mechanism requires a mobile node to establish a 'symbiotic relationship' with the infrastructure, in order to empower it to repel such attack while giving enough insurance to the source(s) of the traffic about the need to cease sending traffic to the targeted network. "Syntax for binding documents with time stamps", Adriano Santoni, 10-Jun-08, This document describes a syntax which can be used to bind a generic document (or any set of data, not necessarily protected by means of cryptographic techniques) to one or more time-stamp tokens obtained for that document, where "time-stamp token" has the meaning defined in RFC 3161. Additional types of temporal evidence are also supported. Santoni Expires December 10, 2008 [page 1] Internet-Draft timestampeddata June 2008 This document proposes a simple syntax based on the Cryptographic Message Syntax (RFC 3852). "LDP extension for AII reachability", Luca Martini, Philippe Niger, Yaakov Stein, Frederic JOUNAY, Matthew Bocci, Simon DeLord, 22-Sep-08, 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. "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, 2-Nov-08, 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. "Digital Signatures on Internet-Draft Documents", Russ Housley, 21-Aug-08, This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. "Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)", Salvatore Loreto, 14-Jul-08, This document registers with IANA two new DNS SRV Protocol Labels for resolving Instant Messaging and Presence services with SIP. "Connecting IPv6 Islands over IPv4 MPLS networks using IPv6 Provider Edge Routers (6PE-Alt)", Vishwas Manral, 4-Sep-08, This document provides an alternate mechanism to [6PE] to interconnect IPv6 routes over MPLS-enabled IPv4clouds. This approach relies on IPv6 Provider Edge routers (6PE-Alt) which are Dual Stack in order to connect to IPv6 islands and to the MPLS core which is only required to run IPv4 MPLS and run the mechanism as described in this document. The 6PE-Alt routers exchange the IPv6 reachability information transparently over the core using the Multi-Protocol Border Gateway Protocol (MP-BGP) over IPv4 or IPv6. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE-Alt router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. Unlike [6PE] case the labels are not sent with each route and does not use BGP to transport labels [RFC3107]. It instead makes use of the IPv6 Explicit NULL label as the VPN label, which is defined [RFC3032] and updated in [RFC4182]. This document elegantly uses the concept of non overlapping IPv6 routes to provide BGP MPLS IP VPN functionality. The document can be further used for provinding the functionality in case of non-overlapping IPv6 routes. This approach allows a functionality similar to [RFC4659], without the cumbursome extensions required for the same. With the [RFC3879] IPv6 addresses are now globally unique (except for Link local). It also reduces the number of multi AS scenarios. "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos Mavrogiannopoulos, 26-Oct-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. "sNAT-PT: Simplified Network Address Translation - Protocol Translation", Hiroshi Miyata, Masahito Endo, 29-Sep-08, This document specifies an IPv4-to-IPv6 transition mechanism to provide accessibility for IPv6 node to IPv4 node, and vice-versa. The goal of this document is not providing the most fundamental technology which could works well with additional technology. We used to have an technology called NAT-PT[RFC2766]. NAT-PT was designed to work with problematic DNS Application Level Gateway. So, it was changed to historical state by [RFC4966]. This document attempts to simplify NAT-PT specification, removing dependability on Application Layer Gateway as well as resolving problems pointed in [RFC4966]. "Shim6 Implementation Report : LinShim6", Sebastien Barre, 11-Jul-08, 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, 2-Jun-08, 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. "Indicating Support for Basic Media Server Capabilities in the Session Initiation Protocol (SIP)", Chris Boulton, 20-Aug-08, This specification defines a profile set of media feature tags that can be used with the Session Initiation Protocol (SIP). The media feature tags allow a Media Server to communicate a basic set of media server capabilities that are supported to its Application Server. "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. "IMAP Response Codes", Arnt Gulbrandsen, 27-Oct-08, IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code and a human-readable text. This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting.1. Conventions Used in This Document Formal syntax is defined by [RFC5234] as modified by [RFC3501]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. "Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, 17-Nov-08, This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a routing protocol for intermittently connected networks, where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where the Delay-Tolerant Network architecture[1] is applicable. The document presents an architectural overview followed by the protocol specification. "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. "XCAST6 (version 2.0) Protocol Specification", Yuji Imai, Takahiro Kurosawa, Nobuo Kawaguchi, Eiichi Muramoto, 17-Aug-08, This document describes the specification of Xcast6 (Explicit Multi- unicast (Xcast) for IPv6), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. The difference from the experimental specification which is described in [5058] is that this version eliminates Hop-by-Hop header which sometimes suffers hardware router. "Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 8-Aug-08, This document registers new disposition-types for the Content- Disposition header 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. "A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework", Lorenzo Miniero, Simon Romano, Roni Even, Scott McGlashan, 8-Jul-08, This document defines a Media Control Channel Framework Package for BFCP-based conference moderation. The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks. This Control Package aims at adding BFCP functionality to conferences using the Media Control Channel Framework. "Enabling an Enhanced Care-of Address Reachability Test for the Home Agent", Wassim Haddad, Francis Dupont, 14-Jul-08, 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. "PIM Group-to-RP Mapping", Bharat Joshi, Andy Kessler, David McWalter, 11-Jun-08, Each PIM-SM router in a PIM Domain which supports ASM maintains Group-to-RP mappings which are used to identify a RP for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not allow administrator to override a specific Group-to-RP mapping with the static Group-to-RP mapping which an administrator would want to use. This algorithm also does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT)", Thomas Phelan, 31-Oct-08, This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-NAT. This encapsulation will allow DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. "More Features for TWAMP", Al Morton, Kaynam Hedayat, 13-Jul-08, The IETF is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes additional features for TWAMP, essentially the ability to use different security modes in the TWAMP-Control and TWAMP-Test protocols. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus Westerlund, David Singer, 14-Jul-08, This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, 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 intends to obsolete RFC 3984. "Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network", Tina Tsou, Fortune Huang, Tom Taylor, 3-Nov-08, This document is written to help coordinate work on pre-congestion notification (PCN) between the IETF PCN Working Group and the ITU-T. It maps the use of PCN into the ITU-T transport control architecture. It examines three scenarios, showing in each, where new requirements are placed on the ITU-T architecture. In each case, the ITU-T functional entity known as the Transport Resource Control Functional Entity (TRC-FE) is seen as the logical destination for PCN congestion reports and PCN flow termination reports, which it uses to keep track of network status. As logical entities, instances of the TRC-FE can be present in the ingress nodes, in one or more centralized devices, or in both. These alternatives define the scenarios examined. "SIP E.164 Problem Statement", John Elwell, 25-Oct-08, SIP has long supported the use of both email-style addresses (user@host) and telephone-style addresses (number@host) in the "From:" address. A significant number of SIP deployments use the latter style with E.164 numbers. This document describes the problems that occur when such E.164 numbers are used in SIP. "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Jonathan Rosenberg, 14-Jul-08, Interative Connectivity Establishment (ICE) has been specified as a NAT traversal mechanism for protocols based on the offer/answer exchange model. In practice, only the Session Initiation Protocol (SIP) has used ICE. This document provides guidance on how other protocols can make use of ICE. "Linguistic Guidelines for the Use of Arabic Characters in Internet Domains", Abdulaziz Al-Zoman, Ayman El-Sherbiny, Mansour Farah, Ibaa Oueichek, 22-Oct-08, This document constitutes technical specifications for the use of Arabic characters 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. "Session Based Trivial Object Transfer and Exchange (TOTE)", Jonathan Rosenberg, 3-Nov-08, This document defines a simple protocol - Trivial Object Transfer and Exchange (TOTE) - that provides bidirectional exchange of MIME objects over a TCP connection. It is used in conjunction with protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). TOTE can be used for any application requiring direct agent-to-agent data communication, such as picture exchange or camera controls. "Usage of Host Generating Interface Identifier in DHCPv6", Frank Xia, Behcet Sarikaya, Sheng Jiang, 1-Nov-08, This document describes a procedure for configuring a host's IPv6 address which prefix is allocated from a DHCPv6 server while it's interface identifier is independently generated by the host. The method is applicable to Cryptographically Generated Addresses (CGA). "IPFRR in the Presence of Multiple Failures", Stewart Bryant, Mike Shand, 30-Oct-08, IP Fast Reroute (IPFRR) work in the IETF has focused on the single failure case, where the failure could be a link, a node or a shared risk link group. This draft describes possible extensions to not-via IPFRR that under some circumstances allow the repair of multiple simultaneous failures. "Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO Method", Jonathan Rosenberg, 3-Nov-08, The Session Initiation Protocol (SIP) Working Group is considering the standardization of a framework for conveying application data through the INFO method. However, the INFO method is just one of several techniques available in SIP for the transfer of application data. Others include through the SIP events framework and through a media session. This document provides guidelines and litmus tests for determining which is the right technique to use. "DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 16-Jun-08, 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. "ILNP Concept of Operations", Randall Atkinson, 11-Jun-08, This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator Network Protocol (ILNP). "Conventions for the Use of the Session Description Protocol (SDP) for Circuit-Switched Bearer Connections in the Public Switched Telephone Network (PSTN)", Miguel Garcia-Martin, Simo Veikkolainen, 30-Oct-08, This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). "Updates to LDP for IPv6", Vishwas Manral, Rajiv Papneja, 4-Sep-08, LDP is defined in [RFC5036]. LDP (for Label Distribution Protocol) defines procedures for LSRs to distribute labels to support MPLS forwarding along normally routed paths. LDP is a protocol defined for distributing labels. It is the set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes. The LDP procedures are defined for both IPv4 and IPv6 networks. This document corrects and clarifies the LDP behavior for IPv6 networks as defined in [RFC5036] for helping in better interoperability between implementations. "TraceFlow", Arun Viswanathan, Subi Krishnamurthy, Rajeev Manur, Vishal Zinjuvadia, 16-Aug-08, This document describes a new OAM protocol - TraceFlow that captures information pertaining to a traffic flow along the path that the flow takes through the network. TraceFlow is ECMP and link-aggregation aware and captures the information about constituent members through which the traffic flow passes. TraceFlow gathers information that is relevant to the flow such as interface address, interface statistics, effect of network policies on the flow and so on. "Mechanisms for safely abandoning loop-free convergence (AAH)", Mike Shand, Stewart Bryant, Pierre Francois, 31-Oct-08, IPFRR and loop-free convergence techniques can deal with single topology change events, multiple correlated change events, and in some cases even certain uncorrelated events. However, in all cases there are events which cannot be dealt with and the mechanism needs to quickly revert to normal convergence. This is known as "Abandoning All Hope" (AAH). This document describes the nature of the problem, and various proposed mechanisms to deal with it. "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Salvatore Loreto, Gonzalo Camarillo, 3-Nov-08, 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' protocol identifier for SDP. "A BGP Inter-AS Cost Attribute", Iljitsch van Beijnum, 3-Nov-08, 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. "Locater ID proposal evaluation", Anne-Louise Burness, Philip Eardley, Luigi Iannone, 14-Jul-08, There are many proposals for improving the Inter-domain routing system, most of which involve a form of locater-identity split. There needs to be a means to reason about the strengths of the different proposals against the design criteria, and without requiring large scale implementations. This document aims to start this process by drawing parallels with existing systems. It identifies a number of questions that need to be more fully thought about whilst we press ahead with system development. "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. "OpenLISP Implementation Report", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 16-Jul-08, The RRG is working on the design of an alternate Internet Architecture in order solve issues of the current architecture related to scalability, mobility, multi-homing, and inter-domain routing. Among the various proposals, LISP (Locator/ID Separation Protocol) is one of the most advanced. The present draft describes the overall architecture of OpenLISP, an open source implementation of the LISP proposal. Further, the draft contains some general remarks concerning the design and the implementation of the LISP protocol. "HIP Certificates", Tobias Heer, Samu Varjonen, 14-Jul-08, This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates. It is used for carrying these certificates in HIP control messages. Additionally, this document specifies the representations of Host Identity Tags in SPKI and X.509.v3 certificates. "IDIPS : ISP-Driven Informed Path Selection", Damien Saucez, Benoit Donnet, Olivier Bonaventure, 3-Nov-08, This draft describes a simple network-based protocol to facilitate Path Selection and to improve traffic engineering capabilities in multihomed corporate networks. With the protocol, any network device that requires to select a path among a list of different paths asks a Traffic Engineering service called IDIPS (ISP-Driven Informed Path Selection) to obtain an ordered list of the possible paths. The ordering is constructed according to the policies and performances requirements of both the host and network provider. "Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 4-Nov-08, 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. "Mobile IPv6 Residual Threats", Wassim Haddad, George Tsirtsis, Benjamin Lim, Suresh Krishnan, Francis Dupont, 14-Jul-08, This memo aims to highlight specific "residual" threats in Mobile IPv6 protocol. We call these threats "residual" simply because they were rightfully deemed not urgent during the design of Mobile IPv6 protocol. However, these threats are somehow benefiting from new mechanisms and/or extensions built on top of Mobile IPv6 protocol to improve their effects and likelihood. Hence, our main goal is to motivate designers to re-assess their potential taking into consideration these new mechanisms. "The Session Initiation Protocol (SIP) P-Private-Network-Indication Private-Header (P-Header)", Hans Erik van Elburg, Keith Drage, 11-Jul-08, 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. "Vendor Specific Message for ANCP.", Peter Arberg, 3-Nov-08, This document is aimed at presenting Access Node Control Protocol (ANCP) with vendor specific protocol extensions. "SIP Usage Scenarios Similar to SPIT", Dan York, 14-Jul-08, This document outlines scenarios in which legitimate SIP traffic may appear similar to traffic associated with voice spam, also known as "SPIT" or "Spam for Internet Telephony. This document is created to provide input into the current discussions about how best to address the issue of SPIT. "Diameter ITU-T Rw Policy Enforcement Interface Application", Dong Sun, 18-Nov-08, This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ responses for authorizing network QoS resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). "The Uniform Resource Identifier (URI) DNS Resource Record", Patrik Faltstrom, Olaf Kolkman, 3-Nov-08, This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. "Simultaneous Mobility Problem Statement", Daniel Wong, Ashutosh Dutta, Henning Schulzrinne, 10-Jul-08, This document provides a problem statement for simultaneous mobility in an infrastructure-based mobility environment. It considers what the simultaneous mobility problem is and describes the conditions under which it may occur. It also illustrates the occurrence of the simultaneous mobility problem in the context of different mobility protocols such as Mobile IPv6. The simultaneous mobility problem defined here is strictly applied to scenarios when the intermediary nodes in the core are not mobile. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 3-Nov-08, 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. "ProxyMIP Extension for Inter-MAG Route Optimization", Ashutosh Dutta, Subir Das, Hidetoshi Yokota, Tsunehiko Chiba, Henning Schulzrinne, 13-Jul-08, This draft describes a light weight route optimization technique that helps to optimize the media path between two communicating nodes when Proxy MIP is used as the mobility protocol. This routing optimization technique is most useful when the two communicating hosts are away from home and need to communicate with each other using an optimized path. It takes advantage of the data packet between LMA and MAG to set up the optimized data path between the communicating hosts. This route optimization technique is applicable to both the intra-LMA and inter-LMA scenarios. "RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", Ali Begen, 11-Sep-08, This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, 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 non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. "Provisioning Protocol Requirements for ENUM-SIP Addressing Servers", Tom Creighton, Jean-Francois Mule, 14-Jul-08, This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by the addressing server to return session establishment data for SIP entities to route SIP requests to the target destinations. An ENUM-SIP addressing server acts as a Lookup Function in session peering to determine the target domain of a given SIP request. It may also act as a Location Routing Function to develop the location of the SIP signaling entity in the target domain. "A Provisioning Protocol for ENUM-SIP Addressing Servers", Kenneth Cartwright, Stephen Dimig, Mark Teodoro, Jean-Francois Mule, 14-Jul-08, This document defines a provisioning protocol for ENUM-SIP addressing servers. An ENUM-SIP addressing server is a host that acts as Lookup Function in session peering to determine the target domain of a given SIP request and it may also act as a Location Routing Function to develop the location of the SIP signaling entity in that target domain. This protocol allows SIP service providers to provision and manage session establishment data used by SIP network elements to route SIP sessions to the target destinations which may be served by the SIP service provider's own internal network or by a session peering partner. The data provisioned into an ENUM-SIP addressing server is queried by SIP entities using ENUM or SIP. This version of the protocol integrates comments received on the IETF peppermint and drinks mailing lists before July 2008. This document is an Internet-Draft and the protocol it describes is subject to technical changes that may make this version incompatible with future versions defined in Internet-Drafts. It is expected that the authors will continue to update this protocol based on the drinks working group requirements on the session establishment data. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 15-Jun-08, 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. "Representing Netconf Data Models using Document Schema Definition Languages (DSDL)", Rohan Mahy, Sharon Chisholm, Ladislav Lhotka, 8-Jul-08, This document describes a concrete approach for representing Netconf and other IETF data models using the RelaxNG schema language and the Schematron validation language, which are both part of ISO's Document Schema Definition Languages (DSDL) standard. "Hierarchical Host Identity Tag Architecture", Sheng Jiang, 28-Oct-08, 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 HITs generation ensure the global uniqueness of HITs. It 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. "Requirements for GMPLS applications of PCE", Tomohiro Otani, Kenichi Ogaki, 14-Jul-08, The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). "Routing System Stability", Dimitri Papadimitriou, James Lowe, 29-Jul-08, 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. "Kerberos Option for DHCPv6", Masahiro Ishiyama, Shoichi Sakane, 30-Oct-08, 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 in 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. "Ivip Mapping Database Fast Push", Robin Whittle, 20-Aug-08, Ivip (Internet Vastly Improved Plumbing) is a proposed map-encap system which is intended to provide a solution for the routing scaling problem - supporting growing numbers of end-user networks with multihoming, traffic engineering and portability, without further growth in the global BGP routing table. Ivip is also intended to provide other benefits, including a new form of IPv4 and IPv6 mobility and better utilization of IPv4 address space. To achieve these benefits, Ivip relies on a "fast mapping database push" system, which is required to securely and reliably deliver updates to the mapping database to hundreds of thousands - or potentially millions - of ITRs (Ingress Tunnel Routers) and Query Servers (QSes) all over the Net, ideally within a few seconds. This ID describes the requirements of such a system and how it could be implemented so as to cope with very large numbers of updates and ITR/QS sites. "RBridges: Use of IS-IS", Donald Eastlake 3rd, Radia Perlman, Dinesh Dutt, 3-Nov-08, RBridges implement the TRILL protocol, which in turn makes use of an extended version of the IS-IS (Intermediate System to Intermediate System) routing protocol to determine topology and frame forwarding and for the distribution and synchronization of data. RBridges provide optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and multipathing for both unicast and multicast traffic. Rbridges also support VLANs. This document specifies some details of IS-IS PDUs used in TRILL. "EAP Method Support for Transporting AAA Payloads", Charles Clancy, 31-Jul-08, 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. "Channel Binding Support for EAP Methods", Charles Clancy, Katrin Hoeper, 3-Nov-08, This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS problem. "Cryptographic Algorithm Implementation Requirements for Routing Protocols", Manav Bhatia, Vishwas Manral, 3-Nov-08, The interior gateway routing protocols OSPFv2 [RFC2328], IS-IS [ISO] [RFC1195] and RIP [RFC2453] currently define clear text and 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 and OSPF. 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. "Security Parameter Index multiplexed Network Address Translation (SPINAT)", Jan Melen, Jukka Ylitalo, Patrik Salmela, 27-Jul-08, This drafts defines a Security Parameter Index multiplexed Network Address Translator (SPINAT). The SPINAT method uses the SPI value of ESP packets to de-multiplex multiple IP addresses on single IP address. The solution presented in this draft requires a state in the SPINAT node and in the peer node. The state establishment requires a control signaling messages carrying the SPI values. "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, 28-Jul-08, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. This document specifies compression of well-known multicast addresses and a framework for compressing next headers. UDP compression is specified within this framework. "Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood, Peter Holliday, 31-Oct-08, This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks, by making every transit node in the network HTTP-capable, and doing peer HTTP transfers between nodes to move data hop-by-hop or subnet-by-subnet towards its final destination. HTTP is well- known and straightforward to implement in these networks. "Sender Policy Framework: Email Address Internationalization", Frank Ellermann, 7-Sep-08, UTF8SMTP is an extension of SMTP (Simple Mail Transfer Protocol) allowing the use of UTF-8 in the SMTP envelope for EAI (Email Address Internationalization) and message headers. This memo discusses the consequences for SPF (Sender Policy Framework). "6LoWPAN Backbone Router", Pascal Thubert, 10-Jul-08, ISA100.11a is a Working Group at the ISA SP100 standard committee that covers Wireless Systems for Industrial Automation and Process Control. The WG is mandated to design a scalable, industrial grade LowPAN for devices such as sensors, valves, and actuators. The upcoming standard uses the 6LoWPAN format for the network header. It also introduces the concept of a Backbone Router to merge small LoWPANs via a high speed transit and scale the ISA100.11a network. This paper proposes an IPv6 version of the Backbone Router concept. "LoWPAN simple fragment Recovery", Pascal Thubert, 29-May-08, 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 between 6LoWPAN endpoints. "Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames", Tat-Chee Wan, Way-Chuang Ang, Chee-Hong Teh, 16-Oct-08, This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC4326 to carry packets compressed with RObust Header Compression (ROHC), RFC 3095 over ULE Stream. "Streamlined FTP Command Extensions", Mark Peterson, Rhino Software, 29-Aug-08, This document specifies FTP commands to download thumbnails of remote images, remove entire directory trees, request the amount of storage space available to the user, request the size of a remote directory and its contents, and to specify an FTP host. The commands are designed to reduce the number of server / client exchanges, provide information that was not previously available, and to reduce bandwidth requirements for some higher level operations. "Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and analysis", Jong-Hyouk Lee, Byung-Jin Han, Tai-Myoung Chung, Hyung-Jin Lim, 20-Sep-08, As Proxy Mobile IPv6 is deployed, a Mobile Network will be initialized in or move to a Proxy Mobile IPv6 domain. In this document, the scenarios of Network Mobility Basic Support within Proxy Mobile IPv6 that ensure session continuance for all nodes in the Mobile Network are presented. In addition, an analysis of all scenarios that comprise the interactions between Network Mobility Basic Support and Proxy Mobile IPv6 is provided as a guideline to PMIPv6 deployments. "Chrysolite - a backbone bridging solution", Mohammad Yousuf, Matthew Thomas, David Hunter, 16-Jun-08, Chrysolite is a combination of differing technologies to create a wide area switched Ethernet solution. Each Chrysolite switch has a unique MAC address (N-MAC). A link state protocol provides pairwise shortest paths between the N-MACs (one N-MAC per switch). Customers connect to the Chrysolite cloud using Ethernet connections. By setting the locally administered bit in the Ethernet address used to connect to the Chrysolite cloud, customers can directly encapsulate traffic into assigned source and destination C-MAC (MAC) addresses. Each of these C-MAC addresses specifies a unique customer 'VLAN circuit'. This proves end to end paths across the Chrysolite cloud without requiring any special headers, MAC in MAC or Q-in-Q encapsulation. "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. "Behavior of Collocated HA/LMA", George Tsirtsis, Suresh Krishnan, 22-Oct-08, In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario C describes the case of collocation of LMA and HA function. In this case a PMIP network emulates the "home link" for MNs using MIPv6. This document argues that even when LMA and HA functions are Collocated they MUST be treated as logically separate entities. In particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa. "The BagIt File Package Format (V0.95) http://www.ietf.org/internet-drafts/draft-kunze-bagit-02.txt", Andy Boyko, John Kunze, Justin Littman, Liz Madden, 11-Jul-08, This document specifies BagIt, a hierarchical file package format for the exchange of generalized digital content. A "bag" has just enough structure to safely enclose a brief "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 package 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. "Host Identity Protocol based Mobile Router (HIPMR)", Jan Melen, Jukka Ylitalo, Patrik Salmela, 27-Jul-08, This drafts defines a moving network support for HIP enabled hosts. The protocol uses asymmetric authentication and symmetric authorization. The solution presented in this draft is based on delegation of signalling rights between mobile nodes and mobile routers that results in route optimization between end-hosts. "X.509 Key and Signature Encoding for the KeyNote Trust Management System", Angelos Keromytis, 1-Oct-08, 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, 12-Oct-08, 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. "IANA Registrations for the 'Send-N' Enumservice", Ray Bellis, 23-Jun-08, This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) applications. "Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 6-Jul-08, 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. "A Scalable IPv4-IPv6 Transition Architecture Need for an address-port-borrowing-protocol (APBP)", Remi Despres, 14-Jul-08, This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connection s from customer sites having IPv6-only permanent addresses; (2) for good scalability, no network address translations (NATs), and a fortiori no application level gateways (ALGs), need to be supported within network infrastructures. To satisfy this requirement, it is concluded that an address-port-borrowing-protocol (APBP) is needed. "Conveying Vendor-Specific Constraints in the Path Computation Element Protocol", Adrian Farrel, Greg Bernstein, 2-Nov-08, The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. "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. "Application-Layer Traffic Optimization (ALTO) Problem Statement", Enrico Marocco, Vijay Gurbani, 2-Nov-08, A significant part of the Internet traffic today is generated by peer-to-peer applications used, for example, for file sharing, realtime communications and live media streaming. Such applications often deal with large amounts of data in direct peer-to-peer connections, but they usually have little knowledge of the underlying network topology. As a result, they may choose their peers based on measurements and statistics which, in some situations, may lead to suboptimal choices. This document describes problem related to optimizing traffic generated by peer-to-peer applications through the use of network-layer information, provides a representative set of use cases that may exhibit this problem, and outlines considerations that have to be taken in account when arriving at equitable solutions. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 28-Oct-08, 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, 3-Nov-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 defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, 8-Oct-08, 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. "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. "A Taxonomy for New Routing and Addressing Architecture Designs", Joel Halpern, 12-Jul-08, The Routing Research Group is tasked to design a new routing architecture to meet the challenges of scalability in face of pervasive multi-homing and inter-domain traffic engineering. A number of solutions have been proposed. This draft describes a taxonomy for the design space. "Marking behaviour of PCN-nodes", Philip Eardley, 26-Jun-08, This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than a first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate. "Extended Random Values for TLS", Eric Rescorla, Margaret Salter, 1-Nov-08, 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, 6-Jul-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. "MAC Security Label Requirements for NFSv4", David Quigley, James Morris, 24-Jun-08, This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.1 . It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer and why existing NFSv4 protection mechanisms are not sufficient. "AtomPub Multipart Media Resource Creation", Joe Gregorio, 6-Oct-08, This specification defines how an Atom Publishing Protocol collection may process multipart/related requests and also defines how a service announces that it accepts multipart/related entities. "A Session Initiation Protocol (SIP) Event Package for Debugging", Peter Dawes, Vodafone Group, 29-Oct-08, This document defines a Session Initiation Protocol (SIP) event package for debugging. An entity that subscribes to this event package for an address of record receives configuration data that controls logging of SIP signalling for that address of record, for example when to begin an end logging. "Private Extension to the Session Initiation Protocol (SIP) for Debugging", Peter Dawes, Vodafone Group, 29-Oct-08, 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 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. "Indication of support for keep-alive", Christer Holmberg, 27-Oct-08, 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. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Arsalan Tavakoli, Stephen Dawson-Haggerty, P Levis, 8-Aug-08, Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have 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 has requirements that existing mesh protocols only partially address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to this class of networks. It provides guidance on how lessons from existing and prior efforts can be leveraged in future protocol design. "WebDAV Current Principal Extension", Wilfredo Sanchez, Cyrus Daboo, 31-Oct-08, This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. "DKIM Author Domain Signing Practices (ADSP)", Table Contents, Author Address, Douglas Otis, 25-Jun-08, DomainKeys Identified Mail (DKIM) as described in [RFC4871], 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 lack valid DKIM signatures for domains used in the author's address. It defines a record that can advertise the extent to which a domain signs outgoing mail that is publicly exchanged on SMTP port 25, as described in [RFC2821]. Also, how other hosts can access those records. Advertisements, defined by this document, may also increase DKIM signature expectations for messages received by Mail User Agents (MUAs) or for messages which might have been exchanged over protocols other than SMTP. In some circumstances, author domains may wish to have accommodations for protocol failures or for mixed public protocol messaging not to be made. In addition, DKIM's identity parameters related to the author address are decisive only when a corresponding DKIM key local-part template precludes an author address. DKIM in conjunction with ADSP is to provide methods for detecting the spoofing of known domains, but not for making strong assertions about the identity of the message author. "Re-direct Mechanism for IKEv2", Vijay Devarapalli, Kilian Weniger, Pasi Eronen, 14-Jul-08, IKEv2 is a popular 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 to re- direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. "Negotiation of Generic Image Attributes in SDP", Ingemar Johansson, Kyunghun Jung, 19-Sep-08, 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. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 27-Oct-08, This document provides methodology and framework for quantifying performance implications of enabling selective monitoring of IP flows on a network device and export of this information to a collector as specified in [RFC5101]. "Common YANG Data Types", Juergen Schoenwaelder, 14-Jul-08, This document introduces a collection of common data types to be used with the YANG data modeling language. "DKIM Author Domain Signing Practices (ADSP)", agent Local-part, Author Domain, Jon Callas, John Levine, Ellen Siegel, 23-May-08, 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 they sign their outgoing mail, and how other hosts can access those records. "DKIM Third-Party Authorization for Author Domain Signing Practices", Douglas Otis, 24-May-08, TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to authorize Third-Party domains. This mechanism allows first-party domains to autonomously authorize a range of third-party domains in a scalable, individual DNS transaction. This authorization extends the scope of DKIM policy assertions to supplant more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate the coordination between two or more domains by setting up selector/key DNS records, DNS zone delegations, or the regular exchange of public/ private keys. Checking DKIM policies may occur when a From header email-address is not within the domain of a valid DKIM signature. When a Third-Party signature is found, TPA-labels offer an efficient means for email address domains to authorize specific third-party signing domains. The scope of the authorization may separately assert identity authentication for From and Sender and Resent-* headers for email- addresses within the authorizing domain. Identity authentication can be asserted by the scope of the authorization, even when signed by a Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize domains for controlling DSNs. "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, 26-May-08, 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. "Atom Link Relation: Discuss", Peter Saint-Andre, 27-May-08, This specification defines a link relation that enables an Atom document to point to a venue for multi-party discussion of the document or its primary topic. "Securing Neighbour Discovery Proxy Problem Statement", Greg Daley, Jean-Michel Combes, 28-May-08, Neighbour Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Neighbour 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 neighbour discovery messages. Neighbour 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 Neighbour Discovery relates to Secured Neighbour Discovery. "Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary", Karl Wolf, 28-May-08, LoST [I-D.ietf-ecrit-lost] is able to map 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 give information about the geographical region, for which the returned service list is valid. Therefore this document proposes a ServiceListBoundary, in addition to the ServiceBoundary (which indicates the region a specific service URL is valid). "Guidelines to authors and reviewers regarding the IETF review process", Suresh Krishnan, Pasi Eronen, Eric Gray, 13-Jul-08, This document describes the authors' experiences with the IETF review process and provides guidelines to draft authors and reviewers on how to effectively participate in it. This document does not define the IETF review process itself. "Classification of Location-based Services", Andrea Forte, Henning Schulzrinne, 28-May-08, 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). "In-Vehicle Routing Requirements in Low Power and Lossy Networks", Ryuji Wakikawa, Hiroshi Kuwabara, 29-May-08, This document presents the routing requirements for in-vehicle low power and lossy networks. Automobiles are already equipped with several sensors and devices named Electronic Control Unit (ECU) for controlling, monitoring and entertainment, etc. For the future in- vehicle networks, the shift to wireless is desirable due to heavy weight and volume of cables in vehicles and to be able to efficiently install devices. However, with the limitation of low power, in- vehicle network still requires reliability and scalability in nature of the rolls of ECU. The routing protocol should support the features of low-power, high-reliability, Subnetting, QoS, Mobility, etc. This document briefly explains the in-vehicle networks and ECUs, then discusses the requirements for the future wireless in- vehicle networks. "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. "Real-Time Transport Protocol (RTP) Timestamps for Layered Encodings", Jonathan Lennox, Thomas Schierl, Sam Ganesan, 2-Jun-08, The Real-Time Transport Protocol (RTP) specification defines how layered encodings can be sent over a layered transmission system. A source can stripe the progressive layers of a hierarchically represented signal across multiple RTP sessions, each carried on, for example, its own multicast group. These layered encodings are given special treatment in RTP, notably in that the same synchronization source (SSRC) identifier space is used across the sessions of all layers. The RTP protocol specification does not, however, explicitly state how RTP timestamps are to be used with layered encodings. This document updates the RTP specification to require that RTP timestamps for layered encodings be synchronized, i.e. that every layer chooses the same random initial value for the timestamp. "Proxy Mobile IPv6 Inter-Technology Handover Issue", Behcet Sarikaya, Frank Xia, 3-Jun-08, Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility management protocol, that is, a mobile node does not take part in any mobility signaling. In inter-technology handovers, mobile node input is required in moving IP sessions from one interface to the other. This document discusses the impact of the mobile node involvement during inter-technology handover. "Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful", Francis Dupont, Jean-Michel Combes, Maryline Laurent-Maknavicius, 3-Jun-08, The Dynamic Home Agent Address Discovery (DHAAD) mechanism is described in the Mobile IPv6 specification. This mechanism is mandatory in any compliant Mobile IPv6 implementation and so in any MIPv6 based protocols too. On the other hand, DHAAD was the only one mechanism to discover a potential Home Agent for a Mobile Node in the past. This is no longer the case today. This document analyzes the security of the different existing home agent discovery mechanisms and promotes the remove of DHAAD from the future Mobile IPv6 standard, in light of this security analysis. "Session Multiplexing for SVC Video", Miska Hannuksela, Ye-Kui Wang, 14-Jul-08, This memo describes two alternative methods for decoding order recovery of the Network Abstraction Layer (NAL) units carried in multiple RTP sessions for Scalable Video Coding (SVC), which is defined in Annex G of the ITU-T Recommendation H.264 video codec that is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The methods apply when non-interleaved transmission of NAL units using the Single NAL Unit packetization mode or the Non-Interleaved packetization mode defined in RFC 3984 is in use. Table of Contents Status of this Memo...............................................1 Copyright Notice..................................................1 Abstract..........................................................2 "Reserved Top Level DNS Names", Frank Ellermann, Donald Eastlake 3rd, 18-Aug-08, To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This memo replaces RFC 2606 reserving 21 additional TLDs. "DHCP Reconfigure Extension Option", Vitali Vinokour, Wojciech Dec, James Bristow, David Miles, 6-Jun-08, The current use of DHCP (Dynamic Host Configuration Protocol) Reconfigure extension is limited by a requirement that FORCERENEW message is authenticated. This document defines a mechanism allowing the use of FORCERENEW without DHCP authentication. "BGP Extended Community Attribute for QoS Marking", Thomas Martin Knoll, 14-Jul-08, 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 peering 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. "BGP ACCEPT_OWN Well-known Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, Intellectual Property, 8-Jun-08, Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. "Clarifying Handling of M & O Flags of IPv6 Router Advertisement", Hyunwook Cha, Bernie Volz, 8-Jun-08, This document clarifies how clients are supposed to use the RA M & O flags. "ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 31-Oct-08, This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to enable ISPs' continuous IPv4 based operation even after the IPv4 address exhaustion. "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 1-Nov-08, 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. "Display-based Address Sorting for the IMAP4 SORT Extension", Dan Karp, 10-Jun-08, This document describes an IMAP protocol extension enabling server- side message sorting based on the commonly-displayed portion of the From header. "IMAP4 Extension for returning STATUS information in extended LIST", Alexey Melnikov, Timo Sirainen, 10-Jun-08, 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. "A New BGP Standards Action Community, LAST_RESORT", Brian Dickson, 20-Aug-08, This Internet Draft describes a new Standards Action BGP community, LAST_RESORT. This community provides a simple and easily deployable solution to a certain class of BGP "wedgies". Initial deployment is expected to be achieved by voluntary use in the network operator community-at-large. Long-term adoption via software enforcement of the community, will improve global behavior, and simplify router configurations. The Standards Action range of communities (previously limited to the "well-known" communities) ensures that the expectation of (eventual) router support is reasonable. "Additional DNS Resource Records", Randall Atkinson, 11-Jun-08, This note describes four additional optional Resource Records for use with the Domain Name System (DNS). At present these optional resource records are subject of experimentation in certain IP networks. Limited deployment is anticipated in the near future. "IPv6 RADIUS attributes for DHCP based networks", Benoit Lourdelet, 12-Jun-08, This document specifies RADIUS [RFC2865] attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6. "Nonce Destination Option", Randall Atkinson, 12-Jun-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. "GRE key as the traffic selector for IPsec tunnel", Hui Deng, Yuanchen Ma, Yingzhe Wu, 13-Jun-08, This document describes the IPsec Tunnel based on GRE key as the traffic selector. When GRE key is used in IP packet transmission scenario of the wireless communication. Several enterprise need different security policy when transmit the packet through some unguaranteeded Internet cloudy. This document propose to adopt GRE key as the IPsec traffic selector. "The application/opensearchdescription+xml media type", Frank Ellermann, 3-Jul-08, This memo defines the application/opensearchdescription+xml media type for OpenSearch descriptions. Atom and XHTML elements are examples where this media type is used. "Providing Satellite Navigation Assistance Data using HELD", Martin Thomson, James Winterbottom, 15-Jun-08, 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. "Neighbor Discovery Registration Extension", Erik Nordmark, 16-Jun-08, In order to reduce Neighbor Discovery multicast messages it is useful if the routers on a link can maintain an authoritative list of the IPv6 and layer 2 addresses for all the hosts on the link. This draft specifies an extension to the Router Advertisement messages which trigger to hosts to send periodic registration messages which can be either unicast, multicast, or anycast. The protocol uses a soft-state approach to gather registration information. "Attention Request (POKE) for Instant Messaging", Gustavo Garcia, Jose-Luis Martin, 16-Jun-08, 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. This message also allows the sender to indicate the preferred realization of the attention request: vibrator, light, tone, media or text. "Requirements for Dialog Correlation in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Salvatore Loreto, 20-Oct-08, This document justifies the need and lists the requirements for correlating SIP (Session Initiation Protocol) dialogs that relate 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. "Conversion parameters for IMAP CONVERT", Alexey Melnikov, 2-Nov-08, This is a companion document to the Lemonade CONVERT (draft-ietf-lemonade-convert-XX.txt) extension. It defines additional conversion parameters for conversions of image/* and text/* body parts. It also demonstrates additional CONVERT usage scenarios. "Pairtrees for Object Storage (V0.1)", John Kunze, Martin Haye, Erik Hetzner, Mark Reyes, 17-Jun-08, This document specifies Pairtree, a filesystem hierarchy for holding objects that are located 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. "BGP Communities use for the prefix origination tagging", Dave Meyer, Matvey Teplov, 17-Jun-08, BGP communities [RFC 1997] are 64-bit values that are used to tag the originated or traversing prefixes for the different purposes, such as origination tagging or policy application purposes. These values can be displayed in a new and old format, which notes different representation of the same 64-bit value. This document defines the way of tagging prefixes based upon their geographical origination to assist in development of geographically-based policies that, ideally, will result in RTD (Round Trip Delay) value improvements, as optimized paths can be established. "Sender RTT Estimate Option for DCCP", Gerrit Renker, 18-Jun-08, This document describes an optional extension for DCCP congestion- control CCIDs that are based on TCP-Friendly Rate Control (TFRC). The extension improves the accuracy of parameter estimation at the TFRC receiver, by periodically communicating the (more precise) RTT estimate available at the sender. "Transient Binding for Proxy Mobile IPv6", Marco Liebsch, Ahmad Muhanna, Oliver Blume, 14-Jul-08, 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 a 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. "HIP support for RFID", Pascal Urien, 18-Jun-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, 18-Jun-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, 19-Jun-08, 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. "Mobile IPv6 Flow Routing over Multiple Care-of Addresses", Michael Eriksson, Conny Larsson, Romain Kuntz, 19-Jun-08, This document specifies a mechanism to selectively route IP flows to and from Mobile IPv6 Mobile Nodes and NEMO Mobile Routers which have registered multiple care-of addresses. It explains how to apply the generic flow distribution language defined in a companion draft to Mobile IPv6, defines a transport mechanism to transmit the rules between Mobile IPv6 nodes, and describes how the rules are sent and handled upon reception. "IANA Registration for Location ('loc') Enumservice", Alexander Mayrhofer, 19-Jun-08, This document requests IANA registration of an Enumservice for reflecting location information. The Enumservice uses the 'loc' Type name, and makes use of the proposed 'held' and 'geo' URI schemes. "Channel binding for HTTP Digest Authentication", Stefan Santesson, 14-Jul-08, This document specifies a method implemented by Microsoft to add channel binding capabilities to the http digest protocol defined in RFC 2617 [2617] "Multicast tunneling optimization for Mobile IPv4", Hui Deng, 20-Jun-08, This document provides the solution to optimize the multicast tunneling in mobile IPv4. This solution will not break the basic bi- directional tunneling multicast solution of MIPv4. A new multicast foreign agent works as a proxy node for multiple mobile nodes within one limit scope. Single tunnel is set up between one home agent and one mobile foreign agent for single multicast stream. A new notification message is created for the communication between home agent and multicast foreign agent. There is no modification on mobile nodes. "Stream Control Transmission Protocol (SCTP) Stream Reset", Randall Stewart, Peter Lei, Michael Tuexen, 20-Jun-08, 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. "Safe IKE Recovery", Frederic Detienne, Pratima Sethi, Yoav Nir, 6-Aug-08, The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE that can be used in all failover or post-crash situations. "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 14-Jul-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. "MPLS Generic Associated Channel", Matthew Bocci, David Ward, 20-Jun-08, This draft describes a generic associated channel header (GE-ACH) that provides a control channel associated with an MPLS LSP, pseudowire or MPLS section. The VCCV ACH defined for PWs in RFC 5085 is generalized to allow a larger set of control channel and OAM functions to be used to meet the requirements of packet transport and other applications of MPLS. "JWT Report on MPLS Architectural Considerations for a Transport Profile", Stewart Bryant, Loa Andersson, 20-Jun-08, This RFC archives the report of the IETF - ITU-T Jooint Working Team (JWT) on the application of MPLS to Transport Networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. There are two versions of this RFC. An ASCII version that contains a summary of the slides and a pdf version that contains the summary and a copy of the slides. "Distributing a Symmetric Neighbor Discovery Key Using SEND", Frank Xia, Suresh Krishnan, Wassim Haddad, Jean-Michel Combes, Chunqiang Li, 20-Jun-08, In this document, a method for provisioning a shared key from the router to the host is defined to protect Neighbor Discovery(ND) signaling between the router and the host. The host sends a Router Solicitation(RS) message with ND Shared Key Request Option to the router. The router encrypts a ND shared key using the host's SEcure Neighbor Discovery(SEND) public key and sends it back to the host through a Router Advertisement(RA) message. The host decrypts the ND shared key using the matching private key. The Neighbor Discovery shared key is then used for protecting the following Neighbor Discovery signaling between the router and the host. The Router Solicitation and Router Advertisement message exchanges are required to have SEND security. "Dissemination of flow specification rules implementation report", Robert Raszuk, Pedro Roque Marques, Craig Labovitz, 21-Jun-08, This document provides an implementation report for Dissemination of flow specification rules as defined in draft-ietf-idr-flow-spec-01 The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. "Alternative RPKI Repository Retrieval Mechanism", Terry Manderson, George Michaelson, 23-Jun-08, This document proposes a mechanism for a relying party to synchronise a local cache of the RPKI repository using a HTTP retrieval mechanism. "A three state extended PCN encoding scheme", T Moncaster, Bob Briscoe, Michael Menth, 23-Jun-08, 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 This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. "No Service To This Number Reject Code", David Schwartz, 3-Nov-08, This specification discusses a SIP response error code ambiguity that may exist due to sematic differences between SIP [RFC3261] and TEL [RFC3966] URIs. "Optimized MAC Address Operations in VPLS with Redundancy", Yuanlong Jiang, Yang Yang, 24-Jun-08, The Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling is described in RFC 4762. That document describes a mechanism called MAC Address Withdrawal to remove or unlearn MAC addresses which have been dynamically learned in a VPLS instance. Further work in progress defines an extension to MAC Address Withdrawal procedure which can greatly restrict the scope of MAC flushing. This document provides two mechanisms which completely remove the need for MAC address flushing in VPLS instances. The mechanisms are MAC address switching and MAC address notification. "Progress and future development of Flow State Aware standards, and a proposal for alerting nodes or end-systems on data related to a flow", jongtae song, John Adams, Jinoo Joung, 24-Jun-08, This document describes the work in progress on Flow State Aware standards activity in the ITU and proposes a new type of control packet to be identified that can alert downstream or upstream nodes on data related to an individual flow. "PW Bonding", Yaakov Stein, Itai Mendelsohn, Ron Insler, 3-Nov-08, There are times when pseudowires must be transported over physical links with limited bandwidth. We shall use the term "bonding" (also variously known as inverse multiplexing, link aggregation, trunking, teaming, etc.) to mean an efficient mechanism for separating the PW traffic over several links. Unlike load balancing and equal cost multipath, bonding makes no assumption that the PW traffic can be decomposed into distinguishable flows, and thus bonding requires delay compensation and packet reordering. Furthermore, PW bonding can optionally track bandwidth constraints in order to minimize packet loss. "Trusted plane for routing equipment embedding a tamper-resistant device", Evren Bulut, Emmanuel Onfroy, 25-Jun-08, Due to their critical role in a network, the protection of routing equipements is crucial, particularly against subversion attacks. For this purpose, we integrate a trusted plane in the network equipments related to the routing protocols (e.g. OSPF, BGP, RIP). This trusted plane is realized by a trusted element embedded or connected to the network equipment. "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", Staffan Blau, Christer Holmberg, 17-Oct-08, 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. "RTP Payload Format for Geographical Location.", Xavier Marjou, Jean Jestin, 26-Jun-08, This memo presents some use-cases and requirements related to the real-time transport of geographical location information. It also defines a Real-time Transport Protocol (RTP) packet payload format to carry real-time geographical location information. "On RFC Streams, Headers, and Boilerplates", Leslie Daigle, Olaf Kolkman, 20-Oct-08, 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, 23-Oct-08, 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 quasi-native IPv6, under the only condition that they activate it. "A Diffserv-TE Implementation Model to dynamically change booking factors during failure events", Jonathan Newton, Mustapha Aissaoui, JP Vasseur, 27-Jun-08, This document discusses the requirements for and describes an implementation model of Diffserv-TE that allows the booking factors applied to network resources to be dynamically changed during network failure events. "Indicating Non-Availability of Dynamic Updates in the DNS", Joe Abley, 27-Jun-08, The Start of Authority (SOA) Resource Record (RR) in the Domain Name System (DNS) specifies various parameters related to the handling of data in DNS zones. These parameters are variously used by authority- only servers, caching resolvers and DNS clients to guide them in the way that data contained within particular zones should be used. One particular field in the SOA RR is known as MNAME, which is used to specify the "Primary Master" server for a zone. This is the server to which Dynamic Updates are sent by clients. Many zones do not accept updates using the Dynamic Update mechanism, and any such DNS UPDATE messages which are received provide no usual purpose. For such zones it may be preferable not to receive updates from clients at all. This document proposes a convention by which a zone operator can signal to clients that a particular zone does not accept Dynamic Updates. "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima, Thomas Nadeau, 27-Jun-08, 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. "Clarification of sender behaviour in persist condition.", Murali Bashyam, Mahesh Jethanandani, Anantha Ramaiah, 28-Jun-08, This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. "Mobility Support in IPv4/v", Zhengming Ma, Qingyu Tan, Zheng Xiang, 30-Jun-08, This document specifies a protocol named Mobile IPv4/v6, which allows mobile nodes to remain reachable while moving in IPv4/v6 mixed networks. A translation gateway called Mobile IPv4/v6 Translation Gateway (MIPv4/v6-TG) is introduced in this protocol. MIPv4/v6-TG is based on NAT-PT gateway and equipped with a newly introduced application level gateway called MIP-ALG. MIPv4/v6-TG is located between IPv4 network and IPv6 network. On IPv4 network side, MIPv4/v6-TG acts as a Mobile IPv4 entity and interacts with other Mobile IPv4 entities under Mobile IPv4, while on IPv6 network side, it acts as a Mobile IPv6 entity and interacts with other Mobile IPv6 entities under Mobile IPv6. In MIPv4/v6-TG, Mobile IPv4 entities and Mobile IPv6 entities are translated with each other. In order to maintain each of Mobile IP sessions that pass through MIPv4/v6-TG, a data structure called Mobile IP Table is introduced. "AtomTriples: Embedding RDF Statements in Atom", Mark Nottingham, Dave Beckett, 30-Jun-08, This specification describes AtomTriples, a set of Atom extension elements for embedding RDF statements in Atom documents (both element and feed), and declaring how they can be derived from existing content. "Performance Evaluation of PCE Architectures for Wavelength Switched Optical Networks", Greg Bernstein, 30-Jun-08, In this note a number of PCE architectural and computational options are evaluated against a medium sized wavelength switched optical network. The key performance measures of overall and backward blocking are reported under different dynamic traffic scenarios. The corresponding reduction in connection blocking probabilities and computational advantages enabled by these architectural alternatives strongly warrant their inclusion in continuing PCE WSON work. "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 30-Oct-08, 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. "Requirements for Label Edge Router Forwarding of IPv4 Option Packets", William Jaeger, John Mullooly, Tom Scholl, David Smith, Intellectual Property, 6-Oct-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 may result in a different forwarding behavior for different IP packets associated with the same prefix-based Forwarding Equivalence Class (FEC). While an IP packet with either a specific option type or no header option may follow the MPLS label switched path (LSP) associated with a prefix-based FEC, an IP packet with a different option type but associated with the same prefix-based FEC may bypass MPLS encapsulation and instead be IP routed downstream. IP option packets that fail to be MPLS encapsulated simply due to their header options present a security risk against the MPLS infrastructure. "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", Kevin Igoe, Jerome Solinas, 30-Jun-08, Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. SSH provides for algorithms that provide authentication , key agreement. confidentiality and data integrity services. This purpose of this document is to show how the AES Galois/Counter Mode can be used to provide both confidentiality and data integrity. "Certified Pan Formation Protocol", Aroua Biri, 30-Jun-08, This draft introduces the Certified PN Formation Protocol (CPFP) based on the personal public key infrastructure (personal PKI) concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques by using ECDH, ECDSA and STS protocols and provides feasible solutions for key revocation and transitive imprinting. "Certified Electronic Mail", Francesco Gennai, Alba Shahin, Claudio Petrucci, Alessandro Vinciarelli, 27-Oct-08, 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. "1 + /64s as IPv6 Standard Access Model", Shin Miyakawa, Yasuhiro Shirasaki, 30-Jun-08, This document proposes the "standard" address assignment scheme for IPv6 access network which uses RA or DHCPv6 to assign an global IPv6 address to the WAN interface of the CPE and DHCPv6 PD on the upstream link of CPE to delegate one or more /64 prefixes to the CPE. "Load Balancing for Mesh Softwires", Clarence Filsfils, Pradosh Mohapatra, Carlos Pignataro, 1-Jul-08, 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. "DHCPv4 bulk lease query", D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 1-Jul-08, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client 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 Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv4 binding data via TCP. "Generic Mobility Management Protocol", Hui Deng, 30-Oct-08, This document discusses the communication protocol between mobile access point and terminal. With the evolution of mobile communication, there are various kind of wireless communication technologies such as WCDMA, LTE, WLAN, WiMAX, and TDS-CDMA et al. Each of these wireless communication technology has independent connection, mobility and configuration management. This document would like to cover all these functions into a common ground especially in the environment of multiple connections. "Extension headers for 6lowpan", Carsten Bormann, 1-Jul-08, 6lowpan applications sometimes need to include application-specific information in layer 2 packets that are intended to be processed as 6lowpan packets. This document specifies a way to include this information in a 6lowpan packet in such a way that it can be ignored by implementations that don't care for it. $Id: draft-bormann-6lowpan-ext-hdr.xml,v 1.5 2008/07/02 06:23:58 cabo Exp $ "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. "Application of Event Package Bodies to Subscriptions to Lists of Resources in the Session Initiation Protocol (SIP)", Adam Roach, 2-Jul-08, This document specifies a mechanism by which subscriptions to the state of request-contained ("ad-hoc") lists of resources can have event-package-defined bodies applied to each of the contained resources. "DHCP Based Configuration of Mobile Node from Home Network", Hui Deng, 2-Jul-08, 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. "DKIM Extensions", Phillip Hallam-Baker, 13-Jul-08, Optional extensions for DKIM are described. A DKIM Policy statement is defined for the policy 'this zone never sends mail'. The NULL Key Algorithm is defined to simplify management of large zones where most mail is signed but with important exceptions. The X509 key record extension allows the location from which an X.509v3 certificate for the key specified in the record may be obtained. "Diameter User-Name and Realm Based Request Routing Clarifications", Jouni Korhonen, Mark Jones, Lionel Morand, Tina Tsou, 27-Oct-08, This specification clarifies the Diameter realm based request routing. We focus on the case where a Network Access Identifier in the User-Name AVP is used to populate the Destination-Realm AVP and the Network Access Identifier contains more than one realm. This particular case is possible when the Network Access Identifier decoration is used to force a routing of request messages through a predefined list of realms. However, this functionality is not unambiguously specified in the Diameter Base Protocol specification. "Moving the Session Initiation Protocol (SIP) Towards Draft Standard", Robert Sparks, 2-Jul-08, This document is intended to stimulate discussion and progress towards advancing SIP to Draft Standard. It points to some of the issues the working group will need to work through and proposes an approach for creating an interoperability statement. "RFC 2026 in practice", Brian Carpenter, 2-Jul-08, This document discusses how RFC 2026, the current description of the IETF standards process, operates in practice. Its main purpose is to document, for information only, how actual practice interprets the formal rules. "Specifying Unsafe Areas in LoST Service Boundary", Qian Sun, Robins George, 2-Jul-08, This document describes how to specify unsafe areas in LoST for emergency services, such as police, mountain, marine and fire. "Location-to-Service Translation Protocol (LoST) Sub-Services", Robins George, Qian Sun, 2-Jul-08, This document describes, how a LoST client can ask LoST server for the list of sub services that it supports, and to incorporate additional information about the service provider in response. "Providing Satellite Navigation Assistance Data using HELD", Martin Thomson, James Winterbottom, 2-Jul-08, 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. "A Packet Partition Scheduling Mechanism for Bandwidth Aggregation through Multiple Network Interfaces", Pyung-Soo Kim, Joo-Young Yoon, Han-Lim Kim, 2-Jul-08, This draft considers a packet partition scheduling mechanism for effective bandwidth aggregation over end-to-end multi-path through multiple network interfaces. "IPv6 in Broadband Networks", John Kaippallimalil, Frank Xia, 3-Jul-08, This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. "Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources", Ted Hardie, 3-Jul-08, Discovering 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 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. While the mechanisms described below each meet similar needs, they are not mutually exclusive; it is expected that each will find some useful deployment during the early days of peer-to-peer overlay deployment. "IPv6 in Broadband Networks", John Kaippallimalil, Frank Xia, 3-Jul-08, This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. "Shelter Service And Classification", Qian Sun, Robins George, Henning Schulzrinne, 29-Oct-08, This document defines and registers a new service 'shelter', for the service URN to find, what instances of shelter service are closest to the user's location. The Location-to-Service Translation (LoST) protocol can provide these information for a geographical region. "RADIUS Over TCP", Alan DeKok, Intellectual Property, 2-Nov-08, 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). "MPLS-TP Requirements", Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher, 31-Oct-08, This document specifies the requirements for a MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union (ITU)-IETF effort to include a MPLS Transport Profile within the IETF MPLS architecture 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 architecture as defined by IETF and packet transport networks as defined by ITU-T. "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, Mohamad Chaitou, Jean-Louis Le Roux, Zafar Ali, 3-Jul-08, 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. "Lossless Compression for IP Flow Information Export (IPFIX)", Gerhard Muenz, Lothar Braun, 3-Jul-08, In this document, we discuss the benefits and possible realizations of IPFIX traffic compression. Experiments with real measurement data show that a significant compression gain can be achieved by applying the DEFLATE compression method to IPFIX data sets. Compression of IPFIX traffic can be based on underlying transport protocols, such as IPComp and TLS/DTLS, or realized as an extension of the IPFIX protocol. "MVPN: Optimized use of PIM, Wild Card Selectors, Bidirectional Tunnels, Extranets", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 31-Oct-08, 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. "Multicast Control Extensions for ANCP", Philippe Champagne, Wojciech Dec, Sanjay Wadhwa, Stefaan De Cnodder, Roberta Maglione, 3-Jul-08, This draft is aimed at describing the ANCP protocol extensions required to support the NAS initiated ANCP Multicast Control use case described in ANCP framework draft. It proposes the definition of new ANCP message types, along with well known TLVs. "MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, Eric Gray, 8-Oct-08, This document specifies the network management requirements for supporting the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Gray, et al Expires April, 2009 [page 1] Internet-Draft MPLS-TP NM Requirements October, 2008 "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, 3-Nov-08, 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 GMSPL 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. "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", Mijeom Kim, JP Vasseur, Hakjin Chong, 17-Nov-08, 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. "ATN Topology Considerations for Aeronautical NEMO RO", Christian Bauer, Serkan Ayaz, 4-Jul-08, The intention of this draft is to provide an overview of the topology of the Aeronautical Telecommunications Network to help with the analysis of the possible options of NEMO RO within this context. The intention is to allow taking the existing NEMO RO solution space analysis document and cross-check it with the aeronautical environment presented within this document. "Updates to Referred-By in the Session Initiation Protocol (SIP).", Nadia Bishai, Salvatore Loreto, Adamu Haruna, 3-Jul-08, SIP has a mechanism for conveying the asserted identity of the originator of a request by means of the P-Asserted-Identity header field. 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 field in the resulting exploded requests is set to the P-Asserted-Identity header field or to the From header field. The Referred-By header is only included if the P-Asserted-Identity header field or From header field needs to carry another value, e.g. the URI of a pre-defined group, or a conference focus URI. Since the P-Asserted-Identity header field may carry up to two values, the Referred-By definition needs to be extended to allow up to two values as well. "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Yuji Kamite, Frederic JOUNAY, Ben Niven-Jenkins, Deborah Brungard, Lizhong Jin, 31-Oct-08, 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. "Management Information Base for the SEcure Neighbor Discovery (SEND) protocol", Alberto Garcia-Martinez, 4-Jul-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, 4-Jul-08, This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA). "UDP-Encapsulated Transport Protocols", Remi Denis-Courmont, 4-Jul-08, This memo defines modified formats for conveyance of TCP and SCTP packets within UDP datagrams, to ease traversal of network address translators. "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Laird Popkin, Stefano Previdi, Richard Woundy, Yang Yang, 3-Nov-08, 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. These recommendations 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 an initial set of requirements for ALTO and solicits feedback and discussion. "P2P Traffic Localization by Traceroute and 2-Means Classification", Yunfei Zhang, Liufei Wen, 14-Jul-08, Most P2P system performance suffers from the mismatch between the randomly constructed overlays topology and the underlying physical network topology, causing a large burden in the ISP and a long RTT time. This document describes how DHT overlay peers can interact with the routers by traceroute to get the path information, and execute 2- Means Classification, thereafter peers leverage the DHT itself to build efficient "closer" cluster. This scheme only requires the infrastructure to enable traceroute queries. "A Fast Handover Scheme in Proxy Mobile IPv6", Youn-Hee Han, Byungjoo Park, 4-Jul-08, This memo proposes a scheme that supports a fast handover effectively in Proxy Mobile IPv6 by optimizing the associated data and signaling flows during the handover. New signaling messages, Fast PBU and Reverse PBU, are defined and utilized to expedite the handover procedure. "Location Routing Function Requirements", Hadriel Kaplan, 4-Jul-08, This document describes the requirements for a Location Routing Function Protocol, for inter and intra-domain SIP session routing. "A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem", Volker Hilt, Ivica Rimac, Marco Tomsu, Vijay Gurbani, Enrico Marocco, 4-Jul-08, A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used traditionally for file-sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. We refer to this as the Application Layer Traffic Optimization (ALTO) problem. In this draft we present a survey of existing literature on discovering topology characteristics. "The RKEY DNS Resource Record", Jim Reid, Jakob Schlyter, Ben Timms, 4-Jul-08, A DNS Resource record which can be used to encrypt NAPTR records is described in this document. "Scope-Extended Router Advertisement for Connected MANETs", Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, 28-Oct-08, In the connected MANET, the MANET Border Router (MBR) is used to connect the MANET with the external network and MANET nodes are required to know the MBR address to communicate with hosts in the external network. One way of acquiring the MBR address is to use the Router Advertisement (RA) and the Router Solicitation (RS) messages. In order to allow RA/RS messages to be delivered in the multi-hop MANET, the modified RA/RS message has been defined [4]. However, this approach may incur the duplicate packet reception problem due to rebroadcasting of received RA/RS messages to its neighbors. In this draft, we define the scope-extended Router Advertisement/ Solicitation message for announcing/solicitating the MBR address in the connected MANET. In the scope-extended RA/RS message, a new message field, the sequence number field, is defined so that duplicate RA/RS messages can be detected based on the sequence number and the MBR address included in the message. "P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications (ATTP)", Yunfei Zhang, Hongluan liao, Naibao ZHOU, 22-Oct-08, Currently P2P applications have accounts for large cross-ISP traffic. This document proposes a method to reduce cross-ISP traffic by setting cooperative ISP-friendly trackers in the ISP's network. Through improving the random node selection mechanism in P2P tracker-based application, we can effectively reduce cross-ISP traffic as well as the cost of network equipments and network operation. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Cellular-based Central Control (CCC) Mechanism for Mobile Ad hoc Networks", Yunfei Zhang, 4-Jul-08, This document discusses a cellular based central control mechanism(CCC) for middle/small scale mobile Ad hoc networks. The proposed mechanism can be used for the mobile operators to build a central-controlled and manageable mobile Ad hoc network. "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, 4-Jul-08, 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. "Address Autoconfiguration for the subordinate MANET with Multiple MBRs", Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, 28-Oct-08, In order to allow the subordinate MANET to be connected to the external network, the MANET border router (MBR) has been defined. For providing scalability and reliability to the subordinate MANET, multiple MBRs may be deployed. One of the issues on the subordinate MANET with multiple MBRs is which network prefixes are to be advertised by MBRs. In the case when MBRs advertise different network prefixes, if a MANET node changes its default MBR to a new one, the node may have to transmit packets via non-optimal paths to keep using the existing connection to the previous MBR, or change its address by using the network prefix information from the new MBR. In the latter case, on-going sessions can be terminated because of the address change. In this draft, we define a PMIPv6 based address autoconfiguration mechanism that enables MANET nodes to operate properly when all MBRs advertise the same network prefix in the subordinate MANET. "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 5-Jul-08, This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Volker Hilt, 5-Jul-08, 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. "Sieve Extension for converting messages before delivery", Alexey Melnikov, Qian Sun, 5-Jul-08, This document describes how Lemonade CONVERT can be used to transform messages before final delivery. "RSVP-TE based impairments collection mechanism", Zafar Ali, University Milan, University Milan, Cisco Systems, University Milan, University Milan, University Milan, 2-Nov-08, The problem of path validation of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical impairments related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical impairments measured over optical nodes along the light-path. "Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6 Coexistence and Transition", Xing Li, Maoke Chen, Congxiao Bao, Hong Zhang, Jianping Wu, 5-Jul-08, 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 (or almost stateless) gateways. The IVI scheme supports the end-to-end address transparency, incremental deployment and performance optimization in multi-homed environment. This document is a comprehensive report on the IVI design and its deployment in large scale public networks. Based on the IVI scenario, the corresponding address allocation and assignment policies are also proposed. "FIB Suppression with Virtual Aggregation and Default Routes", Paul Francis, Xiaohu Xu, Hitesh Ballani, 15-Sep-08, 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. This document specifies two styles of FIB suppression. Edge suppression (ES) allows ISPs that deploy a core- edge topology to shrink the FIBs of their edge routers, including those that interface to other ISPs and exchange the full DFRT. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers. Both styles may be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "The WARC File Format (Version 0.16)", Sven Arvidson, John Kunze, Gordon Mohr, Michael Stack, 5-Jul-08, The WARC (Web ARChive) format specifies a method for combining multiple digital resources into an aggregate archival file together with related information. Resources are dated, identified by URIs, and preceded by simple text headers. By convention, files of this format are named with the extension ".warc" and have the MIME type application/warc. The WARC file format is a revision and generalization of the ARC format used by the Internet Archive to store information blocks harvested by web crawlers. This document specifies version 0.16 of the WARC format. "Graceful Shutdown of LDP Adjacency", Siva Sivabalan, Kamran Raza, Sami Boutros, Bob Thomas, Kenji Kumaki, 3-Nov-08, This document specifies an extension to Label Distribution Protocol (LDP) using which a Label Switched Router (LSR) can explicitly notify its neighbor LSR its intention to shutdown one or more LDP adjacencies. This extension shall be used to shutdown LDP adjacencies for planned maintenance without interrupting traffic. "The Model for Net and App Interaction", Ray Aatarashi, Megumi Ninomiya, 2-Nov-08, 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, 2-Nov-08, 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. "NETCONF DSDL and Yang Mapping", Ladislav Lhotka, Rohan Mahy, Sharon Chisholm, 3-Nov-08, This draft describes the algorithm and rules for defining NETCONF data modelss using Document Schema Definition Languages (DSDL) with additional annotations and based on a mapping from YANG. "Using EAP-GTC for Simple User Authentication in IKEv2", Yaron Sheffer, 6-Jul-08, 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. "IKEv2 based Mobile Network Prefix Assignment", Fan Zhao, Stefano Faccin, Ameya Damle, 6-Jul-08, This document proposes a mechanism for the Mobile Router to dynamically obtain the Mobile Network Prefix through IKEv2. The mechanisms to renew, release and update the allocated Mobile Network Prefixes are also described. "Using EAP keying material to derive keys for DHCP Authentication", Joseph Salowey, Richard Pruss, 6-Jul-08, This memo describes a mechanism to use keying material derived from the extensible authentication protocol (EAP) to derive cryptographic keys for authentication of the Dynamic Host Configuration Protocol (DHCP). Keys are derived from the EAP extended master session key (EMSK) and are used in a new DHCP authentication option based on the DHCP delayed authentication option defined in RFC 3118. "Problem Statement and Requirements for Diameter/Radius Prefix Authorization Application", Behcet Sarikaya, Frank Xia, 6-Jul-08, This document provides problem statement for AAA prefix authorization application. The document also identifies application scenarios and requirements on AAA prefix authorization application. "The References Header for SIP", Dale Worley, 6-Jul-08, This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and by extension, the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. "Practical Request for BGP Specification and Implementation", Yasuhiro Ohara, Kenichi Nagami, Akira Kato, 6-Jul-08, In 2007, a large scale incident have occurred multiple ISPs where a number of BGP sessions were disconnected. This happened because of the different implementation of BGP error handling. Therefore, it is necessary to classify the error processing of BGP to achieve stable operation of BGP, and to define it clearly. This document describes to clarify the classification of BGP error handlings. "Common TCP Evaluation Suite", Lachlan Andrew, Sally Floyd, 6-Jul-08, 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. "Path and Session Management in Proxy Mobile IPv6", Rajeev Koodli, Julien Laganier, 6-Jul-08, In a distributed network environment such as a Proxy Mobile IPv6 domain, it is often necessary to know that a peer is alive and, if not, detect quickly that a peer has failed and subsequently re- started. It is also necessary to detect failures where only a subset of the existing mobility sessions are affected. Furthermore, failure indication should be possible without waiting for an explicit query from a peer. This document outlines a protocol to address such path and session reliability for Proxy Mobile IPv6. "NAT for IPv6-Only Hosts", Cullen Jennings, 3-Nov-08, This specification defines a NAT that allows IPv6-only hosts that are inside the NAT to operate with IPv4 hosts that are outside the NAT. It requires no modifications to the v4 hosts or applications, or to the operating system of v6 hosts, but it does require some changes to v6 applications. Typically this specification would be used to allow the hosts inside a NAT to connect to hosts outside it; but under some limitations, it can also allow hosts outside to connect to hosts inside. The goal of this draft is to consider what is the minimal feasible approach to this problem. The current intention is to merge this with the nat64 draft. This draft is being discussed on the behave@ietf.org list. "DNS SRV Records for HTTP", Cullen Jennings, 6-Jul-08, This document specifies a mechanism for an HTTP client to perform a DNS SRV lookup to find an HTTP server. The draft is being discussed on the apps-discuss@ietf.org list. "HTTP API for Updating DNS Records", Cullen Jennings, Tom Daly, Jeremy Hitchcock, 3-Nov-08, 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. "Multicast Routing Blackhole Avoidance", Rajiv Asati, Mike McBride, 6-Jul-08, This document specifies a mechanism to avoid blackholing of IP Multicast traffic due to the disruption of multicast tree during the time when the RPF neighbor is yet to become the PIM neighbor. Such scenario is possible during the topology change (e.g. link UP) in an IP network that employs PIM-SM (or SSM) as the multicast routing protocol and a unicast routing protocol (including static routing). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "P2P Traffic Localization by Traceroute and 2-Means Classification", Yunfei Zhang, Liufei Wen, 23-Oct-08, Most P2P system performance suffers from the mismatch between the randomly constructed overlays topology and the underlying physical network topology, causing a large burden in the ISP and a long RTT time. This document describes how DHT overlay peers can interact with the routers by traceroute to get the path information, and execute 2- Means Classification, thereafter peers leverage the DHT itself to build efficient "closer" cluster. This scheme only requires the infrastructure to enable traceroute queries. "Effects of port randomization with TCP TIME-WAIT state.", Anantha Ramaiah, Patrick Tate, 6-Jul-08, Source port randomization has been suggested to provide improved security and obfuscation which helps in adding robustness towards blind attacks. With TCP in practice, simply producing a random port as the source port for a new connection can lead to problems when a TCP client establishes connections to a TCP server at a high rate. If the same source port value is chosen twice, the client TCP connection can fail due to the server having the Transmission Control Block (TCB) for this tuple lingering in TIME-WAIT state. This memo discusses the ramifications of such source port reuse scenarios and suggests some mitigations to avoid the same. "GMPLS RSVP-TE recovery extension for data plane initiated reversion", Attila Takacs, Benoit Tremblay, 3-Nov-08, 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 defines two new fields in the PROTECTION Object to specify wait-to-restore and hold-off intervals. "A Presence Information Data Format - Location Object Extension for Triangulation Data", James Polk, 6-Jul-08, This document describes how a Presentity Agent (PA) provides a Location Information Server (LIS) with location specific measurement data it observes, for example - how many satellites are visible to a PA, and at what angle are each currently, to aid the LIS in determining geographically where the PA is. This is done within a Session Initiation Protocol subscription framework where the LIS subscribes to the PA for its measurement data. The LIS performs the location calculation, determining where the PA is. "Extending the Presence Information Data Format - Location Object (PIDF-LO) for Assisted Global Positioning System (A-GPS) Data", James Polk, Jay Iyer, 6-Jul-08, This document defines how a device encapsulates Assisted Global Positioning System (A-GPS) data to ask a Location Information Server (LIS) to calculate the device's position, and return that information to the device. This communication will be completed using the Session Initiation Protocol (SIP), using Presence Filters specific to A-GPS in a (SUBSCRIBE) request, and a Presence Information Data Format - Location Object (PIDF-LO) as the (NOTIFY) reply. "Session Initiation Protocol (SIP) Location Get Function", James Polk, 6-Jul-08, This document defines how a watcher seeks the geographic location information from presentity. SIP Location Conveyance defines how location is sent from one entity to another unsolicited. This document specifies how a watcher, i.e., a Location Target, requests for specific geolocation state information of a presentity, in addition to the details within the subscription such as the format (geo or civic) returned and the frequency of updated location from the presentity. "Sensor Network Routing Requirements of Structural Health Monitoring", Jaakko Hollmen, Jukka Manner, 6-Jul-08, This document discusses monitoring the status of constructions, structural health monitoring, using sensor networks, and the requirements such a system puts on routing. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, 3-Nov-08, 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 Expires May 2009 [page 1] Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt address many issues that comes when a P2MP-TE LSP is signaled in a multi-domain networks. Specifically, one of the issues in multi-domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is remerge free. This document provides a framework and required protocol extensions needed 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). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Requirements for IP Multicast Session Announcement in the Internet", Hitoshi Asaeda, Vincent Roca, 6-Jul-08, 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 usefull and easy to use, but difficult to control the SAP message transmission in a wide area network. This document describes the several major limitations SAP has and the requirement of multicast session announcement in the global Internet. "PIM/GRE Based MVPN Deployment Experience and Recommendations", Rahul Aggarwal, Yakov Rekhter, 6-Jul-08, Multicast VPN, based on the Virtual Router model using PIM with GRE tunnels, has been in operation in production networks for several years. This document describes some of the experiences gained from implementation and deployment of such Multicast VPNs. Further it describes the practices used by such deployments based on the experience. "Meta-Architecture : A Common Means to Accommodate Heterogeneous Network Architectures", Myung-Ki Shin, Eun Paik, JinHyeock Choi, 7-Jul-08, The today's Internet architecture is under serious reconsideration and people started thinking about alternatives. Redefining Internet architecture requires many challenged works and a lot of new heterogeneous architectures suited to the future of the Internet would be considered. It is necessary to support a variety of the new different architectures to accommodate the heterogeneity of Future Internet. So, a common means should be provided to accommodate the new heterogeneous architectures. This document presents Meta- Architecture to accommodate heterogeneous and diverse multiple network architecture and user services, for example, heterogeneous wireless, mobile, sensor, vehicular and/or ad-hoc architectures and services. "SIP SAML Profile and Binding", Andreas Pashalidis, Joao Girao, 7-Jul-08, This document specifies the SIP/SAML profile and binding, i.e. a protocol for the use of Security Assertion Markup Language (SAML) assertions for the purposes of authentication and the exchange of attributes in a Session Initiation Protocol (SIP) environment. "TWAMP Reflect Padding Feature", Al Morton, Len Ciavattone, 7-Jul-08, The IETF is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a proposed feature for TWAMP, intended for discussion in the IP Performance Metrics WG. The feature gives the reflector the ability to return some of the packet padding bits to the sender. "Multicast Pruning in Provider Backbone Bridged VPLS", Ali Sajassi, Luyuan Fang, Pradosh Mohapatra, Nabil Bitar, Raymond Zhang, 7-Jul-08, The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. The ingress replication of PBB multicast traffic can be further improved by replicating such traffic over a subset of PWs for which there are receivers interested in that PBB multicast group. This document discusses the use of BGP for distribution of PBB multicast addresses (e.g., auto-discovery of these addresses) and applying multicast pruning to a VPLS instance for efficient ingress replication. "Multiprotocol Label Switching Transport Profile Survivability Framework", Nurit Sprecher, Adrian Farrel, Vach Kompella, 7-Jul-08, 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 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 protection 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 protection mechanisms utilize the MPLS-TP control plane. This document provides a framework for MPLS-TP survivability. "Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 3-Nov-08, 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. "Rich Template Set Extension to the IPFIX Protocol", Christoph Sommer, Falko Dressler, Gerhard Muenz, 7-Jul-08, This draft describes the Rich Template Set, a Template Set for the IPFIX Protocol, as well as its respective Template Records. One possible application domain for this new Set is the transport of IPFIX Flow Mediation selection criteria. In comparison to the use of Common Properties, the use of Rich Template Sets reduces the overhead of repeated transmissions and makes data transmissions more robust against failures. "Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, Kazuhide Koide, Sri Gundavelli, Ryuji Wakikawa, 3-Nov-08, This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway node and the local mobility anchor functions of a Proxy Mobile IPv6 (PMIPv6) entity. "New Care-of CGA Configuration for FMIPv6", David Hu, Chunqiang Li, 7-Jul-08, Fast Mobile IPv6 defines the necessary IP protocol messages to reduce the handover latency resulting from the Mobile IPv6 procedures. One of the important functionality is new care-of address configuration. This document introduces two possible methods for configuring NCoA based on CGA in FMIPv6. "IKEv2 SA Synchronization for session resumption", Yan Xu, Peng Yang, Yuanchen Ma, Hui Deng, Hui Deng, 7-Oct-08, It will take a long time and mass computation to do session resumption among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. The major reason is that the prcocedure of IKEv2 SA re-establishment will incur a time-consuming computation especially in the Diffie- Hellman exchange. In this draft, a new IKE security associations synchronization solution is proposed to do fast IKE SA session resumption by directly transferring the indexed IKE SA (named stub) from old gateway to new gateway, wherein the most expensive Diffie- Hellman calculation can be avoided. Without some time-consuming IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption procedures can be finished in a short time. "Camellia Cipher Suites for TLS", Akihiro Kato, Masayuki Kanda, Satoru Kanno, 15-Jul-08, This document specifies set of cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a block cipher algorithm. This proposal provides options for fast and efficient block cipher algorithms. "A Handover Authentication based on AAA server in FMIPv6", Jaeduck Choi, Doohwan Kim, Souhwan Jung, 7-Jul-08, This document describes a handover authentication protocol based on the AAA server in FMIPv6. The proposed scheme employs the Diffie- Hellman (DH) algorithm to enhance security aspects, and modifies the DH key exchange to reduce computational cost at the Mobile Node (MN) by delegating exponential operation to the AAA server. The MN and Access Router (AR) establish the handover key HK through the AAA server. The main advantage of this document is more secure and suitable to a light-weight mobile terminal. "The Extended GSS-API Negotiation Mechanism (NEGOEX)", Larry Zhu, Kevin Damour, Dave McPherson, 14-Jul-08, This document defines the Extended Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (NegoEx). NegoEx is a pseudo-security mechanism that logically extends the SPNEGO protocol as defined in RFC4178. The NegoEx protocol itself is a security mechanism negotiated by SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY adds a pair of meta-data messages for each negotiated security mechanism. The meta-data exchange allows security mechanisms to exchange auxiliary information such as trust configurations, thus NegoEx provides additional flexibility than just exchanging object identifiers in SPNEGO. NegoEx preserves the optimistic token semantics of SPNEGO and applies that recursively. Consequently a context establishment mechanism token can be included in the initial NegoEx message, and NegoEx does not require an extra round-trip when the initiator's optimistic token is accepted by the target. Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a security mechanism MUST support in order to be negotiated by NegoEx. This document defines these GSS-API extensions. Unlike SPNEGO however, NegoEx defines its own way for signing the protocol messages in order to protect the protocol negotiation. The NegoEx message signing or verification can occur before the security context for the negotiated real security mechanism is fully established. "Problem Statement and Requirement of Simple IP Multi-homing of the Host", Min Hui, Hui Deng, 3-Nov-08, 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. "MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov Weingarten, 7-Jul-08, The intention of this document is to analyze the set of requirements for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to verify whether the existing MPLS OAM tools can be applied to these requirements, identify which of the existing tools need to be extended, and which new tools should be defined. 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. "The requirement and proposal of extenting M3UA signalling network route management", Xu Chen, Hao Zhang, Xiaodong Duan, Zhao Yuyi, Li Xinyan, 7-Jul-08, RFC 4666 defines M3UA a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP applications, so the network level management function isn't required. But when M3UA is used in IP based signaling network, the network level management function needs to be extended. This document provides the proposals for extending M3UA signalling network route management. This document is consistent with RFC4666 in other sides. "Suggested process changes for handling new SIP headers and SIP responses", Keith Drage, 7-Jul-08, RFC 3427 currently defines the process for defining and registering new SIP header fields. This document proposes that prefixs to header field names should be discontinued, and that an additional category of experimental header field should be created. This document also relaxes the requirement that response codes are defined by standards track RFCs, also allowing them to be defined by experimental RFCs. "Best Current Practice for IP-based In-Vehicle Emergency Calls", Brian Rosen, Hannes Tschofenig, Ulrich Dietz, 15-Jul-08, 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, 7-Jul-08, 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. "A Session Initiation Protocol (SIP) Event Package for Location Information", James Winterbottom, Martin Thomson, Hannes Tschofenig, 7-Jul-08, This document specifies a SIP event package allowing allowing a location receiptient to subscribe for location information when provided a location URI using the sip, sips, or pres URI schemes. The notification that results from the subscription is either the location of the Target or an error. "MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov Weingarten, 3-Sep-08, The intention of this document is to analyze the set of requirements for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to verify whether the existing MPLS OAM tools can be applied to these requirements, identify which of the existing tools need to be extended, and which new tools should be defined. 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. "Link properties advertisement from modem to router", Lloyd Wood, Rajiv Asati, Daniel Floreani, 14-Jul-08, Routers are increasingly connected to a variety of smart modems. Such a modem's incoming and outgoing link rates can be varied over time with adaptive coding and modulation to suit the channel characteristics. The link rate and conditions offered by the modem to connected devices therefore vary. For connected devices to condition traffic and get the most out of the modem's link capacity, they need to know the modem's link conditions. This document describes one simple method for the modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. "Independent Session Control Feature for TWAMP", Al Morton, 7-Jul-08, The IETF is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a proposed feature for TWAMP, intended for discussion in the IP Performance Metrics WG. The feature gives the sender the ability to start and stop one or more test sessions using the Session Identifiers. "Why should the Traffic Optimization not be restricted to the Application-Layer?", Damien Saucez, Dimitri Papadimitriou, 7-Jul-08, The Application-Layer Traffic Optimization (ALTO) problem is being discussed within the IETF and more globally by the research community and some enterprises. In this memo, we argue that it is important to conceive general-purpose mechanisms to solve this problem. By general-purpose we say not only application independent but also layer independent mechanism. The generality can be obtained because the underlying problem is the same regardless the application or the layer. "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, 6-Jul-08, 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. "TCP Flow Control for Fast Startup Schemes", Michael Scharf, Sally Floyd, Pasi Sarolahti, 7-Jul-08, This document describes extensions for the flow control of the Transmission Control Protocol (TCP) that avoid interactions with fast startup congestion control mechanisms, in particular the Quick-Start TCP extension. Quick-Start is an optional TCP extension that allows to start data transfers with a large congestion window, using feedback of the routers along the path. This can avoid the time consuming Slow-Start, provided that the TCP flow control is not a limiting factor. There are two potential interactions between the TCP flow control and congestion control schemes without the standard Slow-Start: First, receivers might not allocate a sufficiently large buffer space after connection setup, or they may advertise a receive window implicitly assuming the Slow-Start behavior on the sender side. This document therefore provides guidelines for buffer allocation in hosts supporting the Quick-Start extension. Second, the TCP receive window scaling mechanism can prevent fast startups immediately after the initial three-way handshake connection setup. This document describes a simple solution to overcome this problem. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 7-Jul-08, Many Service Providers (SPs) offer the 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. "Monitoring Architectures for RTP", Geoff Hunt, Philip Arden, 7-Jul-08, This memo is intended to stimulate discussion on a hierarchical monitoring architecture for RTP, including a scheme for the definition of lower-layer metrics which are usable by a range of applications. Systematic investigation of a monitoring architecture for RTP/RTCP was requested at the IETF71 (Philadelphia) AVT session. This first version of the draft is restricted to transport metrics and to a subset of audio application metrics, but it is envisaged that future work should extend this to other applications, principally video. "SRTP Store and Forward", Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman, 3-Nov-08, 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 to 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 proposal on how to introduce the needed new functionality and transforms in SRTP is also presented. "JWT Report on MPLS Architectural Considerations for a Transport Profile", Stewart Bryant, Loa Andersson, 7-Jul-08, This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to Transport Networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. There are two versions of this RFC. An ASCII version that contains a summary of the slides and a PDF version that contains the summary and a copy of the slides. "Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6 Domains", Niklas Neumann, Xiaoming Fu, Jun Lei, Gong Zhang, 7-Jul-08, 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. "A Session Initiation Protocol (SIP) Load Control Event Package", Charles Shen, Henning Schulzrinne, Arata Koike, 3-Nov-08, This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to SIP servers. The load control information can throttle outbound calls based on their destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. "The Global HAHA Operation at the Interop Tokyo 2008", Ryuji Wakikawa, Keiichi Shima, Noriyuki Shigechika, 7-Jul-08, This document describes the protocol design consideration of the correspondent router for the NEMO Basic Support Protocol. "The Design Consideration of Correspondent Router", Ryuji Wakikawa, 7-Jul-08, This document describes the protocol design consideration of the correspondent router for the NEMO Basic Support Protocol. "NEMO Basic Support for Fixed Access Networks", Ryuji Wakikawa, Shin Miyakawa, 7-Jul-08, This document describes the usage of Network Mobility (NEMO) for the commercial ISPs. NEMO can be a mechanism to provide IP subscription. "Marking Converter for Excess-Marked Traffic", Michael Menth, Frank Lehrieder, 7-Jul-08, This document proposes an algorithm that converts packet markings of a stream that was excess-marked based on a lower-rate into packet markings that correspond to a stream that was excess-marked based on a higher-rate. It may be applied in the PCN context to convert marked admissible-rate-overload into marked supportable-rate- overload. This allows to perform marked flow termination when packets are excess-marked based on the admissible rate only. "End-to-End Identity Important in the Session Initiation Protocol (SIP)", John Elwell, 25-Oct-08, 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. "RUCUS Test Cases", David Schwartz, 7-Jul-08, This document is meant to serve as a repository for test cases assoicated with taking some action upon receipt of unwanted communications. "A way for a host to indicate support for 240.0.0.0/4 addresses", Teemu Savolainen, 7-Jul-08, This document describes how the 240.0.0.0/4 address space can be taken into use in incremental and backwards compatible manner in certain networks, and how reclassification of 240.0.0.0/4 address space as private would help Internet growth and transition to IPv6. "IPv4 support in PMIP-MIP interaction", Desire Oulai, Suresh Krishnan, 7-Jul-08, PMIPv6 and MIPv6 are respectively the leading protocols for network based and client based mobility. As backward compatibility is an important feature, IPv4 support for PMIPv6 and MIPv6 becomes mandatory. This document highlights some scenarios for PMIPv6-MIPv6 interaction with IPv4 support as well as some proposed solutions. "Key Data for a Registry Provisioning Interface draft-guyton-drinks-registry-data-00.txt", Debbie Guyton, 7-Jul-08, This document defines data that should be included in a provisioning interface for a Registry. The provisioning interface may be used in (near) real time, or periodically, from a service provider's service provisioning system to establish and administer telephone number (TN) and associated routing information in the Registry after necessary validations. Based on 1) effective date/time specified for the data and 2) validation of the TN assignee, these data will be used to define selective routing views for various recipient service providers which would be reflected in ENUM-SIP address servers. In addition, the concept of multiple TNs sharing a common routing pattern simplifies the definition and administration of routing data. D. Guyton Expires 01/07/09 [page 1] Registry Provisioning Interface July 2008 "Local Forwarding in Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury, 7-Jul-08, 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. "Bulk Re-registration for Proxy Mobile IPv6", Domagoj Premec, Basavaraj Patil, Suresh Krishnan, 14-Jul-08, 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. "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", Ulas Kozat, Ali Begen, 7-Jul-08, 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. "Problem Statement: Link Degradation Isolation in Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", Zhenqiang Li, Lianyuan Li, Xiaodong Duan, 7-Jul-08, IS-IS protocol specifies a procedure that if a Link State Protocol Data Unit (LSP) with an incorrect LSP Checksum is received, the corruptedLSPReceived circuit event will be generated and the corrupted LSP will be discarded. This document aims to emphasize that although this procedure can maintain the network stability, it can not diagnose and isolate the source of the network problem. In some cases this procedure will create bad effect on the services carried by the network. This document suggests that IS-IS protocol introduce the mechanism for link degradation detection and isolation, which should be triggered when corrupted LSP is received. "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", Carlos Bernardos, Maria Calderon, Ignacio Soto, 7-Jul-08, The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON enables mobility-agnostic nodes within the mobile network to directly communicate (i.e. without traversing the MRHA bi-directional tunnel) with Correspondent Nodes. The solution is based on the Mobile Router performing the Mobile IPv6 Route Optimisation signalling on behalf of the nodes of the mobile network. This document (in an appendix) also analyses how MIRON fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. "Teredo Extensions", Dave Thaler, 3-Nov-08, 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. "Correspondent Router based Route Optimisation for NEMO (CRON)", Carlos Bernardos, Maria Calderon, Ignacio Soto, 7-Jul-08, The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, based on the well-known concept of Correspondent Router. The solution aims at meeting the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. Based on the ideas that have been proposed in the past, as well as some other extensions, this document describes a Correspondent Router based solution, trying to identify the most important open issues. The main goal of this first version of the document is to describe an initial NEMO RO solution based on the deployment of Correspondent Routers and trigger the discussion within the MEXT WG about this kind of solution. This document (in an appendix) also analyses how a Correspondent Router based solution fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. "BGP Class of Service Interconnection", Thomas Martin Knoll, 7-Jul-08, This document focuses on Class of Service Interconnection at inter- domain peering points. It specifies two new non-transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability Attribute" is deliberately kept simple and denotes the general EF, AF Group and BE 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. The denoted Class of Service forwarding support is meant as the AS externally available (transit) Class of Service support. "GDOI Generic Message Authentication Code Policy", Brian Weis, Sheela Rowles, 7-Jul-08, A number of IETF signaling and routing applications require a set of devices to share the same policy and keying material and include a message authentication code in their protocols packets for authentication . It is often beneficial for this keying material to be chosen dynamically using a group key management protocol. This memo describes the policy required for the Group Domain of Interpretation (GDOI) group key management system to distribute a message authentication code key and associated policy. "Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, Robin Seggelmann, Eric Rescorla, 7-Jul-08, This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). The user of DTLS over SCTP can take advantage of all features provided by SCTP and its extensions, especially support of o multiple streams to avoid head of line blocking. o multi-homing to provide network level fault tolerance. o unordered delivery. o partial reliable data transfer. "The Use of Entropy Labels in MPLS Forwarding", Kireeti Kompella, Shane Amante, 7-Jul-08, Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the notion of "entropy labels". It defines the concept, describes why they are needed, suggests how they can be used, and enumerates properties of entropy labels that allow optimal benefit. "Raptor FEC Schemes for FECFRAME", Mark Watson, 7-Jul-08, This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor code and its application to reliable delivery of media streams in the context of FEC Framework. The Raptor code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor code offers a close to optimal protection against arbitrary packet losses at a low computational complexity. Two FEC Schemes are defined, one for protection of arbitrary packet flows and another for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. An RTP Payload Type is defined for this latter case. "Unicast-Based Rapid Synchronization with RTP Multicast Sessions", Bill Steeg, Ali Begen, Tom Caenegem, 3-Nov-08, When a receiver joins a multicast session, it may need to acquire and parse certain key information before it can process any data sent in the multicast session. Depending on the join time, length of the key information repetition interval, size of the key information as well as the application and transport properties, the time lag before a receiver can usefully consume the multicast data, which we refer to as the synchronization 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 existing RTP and RTCP protocol machinery that reduces the synchronization delay. In this method, an auxiliary unicast RTP session carrying the key information to the receiver precedes/accompanies the multicast flow. This unicast flow may be transmitted at a faster than natural rate to further accelerate the synchronization. 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 synchronization delay is long enough to be a problem. "TICTOC Requirement", Silvana Rodrigues, Kurt Lindqvist, 17-Nov-08, 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 workinggroup to address the problem and perform an analysis on existing solutions and the needs. This document summarises application needs, as described and agreed on at an TICTOC interim meeting held in Paris from June 16 to 18, 2008. "Generic Ethernet Pseudowire", Shane Amante, Giles Heron, Andrew Malis, Vach Kompella, Florin Balus, 15-Jul-08, This draft proposes a simpler approach to handling various encapsulations of Ethernet packets over a pseudowire, over the existing Ethernet Pseudowire definition in [RFC4448]. "PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri Papadimitriou, JP Vasseur, 7-Jul-08, 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) Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms and defines no new formats or mechanisms. It relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. "NETCONF Notification Content", Sharon Chisholm, Alex Clemm, Malcolm Betts, 7-Jul-08, The NETCONF Event Notifications standard specifies the mechanism by which NETCONF clients can subscribe to and receive event notifications. However, with the exception of a timestamp, no standard Notification content was defined. This memo defines a set of information that should be included in all NETCONF notifications, information that should be included based on class of notification and also defines a set of specific notifications to support specific management functions, such as configuration. "Requirements for OAM in MPLS Transport Networks", Martin Vigoureux, David Ward, Malcolm Betts, Matthew Bocci, Italo Busi, 1-Nov-08, This document lists the requirements for Operations, Administration and Maintenance functionality in MPLS networks that are used for packet transport services and network operations. These requirements are derived from the set of requirements specified by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5]. "PCN Encoding for Packet-Specific Dual Marking (PSDM)", Michael Menth, Jozef Babiarz, T Moncaster, Bob Briscoe, 7-Jul-08, This document proposes how PCN marks can be encoded into the IP header. The presented encoding reuses the ECN field of the Voice- Admit DSCP in a single PCN domain. The encoding of unmarked PCN packets indicates whether they are subject to either excess- or exhaustive-marking. This is useful, e.g., when data and probe packets require different marking mechanisms. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. "A Framework for MPLS in Transport Networks", Matthew Bocci, Stewart Bryant, 31-Oct-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. "Private Extensions to the Session Initiation Protocol (SIP) for Asserter Identification within Trusted Networks", Hadriel Kaplan, 7-Jul-08, 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. "Simplified VPLS-PBB interworking via MMRP", David Allan, Nigel Bragg, Dinesh Mohan, 7-Jul-08, This document describes how MAC filtering programmed by the IEEE multiple MAC registration protocol (MMRP or 802.1ak) can be employed by VPLS-PE devices as the exclusive mechanism for interworking with 802.1ah PBBNs. No new protocol standardization is required to do this, however there are small procedural changes associated with the interworking of protocols. "DHCPv4 Vendor-specific Message", Bernie Volz, 7-Jul-08, This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes. "Uses of policy control in routing", Anne-Louise Burness, 7-Jul-08, When considering a new routing system, we need to ensure that it is able to meet the functionality requirements of the participant networks. One aspect that is frequently over-looked is that routing is rarely a simple matter of choosing a least-hop path. This document attempts to highlight some of the more common policy choices that are made. We expect that policies that are in common use today should be easy to implement with any new routing schemes. Any routing scheme make it possible or significantly easier to implement the harder policies would have an implementation advantage. "Enhanced BGP Capabilities for Exchanging Second-Best Paths", Brian Dickson, 13-Jul-08, This Internet Draft describes an enhanced format for encoding prefix information, to permit multiple copies of a prefix with different paths to be announced and withdrawn. Prefix instances using the new format include both unique identifiers, and ordinals to control path selection. Withdrawal of prefixes requires a slight modification to disambiguate prefix instances.Author's Note This Internet Draft is intended to result in this draft or a related draft(s) being placed on the Standards Track for idr. "Enhanced BGP Capabilities for Exchanging Additional Nth-Best Paths", Brian Dickson, 13-Jul-08, This Internet Draft describes an enhanced way to exchange prefix information, so as to permit multiple copies of a prefix, with different paths, to be announced and withdrawn. This negotiated capability facilitates faster local (inter-AS) and global (intra-AS) convergence, reduces path-hunting, improves route- reflector behaviour, including eliminating persistent oscillations. Additional prefix instances have a new wire format for updates and withdrawals, to control path selection. Benefits are seen both when deployed intra-AS, and on inter-AS peering. Author's Note This Internet Draft is intended to result in this draft or a related draft(s) being placed on the Standards Track for idr. "End-to-end Extension for PCN Encoding", Michael Menth, Jozef Babiarz, T Moncaster, 7-Jul-08, This document proposes an encoding of PCN marks based on the ECN field of the Voice-Admit DSCP. It has global meaning and ECN semantics are not applied to that field. The PCN codepoints are the same as those for packet-specific dual marking (PSDM) within a single PCN domain, but the general concept can also be applied to other encodings requiring only a single PCN-enabled DSCP. "Opaque MSRP Path Uri", Derek MacDonald, Hadriel Kaplan, 7-Jul-08, The Message Session Relay Protocol(MSRP) does not allow efficient 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 topology hiding. It defines the option tag msrp-opaque. "Datagram Transport Layer Security Transport Model for SNMP", Wesley Hardaker, 3-Nov-08, 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 (UDP) 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. "Context-based Header Compression for 6lowpan", Carsten Bormann, 7-Jul-08, 6lowpan (RFC 4944) so far has only defined stateless forms of header compression. This document specifies how a node and a router can agree on state that will allow much better header compression of global addresses. $Id: draft-bormann-6lowpan-cbhc.xml,v 1.2 2008/07/07 22:19:28 cabo Exp $ "EDNS Option Code for Private Opaque Text", Hadriel Kaplan, Robert Walter, Raja Gopal, Tom Creighton, 7-Jul-08, This document requests an IANA allocation for an EDNS Option code, per [RFC2671], for an opaque text field for private use. "IP Flow Anonymisation Support", Elisa Boschi, Brian Trammell, 14-Jul-08, This document describes anonymisation techniques for IP flow data. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It describes support for anonymization 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. "An Extension to the Presence Information Data Format - Location Object (PIDF-LO) for the Timezone of a Presentity", James Polk, Jonathan Rosenberg, 7-Jul-08, The Presence Information Data Format - Location Object (PIDF-LO) lacks an indication for the timezone offset of a particular presentity is in. This document extends the PIDF-LO for including such an XML element. "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", Mary Barnes, Chris Boulton, Lorenzo Miniero, Simon Romano, 7-Jul-08, 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. "Nominating Committee Process: Issues since RFC 3777", Spencer Dawkins, Danny McPherson, 7-Jul-08, This document describes issues with the current IETF Nominating Committee process that have arisen in practice. "AS4-specific RD/RT/SOO Capability exchange", Samita Chakrabarti, 7-Jul-08, RFC 4893 defines BGP support for four-octet AS number space for handling AS_PATH attributes and "My ASN" value in BGP OPEN messages. Foue-Octet AS specific Extended Community attribute formats are defined in draft-rekhter-as4octet-ext-community-03.txt. However, an implementation compliant to RFC 4893 does not necessarily provide support for 4-Octet Route-distinguisher, Route-target or Site-of- origin in the BGP-MPLS-VPN. Thus BGP capability exchange for extended AS number attribute does not cover the BGP-MPLS-VPN AS4- specific route-attributes and route-distinguishers. This document proposes an optional BGP capability exchange between the Provider Edge (PE) routers in order to communicate the intention of handling 4-Octet or 2-Octet exteneded AS-specific Route-targets or Site-of- Origins or being able to handle and inteprete the 4-Octet route- distinguishers correctly. This capability parameter will be part of OPEN message during the BGP session initiation. "The Importance of a Visual Identifier of Trusted Identity", Dan York, 3-Nov-08, This document discusses the need for a visual identifier in Session Initiation Protocol (SIP) endpoints to indicate to the end user that they are speaking with someone whose identity is trusted. "Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, 3-Nov-08, This document describes a Session Traversal Utilities for NAT (STUN) usages for discovering the path MTU between a client and a server. "PBS NSLP: Network Traffic Authorization", Se Gi Hong, Henning Schulzrinne, 3-Nov-08, This document describes the NSIS Signaling Layer protocol (NSLP) for network traffic authorization on the Internet, the Permission-Based Sending (PBS) NSLP. This NSLP aims to prevent Denial-of-Service (DoS) attacks and other forms of unauthorized traffic. PBS NSLP is based on the proactive approach of explicitly granting permissions and the reactive approach of monitoring and reacting against the attacks. Signaling installs and maintains the permission state of routers for a data flow. PBS NSLP uses two security mechanisms: message security in an end-to-end fashion and channel security in a hop-by-hop fashion. The message security is for protecting the integrity of the message on end-to-end traffic and channel security is for protecting the integrity and confidentiality between adjacent nodes. These security mechanisms enable the secure distribution of shared keys, as well as protection of signaling messages. To authenticate data packets, the PBS NSLP requests a sender to use an existing security protocol, the IPsec Authentication Header (AH). This allows routers to drop bogus packets by using an IP packet filter. To avoid a compromised router that drops legitimate packets, the PBS NSLP triggers the sender to change the data flow path. "Signaled PID When Multiplexing Multiple Payloads over RSVP-TE LSPs", Zafar Ali, 7-Jul-08, 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 Expires January 2009 [page 1] draft-ali-mpls-sig-pid-multiplexing-case-00.txt [RFC3471], [RFC3473]. The document propose use of some dedicated PID values to cover some typical cases of multiple payload carried by the LSP, including that indicates to the egress node to ignore signaling to learn payload carried by the LSP. "IPv4 ID Uniqueness Requirements", Joseph Touch, Matt Mathis, 7-Jul-08, The IPv4 Identification field enables fragmentation and reassembly. This document clarifies the meaning of this field in the absence of fragmentation, based on ubiquitous current practice. "Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley, 7-Jul-08, This document discusses the role of tunnels in the Internet architecture. It explains their relationship to existing protocol layers, and the challenges in supporting tunneling. "The Location "On Behalf Of" Model is Broken", Marc Linsner, 7-Jul-08, There is proposed solution submitted to the GeoPriv work group that outlines the need for a location recipient to obtain the location of a target without the target's knowledge. The scenario is described as supporting a legacy device (a device lacking support for location) for the purposes of utilizing location when the legacy device summons emergency help (by dialing 911/112, etc.). Below is a discussion of the of the general topic of discovering location via 'On Behalf Of' or OBO. "Requirements of One-way Passive Measurement for End-to-End Quality", Yutaka Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, 7-Jul-08, This draft describes the necessary requirements to passively measure end-to-end quality and to monitor them via applicable ways. This feature is crucial for Service Providers (SPs), especially who provide transports with Service Level Agreements (SLAs). "On the Relative Importance of P2P Peer Selection", Patrick Crowley, 7-Jul-08, This Internet-draft discusses the relative importance of path selection in peer-to-peer (P2P) applications in light of the recent discussions highlighting the conflict between the use of P2P applications and the costs borne by network infrastructure operators. "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy, 3-Nov-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 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. "Transport for Advanced Networking Applications (TANA) Problem Statement", Stanislav Shalunov, 14-Jul-08, The IETF P2PI workshop conducted in the end of May 2008 at MIT in Boston has identified a number of potential documents for the IETF to work on. One is a transport protocol with congestion control mechanism that enables an advanced networking application to minimize the extra delay it induces in the bottleneck while implementing an end-to-end version of scavenger service. At least one such protocol has now been implemented by a major peer-to-peer application and deployed in the wild with favorable results. Another is a document that addresses community concerns about the use of multiple transport connections by peer-to-peer applications, both when these connections run to the same peer and to different peers. These two items appear to fall within the Transport area, but not within the charter of any existing working group. It is not obvious what WG's charter could be naturally extended to encompass these two items. The TANA BoF is held to explore the problem space, gauge the interest in the problems within the Transport area, and to see if the community and the area directors believe that it makes sense to form a TANA working group within the Transport area chartered to work on 1. standardizing end-to-end congestion control that enables advanced application to minimize the delay they introduce into the network and a protocol using it and 2. a document describing the current practice of peer-to-peer apps' use of multiple transport connections and recommendations in this space.1. Requirements notation "HIP Extensions for Object to Object Communications", Gyu Myoung Lee, Jun Kyun Choi, Taesoo Chung, 3-Nov-08, 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. "Customer MAC Address Flushing Mechanisms for Provider Backbone Bridging over VPLS", Ali Sajassi, Samer Salam, Luyuan Fang, Nabil Bitar, Dinesh Mohan, 7-Jul-08, The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB introduces the notion of Backbone MAC (B-MAC) addresses vs. Customer MAC (C-MAC) addresses, thereby leading to the requirement for having MAC address flushing mechanisms for each. This document discusses a C-MAC address flushing notification mechanism to be used in VPLS networks that employ PBB technology. "Provider Backbone Bridges in H-VPLS with MPLS Access", Ali Sajassi, Samer Salam, Nabil Bitar, Dinesh Mohan, 7-Jul-08, Provider Backbone Bridge (PBB) functionality, under standardization in IEEE 802.1ah, can be employed to enhance the scalability of H- VPLS with MPLS access. This document describes how PBB technology can be used in H-VPLS with MPLS access networks to improve the scalability of customer MAC addresses and number of service instances that can be supported. The document also describes the migration mechanisms and scenarios by which PBB functionality can be incorporated into H-VPLS with existing MPLS access. "Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, 7-Jul-08, 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. "6LoWPAN Architectural Consideration for Mobility", Geoffrey Mulligan, Carl Williams, David Huo, 3-Nov-08, The 6LoWPAN problem statement [RFC4919] provides for a goal that 6LowPAN devices have simple interconnectivity to other IP networks including the Internet. Such interconnectivity means that a global reachability requirement to 6lowpan networks is part of the 6LoWPAN architecture. Here the 6LoWPAN devices must be reachable by any corresponding node, independent of the current location. The 6LoWPAN architecture also describes support for various topologies which require mobility support. Architectural considerations and analysis for mobility is needed to ensure proper performance for these usage scenarios. The architectural considerations for mobility may present unique challenges to the 6LoWPAN given their requirements for low memory and power constraints. Hence it is best to have mobility as an architectural consideration upfront rather than an after thought in the development of 6LoWPAN milestones. This document provides a mobility perspective to the 6LoWPAN sensor network architecture. "AntiVirus Markup Language(AVML)", Antiy Labs, Antiy Labs, 11-Jul-08, This document describes the AntiVirus Markup Language(AVML). AVML is common standards language for storage, interaction and statistics of malicious software information. Malware information described by AVML More easily is dealt in distributed system. At the same time, people can read it . This document defines the AVML and explains the elements in AVML. "General Virus Process Language(GVPL)", Antiy Labs, Antiy Labs, 9-Jul-08, General Virus Process Language (GVPL) is lua scripting language expansion. It is designed to dispose of the virus which found in network terminal quickly. Because of the flexibility and simplicity of Lua script, GVPL is easy to achieve the goal which is rapid response to large-scale expansion of the virus. At the same time,it will reduce economic losses of users. "Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 1-Nov-08, 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 or with the Voicemail-URI which are standardized solutions. In addition, an interworking policy is proposed to manage the headers coexistence. The History-Info header is described in [RFC4244] and the Voicemail URI in [RFC4458]. 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. "DNS Encryption", Duane Groth, 14-Jul-08, This document requests IANA registration of a new DNS OpCode and ErrorCode type in facilitating encryption of DNS requests and replies and feed back to the client if plain text requests are not acceptable. Once this OpCode is seen the DNS server attempts to decrypt the request using its private OpenPGP key. Inside the encrypted packet is the AES key which the client expects to be used when the server encrypts a response. A server may advertise that it is capable of DNS encryption by returning OpenPGP fingerprints in TXT records using a similar format to Public Key Association (PKA). The full pubic keys are returned from DNS servers by using a CERT request against the host name(s) of the domain's NS records or via OpenPGP key servers. "RTP Payload Format for the iSAC Codec", Tina le Grand, Paul Jones, 12-Jul-08, iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions, suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within an RTP packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). "Commercial Routing Requirements in Low Power and Lossy Networks", Jerry Martocci, Ted Humpal, Nicolas Riou, Jon Williamsson, 14-Jul-08, The ROLL Working Group was recently chartered by the IETF to define routing characteristics for low power embedded devices. ROLL would like to serve the Industrial, Commercial, Home and Urban markets. Pursuant to this effort, this document defines the functional and cost requirements for installing integrated facility management systems in commercial facilities. The routing requirements for commercial building applications are presented in this document. Commercial buildings have been fitted with pneumatic and subsequently electronic communication pathways connecting Martocci Expires January 14, 2009 [page 1] Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008 sensors to their controllers for over one hundred years. Recent economic and technical advances in wireless communication allows facilities to increasingly utilize a wireless solution in lieu of a wired solution; thereby reducing installation costs yet maintaining highly reliant communication. Wireless solutions will be adapted from their existing wired counterparts in many of the building applications including, but not limited to HVAC, lighting, security, fire, and elevator products. These devices will be developed to reduce installation costs; while increasing installation and retrofit flexibility. Sensing devices may be battery or mains powered. Actuators and area controllers will be mains powered. To meet the cost target, these devices must have a total installed cost below that of the traditional wired alternative; yet maintain reliability on par with wired devices. The total installed cost includes the infrastructure, product, installation, commissioning, labor and operational costs of the device over its 30 year lifespan. Except for special circumstances such as flexible installation (e.g. airports) or cosmetics (e.g. museums, there is nothing compelling about installing wireless solutions inside a building unless it can be accomplished below the cost of a wired installation. This document will define the requirements necessary for wireless technology to displace wired infrastructure and meet this objective. "Faster application handshakes with SYN/ACK payloads", Adam Langley, 5-Aug-08, This document advocates the usage of small, mostly constant payloads in the SYN+ACK frame of the 3-way TCP [RFC0793] handshake. We show how this can have immediate benefits for some protocols. Additionally, we describe a new TCP option that enables a wider range of protocols to gain from it. "User centric QoS policy management for heterogeneous Internet environment", Ilka Miloucheva, Irit Sterdiner Mayer, P.A. Aranda Guiterrez, Adam Flizikowski, Christophe Chassot, 18-Jul-08, This document presents a framework for user-centric Quality of Service (QoS) management in heterogeneous Internet environments (considering fixed, mobile and broadcast networks). The framework is based on dynamic business level QoS policy specification by different actors (such as users, operators and administrators), as well as hierarchical policy refinement and translation, supporting the automated configuration of QoS mechanisms at heterogeneous network and transport entities. The hierarchical policy approach involves abstractions and mapping of policies described at business, unified, operational and configuration level considering networks with different capabilities and QoS requirements of different actors. The policy specification is dependent on the Service Level Agreements (SLAs) of the particular actors. This allows controlled and restricted usage of the network resources by the actors according to the actor dependencies and corresponding SLA rules. The policy management framework includes components for dynamic actor-based QoS policy specification, policy consistency check and dependency analysis regarding SLAs, automated policy provisioning and configuration at heterogeneous transport and network entities, policy monitoring and performance assessment, as well as automated adaptation of QoS mechanisms at operational level. Policy enforcement combined with policy monitoring and performance assessment is considered, as well as automated adaptation of policy parameters (e.g. operational policies) based on policy performance analysis. Interactions of components for policy specification and automated provisioning are based on policy repository storing the unified (intermediate) policy representations describing policy parameters, conditions and actions. "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Teco Boot, Arjen Holtzer, 1-Nov-08, Mobile Ad hoc Networks (MANET) may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing preferred Border Router(s) and configuring IP address(es) needed for communication between MANET nodes and nodes on the Internet via the selected Border Router. Autonomous MANETs do not have Border Routers; an self-sufficient Address Autoconfiguration is defined as well. "A CGA based Source Address Authorization and Authentication (CSA) Mechanism for First IPv6 Layer-3 Hop", Jun Bi, Jianping Wu, Guang Yao, 27-Jul-08, This document describes a method to authorize and authenticate the address of a node in an IPv6 network. Except for "Host Change", this method satisfies all the requirements in the Charter of SAVI. The modification on a host can be regarded as the extension of SEND and IPSec. "Specifying Derived Location in a PIDF-LO", James Winterbottom, Martin Thomson, 27-Jul-08, This document describes how specify that a location in a PIDF-LO has been derived or converted from a different location. The source location may reside in the same PIDF-LO or be a remote document referenced by a location URI and associated id fragement. "Advertisement of the best-external route to IBGP", Pedro Roque Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, 27-Jul-08, This document makes a case and provides the rules for a border router to advertise its best external route towards its IBGP peers when its overall best is a route received from an IBGP peer. The best external route may be different from the overall best route installed in the Loc-Rib. Advertising the best-external route (when different from the overall best route) into an IBGP helps in speeding up routing convergence, has positive effects in reducing inter-domain churn and in some limited scenarios could help avoid permanent IBGP route oscillation. The document also extends this mechanism to route reflectors and confederation border routers to advertise a best route that is external to the cluster/domain. "FTP Extension Registry", John Klensin, 27-Jul-08, Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. As the number of those extensions increases, it appears useful to establish an IANA registry to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. "FTP Extension for Internationalized Text", John Klensin, 27-Jul-08, The original FTP protocol supported TYPE values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet becomes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP TYPE value for Unicode data. "Location and Discovery of Subsets of Resources", Lican Huang, 27-Jul-08, 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. "Textual Representation of AS Numbers", George Michaelson, Geoff Huston, 28-Jul-08, A textual representation for Autonomous System (AS) numbers is defined using "asdot" notation. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. "Textual Representation of AS Numbers", Geoff Huston, George Michaelson, 28-Jul-08, A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS Number. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. "Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks", Jonathan Hui, 28-Jul-08, This document specifies a simple version of IPv6 Neighbor Discovery for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover routers, discover network configuration parameters, and IPv6 prefixes for use with stateless address autoconfiguration and context-based 6LoWPAN compression for IPv6 headers. This document also specifies autoconfiguration mechanism for use in 6LoWPAN networks. "Capabilities Update Problem Statement", Tina Tsou, 28-Jul-08, This specification clarifies "Capabilities Update" in OPEN state defined in RFC 3588bis. Capabilities update in OPEN state can reuse commands CER/CEA commands for re-negotiation between Diameter peers when one of them changes its capabilities.It is a very important function in Diameter. However, RFC 3588 has defined a mechanism of containing capabilities list both in CER and CEA commands and the peer should update its local database whenever it receives CER/CEA. This makes the process complex and redundant when they are used in OPEN state. So this draft proposes a simpler solution based on CER/CEA commands to deal with this problem. "EDNS0 Support in Authority Servers on 27 July 2008", Shane Kerr, Joe Abley, 28-Jul-08, This memo documents the methodology and results of an experiment which tested the availability of the DNS Extension Mechanism (EDNS0) on a large set of authority-only nameservers. The experiment was conducted in the bar during the IETF 72 meeting on 27 July 2008. The results of this experiment suggest that EDNS0 deployment is extensive: it was found that 94.4% of non-defective authority-only servers are EDNS0-capable. "Incentives and Deployment Considerations for P2PI Solutions", Jari Arkko, 29-Jul-08, Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to- peer traffic in networks in the most efficient way and with minimal impact to other traffic. This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic. The paper concludes that it is essential to understand the incentives in order to have a deployable solution. "Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet", Brian Rosen, 3-Nov-08, 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. "MSWS Method to Support Shared-Mesh Restoration for Wavelength Switched Optical Networks", Lin Guo, Yuefeng Ji, Hongxiang Wang, 29-Jul-08, This document proposes a method called Most Sharable Wavelength per Segment (MSWS) to support shared-mesh restoration for wavelength switched optical networks (WSON). The proposed method can perform efficient wavelength sharing in a distributed fashion. It uses the signaling extensions for WSON which is previously proposed in the document "Signaling Extensions for Wavelength Switched Optical Networks" (draft-bernstein-ccamp-wson-signaling-01) and no other protocol extensions of Generalized Multi-Protocol Label Switching (GMPLS) routing and signaling are needed. "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)", Pekka Nikander, Gonzalo Camarillo, Jan Melen, 3-Nov-08, This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks. "Remote Triggered Black Hole filtering with uRPF", Warren Kumari, Danny McPherson, 29-Oct-08, 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. It also defines a standard BGP community for black hole prefixes to simplify associated semantics. "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 Softwires", David Hankins, 11-Aug-08, This document describes how Softwires configuration can be obtained via DHCPv6. "Application Extension Bundle description Language (AEBL)", Trevor Clarke, 31-Jul-08, This memo presents an RDF [refs.RDF] vocabulary for describing an application extension bundle [refs.aeb]. An application extension bundle, otherwise known as an add-on, extension, plug-in, suite, or package, is an encapsalation of all the data needed to add functionality to a plug-in based application. An integral piece of an application extension bundle is the metadata describing the bundle. The described RDF vocabulary contains required and optional metadata fields used by an application extension bundle to describe itself. "Application Extension Bundle (AEB)", Trevor Clarke, 31-Jul-08, This memo presents a file format for describing an application extension bundle. An application extension bundle, otherwise know as an add-on, extension, plug-in, suite, or package, is an encapsalation of all the data needed to add functionality to a plug-in based application. "Guidance on Interoperation and Implementation Reports", Lisa Dusseault, Robert Sparks, 31-Jul-08, 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. "Nest Route Optimization for NEMO (NERON)", Faqir Zarrar Yousaf, Christian Wietfeld, Alain Tigyo, 21-Aug-08, IETF has proposed MIPv6 based Network Mobility (NEMO) Basic Support protocol that handles the mobility management of IPv6 based mobile networks. However the NEMO protocol has severe performance limitations and does not specify the route optimization method for mobile networks and does not take into account the operational and functional complexities involving nested mobile networks. In this draft we present NEst Route Optimization for NEMO (NERON) protocol, a light weight, efficient and scalable approach that aims at enabling nodes behind nested mobile networks to use optimized communication paths with zero tunneling overhead and minimum end-to- end delay, irrespective of the depth of the nest, with minimum but manageable changes to the base MIPv6 and IPv6 Neighbor Discovery protocols and without introducing any new network entities. "The Expires Header in E-mail", Michael Welzl, Thomas Nolf, Jacob Palme, 4-Aug-08, This memo introduces a new email header called Expires. Using this header, the sender of an email can state that (s)he believes this message will be irrelevant after the indicated date/time. The receiving MUA can then automatically detect that a message has expired and facilitate handling of such emails for the user. "IPv6 Path MTU computation using routing protocol", Vijay Kumar Vasantha, 4-Aug-08, This document describes a mechanism for dynamically computing IPv6 PMTU and the modifications needed in IPv6 to support the solution. "ISIS: Path MTU calculation in ISIS", Vijay Kumar Vasantha, 4-Aug-08, This draft defines a method for calculating the PMTU for each IPv6 destinations using ISIS routing protocol. By doing so the overhead incurred in the existing path maximum transferable unit discovery mechanism is reduced and the same solution can be extended to other link state routing protocols as well. "SASL Mechanism for External Authentication using Channel Bindings: EXTERNAL-CHANNEL", Simon Josefsson, 5-Aug-08, This document describes a way to perform end-user authentication in the Simple Authentication and Security Layer (SASL) framework which re-use an external security layer (such as the Transport Layer Security (TLS) protocol) that may have already completed end-user authentication. In comparison with the existing EXTERNAL mechanism, this mechanism offers a way to cryptographically bind the authentication to the security layer via a channel binding. The EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made by the design of the EXTERNAL mechanism. See for more information. "MLD Extensions to Support the Mobile Multicast Group Management", Hong-Ke Zhang, Jian-feng Guan, Hua-chun Zhou, Zhi-wei Yan, 5-Aug-08, Mobile multicast is a research hotspot. Some mobile multicast schemes was proposed, but most of them depend on the traditional group membership management protocol and concern on the reconstruction of multicast delivery tree by various algorithms, and they little consider the mobile group membership management. So in this memo, we extend the MLD protocol to support the mobile multicast group management. The extension is compatible with the traditional MLD protocols, and it can also be applied to the IGMP protocol to manage the mobile multicast in IPv4. "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, 6-Aug-08, 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. "A DNS Resource Record for Additional Entropy", Jim Reid, 6-Aug-08, A scheme to defend against cache poisoning attacks against the Domain Name System (DNS) by predicting the ID and source port number of outgoing queries is described in this draft. It proposes a new resource record to provide a mechanism to introduce additional entropy into DNS queries. "Translator Friendly DNS Proxy", Masahito Endo, Hiroshi Miyata, 1-Oct-08, This document describes the DNS Proxy that is separated from NAT-PT [RFC2766]. NAT-PT was designed to work with DNS Application Level Gateway. However [RFC4966] pointed out DNS related issues, and [RFC2766] was changed to historical state. This document attempts to DNS Proxy specification, removing dependency on NAT-PT as well as resolving problems pointed in [RFC4966]. "DKIM Author Domain Signing Practices (ADSP) Security Issues", Douglas Otis, 30-Sep-08, The proposed [I-D.ietf-dkim-ssp] defines DNS records that advertise the extent to which a domain employs [RFC4871] to sign [RFC2822] messages, and defines how other hosts can access these advertisements. Its laudable goal is to allow domains control over the use of the From header field. When a message is not adequately signed, advertised assertions, referenced by a domain in the From header field, assist in resolving the message's intended disposition. Rather than dealing with keys that impose a restriction on the "on- behalf-of" identity as a separate security consideration to be handled independently from an assertion that a domain signs their messages, [I-D.ietf-dkim-ssp] instead employs a flawed two-stage signature validation process that works in conjunction with advertised practices. The two-stage approach will most likely occur after message acceptance, and impairs the range of authentication assertions permitted by a single signature. The limitations on authentication assertions inhibits tactics needed to deal with replay abuse. As currently structured, advertised practices not only assert whether a signature should be expected, they also constrain the "on-behalf-of" identity applied by signing agents that are not otherwise so restricted by [RFC4871]. By constraining the "on- behalf-of" identity for all signing agents, the draft neglects the predominate role of the domain as a point of trust, and incorrectly assumes the signature is limited to supporting assertions regarding the identity of the author. By limiting the DKIM signature's "on- behalf-of" value to being representative of only the message's author, the draft goes well beyond the working group's charter and appears to infringe on S/MIME's and OpenPGP's role. [I-D.ietf-dkim-ssp] impairs security in other ways as well, such as the only directly actionable practice is defined using a term likely to negatively impact the integrity of delivery status. Fortunately minor changes to the definition of a compliant signature can remedy the impairment created, where the critical security issues are best handled independent of any [I-D.ietf-dkim-ssp] assertion. "New Tunnel-Type Values", Abhishek Tiwari, 29-Aug-08, This document defines a set of values for the Tunnel-Type RADIUS Attribute. "Kerberos ticket extensions", Love Astrand, 14-Sep-08, The Kerberos protocol does not allow ticket extensions. This make it harder to deploy features like referrals and 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. "GSS-API: Delegate if approved by policy", Love Astrand, Sam Hartman, 23-Sep-08, 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 ability to act as a user 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). "ECC Support for SEND/CGA", Sean Shen, Michaela Vanderveen, 10-Oct-08, This draft proposes an upgrade to the SEND/CGA protocols to incorporate support for elliptic curve cryptography. "Approach to Digital Signature Systems Deployment", John Marchioni, Yair Itzhaki, 14-Aug-08, Most digital-signature system deployments require dedicated and solution-specific user-enrollment procedures and user-enrollment software[1], and mandate provisioning and distribution of physical or software-based signature-key tokens to end users. As deployed such approaches create a high burden in logistics, cost, and help-desk support. They also introduce training obstacles for users and systems administrators. This document describes the deployment architecture approach used by ARX to provide secure and efficient digital signature services based on its CoSign(r) solution. The security solution's deployment architecture is documented in the hope that other digital-signature and PKI deployment efforts will deliver comparable efficiencies. [1] This is also true for deployments of non-standard proprietary electronic signature solutions. "OpenPGP Attribute Extension", Duane Groth, 14-Aug-08, A RFC was accepted extending TLS usage to include OpenPGP keys (RFC 5081) as an alternative or in addition to X.509 certificates, however the author did not really standardise the way the information in OpenPGP keys was to be presented and this could be detrimental or fragment efforts to utilise OpenPGP keys in this manner. The author didn't touch on the issue generating confidence scores beyond potential use of Certificate Authorities. "Applicability of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Headers", Julian Reschke, 15-Aug-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, 17-Aug-08, For various reasons, it may be desireable to ask a remote nameserver to add certain data to the response to a query. This document describes an EDNS option that implements such behaviour. "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Arnaud Ebalard, Sebastien Decugis, 18-Aug-08, This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IKE in a Mobile IPv6 environment. This document is heavily based on a previous draft [MIGRATE] written by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply reuses the MIGRATE mechanism defined in the expired document, removes a companion extension (SADB_X_EXT_PACKET) based on implementation feedback (complexity, limitations, ...) and fills the gap by very simple changes to MIGRATE mechanism. This results in a more simple and consistent mechanism, which also proved to be easier to implement. This document is expected to serve as a continuation of [MIGRATE] work. For that reason, the name of the extension has been kept. PF_KEY MIGRATE message serves as a carrier for updated address information for both the in-kernel IPsec structures (SP/SA) and those maintained by the key managers. This includes in-kernel SP/SA endpoints, key manager maintained equivalents and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements. "Alert-Info header URNs for Session Initiation Protocol (SIP)", Denis Alexeitsev, 2-Sep-08, The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. "Ivip4 ETR Address Forwarding", Robin Whittle, 22-Aug-08, ETR Address Forwarding (EAF) is a novel method by which an IPv4 Core- Edge Separation solution to the Internet's routing scaling problem can tunnel packets from an ITR to an ETR. EAF involves using 31 bits of the IPv4 header for new purposes: bit 48, the More Fragments flag, the Fragment Offset field and the Header Checksum field. Consequently, packets in this format need to be handled by routers with modified functionality. EAF is an alternative to encapsulation (map-encap) or address translation (Six/One Router) and has advantages including: simpler ITRs and ETRs, direct support for conventional RFC 1191 PMTUD, no encapsulation overhead and full compatibility with IPsec AH and Traceroute. "Neighbor Discovery Suppression", Laurent Toutain, Guillaume Chelius, Yoongsoo Lee, Yongqiang DONG, 20-Aug-08, The 6LoWPAN IETF working group is developing protocols to allow IPv6 end-to-end communication with sensors networks. Low-power MAC protocols such as IEEE 802.15.4 impose a slightly reduced frame size. To enable IPv6 communication, 6LoWPAN proposes to use fragmentation and header compression techniques. This document proposes an extension to the 6LoWPAN proposal and defines a class of sensors that can be joined at the network level while ignoring their own global IPv6 address. This architecture centralizes the address management on the sensor network gateway (the PAN Coordinator) and allows the suppression of the Neighbor Discovery Protocol. Consequently, the insertion of sensors in such a network is faster and the traffic within the network, largely composed of broadcast messages generated by Neighbor Discovery Protocol, is reduced. We investigate the impact of this architecture on star and mesh topologies. "Rbridge Notes", Donald Eastlake 3rd, 20-Aug-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, 21-Aug-08, 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. "IP and ARP over Wiegand", Scott Guthery, 22-Aug-08, This document describes the transport of IP datagrams over the Security Industry Association standard [3] five-conductor cable called the Wiegand interface used for communication between card readers and control panels in physical access control systems. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Images in RFCs", Robert Braden, John Klensin, 25-Sep-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 graphics or picture images. The historic solution to this requirement, allowing secondary PDF and Postscript files, is seldom used because it is awkward for authors and publisher. This memo sugests a more convenient scheme for attaching authoritative diagrams, illustrations, equations or other graphics to RFCs. "Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications", David Hankins, 22-Aug-08, The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the previously defined standard, and some questions about DHCPv4 server behaviour remain unclear. "The Metalink Download Description Format", Anthony Bryan, 18-Sep-08, This document specifies Metalink Documents, an XML-based download description format. "Security Assessment of the Internet Protocol version 4", Fernando Gont, 31-Aug-08, 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). "Resolver side mitigations", Wouter Wijngaards, 25-Aug-08, Describes a set of mitigations that stop the known Kaminsky variations, for which only resolver side deployment is necessary. "EDNS EXPIRE OPTION", Mark Andrews, 25-Aug-08, Provide a method for slave DNS servers to honour the SOA EXPIRE field as if they were always transferring from the master, even when using other slaves to perform indirect transfers and refresh queries. "With-defaults capability for NETCONF", Andy Bierman, Balazs Lengyel, 22-Oct-08, 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 rpc reply 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 rpc reply messages. "Media Format Choices for RFCs", Dave Crocker, 27-Aug-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 graphics or picture images. The historic solution to this requirement, allowing secondary PDF and Postscript files, is seldom used because it is awkward for authors and publisher. This memo suggests a more convenient scheme for attaching authoritative diagrams, illustrations, or other graphics to RFCs. It further proposes conventions for additional input and display formats, to improve readability. This proposal is based on draft-rfc-image-files-00, by Braden and Klensin, and revises it as little as possible, while expanding the goals of the effort. "Transport Layer Security (TLS) Authorization Using KeyNote", Angelos Keromytis, 1-Oct-08, 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. "Spam reduction using messageid.", Mark Turner, 27-Sep-08, This draft suggests a technique of spam reduction by extending the SMTP service to include a 'Did You Send' query protocol. "An Architecture for Network Management", Philip Shafer, 4-Sep-08, 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, the standards 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. An architecture is described which is friendly to both devices and applications, to vendors and standards bodies, to young and to old, to red states and to blue states. It's a startling vision, coming to networks near you starting August, 2009. "Multicast Routing in Proxy Mobile IPv6", Hong-Ke Zhang, Jian-feng Guan, Hua-chun Zhou, ying zhu, 4-Sep-08, With the development of various mobile technologies, mobile multicast becomes a research hotspot. Several mobile multicast schemes were proposed, but most of them are based on the Mobile IPv6 and its alternatives. Recently, the Proxy Mobile IPv6 (PMIPv6) was proposed to provide the mobility support for mobile node without mobility function. However, the PMIPv6 mainly concerns on the unicast transmission support, and little considers the multicast routing. So, in this memo, we propose two mobile multicast mechanisms, the MAG- based method and LMA-based method to support the multicast routing in PMIPv6. "Never Ending Network Addresses: IPv4 Multiplexing trought IPv6", Alessandro Spinella, 5-Sep-08, 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. "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Adrian Farrel, 1-Nov-08, Several protocols have been specified using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Reduced BNF), and makes it available for use by new protocols. "Resolver side mitigations", George Barwood, 26-Oct-08, Describes mitigations against spoofing attacks on DNS, including: (1) Repeating the query, including techniques for handling non-deterministic responses. (2) Prepending a random nonce to the question where a referral is probable. (3) Estimating the entropy available, taking into account (a) Observed packets with incorrect IDs. (b) The content of the cache. "RTP Payload Format for Portable Network Graphics (PNG) image", Omer Boyaci, Henning Schulzrinne, 8-Sep-08, This document describes how to carry Portable Network Graphics (PNG) images in RTP packets. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", Vishwas Manral, 8-Sep-08, This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. This document updates RFC3811 and fixes the . "Encapsulation Methods for Transport of InfiniBand over MPLS Networks", Suresh Shelvapille, Vikas Puri, 8-Sep-08, 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. "In-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria Napierala, 8-Sep-08, 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. "Link Connectivity and Common Constraint Information Extension to GMPLS for WDM Switched Optical Networks", Zhihong Kang, Zhenyu Wang, Feng Gao, 9-Sep-08, This document provides the mechanism of link connectivity verification and the constraint information extension to GMPLS IGP or Conveyed to a path computation element (PCE) for static light path computation and selection in WDM network. "Building Automation Routing Requirements in Low Power and Lossy Networks", Jerry Martocci, Nicolas Riou, Pieter Mil, Wouter Vermeylen, 14-Oct-08, 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. "AS Number Reservation for Documentation Use", Geoff Huston, 10-Sep-08, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. "A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information", Samir Saklikar, Subir Saha, Ranjit Avasarala, 10-Sep-08, This draft defines a Session Initiation Protocol (SIP) Event Notification Framework-based mechanism 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. The applicability of this event package includes 3GPP IMS. "Suite B Cryptographic Suites for Secure Shell", Kevin Igoe, 11-Sep-08, This document describes the basic architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol. Suite B secure shell makes use of elliptic curve Diffie-Hellmann (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. "SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services", Milan Patel, 3-Nov-08, This memo describes requirements and protocol conventions for a new SIP (Session Initiation Protocol) URI parameter intended for marking SIP requests and responses related to emergency services. This proposal addresses issues that exist in the current 3rd Generation Partnership Project IP Multimedia Subsystem (IMS) Emergency services solution, but is not precluded from being used by other SIP-based emergency services solutions. It is not intended as a replacement for the service URN. "Delay-Tolerant Networking Metadata Extension Block", Susan Symington, 15-Sep-08, This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. This Metadata Extension Block is designed to be used to carry metadata that forwarding nodes can use to make routing and other decisions regarding the bundle. This block is defined to enable the actual metadata that is inserted into the block to have any content and format, providing the format has been documented as a metadata ontology. Specific metadata ontologies may be defined in additional documents. "IVI Update to SIIT and NAT-PT", Xing Li, Congxiao Bao, Fred Baker, Kevin Yin, 16-Sep-08, This note proposes an address and service architecture designed to facilitate transition from an IPv4 Internet to an IPv6 Internet. This service contains three parts: A DNS Application Layer Gateway, a stateful Network Address Translator that enables IPv6 clients to initiate connections to IPv4 servers and peers, and a stateless Network Address Translator that enables IPv4 and IPv6 systems to interoperate freely. It is couched as an update to RFCs 2765 and 2766. This is because the stateless service is essentially the SIIT with a different address format, and because the DNS Application Layer Gateway and the stateful translator have significant similarities to NAT-PT. There are, however, important differences from NAT-PT, responsive to the issues raised in RFC 4966. "BU/BA Based Prefix Delegation Support for Mobile Networks", Behcet Sarikaya, Frank Xia, 15-Sep-08, This document defines prefix delegation support for a mobile network. 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. "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", James Randall, 15-Sep-08, This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This is an update of 3447. Certain errors were also corrected for this update and are identified in the text. "A Comparison of Proposals to Replace NAT-PT", Dan Wing, David Ward, Alain Durand, 29-Sep-08, As we approach IPv4 address depletion, the IETF must provide for IPv4 and IPv6 coexistence: a way for ISPs and enterprises to reduce public IPv4 address consumption and a way for hosts to migrate to IPv6 connectivity -- while providing reasonable access for those IPv6 hosts to access the IPv4 Internet. This draft compares eight proposals for IPv6 and IPv4 coexistence. "Decrypted Content Attachment Flag for Internet Message Access Protocol (IMAP)", Dan Newman, Ned Freed, 16-Sep-08, This document promulgates an Internet Message Access Protocol (IMAP) flag keyword which Mail User Agents (MUAs) may use to indicate that the decrypted content of an encrypted message contains one or more attachments. This document intentionally leaves undefined the definition of an "attachment" and is neutral as regards the message encryption system. This document also defines an IANA registry for IMAP flag keyword conventions. "Multicast Support Requirements for Proxy Mobile IPv6", Hui Deng, Thomas Schmidt, Pierrick Seite, Peng Yang, 19-Oct-08, This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. "Wireless Multi-path Transmission Using SCTP", Hong-Ke Zhang, Bo Wang, Fei Song, Huan Yan, 16-Sep-08, In this draft, WCMT-SCTP(WCMT:Wireless Concurrent Multi-path Transfer)is proposed to allow a host to improve the transmission throughput in wireless multi-hop networks using simultaneous multi- path transmission of Stream Control Transmission Protocol. Relevant issues of WCMT-SCTP included are: (1) data transmission mode and path selection, (2) path management and, (3) multi-path handover mechanism. Transmission modes of WCMT-SCTP, and the path handover mechanism, are designed to enhance the transmission throughput and solve the receive buffer blocking problem of different wireless link status. Since the transmission paths used for WCMT-SCTP may differ when an WCMT-SCTP host moves, the multi-path handover problem is defined, and a handover mechanism is proposed. "IPv6 Connectivity Check and Redirection by HTTP Servers", Eric Vyncke, 17-Sep-08, Rather than forcing the client to decide whether IPv4 or IPv6 is more convenient to reach a web server; this document proposes to let the web server check whether there is IPv6 connectivity to the client; then the web server can do a HTTP redirect to the force the client to use IPv6. This is done easily by a script within the server HTML pages and does not require any change in the client applications or configuration. The client still can control whether he/she wants to enabled IPv6. This draft could be discussed on the Applications Discuss mailing list, https://www.ietf.org/mailman/listinfo/apps-discuss. "IETF Streaming Media, Current Status", Joel Jaeggli, 17-Sep-08, This document describes the operation of the audio streaming service provided for the IETF from IETF 62 up to the most recent (IETF 72) meeting. Efforts associated with meetings prior to IETF 62 back to IETF 49 as well as a proposal for the current effort were detailed in the now expired draft draft-jaeggli-ietftv-ng-01.txt. The purpose of this document is to inform future efforts to deliver streaming media services for remote or local participants of the level of service and the technology that was employed. "Signaling 3 PCN states with baseline encoding", Ruediger Geib, 19-Sep-08, Layer 2 transport services like MPLS offer only 2 states to encode ECN state, if DiffServ based Class of Service is operated. Still, a mechanism by which PCN egress nodes can differentiate between the normal behaviour state, admission stop state control state and flow termination state, by using PCN marking of packets is desirable. This document describes how threshold and excess marking can be combined with PCN baseline encoding. A minimalistic approach like the one described in the following has some obvious shortcomings. These shortcomings are also presented and discussed. Currently, the aim of this document is to trigger experimentation feasability studies. Standardisation will be pursued in the future based on the results of the studies. "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Jari Arkko, Mark Townsley, 19-Sep-08, When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. "RTP Payload Format for MPEG-4 Audio/Visual Streams", Yoshihiro Kikuchi, Yoshinori Matsui, Toshiyuki Nomura, Shigeru Fukunaga, Hideaki Kimata, Malte Schmidt, Frans Bont, Intellectual Property, 19-Sep-08, 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, 2-Oct-08, 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 lead 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, Intellectual Property, 22-Sep-08, 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, Intellectual Property, 22-Sep-08, 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. "RSVP-TE Recovery Signaling Fixes", Andrew Rhodes, Nic Neate, David McWalter, 24-Sep-08, This document updates the ASSOCIATION object used in RSVP-TE signaling of End-to-End and Segment Recovery. This document solves problems with existing Segment Recovery procedures, and also makes possible recovery paths that cross addressing domain boundaries. "Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen, 3-Nov-08, With the foreseen scarcity of public IPv4 addresses and the hesitation and technical difficulties to deploy IPv6, the transition scenarios which assumed that migration to IPv6 happens before the run-out of IPv4 addresses, need to be revisited. This document defines a method to allocate the same IPv4 address to multiple hosts, thus prolonging the availability of public IPv4 addresses for as long as it takes for IPv6 to take over the demand for IPv4. The document also describes the deployment scenarios where this method is applicable. "Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements", Greg Bernstein, Young Lee, Dan Li, 26-Sep-08, 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 such an approach and their potential impacts on network nodes, routing protocols, and PCEs. "Fast Connectivity Restoration Using BGP Add-path", Pradosh Mohapatra, Rex Fernando, Clarence Filsfils, Robert Raszuk, 27-Sep-08, A BGP route defines an association of an address prefix with an "exit point" from the current Autonomous System (AS). If the exit point becomes unreachable due to a failure, the route becomes invalid. This usually triggers an exchange of BGP control messages after which a new BGP route for the given prefix is installed. However, connectivity can be restored more quickly if the router maintains precomputed BGP backup routes. It can then switch to a backup route immediately upon learning that an exit point is unreachable, without needing to wait for the BGP control messages exchange. This document specifies the procedures to be used by BGP to maintain and distribute the precomputed backup routes. Maintaining these additional routes is also useful in promoting load balancing, performing maintenance without causing traffic loss, and in reducing churn in the BGP control plane. "OAuth: HTTP Authorization Delegation Protocol", Eran Hammer-Lahav, Blaine Cook, 29-Sep-08, This document specifies OAuth, an HTTP authorization delegation protocol for accessing protected resources. "Dual-stack lite broadband deployments post IPv4 exhaustion", Alain Durand, Ralph Droms, Brian Haberman, James Woodyatt, 2-Nov-08, 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. "A Profile for AS Adjacency Attestation Objects", Geoff Huston, George Michaelson, 29-Sep-08, This document defines a standard profile for AS Adjacency Attestation Objects (AAOs). An AAO is a digitally signed object that provides a means of verifying that an AS has made an attestation that it has a inter-domain routing adjacency with one or more other AS's, with the associated inference that this AS may announce or receive routes with these adjacent AS's. "Stateless Address Mappings (SAMs) IPv6 & extended IPv4 via local routing domains - possibly multihomed", Remi Despres, 3-Nov-08, Stateless Address Mapping (SAM) is a generic technique to achieve global IPv4 or IPv6 connectivity across local domains where routing is in a different address space. To cope with the IPv4 address shortage, it supports an extension of IPv4 addresses with dynamic- port prefixes. For multi-homed routing domains, it ensures that source addresses that cross domain borders are always routable in the reverse direction (Reverse Path Forwarding). SAM can be used alone as an alternative to NATs, to improve scalability and end-to-end network transparency, or in combination with NATs, to cover a wider range of IPv4-IPv6 coexistence scenarios. "Comprehensive DNS Resolver Defenses Against Cache Poisoning", Nicholas Weaver, 30-Sep-08, DNS resolvers are vulnerable to many attacks on their network communication, ranging from blind attacks to full men-in-the-middle. Although a full man-in-the-middle can only be countered with cryptography, there are many layers of defenses which apply to less powerful attackers. Of particular interest are defenses which only require changing the DNS resolvers, not the authoritative servers or the DNS protocols. This document begins with a taxonomy of attacker capabilities and desires, and then discusses defenses against classes of attackers, including detecting non-disruptive attacks, entropy budgeting, detecting entropy stripping, semantics of duplication, and cache policies to eliminate "race-until-win" conditions. Proposed defenses were evaluated with traces of network behavior. "Approach to Digital Signature Systems Deployment", John Marchioni, Yair Itzhaki, 30-Sep-08, Conventional deployments store keys on PC hard disks, application- server hard disks, or in tokens, and also introduce complications for user enrollment and management. User and administrator frustration with the conventional approach has cramped development of a market for PKI. As a result, PKI has not reached its utilization potential and is far from becoming ubiquitous. This document describes architecture for deployment of secure and efficient digital signature capabilities based on a centralized key- management approach and emphasizes the importance of not disrupting existing identity and authentication management and application infrastructure. An alternative architecture is documented here so that PKI deployments will lower their associated administrative burdens and deliver improved scalability. "MLD Source Address Selection for Mobile Multicast", Hong-Ke Zhang, Jian-feng Guan, Hua-chun Zhou, Zhi-wei Yan, 30-Sep-08, With the development of wireless and mobile technologies, mobile multicast becomes a research hotspot. However, the current multicast routing protocols can not provide the mobile multicast services. To support the mobile multicast, the related multicast specifications need to be extended. In this memo, we focus on the group membership management protocol and define the new source address selection policy for mobile multicast. "The Extension in NetLMM to Carry Network Condition Information", Hong-Ke Zhang, Hua-chun Zhou, Zhi-wei Yan, Jian-feng Guan, 30-Sep-08, The NetLMM WG is specifying Proxy Mobile IPv6 for network-based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover into account in the first protocol release. When a mobile node connects to the access networks through a sole interface or multiple interfaces, the condition of the access networks should be considered to improve the performance of the ongoing applications. According to the normal operation, Local Mobility Anchor (LMA) can not get enough information to do the necessary scheduling with Mobile Access Gateway (MAG) and Mobile Node (MN), such as flow distribution. This document defines a PMIPv6 extension that carries network condition in the form of simple class indication which is calculated and sent from MAG to LMA in the Access Technology Type option. "Router Advertisement Extension to Recognize Access Location for Mobile Router", Hong-Ke Zhang, Zhi-wei Yan, Hua-chun Zhou, Jian-feng Guan, 30-Sep-08, The Router Advertisement message in IPv6 Neighbor Discovery Protocol [2] contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines a flag to the Router Advertisement message that extends the available number of flag bits available. The extended flag defined in this document is mainly used by Mobile Router to identify its location. "Identity Handling at a Session Initiation Protocol (SIP) User Agent", John Elwell, 1-Oct-08, Session Initiation Protocol (SIP) User Agents (UA) receive identifiers for the caller and callee during call establishment. These identifiers can come in a variety of forms, can be delivered by a variety of means, and may or may not be accompanied by evidence of authenticity. Furthermore, if media are secured (e.g., using the Secure Real-Time Protocol, SRTP), the security properties of the media will depend on binding the media to a received authenticated identifier. This document examines the various identification information a UA can receive during call establishment and how a user agent can use this information to present a caller or callee identifier to the user and indicate to the user the security properties of the call, as well as how the user agent might use this information for other purposes, such as authorizing acceptance of a call. This work is being discussed on the sip@ietf.org mailing list. "IKEv2 Session Resumption", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 3-Nov-08, 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 (SA) 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 uses a ticket to store state information that is later made available to the IKEv2 responder for re-authentication. Restoring state information by utilizing a ticket is one possible way. This document does not specify the format of the ticket but recommendations are provided. "RFC Editor Model", Olaf Kolkman, 3-Nov-08, 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. 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, 3-Oct-08, 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, 3-Oct-08, 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, 3-Nov-08, 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. As a result, this draft can serve as a guideline for risk assessments 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. "RPKI Repository Retrieval Mechanism", Terry Manderson, George Michaelson, 5-Oct-08, This document proposes a mechanism for a relying party to synchronise a local cache of the RPKI repository using a HTTPS retrieval mechanism. "A UDP/IP Adaptation of the ZigBee Application Protocol", Gilman Tolle, 8-Oct-08, This document describes a UDP/IP adaptation of the IEEE 802.15.4- based ZigBee Application Protocol that enables IP hosts to communicate using the application profiles and data models described by that protocol, over a wide range of links. This modified version of the ZigBee Application Protocol is named CAP (Compact Application Protocol), and it is intended to provide a complete stack of application profiles, data exchange, binding operations, security protocols, and discovery to IP-networked hosts and embedded devices. The protocol's domain of applicability includes IEEE 802.15.4-based 6LoWPAN devices, but also those on conventional wired and wireless links and emerging powerline communication networks. "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. "Load Sharing in Proxy Mobile IPv6", An-fu Zhou, Gang Chen, Min Liu, Dapeng Liu, 9-Oct-08, 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 proposes to use multiple LMAs for the consideration of traffic overload, and describes a load sharing mechanism between multiple LMAs. "LMA Discovery for Proxy Mobile IPv6", Jouni Korhonen, Vijay Devarapalli, 10-Oct-08, 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, 10-Oct-08, 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, David Ward, George Swallow, 10-Oct-08, This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) using which an MPLS Label Switching Router (LSR) can explicitly request another MPLS LSR to operate an MPLS Transport Profile(MPLS-TP) Label Switched Path between the two LSRs in loopback mode. This extension can be used to loop the data traffic up to certain LSR in the path of the MPLS LSP back to the source for management purpose. "PREFIX64 Comparison", Hiroshi Miyata, 13-Oct-08, There are several NAT64 and/or NAT46 proposals. Each of them have recommended PREFIX64, which is used to represent IPv4 address in IPv6 address format. Each of them have advantages and shortcomes. Therefore the preferable PREFIX64 would depends on the utilization scene. This draft compares seven proposals for IPv6 and IPv4 coexistence.i "Diameter Command Codes for 3GPP EPS Diameter Applications", Mark Jones, Lionel Morand, 14-Oct-08, This document describes a set of new IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). "Routing and Addressing in Next-Generation EnteRprises (RANGER)", Fred Templin, 17-Nov-08, Enterprise networks will require support for both Internet protocol versions (IPv4 and IPv6) for an indeterminant period; perhaps even indefinitely. This is particularly true for existing enterprise networks that must introduce IPv6 without disruption of IPv4 services, but the same principles apply even for clean-slate deployments in new enterprises. Next-generation enterprises therefore require an architected solution for coordination of their internal routing and addressing plans for both IPv6 and IPv4. The RANGER architecture addresses these requirements. "CAPWAP WLAN-VLAN Information Message Element", Haibo Wen, Sudhanshu JAIN, 14-Oct-08, In Control And Provisioning of Wireless Access Points Protocol, the WLANs on the Wireless Termination Point are created by the Access Controller with the appropriate setting. This document defines a mew messages elements, i.e., WLAN-VLAN Information message element, which is used to set WLAN-VLAN binding information on the WTP. "CAPWAP Station IP Address", Haibo Wen, Sudhanshu JAIN, 14-Oct-08, In Control And Provisioning of Wireless Access Points Protocol, the Access Controller controls whether Wireless Termination Point should forward the traffic for some specified station. This document defines a mew messages elements, IEEE Station IP Address, which are used for better control of station's access in local-MAC mode of CAPWAP. "Intradomain Presence and IM Federation Call Flow Examples", Sanjay Sinha, Avshalom Houri, 14-Oct-08, This document gives call flow examples and relevant message details at the interface of two federating server that have implemented intradomain federation using the model described in Models for Intra- Domain Presence and Instant Messaging (IM) Federation, [I-D.ietf-simple-intradomain-federation]. "Feature Interactions Problem Statement", Rui Gustavo Crespo, Luigi Logrippo, 14-Oct-08, Internet applications have been enhanced with many features. A feature may be defined as a unit of functionality in a system, having a self-contained role. However, the introduction and modification of features may result in undesired behaviors, and this effect is known as feature interaction- FI for short. This document provides a description of the FI problem in Internet, the main problems to be solved in the FI resolution, and compares some solutions for FI identification and resolution explored that have been discussed in the literature. "Distributed Resolution of Feature Interactions for Internet Applications", Rui Gustavo Crespo, Luigi Logrippo, 15-Oct-08, Internet applications have been enhanced with many features. A feature may be defined as a unit of functionality in a system, having a self-contained role. However, the introduction and modification of features may result in undesired behaviors, and this effect is known as feature interaction - FI for short. This document specifies the architecture of a distributed feature mana- ger that proposes the resolution of feature interactions. The resolu- tion may be done locally, or with cooperation between different nodes. The resolution method is left to the implementation. In this document we provide an example of one resolution method, based on feature interdiction, as described by a set of deontic formulas. "draft-nottingham-site-meta-00", Mark Nottingham, Eran Hammer-Lahav, 15-Oct-08, This memo describes a method for locating site-wide metadata for Web sites. "RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support", Glen Zorn, 17-Oct-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. "Use of IP Router Alert Considered Dangerous", Reshad Rahman, David Ward, 17-Oct-08, This document provides guidelines to address security concerns which arise with the use of IP Router Alert option [RFC2113] and [RFC2711]. RSVP,[RFC2205] and [RFC3209], and IGMP [RFC3376] are some of the protocols which make use of the IP Router Alert option. IP datagrams carrying the Router Alert option are usually examined in a router's "slow path" and an excess of such datagrams can cause performance degradation or packet drops in a router's "slow path". "IPv6 destination header option for IPv4 translator mapping notification", Remi Denis-Courmont, 20-Oct-08, 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. "IPv6 Ephemeral Addresses", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 20-Oct-08, This document describes a new address type that is called "Ephemeral Addresses". Ephemeral Addresses are designed to be used as clients' source addresses of TCP / UDP sessions. An idea Ephemeral Addresses is simple enough. They are achieved by deriving existing "ephemeral ports" specifications. In other words, they are achieved by naturally upgrading their concept from the port space to the address space. Since Ephemeral Addresses functions are implemented only in the kernel side of the OS, we can use the Ephemeral Addresses functions in current exiting enormous client applications without modifying them. Ephemeral Addresses functions can contribute to various types of security enhancements that include privacy protections etc. "EAI Deployment Practices", Jiankang Yao, XiaoDong Lee, Xiaodong WU, 20-Oct-08, This document captures experience in implementing systems based on the EAI protocols. Its aim is to help the engineers to implement these protocols. This document gives some suggestions about implementaions and reports on the prototype implementation and the inter-operability test results, as well as the lessons and insights gained from this test. "Extension of Multiple Care-of Addresses Registration for Handover", Hong-Ke Zhang, Zhi-wei Yan, Hua-chun Zhou, Jian-feng Guan, 20-Oct-08, The Multiple Care-of Addresses Registration [2] is a useful protocol which allows a 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. It proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses with the Binding Identifier Mobility Option. This document describes a simple extension to Binding Identifier Mobility Option to allow mobile node to select the most wanted link for the ongoing service. "Asymmetric Key Packages", Sean Turner, 30-Oct-08, This document defines the syntax for private key information and a content type for it. Private-key information includes a private key for some public-key algorithm and a set of attributes. The document also describes a syntax for encrypted private keys. The Cryptographic Message Syntax, as defined in RFC 3852, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. "Delivering Geographic Location in Host Identity Protocol (HIP)", Feng Cao, David Ward, Hui Deng, 27-Oct-08, This document defines a new parameter for delivering geographic location in Host Identity Protocol (HIP). For mobile users using HIP, one generic mechanism is proposed to share or update their geo- location information with either rendezvous servers or their peers. In addition, geo-location privacy is also protected with the help of the ENCRYPTED parameter. "RADIUS Support for Prefix Authorization", Behcet Sarikaya, Frank Xia, 2-Nov-08, This document specifies new attributes 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, 21-Oct-08, 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 de Bont, 21-Oct-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. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 21-Oct-08, Maintaining the current best practices with communities, ISPs and enterprises that get 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. "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", Jari Arkko, 24-Oct-08, This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. "ALTO: A Multi Dimensional Peer Selection Problem", Saumitra Das, Vidya Narayanan, Lakshminath Dondeti, 22-Oct-08, Bulk data applications are posing serious challenges to the Internet infrastructure and more mass adoption of such applications would only increase that challenge. P2P bulk data applications and other large volume HTTP traffic such as video currently dominate the Internet traffic. These applications do not generally benefit from the traffic engineering techniques developed for the Internet. In the HTTP traffic case, the traffic optimization issues are often addressed using the CDN infrastructure. For P2P bulk data applications, the problem is about picking the right peers to communicate with and the criteria for doing this vary greatly based on the application. Hence, intelligent peer selection is the fundamental problem to address for these applications. This document explains the multiple dimensions of the peer selection problem with respect to obtaining information from the network as well from other peers and argues for an integrated, common framework to share such information. "Requirements for the Support of Continuously Varying Values in Presence", Martin Thomson, 22-Oct-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. "Provider-Provisioned CPE: IPv4 Connectivity Access in the context of IPv4 address exhaustion", Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain Villefranque, 23-Oct-08, 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. Finally, it makes a comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions. "IPv6 Inverse Neighbor Discovery Update", Pascal Thubert, Eric Levy-Abegnoli, 23-Oct-08, 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. "PANA (Protocol for Carrying Authentication for Network Access) Base Protocol MIB", Victor Fajardo, 23-Oct-08, This document defines the Management Information Base (MIB) module which defines a minimum set of objects that can be used to manage an implementation of the PANA Base Protocol [RFC5191]. "Renumbering still needs work", Brian Carpenter, Randall Atkinson, 23-Oct-08, 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. "Domain name based network interface selection", Teemu Savolainen, 23-Oct-08, A multi-homed host with multiple physical and/or virtual network interfaces has to select which one of the network interfaces to use for a new outgoing IPv4 or IPv6 connection. This document describes a method to select an interface by using destination's fully qualified domain name and DNS suffix information received dynamically for each network interface. The method is useful, for example, in split horizon DNS and walled garden scenarios, where right network interface has to be selected even before DNS resolution is conducted. "A Proposal to Define Interactive Connectivity Establishment for the Transport Control Protocol (ICE-TCP) as an Extensible Framework", Adam Roach, Bruce Lowekamp, 23-Oct-08, The ICE-TCP mechanism is currently regarded as of limited usefulness due to the low success rate of TCP simultaneous open for NAT traversal. This document presents a vision of the ICE-TCP document as an extensible framework for negotiating a variety of approaches for establishing a TCP connection between NATed hosts. This document further proposes significantly extending the current set of collection mechanisms to encompass a wide variety of technologies that are currently available, including UPnP, SOCKS, and Teredo. Because several of these technologies are already widely deployed, the direct connection rate should be significantly higher than using straight TCP alone. We envision that as future TCP connection establishment techniques are developed, they too will specify an ICE encoding that will allow their negotiation. "Local Mobile Anchor Discovery Using DHCP", Frank Xia, Behcet Sarikaya, 23-Oct-08, 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. "Differentiation Using Virtualization of Mobile Network", Chulhyun Park, Nakjung Choi, Taekyoung Kwon, Yanghee Choi, Eun Paik, 24-Oct-08, A mobile router with multiple interfaces can make connection to several access networks. Using virtualization on the mobile network, several virtual mobile network can be exist for a single mobile network. Multiple virtual mobile networks for a single mobile network can be used for service differentiation for mobile network nodes. "Call Parameter Negotiation with GMPLS Calls", Hongmiao Xia, Jianhua Gao, Fatai Zhang, 24-Oct-08, This document defines the use of Generalized Multi-Protocol Label Switching (GMPLS) Calls for parameter negotiation in Automatically Switched Optical Networks (ASON) and Wavelength Switched Optical Networks (WSON). The intention of the document is to provide a reference for the authors of future documents to understand the application of GMPLS Calls. "CGA Extension Header of IPv6", Lifeng Liu, Dong Zhang, 24-Oct-08, 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. "RTP Payload format for GSM-HR", Magnus Westerlund, Karl Hellwig, Ingemar Johansson, 24-Oct-08, This document specifies the RTP payload format for packetization of the GSM Half-Rate speech codec. "Neighbor Discovery for 6LoWPAN", Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Erik Nordmark, 17-Nov-08, This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new mechanism allowing efficient Duplicate Address Detection over entire 6LoWPAN networks. In addition it specifies prefix and context dissemination for use with router advertisements, allows for stateless address assignment, and the use of Neighbor Discovery Proxy. "Framework and Requirements for Composite Transport Group (CTG)", So Ning, Andrew Malis, Dave McDysan, Lucy Yong, 24-Oct-08, This document states a traffic distribution problem in today's IP/ MPLS network when multiple links are configured between two routers. The document presents a Composite Transport Group framework as the solution for the problems and specifies a set of requirements for Composite Transport Group(CTG). "Learning the Address Family Translator's IPv6 Prefix", Dan Wing, 24-Oct-08, In some IPv6/IPv4 translation scenarios it is necessary for an IPv6 host to know the IPv6 prefix used by its address family translator. In some of the IPv6/IPv4 translation proposals, the prefix is not fixed; that is, the prefix is chosen by the network operator. This specification provides several methods to learn the prefix and its length. "MIKEY General Extension Payload for OMA BCAST 1.0", Anja Jerichow, Laurent Piron, 24-Oct-08, This document extends the General Extension Payload for OMA BCAST usage defined in RFC 4909 [1]. It adds necessary support for the newly specified management data as defined in the Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service and Content protection specification [2]. "HTTP Access to Email Stores", Lisa Dusseault, 24-Oct-08, This document proposes a standard format and a standard navigation mechanism so that mail stores can provide interoperable access to mailboxes and messages over HTTP. Mailbox contents and listings of mailboxes are exposed as Atom Feeds, while messages themselves are downloaded as a document of type message/822. Each mailbox and each message is assigned an HTTP URL, and if permissions checks are satisfied, each message may be downloaded independently. "Flow Handover for Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury, 24-Oct-08, With interface multihoming, Mobile Nodes are capable of simultaneous attachment to multiple radio access networks. This enables a network node such as the Local Mobility Anchor to distribute the application traffic to interfaces that can best serve them. This document specifies a network-controlled protocol to handover application flows from one interface to another. Such control could provide better experience for end users and better traffic management for network operators. "Report from the IETF workshop on P2P Infrastructure, May 28, 2008", Jon Peterson, Alissa Cooper, 24-Oct-08, 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. "Fast Handover for IP Flow Mobility", Fan Zhao, Ameya Damle, 24-Oct-08, This document discusses and proposes some extensions to reduce handover latency, especially when the mobile node or router handovers IP flows between different access networks. "Interworking between FMIP and PFMIP", Fan Zhao, Ameya Damle, 24-Oct-08, This document discusses and proposes extensions to enable interworking between the FMIP and the PFMIP. "RTP Payload Format for Raptor FEC", Mark Watson, 24-Oct-08, 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. "MPLS Tunnel Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, 25-Oct-08, The 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 or IPv4-UDP encapsulation headers. In this document, Multiprotocol Label Switching (MPLS) tunneling is proposed as an alternative tunnel technology which is used between a MAG and a LMA. MPLS is now become more and more popular, and MPLS support is an important function for edge and core routers. Integrating MPLS and Proxy IP Mobility can leverage Proxy IP Mobility deployment in the industry. "An extension to RELOAD to support Direct Response and Relay Peer routing", XingFeng Jiang, Roni Even, 25-Oct-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 address concerns about these two routing modes mentioned in RELOAD. Then methods about how to discover NAT behavior of the client in P2PSIP situations are discussed. The last part proposes extensions to RELOAD for supporting these additional routing modes. "Mobile IPv6 Handover Using Home Agent Buffering", Frank Xia, Behcet Sarikaya, Basavaraj Patil, 1-Nov-08, In Mobile IPv6, when a Mobile Node (MN) moves from one Access Router(AR) to another, there is a period during which the MN is unable to send or receive packets because of link switching delay and IP protocol operations. This document specifies a mechanism to reduce packet loss through a Home Agent (HA) buffering downlink packets during the handover period. "DHCPv6 Remote Boot Options", Vincent Zimmer, Dave Thaler, 3-Nov-08, This document describes a means by which to support network boot of a bare-metal platform utilizing a pre-boot execution environment, such as the Unified Extensible Firmware Interface [UEFI22]. The problem being addressed is that the PXE [PXE21] and UEFI Specifications [UEFI22] only describe how to ascertain boot configuration options using DHCPv4 [RFC2131], not for DHCPv6 [RFC3315]. Similarly, iSCSI boot [RFC4173] does not specify how to discover boot device information in an DHCPv6 environment. This document will describe how to ascertain this boot information in an IPv6 environment utilizing options in the DHCPv6 hand-off [RFC3315]. "Measuring IP Performance Metrics on Mobile Network", Pyung-Soo Kim, Sun-Young Shin, 26-Oct-08, In this draft, the new measurement scheme of IP performance metrics is proposed for the mobile network in heterogeneous wireless network environment. In the proposed scheme, all mobile nodes (MNs) inside the mobile network can get IP performance metrics irrespective of the presence or absence of measurement functionality. That is, the proposed scheme does not require the MN to be involved in measuring IP performance metrics. The multihomed mobile router (MR) with heterogeneous wireless interfaces measures IP performance metrics on behalf of the MNs inside the mobile network. Then, when MNs want to understand the condition of multiple communication paths, MNs can get measured IP performance metrics from the MR using L3 messages. The proposed scheme can reduce burden and power consumption of MNs with limited resource and battery power since MNs don't measure directly IP performance metrics. In addition, the proposed scheme can reduce considerably traffic overhead over wireless links on measurement paths since signaling messages and injected testing traffic are reduced. "Framework for IPv4/IPv6 Translation", Fred Baker, 26-Oct-08, 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", Xing Li, Congxiao Bao, Fred Baker, 26-Oct-08, 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 stateful and a stateless mode. 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. 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 translator. 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 stateful mode that are not addressed in this document, related to the maintenance of the translation tables. 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. Some text had been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. The changes in this document reflect five components: 1. Updating references 2. Redescribing the network model to map to present and projected usage 3. Moving the address format to the framework document, to coordinate with other drafts on the topic 4. Some changes in ICMP. 5. Description of both stateful and stateless operation. "SeND-based Source-Address Validation Implementation", Marcelo Bagnulo, 26-Oct-08, 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. "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, 26-Oct-08, This document describes a confidentiality ciphersuite for metadata in Delay-Tolerant Networking (DTN) Bundle Protocol (BP) bundles. "DTN EID References Specification", Peter Lovell, 26-Oct-08, This document describes a convention for storing references to Delay- Tolerant Networking (DTN) Bundle Protocol (BP) endpoint identifiers [EIDs] within extension blocks of bundles. "A Framework for defining Optical Parameters to be used in WSON networks through GMPLS", Giovanni Martinelli, David Bianchi, Alberto Tanzi, Ori Gerstel, Andrea Zanardi, 26-Oct-08, In the context of Wavelength Switched Optical Networks (WSON) the problem of selecting a lightpath might be constrained by an evaluation of the optical impairments associated to a wavelength. This is a critical step in a transparent dense wavelength division multiplexing (DWDM) optical islands where a lightpath feasibility has to be assessed between two regenerations nodes. This memo provides a framework in which optical parameters can be considered a control plane. The document relies on information already present in ITU documents and summarize in term of lightpath constraints. "Tunnel Endpoints in BGP", Xiaohu Xu, Paul Francis, 26-Oct-08, Virtual Aggregation (VA) is a mechanism for shrinking the size of the DFZ FIB in routers [I-D.francis-idr-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. "Mapped BGP Design", Paul Francis, Xiaohu Xu, Hitesh Ballani, 26-Oct-08, This draft introduces Mapped-BGP, a routing protocol that uses BGP to distributed tunnel endpoint-to-prefix mappings. The goal of this draft are to present preliminary concepts and get feedback. It is not meant to be a fully-formed proposal. The goals of Mapped-BGP are: 1) to reduce the processing required to run BGP, 2) to speed up inter-domain convergence, 3) to improve the cross-ISP load balancing capabilities of BGP, and where possible, 4) to enable forms of address aggregation like geographical addressing (i.e. for IPv6). Improved address aggregation is unlikely to be very useful for IPv4, because most addresses have already been assigned. This design takes the position that Mapped BGP is useful even without better aggregation, because 1) FIB size can be reduced through FIB suppression with Virtual Aggregation, and 2) RIB size per se is not the growth bottleneck. "A Modest Proposal for Session Initiation Protocol (SIP) Work in the IETF", Jonathan Rosenberg, 26-Oct-08, The Session Initiation Protocol (SIP) has become widely deployed on the Internet, covering a wide range of usages from toll bypass to instant messaging, from service provider to enterprise. However, its realization in actual deployments differs in important ways from the specifications. This has created a gulf between existing and ongoing standards work, and real live deployments. This document argues that the RAI area should focus on solving real world interoperability issues and address real world functional gaps. "A Framework for the Control and Measurement of Wavelength Switched Optical Networks (WSON) with Impairments", Greg Bernstein, 29-Oct-08, The operation of optical networks can require a level of detail in the characterization of network elements, subsystems, devices, and cabling not typically encountered with other networking technologies. In addition, these physical characteristics may be important to consider during typical day-to-day operations such as optical path establishment and connection monitoring, as well as during the network planning, installation, and turn-up phases. 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 common control and measurement plane and path computation element technologies to support impairment aware Routing and Wavelength Assignment (RWA) in optical networks. "Tunnel Loops and its Detection", Chan-Wah Ng, Benjamin Lim, Mohana Jeyatharan, 26-Oct-08, Many protocols in the Internet Protocol suite use packet encapsulations. This runs into the danger of forming a tunnel loop. Since each tunnel entry point encapsulates the inner packet with a tunnel packet header that contains a new hop count, a packet entering a tunnel loop may be routed infinitely, consuming network resources. Although there exist methods to cause a packet in a tunnel loop to be discarded eventually, it would be more desirable to detect the presence of a tunnel loop and act accordingly. This draft explores the possibility for tunnel entry points to detect the presence of a tunnel loop by using an extra identifier tagged to the outer packet header. "Information Model for Impaired Optical Path Validation", Greg Bernstein, 26-Oct-08, 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. "Extensions to RTCP Feedback Mechanism for Burst Streaming", Orit Levin, Zeev Vax, 26-Oct-08, This document defines extensions to the "RTCP-Based Feedback" [RFC4585] to reduce synchronization time when an RTP receiver joins a multicast stream at a random point in time. "Delivery of Request-URI Targets to User Agents", Jonathan Rosenberg, 26-Oct-08, 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 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. "Securing RPSL Objects with RPKI Signatures", Robert Kisteleki, Jos Boumans, 26-Oct-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. "Multi-Session and Multi-Source Transmission in the Real-Time Transport Protocol (RTP)", Thomas Schierl, Jonathan Lennox, 26-Oct-08, In this draft, we discuss problems related to multi-session and multi-source transmission using the Real-Time Transport Protocol (RTP). Most of the input to this draft is taken from email discussion. Multi-session and multi-source transmission is motivated by media data which allows for different transport layer treatment of parts of the media. This is typically the case for layered media. Multi-session transmission is when media data from a single media source is split over multiple RTP sessions. Single-session multi- source transmission (from now on just called "multi-source transmission") is when data from a single media source is sent as several RTP streams in the same RTP session. The main problems discussed are the mechanisms used for data alignment and source correlation. This draft gives further an overview of payload formats using multi-sessions/multi-source transmission and highlights other transport related issues. The draft concludes with recommendations for the discussed problems. "Mobile Agent Discovery Proxy (MADP) in IPv4 Mobility Management", Chunyan Yao, Bruno Mongazon-Cazavet, 27-Oct-08, In some networks such as xDSL networks with WiFi extension, the periodical transmission of Agent Advertisements (AA) by mobility agents is used by Mobile Nodes (MN) to detect movement. To allow fast movement detection, the interval at which AAs are sent should not be long. In the early deployment of Mobile IPv4 (MIPv4), mobility agents are deployed in the edge network. For example, in xDSL networks, Home Agents (HA) and Foreign Agents (FA) are located on or beside Edge Routers (ER) that usually serves thousands of MNs (typically between 2000 and 5000 in xDSL networks). The periodical transmission of multicast AA to MNs in such a large network consumes a significant amount of the aggregation network bandwidth and CPU resources of ERs. This is a practical problem in xDSL networks with WiFi extension. This is also a common problem for others access networks in which a large layer-2 network is served by one router. Hence a Mobility Agent Discovery proxy (MADP) can be set in access nodes to make the MNs detect movement fast meanwhile avoiding CPU and network bandwidth consumption in the aggregation network. The MADP acts as a proxy to MNs as far as agent discovery is concerned allowing for AS issued by MNs to be locally replied according to AA issued by HA/FA on the access network. MADP is a logical function that can be placed on a suitable node location depending on access network technology and architecture (i.e. WiMAX) to reduce network resource cost related to agent discovery. "Time synchronization method in packet-switched transport network for mobile backhaul", Li He, Fei Su, 27-Oct-08, This document introduces a time/phase 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 a preliminary thought of time transfer error detection. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for ODU0 of Optical Transport Networks Control", Ming Ke, Yuanlin Bao, 27-Oct-08, This document describes the extensions of GMPLS signaling to control Optical Transport Networks (OTN) including ODU0 of new optical channel data unit (ODUk) layer rate. "A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 27-Oct-08, The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. Different organizations issue alerts for specific geographic regions. The Location-to-Service Translation (LoST) protocol provides a way to discover servers that distribute these alerts for a geographical region. This document defines the Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined with RFC 5031 for citizen-to-authority emergency services. Additionally, this document suggests to use LoST for the discovery of servers distributing alerts. "Additional Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 27-Oct-08, 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, 27-Oct-08, This document describes a network model with ISP Shared Address and Carrier Grade NAT (CGN) called NAT444. 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. "On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", Wassim Haddad, Mats Naslund, 27-Oct-08, This document introduces a simple mechanism which enables a host using a cryptographically generated IPv6 address to delegate the task of secure neighbor discovery to another node, i.e., proxying, by means of establishing a 'symbiotic' relationship with that node. "Multiprotocol Label Switching Transport Profile Ring Protection Analysis", Jian Yang, Hui Su, 27-Oct-08, 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. "Scenario and Solution: Simple IP Multi-homing of the Host", Min Hui, Hui Deng, 3-Nov-08, Current host routing mechanism doesn't allow simple IP multi-homing for the default gateway consideration. This document proposes a solution to make multiple connections can work simultaneously. "Data forwarding behaviour of co-located HA/LMA in PMIP6-MIP6 interactions scenario C", Kilian Weniger, Genadi Velev, Vijay Devarapalli, 27-Oct-08, In PMIP6-MIP6 interactions scenario C, the HA and LMA are co-located and a transition between MIP6 and PMIP6 is supported without breaking the session. This draft discusses possible data forwarding behaviours of the co-located HA/LMA in such scenario. The two recently discussed options are: 1) data forwarding always according to the mobile node's MIP6 BCE, if exists, which means that MIP6 BCE has higher priority than PMIP6 BCE, or 2) data forwarding according to type of the last received mobility management registration message, i.e., PMIP6 and MIP6 BCE have equal priority. It is argued that option 1) increases handover delay by 1 MN-HA RTT and implementation complexity of the HA/LMA may be higher. Hence, it is proposed that HA/LMA should behave according to option 2, i.e., MIP6 BCE and PMIP6 BCE have same priority and HA/LMA forwards data according to the type of the last received mobility management registration message. "First-Come First-Serve Source-Address Validation Implementation", Erik Nordmark, Marcelo Bagnulo, 27-Oct-08, This memo describes FCFS SAVI a mechanism to provide source address validation for IPv4 and 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. "VPLS protection switching with ring access", xiaojuan song, Shaoyong Wu, Hong Shao, 27-Oct-08, This document introduces a new method to access VPLS network using ring techonology . This method can improve VPLS access reliability. Fast switch can be done within 50 ms after link failure detection. It not only can be used in normal VPLS, but also can be used in VPLS PBB network. "Setup of Pseudowires over bi-directional LSP", Wei Cao, 27-Oct-08, In MPLS and MPLS-TE environments pseudo wires use two unidirectional LSPs as PSN tunnels, the two PEs select LSP tunnels independently. In contrast the MPLS-TP environment supports both bidirectional and unidirectional LSPs and PWE may, therefore, use bidirectional LSPs as PSN tunnels. In order to use MPLS-TP bidirectional LSPs as a PSN tunnels for pseudo wires some modification of the pseudowire signaling procedures is required. This draft specifies an extension to LDP that ensures pseudo-wires are correctly constructed over bi-directional LSPs. "HIP Mobility and Multihoming Extensions for the Traversal of Network Address Translators", Jan Melen, Miika Komu, Marcelo Bagnulo, Tom Henderson, 27-Oct-08, This document defines extensions for HIP mobility and multihoming mechanisms to operate in network environments with NAT devices. The extensions are based on the ICE protocol that allows two communicating end-hosts to establish a direct communications path with each other even when residing in separate private address realms. The focus of the extensions in this document is on fault- tolerance with symmetric locator pairs, and load-balancing is also discussed. This document also updates RFC5206. "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", Miguel Garcia, Simo Veikkolainen, Robert Gilman, 27-Oct-08, SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a Media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate a number of miscellaneous SDP capabilities. In particular, this memo provides a mechanism to negotiate media titles ("i=" line for each media), connection data ("c=" line), and media bandwidth ("b=" line). "BFD Extensions in Support of Performance Measurement", Xinchun Guo, Mach Chen, 27-Oct-08, 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, Philip Matthews, Iljitsch van Beijnum, Andrew Sullivan, Masahito Endo, 1-Nov-08, 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. "RADIUS Attributes for IPv6 Support", Benoit Lourdelet, Glen Zorn, 2-Nov-08, This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. "PCN 3-State Encoding Extension in a single DSCP", Bob Briscoe, 27-Oct-08, 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 document specifies an extension to the two-state PCN baseline encoding that enables three encoding states to be carried in the IP header without using more than one Diffserv codepoint. It presupposes a standards action has removed the limit of two encoding states in current tunnelling mechanisms. "Representational State Transfer (REST) for Feature Configuration in Session Initiation Protocol (SIP)", Keith Griffin, Jonathan Rosenberg, 27-Oct-08, In order to provide interoperable implementations of certain Session Initiation Protocol (SIP) based features, such as automated call handling, it is necessary for devices to configure network servers with feature data. An example is a call forwarding number for a call forwarding service. This document introduces the concept of Representational State Transfer (REST) and gives an example of how REST can be used for such configuration. "Design for a Nameserver Control Protocol", John Dickinson, Stephen Morris, Roy Arends, 27-Oct-08, This document presents a design for a nameserver control protocol (NSCP). A common data model for describing the configuration and operation of a basic, but usable, generic name server is defined. This is expressed in a formal modeling language (YANG) and can be used as the basis of a set of NETCONF operations and capabilities. The data model described is extensible and will allow for the creation of additional capabilities, ensuring that the protocol can support all the features of a name server. "Deployment Models for PCN-Based Admission Control and Flow Termination Using Packet-Specific Dual Marking (PSDM)", Michael Menth, 27-Oct-08, This document presents different deployment models of PCN-based admission control (AC) and flow termination (FT) using packet- specific dual marking (PSDM) for encoding. Their major is that they require only a single DSCP for packet marking and that they work reliably in the presence of ingress-egress aggregates (IEAs) with only a very small average number of flows. Moreover, an advanced model even works with multipath routing. "DNS Proxy Implementation Guidelines", Ray Bellis, 27-Oct-08, This document provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network devices. "Enabling Source Address Verification via Prefix Reachability Detection", Wassim Haddad, Mats Naslund, Christian Vogt, 27-Oct-08, In this memo, we introduce an approach called "Prefix Reachability Detection", which aims to address certain man-in-the middle misbehavior problems and enable a location-based authentication. "Automatic Call Handling (ACH) Configuration Requirements", Theo Zourzouvillys, 27-Oct-08, This document examines the requirements for a protocol that allows an agent to configure an ACH enabled proxy. "PMIPv6 Extensions for Multicast", Hitoshi Asaeda, Pierrick Seite, Jinwei Xia, 27-Oct-08, 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, 27-Oct-08, Mobile IPv6 Support for Dual Stack Hosts and Routers requires that the mobile node's home link provides native dual stack support. This document relaxes this requirement and specifies how a DSMIP6-enabled mobile node can, with the help of its home agent, maintain connectivity for both of its home addresses while attached to a home link that supports only single IP family. "The A+P Approach to the Broadband Provider IPv4 Address Shortage", Olaf Maennel, Randy Bush, Luca Cittadini, Steven Bellovin, 3-Nov-08, 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, for which many solutions have been proposed. Some prominent ones involve carrier-grade-NATs (CGN), which have been shown to provide an inadequate experience to IPv4 users and enshrine a walled garden in the core of the provider. Instead, we propose using specialized NATs at the consumer premises equipment (CPE) edge which treat some of the port number bits as part of an extended IPv4 address. "Diameter MIP6 Feature Vector Additional Bit Allocations", Jouni Korhonen, 27-Oct-08, During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 Home Agent and the Authentication, Authorization, and Accounting server may exchange a set of capabilities as defined in. This document defines additional capability flag bits that are used to authorize per Mobile Node route optimization, Multiple Care-of Address and user plane traffic encryption support. Furthermore, this document also defines a capability flag bit of indicating whether the Home Agent is authorized to act as a stand alone Virtual Private Network gateway. "Extensions to RTSP for the CableLabs Edge Resource Management Interface Specification (ERMI)", Jean-Francois Mule, Greg White, 27-Oct-08, This document provides a description of the RTSP extensions used in the second version of the CableLabs Edge Resource Manager Interface specification. It is provided to seek comments from the IETF with the intent of following the IETF procedures for protocol extensions and variations. It is a work-in-progress document and future revisions will contain IANA registrations. "Issues related to the design choice of IPsec for Mobile IPv6 security", Basavaraj Patil, Charles Perkins, Hannes Tschofenig, 27-Oct-08, Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies. "Object Naming Service (ONS) Extension for Extensible Supply-chain Discovery Service (ESDS)", Ning Kong, Xiaodong Li, Seung Jai Yi, 27-Oct-08, Object Naming Service (ONS) is a network service that leverages Domain Name System (DNS) to discover information about a product and related services from the Electronic Product Code (EPC). Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. Unlike DNS or ONS, where there is a known set of root servers, ESDS will have numerous roots for various supply chains operating globally. ONS can be used in collaboration with ESDS to make the multiple ESDS roots be found easily. This document is intended to extend the ONS to support ESDS by defining a new Naming Authority PoinTeR (NAPTR) service type of ONS for ESDS. "Analysis on how to address NEMO RO for Aeronautics Mobile Networks", Carlos Bernardos, Marcelo Bagnulo, 3-Nov-08, The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the mobile network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the mobile network are not required to support any kind of mobility, since packets go through the Mobile Router-Home Agent (MRHA) bi- directional tunnel. Data packets belonging to communications of nodes of the mobile network have to traverse the Home Agent, and therefore resulting paths are likely to be suboptimal. Additionally, the solution adds packet overhead, due to the use of encapsulation between the Mobile Router and the Home Agent. There are currently a set of well defined NEMO Route Optimization requirements for Operational Use in Aeronautics and Space Exploration, which potential solutions should meet. This document analyses how the problem of NEMO RO for Aeronautics Mobile Networks might be tackled, in a way as generic as possible, trying to identify those open questions and deployment considerations that need to be addressed. The main goal of this document is to foster the discussion about aeronautics NEMO RO solution space within the MEXT WG. "MPLS Generic Associated Channel", Martin Vigoureux, Matthew Bocci, David Ward, George Swallow, Rahul Aggarwal, 27-Oct-08, This document generalises the applicability of the pseudowire Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSP), MPLS pseudowires (PW) and MPLS Sections. In order to identify the presence of this G-ACH, this document also assigns of one of the reserved MPLS label values to the 'Generic Alert Label (GAL)', to be used as a label based exception mechanism. "Dialog Event foR Identity VErification", J Kuthan, Dorgham Sisalem, Raphael Coeffic, Victor Pascual, 27-Oct-08, This document provides a simple mechanism to prevent an attacker from presenting a forged "From" header field. It offers an end-to-end identity assumption which does not require any previous association or trust relationship between administrative domains or the UAs. The UAS verifies the "From" header by subscribing to the Dialog Event package [RFC 4235] at the AOR in the "From" header field. If the entity calling is registered under this AOR, it will confirm that it is calling by sending some valid dialog state. In this case, the identity of the caller is considered to be verified. "Definition of Managed Objects for the MANET Optimized Link State Routing Protocol version 2", Robert Cole, Thomas Clausen, 27-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 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. "OAM Configuration Framework and Requirements for GMPLS RSVP-TE", Attila Takacs, Don Fedyk, He Jia, 3-Nov-08, OAM functions are essential to ensure that the desired service level of traffic engineered connections are met. In certain technologies OAM entities are inherently established once the connection is set up. However other technologies, especially OAM for packet switched networks, require an extra configuration step after connection establishment to setup OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signalling. "The MANET Link Type", Thomas Clausen, 27-Oct-08, This document describes the link characteristics and properties for links over which MANET protocols are designed to operate. "Harmless IPv6 Address State Extension (Uncertain State)", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 27-Oct-08, This document describes a new IPv6 address state called "Uncertain" address state as an extension of IPv6 address state specification. "Uncertain" address state is designed to introduce two functionalities. One is to achieve "Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. "Uncertain" Address State is inserted between "Tentative" address state and "Valid" address state. After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for the node to utilize the reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem. "PIM Multi-Topology ID (MT-ID) Join-Attribute", Yiqun Cai, Heidi Ou, 27-Oct-08, 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. "Forward Error Correction Grouping Semantics in Session Description Protocol", Ali Begen, 27-Oct-08, 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 were 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 also do not support additive repair flows and prioritization among the repair flows protecting one or more source flows. This document addresses these issues by introducing new FEC grouping semantics. "DHCPv6 and CGA Interaction: Problem Statement", Sheng Jiang, Sean Shen, 27-Oct-08, 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, 3-Nov-08, 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. This document also describes an address mapping option for NAT66 that offers the topology hiding benefit associated with NAT44 at the cost of additional state in the NAT66 device. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Many-to-Many Text Chat", Peter Saint-Andre, Salvatore Loreto, Fabio Forno, 27-Oct-08, 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). "DHCP Options for Conveying Port Mask and Port Range Router IP Address", Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain Villefranque, 29-Oct-08, This draft defines two new DHCP (Dynamic Host Configuration Protocol, [RFC2131]) Options to be used in the context of Provider-Provisioned CPE solution (a.k.a. Port Range solution or Fractional Address). The first option is used to convey a Port Mask and the second one may be used to convey a list of Port Range Router IP addresses. "MPLS-TP OAM Framework and Overview", Italo Busi, Ben Niven-Jenkins, 27-Oct-08, 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 for supporting the MPLS-TP OAM requirements .[10] in a manner that admits a comprehensive set of OAM procedures. "Real-time Transport Control Protocol (RTCP) in Overlay Multicast", Jegadish Devadoss, Joerg Ott, Igor Curcio, 27-Oct-08, 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, the suitability of RTCP in such an environment need to be analyzed. The applicability of the existing RTCP reporting architectures in an overlay multicast environment is investigated and the new features that may be required are discussed in this document. "BGP Bestpath Selection Criteria", Rajiv Asati, 27-Oct-08, BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. "Framework for Content Push Delivery over the Session Initiation Protocol (SIP)", Martin Dolly, Kent Bogestam, Salvatore Loreto, 27-Oct-08, This document specifies a protocol for 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. As part of this framework, a new SIP event package is defined for notification of push events for content delivery. "Presence & Instant Messaging Provisioning", Avshalom Houri, Gil Perzy, Edwin Aoki, Sriram Parameswar, 27-Oct-08, NOTE: This is still an initial draft of this document The document defines data for provisioning between two presence and IM domains and the methods that can be used to convey the data between the domains. "Virtual IPv6 Connectivity for IPv4-Only Networks", Christian Vogt, Alain Durand, 27-Oct-08, This document proposes Virtual IPv6 Connectivity, a method for deployment in IPv4-only networks to enable communications with the IPv6 Internet. Virtual IPv6 Connectivity uses IP protocol translation to support both incoming traffic from IPv6 to IPv4, and outgoing traffic from IPv4 to IPv6. Communications initiated into the latter direction are facilitated through DNS or DNSSEC proxies. Different than existing IPv4/IPv6 interworking techniques, which are for deployment in IPv6 networks, Virtual IPv6 Connectivity does not require extra, globally unique IPv4 addresses. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, 27-Oct-08, 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. "Periodic Retrieval of Location Information by Devices and Location Information Servers", Mary Barnes, 27-Oct-08, The base HTTP Enabled Location Delivery (HELD) protocol includes options for retrieving location information from a LIS by a Device. Some networks require the ability for the device to periodically request location information from the LIS and/or for the LIS to periodically request location information from the device. Extensions to base HELD allow a Device to establish a context with a LIS and negotiate capabilities of the Device in terms of providing location information. The measurement extensions to base HELD allow the LIS to request location information from a Device. This document provides an overview of the requirements and a solution using HELD and HELD extensions to support the periodic request of location information, both by a Device from an LIS and by the LIS from a Device, depending upon the specific scenario and measurement capabilities of the Device. "RBridge VLAN Mapping", Radia Perlman, Dinesh Dutt, Donald Eastlake 3rd, 27-Oct-08, 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. "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", Lyndon Ong, Janathan Sadler, Stephen Shew, 27-Oct-08, The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. "Threshold Secret Sharing", David McGrew, Praveen Patnala, 27-Oct-08, 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. "LSA Correlation to Schedule Routing Table Calculations", Mukul Goyal, G Choudhury, Aman Shaikh, Kishor Trivedi, Hossein Hosseini, 27-Oct-08, OSPF requires a router to recalculate its routing table whenever it receives a new router or network LSA. However, a topology change, such as a router down event, may cause a number of new LSAs to be generated. These LSAs may arrive at a router at different times. In order to avoid several routing table calculations in quick succession in such cases, commercial routers enforce a hold time between successive routing table calculations. The hold time based schemes, while limiting the number of routing table calculations, may also cause undesirable delays in convergence to the topology change. This ID describes an alternate approach to schedule routing table calculations, called LSA Correlation. Rather than using individual LSAs as triggers for routing table calculations, LSA Correlation scheme correlates the information in the LSAs to identify the topology change. A routing table calculation can be performed when the topology change has been identified, which could span multiple LSAs. "Mechanism for performing LSP-Ping over RSVP protection paths", Nitin Bahadur, Kireeti Kompella, 27-Oct-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, 3-Nov-08, Through operational experience of IPv6 Default Address Selection (RFC3484) [1] implementations, it appears that a requirement has arisen for hosts and networks to be able to have their policies for address selection updated. This text discusses considerations for such policy changes, e.g. 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. "VPLS Flush in BGP-based Virtual Private LAN Service", Bhupesh Kothari, Rex Fernando, 27-Oct-08, This document defines procedures that allow BGP based Virtual Private LAN Service (VPLS) provider edge (PE) devices to send explicit flush notifications to remote VPLS PEs. "Comcast's ISP Experiences In a Recent P4P Technical Trial", Chris Griffiths, Jason Livingood, Richard Woundy, 28-Oct-08, This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a recent Proactive Network Provider Participation for P2P (P4P) technical trial. This trial used iTracker technology being considered by the IETF, as part of what is currently known as the Application Layer Transport Optimization (ALTO) Birds of a Feather (BoF). "TANA Practices and Recommendations", Reinaldo Penno, Janardhan Iyengar, 3-Nov-08, 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. "Metadata Striping for pNFS", Mike Eisler, 27-Oct-08, This Internet-Draft describes a means to add metadata striping to pNFS. "Separating Control and Data Plane for Proxy Mobile IPv6", Vijay Devarapalli, 27-Oct-08, 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 an extension to the Proxy Mobile IPv6 protocol to register a data plane address, that is different from the Proxy Care-of Address with the LMA. This allows separation of control and data plane. "Authenticated Encryption with AES-CBC and HMAC-SHA1 (and other generic combinations of ciphers and MACs)", David McGrew, 27-Oct-08, 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. "Storage De-Duplication Awareness in NFS", Mike Eisler, 27-Oct-08, This Internet-Draft describes a means to add awareness of de- duplication storage to NFS. "Geopriv Concerns about SIP Location Conveyance Retransmission Recommendations Document", James Polk, 27-Oct-08, This document expresses grave concerns about the recommendations made in the 'Implications of ' document, which in turn states several recommendations towards the modification of SIP Location Conveyance. This document makes several counterproposals to what is currently in the 'Implications of ' document. "DRINKS Use cases and Protocol Requirements", Sumanth Channabasappa, 3-Nov-08, This document presents use cases that illustrate what constitutes session establishment data, the functional components that need them, and the protocol requirements for provisioning and managing session establishment data within the identified functional components. "ALTO Information Export Service", Stanislav Shalunov, Reinaldo Penno, Richard Woundy, 27-Oct-08, The ALTO Information Export Service is a simple way to convey ISP routing policy preferences to applications. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer 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 routing policy information -- what does the local ISP actually prefer? This document describes a very simple mechanism that would allow to export such information to applications. While such service would primarily be provided by the network, i.e., the local ISP, third parties could also operate this service.1. Requirements notation "RTP Payload format for Application and Desktop Sharing", Omer Boyaci, Henning Schulzrinne, 27-Oct-08, This document defines a protocol to support accessing general graphical user interface (GUI) desktops and applications remotely, either by a single remote user or embedded into a multiparty conference. The protocol is designed to allow sharing of, and access to general windowing system applications that have not been expressly written to be accessed remotely. "BGP Prefix Origin Validation", Pradosh Mohapatra, John Scudder, 27-Oct-08, 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, 27-Oct-08, This document analyzes the current practices for handling TCP urgent data in the current Internet. It describes how popular TCP implementations process urgent data, and also describes how a number of middle-boxes affect how urgent data is processed by end systems. Additionally, it includes a survey of the processing of urgent data by popular TCP implementations. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent data. "On the generation of TCP timestamps", Fernando Gont, 27-Oct-08, 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 the possibility of an attacker guessing the exact value is reduced. Additionally, it describes an algorithm for processing incoming SYN segments to allow a higher connection establishment rates to any TCP end-point. "Evolution of the IP Model", Dave Thaler, 3-Nov-08, This draft attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, and especially properties which were (and at times still are) incorrectly perceived to exist, as well as properties that would cause problems if changed. Finally, it provides some guidance to protocol designers and implementers. "IPv4/v6 NAT With Explicit Control (NAT-XC)", Keith Moore, 3-Nov-08, 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 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, 27-Oct-08, 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. "Security implications of Network Address Translators (NATs)", Fernando Gont, 4-Nov-08, This document analyzes the security implications of Network Address Translators (NATs). It neither deprecates nor encourages the use of NATs, but rather aims to raise awareness about their security implications, and possible implementation approaches to improve their security. "RELOAD Node Operations Proposal", Bruce Lowekamp, 27-Oct-08, This document defines a set of methods for Node-specific operations as part of the REsource LOcation And Discovery (RELOAD) protocol. This document defines NodeFetch, NodeStore, and NodeRemove methods that allows manipuation of Node specific usage data. These methods will be useful for multiple diagnostic, administrative, and discovery usages. Because of their usefulness for a variety of expected usages, these methods are advanced for inclusion in the base RELOAD protocol. "Client MIP6 Binding Revocation Using Auth Option", Ahmad Muhanna, Mohamed Khalil, Alper Yegin, Frank Xia, 27-Oct-08, This document describes the use of the Authentication Protocol in protecting binding revocation signaling messages between the home agent and the mobile node. The home agent uses this mechanism to revoke a client mobile IPv6 binding cache entry that was created using Client Mobile IPv6 protocol signaling with authentication protocol. "Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks", Steven Blake, 3-Nov-08, TCP and other transport-layer protocols are vulnerable to spoofing attacks from off-path hosts. These attacks can be prevented through the use of cryptographic authentication. However, it is difficult to use cryptographic authentication in all circumstances. A variety of obfuscation techniques -- such as initial sequence number randomization and source port randomization -- increase the effort required of an attacker to successfully guess the packet header fields which uniquely identify a transport connection. This memo proposes the use of the IPv6 Flow Label field as a random, per- connection nonce value, to add entropy to the set of packet header fields used to identify a transport connection. This mechanism is easily implementable, allows for incremental deployment, and is fully compliant with the rules for Flow Label use defined in RFC 3697. "DHCP options for Access Point Name and attach type indication", Basavaraj Patil, Kuntal Chowdhury, 27-Oct-08, Cellular data networks which are based on 3GPP standards use the concept of Access Point Name. A mobile node which attaches via a 3GPP access network indicates thru layer 2 signaling the access point name to which connectivity is desired. This document specifies a DHCP option which enables the mobile node to request 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. A DHCP option which enables the host to indicate if the attachment via the new interface is a handover or another connction is also specified. "Architecture and Practice for VoIP Lawful Interception Using Session Border Controller(SBC)", Menghui Yang, XiaoDong Lee, Wei Mao, 27-Oct-08, Recently broadband Voice over IP (VoIP) has a clear trend to substitute for traditional telephone services such as wire telephone, wireless telephone and mobile telephone service, it has become increasingly clear that VoIP services will be expected to provide Lawful Intercept to the same level experienced in the Public Switched Telephone Network(PSTN)[7]. In an effort to provide lawful interception for broadband VoIP, an architecture using session border controller was proposed, and a prototype implementation of the broadband VoIP lawful interception was created and basic performance evaluation was conducted on this prototype system. This document reports on the prototype implementation and the test results. "Diameter Routing Problem Statement", Tina Tsou, 27-Oct-08, This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms. "Creation of a registry for DNS SRV record protocol names", Olafur Gudmundsson, 27-Oct-08, DNS SRV record was specified in RFC2052 and RFC2782. These two RFC did not specify an IANA registry for names of the protocols using SRV records. This document creates such a registry. "PCECP Requirements and Extensions of Alternate Routing for Wavelength Switched Optical Networks", Dajiang Wang, Zhenyu Wang, Qimin Xiang, Feng Gao, 27-Oct-08, This memo provides application-specific requirements and extensions of alternate routing for the support of Wavelength Switched Optical Networks (WSON). "OAuth Access Tokens using credentials", Bill de Hora, Stephen Farrell, 27-Oct-08, 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. "Look Up Function vs. Location Routing Function discussion", Greg Schumacher, Hadriel Kaplan, 3-Nov-08, This document provides a comparison between the Look Up Function (LUF) and the Location Routing Function (LRF) as used for inter and intra-domain SIP session routing. It also develops the relationship between the two functions. This document is meant for discussion purposes only. Schumacher Expires May 3, 2009 [page 1] Look Up Function vs. Location Routing Function discussion Nov 2008 "Rapid Synchronisation of RTP Flows", Colin Perkins, 27-Oct-08, This memo outlines how RTP multimedia sessions are synchronised, and discusses how rapidly such synchronisation can occur. It is shown that unicast sessions can be synchronised immediately in most cases. Multicast groups have longer synchronisation delay. A modification to the RTCP timing rules is suggested to improve synchronisation time for SSM senders. A new RTP/AVPF feedback packet is defined to improve general synchronisation times. "Extreme Networks' Ethernet Automatic Protection Switching (EAPS), Version 1.3", S Shah, 27-Oct-08, This document describes version 1.3 of the Ethernet Automatic Protection Switching (EAPS) (TM) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at lower cost and without some of the constraints (e.g. ring size) of SONET. "Report on first GMPLS Controlled Ethernet tests", Attila Takacs, Benoit Tremblay, Remi Theillaud, Kenichi Ogaki, 27-Oct-08, In this memo we report on the first GMPLS controlled Ethernet interoperability test involving three independent implementations. We also briefly introduce our GMPLS controlled Ethernet test-beds and identify the implemented GMPLS extensions. Note, this memo does not intend to specify any GMPLS extension. "The Solution for Pmipv6 Multicast Service", Yuankui Zhao, Pierrick Seite, 3-Nov-08, To mobility scenario, multicast service is a valuable feature to those mobile customers. We need to consider how to integrate current multicast service in PMIPv6 domain. This draft will introduce this kind of solution about proxy mobile multicast. It explains the system consideration about how to provide the proxy mobile multicast system. "Line identification in IPv6 Router Solicitation messages", Suresh Krishnan, Alan Kavanagh, 3-Nov-08, 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, 3-Nov-08, 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. "Multicast VPN fast upstream failover", Thomas Morin, Yakov Rekhter, Rahul Aggarwal, Praveen Muley, 3-Nov-08, 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. "Fast Hello exchange procedures for Protocol Independent Multicast", Thomas Morin, 4-Nov-08, This document is proposed as an update of RFC4601 and describes procedures allowing exchanges of PIM Hellos to complete earlier when a new link comes up, to mitigate the multicast traffic blackholing issues that result from inconsistencies between links advertised by unicast routing and the links on which PIM adjacencies are fully set up. "Interworking between MPLS-TP and IP/MPLS", Riccardo Martinotti, Diego Caviglia, Nurit Sprecher, 17-Nov-08, Purpose of this ID is to illustrate interworking scenarios between network(s) supporting MPLS-TP and network(s) supporting IP/MPLS. Main inteworking issues and open points are highlighted. "IP Router Alert Considerations and Usage", Reshad Rahman, 17-Nov-08, 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. This document discusses security aspects and common practices around the use of router alert and discusses consequences on the use of router alert by existing or new applications. Common practices in router alert implementation facilitating router protection are also discussed. Finally a possible enhancement to the current specification of Router Alert is presented for feedback. "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, 18-Nov-08, 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, 18-Nov-08, 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, 18-Nov-08, This document defines the XML schema of the vCard data format. "A Session Identifier for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 18-Nov-08, 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. Kaplan Expires May 18, 2009 [page 1] SIP Session Identifier November 2008 "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, Mika Ishizuka, Oratai Phanachet, Yukari Maeda, 19-Nov-08, 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 proposed algorithm uses threshold marking whose TBthreshold.threshold is set to the number of bits of a metered-packet smaller than the token bucket size. Another threshold for the token bucket is required to change the marking. frequency. Under the flow termination state, all the packets are to be threshold-marked. Under the admission stop state, 1/Nth of packets are to be threshold-marked when the meter indicates. We evaluates the performance of the proposed algorithm by simulations. Our simulation indicates that the performance is almost the same as that of the CL[I-D.briscoe-tsvwg-cl-architecture] algorithm. "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, 20-Nov-08, 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, 20-Nov-08, This document proposes an alternative to the Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations [I-D.ietf-behave-turn-tcp] document. "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]. 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, Robert Hancock, 31-Oct-08, 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. "Applicability Statement of NSIS Protocols in Mobile Environments", Takako Sanda, Xiaoming Fu, Seong-Ho Jeong, Jukka Manner, Hannes Tschofenig, 18-Nov-08, 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, 7-Jul-08, 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. "GIST State Machine", Tseno Tsenov, Hannes Tschofenig, Xiaoming Fu, Cedric Aoun, Elwyn Davies, Intellectual Property, 3-Nov-08, This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", 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. "NSIS Operation Over IP Tunnels", Charles Shen, Henning Schulzrinne, Sung-Hyuck Lee, Jong Bang, 3-Nov-08, This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. "General Internet Signaling Transport (GIST) over SCTP", Xiaoming Fu, Christian Dickmann, Jon Crowcroft, 26-Oct-08, The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take 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. Additionally, the support for datagram TLS is also discussed. 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, 11-Jul-08, The NTP Server Option for DHCPv6 provides NTP (Network Time Protocol version 4) configuration information to DHCPv6 hosts. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "The Camellia Cipher in OpenPGP", David Shaw, 25-Apr-08, This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Guidelines for Considering Operations and Management of New Protocols", David Harrington, 27-Oct-08, New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocol. 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, 28-Oct-08, This memo (when approved as a standards-track RFC) 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. "Alarms in SYSLOG", Sharon Chisholm, Rainer Gerhards, 2-Nov-08, This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 6-Jun-08, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Recommendations for filtering ICMP messages", Fernando Gont, Guillermo Gont, 31-Aug-08, This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. "Issues with existing Cryptographic Protection Methods for Routing Protocols", Susan Hares, Manav Bhatia, Vishwas Manral, Russ White, 21-Oct-08, Routing protocols are designed to use cryptographic mechanisms to authenticate data being received from a neighboring router to ensure that it has not been modified in transit, and actually originated from the neighboring router purporting to have originating the data. Most of the cryptographic mechanisms defined to date rely on hash algorithms applied to the data in the routing protocol packet, which means the data is transported, in the clear, along with a signature based on the data itself. These mechanisms rely on the manual configuration of the keys used to seed, or build, these hash based signatures. This document outlines some of the problems with manual keying of these cryptographic algorithms. Open Shortest Path First IGP (ospf) ----------------------------------- "Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, 21-Sep-07, 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, 22-Apr-08, 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. "Support of address families in OSPFv3", Acee Lindem, Sina Mirtorabi, Abhay Roy, Michael Barnes, Rahul Aggarwal, 31-Oct-08, This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. "Advertising a Router's Local Addresses in OSPF TE Extensions", Rahul Aggarwal, Kireeti Kompella, 18-Nov-08, 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", Manav Bhatia, 21-Oct-08, This document describes a mechanism for authenticating OSPF packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. Because of the way the hash functions are used in HMAC construction, the collision attacks currently known against SHA-1 do not apply. This will be done in addition to the already documented authentication schemes described in the base specification. "OSPF MPR Extension for Ad Hoc Networks", Emmanuel Baccelli, Philippe Jacquet, Dang-Quan Nguyen, Thomas Clausen, 17-Nov-08, This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and denoted the "OSPFv3 MANET interface type". "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, Intellectual Property, 3-Nov-08, 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, 14-Oct-08, 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. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "Concepts and Terminology for Peer to Peer SIP", David Bryan, Philip Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins, 7-Jul-08, This document defines concepts and terminology for use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related open problems being addressed by the P2PSIP working group. As this document matures, it is expected to define the general framework for P2PSIP. "REsource LOcation And Discovery (RELOAD)", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 14-Jul-08, 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 which do not need to route traffic or store data for others. "A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 27-Oct-08, 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 Attach 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, 27-Oct-08, 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. 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, 22-Oct-08, 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, 24-Oct-08, This document defines an extension to the Protocol for carrying Authentication for Network Access (PANA) for proactively establishing a PANA SA (Security Association) between a PaC in one access network and a PAA in another access network to which the PaC may move. The proposed method operates across multiple administrative domains. "Application of PANA framework to DSL networks", Lionel Moreland, Alper Yegin, Yoshihiro Ohba, John Kaippallimalil, 4-Nov-08, This document provides guidelines for PANA deployment over DSL access networks. The document specifically describes the introduction of PANA in DSL networks migrating from a traditional PPP access model to a pure IP-based access environment. Path Computation Element (pce) ------------------------------ "Path Computation Element (PCE) Communication Protocol (PCEP)", Arthi Ayyangar, Adrian Farrel, Eiji Oki, Alia Atlas, Andrew Dolganow, Yuichi Ikejiri, Kenji Kumaki, JP Vasseur, Jean-Louis Le Roux, 19-Nov-08, This document specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Eiji Oki, Jean-Louis Le Roux, Kenji Kumaki, Adrian Farrel, Tomonori Takeda, 15-Oct-08, 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", Tomonori Takeda, Jean-Louis Le Roux, Adrian Farrel, Eiji Oki, 24-Jul-08, 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). "Policy-Enabled Path Computation Framework", Igor Bryskin, Dimitri Papadimitriou, Lou Berger, Gerald Ash, 31-Oct-08, The Path Computation Element (PCE) Architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. "A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", JP Vasseur, Raymond Zhang, Nabil Bitar, Jean-Louis Roux, 14-Apr-08, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE 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. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter- domain shortest constrained paths across a predetermined sequence of domains, using a backward recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. "Definitions of Managed Objects for Path Computation Element Discovery", Emile Stephan, 24-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 objects used for managing Path Computation Elements Discovery. "Definitions of Textual Conventions for Path Computation Element", Emile Stephan, 1-Jul-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 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, 15-Oct-08, 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. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", Tomonori Takeda, Eiji Oki, Adrian Farrel, 18-Jul-08, 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. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Richard Bradford, JP Vasseur, Adrian Farrel, 17-Nov-08, 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. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. Bradford, Vasseur and Farrel [page 1] draft-ietf-pce-path-key-05.txt November 2008 This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. "Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization", Young Lee, Jean-Louis Le Roux, Daniel King, Eiji Oki, 23-Oct-08, The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. 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. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. 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, 6-Sep-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. "A set of monitoring tools for Path Computation Element based Architecture", JP Vasseur, Jean-Louis Le Roux, Yuichi Ikejiri, 3-Nov-08, 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). 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. "Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol", Siva Sivabalan, Jon Parker, Sami Boutros, 3-Nov-08, This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). "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, 30-Jun-08, 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. 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. "draft-ietf-pce-p2mp-app-00.txt", Seisho Yasukawa, Adrian Farrel, 8-Aug-08, 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, 8-Aug-08, 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, Mohamad Chaitou, Jean-Louis Le Roux, Zafar Ali, 3-Nov-08, 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. "Requirements for GMPLS applications of PCE", Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, 17-Sep-08, The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). "The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations", Itaru Nishioka, Daniel King, 29-Sep-08, 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. This document describes the usage of multiple SVECs in the SVEC list and its processing guideline, for the synchronized computation of dependent paths. Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ "Pre-Congestion Notification (PCN) Architecture", Philip Eardley, 20-Oct-08, 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, 14-Oct-08, Pre-congestion notification (PCN) provides information to support admission control and flow termination in order 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 document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extended to provide more encoding states but such schemes will be described in other documents. "Marking behaviour of PCN-nodes", Philip Eardley, 20-Oct-08, This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than its configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of its configured rate. Setting the configured rates below the physical link rates enables PCN-nodes to provide information to support admission control and flow termination in order to protect the quality of service of established inelastic flows. Protocol Independent Multicast (pim) ------------------------------------ "The RPF Vector TLV", IJsbrand Wijnands, 20-Oct-08, This document describes a use of the PIM Join Attribute as defined in draft-ietf-pim-join-attributes [I-D.ietf-pim-join-attributes] which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. "Authentication and Confidentiality in PIM-SM Link-local Messages", William Atwood, Salekul Islam, Maziar Siami, 3-Nov-08, 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) Authentication Header (AH) or Encapsulating Security Payload (ESP). 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 automated group key management mechanism is specified. "Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, 28-Jul-08, This specification defines a method for providing multicast distribution-tree accounting data for billing and debugging. Simple extensions to the PIM protocol allow a rough approximation of tree- based data in a scalable fashion. "A Reliable Transport Mechanism for PIM", Dino Farinacci, IJsbrand Wijnands, Apoorva Karan, A Boers, Maria Napierala, 22-Aug-08, This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. "PIM Group-to-RP Mapping", Bharat Joshi, Andy Kessler, David McWalter, 21-Oct-08, Each PIM-SM router in a PIM Domain which supports ASM maintains Group-to-RP mappings which are used to identify a RP for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not allow administrator to override a specific Group- to-RP mapping with the static Group-to-RP mapping which an administrator would want to use. This algorithm also does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. The intention of this document is to suggest a standard algorithm to deterministically choose between several group-to-rp mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Quynh Dang, 30-Oct-08, 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). "Elliptic Curve Cryptography Subject Public Key Information", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 27-Oct-08, This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5, 3, and 5 of RFC 3279. "New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 10-Jul-08, 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, 1-May-08, This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature 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, 28-Oct-08, 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 [2], CRMF [3]. 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, 30-Oct-08, 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 protocols designed to address these problems. "PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 2-Jul-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, 29-Sep-08, 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. "Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08, 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. "Trust Anchor Format", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08, This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented 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 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 and for use within the context of the Trust Anchor Management Protocol (TAMP). "Trust Anchor Management Protocol (TAMP)", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08, 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: Update", Russ Housley, Stephen Farrell, Sean Turner, 27-Oct-08, This document updates RFC 3281. It incorporates verified errata. "Clearance Attribute and Authority Clearance Constraints Certificate Extension", Santosh Chokhani, Sean Turner, 31-Oct-08, 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. Performance Metrics for Other Layers (pmol) ------------------------------------------- "SIP End-to-End Performance Metrics", Daryl Malas, 1-Nov-08, 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 set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. "Framework for Performance Metric Development", Alan Clark, 2-Nov-08, 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. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Derek Chiou, Benoit Claise, Nick Duffield, Albert Greenberg, Matthias Grossglauser, Jennifer Rexford, Sharon Goldberg, 26-Jun-08, This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized selectors, to form a stream of reports on the selected packets, and to export the reports to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and exporting are described, along with configuration requirements of the PSAMP functions. "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, 10-Jul-08, This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. "Packet Sampling (PSAMP) Protocol Specifications", Benoit Claise, 18-Dec-07, This document specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. "Information Model for Packet Sampling Exports", Thomas Dietz, Benoit Claise, Paul Aitken, Falko Dressler, Georg Carle, 20-Oct-08, This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model. 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, 9-Jan-08, 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, 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 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", Thomas Nadeau, Monique Morrow, Luca Martini, Carlos Pignataro, Dinesh Mohan, 3-Nov-08, This document specifies the mapping of defect states between a Pseudo Wire and the Attachment Circuits (AC) of the end-to-end emulated service. This document covers the case whereby the ACs and the PWs are of the same type in accordance to the PWE3 architecture [RFC3985] such that a homogenous PW service can be constructed. "Segmented Pseudo Wire", Thomas Nadeau, Chris Metz, Michael Duckett, Matthew Bocci, Florin Balus, Luca Martini, 25-Jul-08, 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, 25-Jul-08, 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-Sep-08, 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, Tel Aviv, David Zelig, Tel Aviv, San Jose, 19-Aug-08, A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. "Pseudowire Congestion Control Framework", Stewart Bryant, Bruce Davie, Luca Martini, Eric Rosen, 28-May-08, Pseudowires are sometimes used to carry non-TCP data flows. In these circumstances the service payload will not react to network congestion by reducing its offered load. Pseudowires should therefore reduces their network bandwidth demands in the face of significant packet loss, including if necessary completely ceasing transmission. Since it is difficult to determine a priori the number of equivalent TCP flow that a pseudowire represents, a suitably "fair" rate of back-off cannot be pre-determined. This document describes pseudowire congestion problem and provides guidance on the development suitable solutions. "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Thomas Nadeau, Carlos Pignataro, 25-Jun-08, 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. "Preferential Forwarding Status bit definition", Praveen Muley, Matthew Bocci, Luca Martini, 30-Sep-08, This document describes a mechanism for standby status signaling of redundant PWs between their termination points. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status bit is needed to indicate a preferential forwarding status of active or standby for each PW in the redundancy set. In addition, a second status bit is defined to allow peer PE/T-PE nodes to coordinate a switchover operation of the PW/MS-PW path. "Pseudowire (PW) Redundancy", Praveen Muley, Matthew Bocci, 30-Sep-08, This document describes a framework comprised of few scenarios and associated requirements where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. "Requirements for Point-to-Multipoint Pseudowire", Frederic JOUNAY, Philippe Niger, Yuji Kamite, Simon DeLord, Luca Martini, 4-Sep-08, This document presents a set of requirements for providing an unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The requirements identified in this document are related to architecture, signaling and maintenance aspects of a Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast services as defined in the Layer 2 Virtual Private Network working group. 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, Intellectual Property, 26-Aug-08, 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, 2-Nov-08, 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, 24-Oct-08, 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, 3-Nov-08, 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. Reliable Multicast Transport (rmt) ---------------------------------- "Layered Coding Transport (LCT) Building Block", Michael Luby, Mark Watson, Lorenzo Vicisano, 12-Jul-08, 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. "Basic Forward Error Correction (FEC) Schemes", Mark Watson, 31-Oct-08, This document provides Forward Error Correction (FEC) Scheme specifications according to the RMT FEC Building Block for the Compact No-Code FEC Scheme, the Small Block, Large Block and Expandable FEC Scheme, the Small Block Systematic FEC Scheme and the Compact FEC Scheme. This document obsoletes RFC3695 and assumes responsibility for the FEC Schemes defined in RFC3452. "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, 25-Oct-08, This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. "Multicast Negative-Acknowledgment (NACK) Building Blocks", Brian Adamson, Carsten Bormann, University London, Joseph Macker, 9-Sep-08, This document discusses the creation of reliable multicast protocols utilizing negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. "Reed-Solomon Forward Error Correction (FEC) Schemes", Jerome Lacan, Vincent Roca, Jani Peltotalo, Sami Peltotalo, 12-Nov-07, This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), with m in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8). Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. "Security and Reliable Multicast Transport Protocols: Discussions and Guidelines", Brian Adamson, Vincent Roca, Hitoshi Asaeda, 3-Nov-08, This document describes general security considerations for the Reliable Multicast Transport (RMT) Working Group set of building blocks and protocols. An emphasis is placed on risks that might be resolved in the scope of transport protocol design. However, relevant security issues related to IP Multicast control-plane and other concerns not strictly within the scope of reliable transport protocol design are also discussed. The document also begins an exploration of approaches that could be embraced to mitigate these risks. The purpose of this document is to provide a consolidated security discussion and provide a basis for further discussions and potential resolution of any significant security issues that may exist in the current set of RMT standards. "Simple Authentication Schemes for the ALC and NORM Protocols", Vincent Roca, 27-Oct-08, This document introduces two 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 a group Message Authentication Code (MAC). Because this scheme relies 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. Robust Header Compression (rohc) -------------------------------- "Integration of Robust Header Compression (ROHC) over IPsec Security Associations", Emre Ertekin, Rohan Jassani, Chris Christou, Jonah Pezeshki, Carsten Bormann, 14-Oct-08, 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, Jonah Pezeshki, 14-Oct-08, In order to integrate ROHC with IPsec [ROHCOIPSEC], a mechanism is needed to negotiate ROHC configuration parameters between end-points. Internet Key Exchange (IKE) is a mechanism which can be leveraged to handle these negotiations. This document specifies extensions to IKEv2 [IKEV2] that will allow ROHC and its associated configuration parameters to be negotiated for IPsec security associations (SAs). "IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)", Emre Ertekin, Chris Christou, Jonah Pezeshki, Michele Casey, Carsten Bormann, 14-Oct-08, Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, extensions to the SPD and SAD are required in order to integrate ROHC with IPsec. This document describes the IPsec extensions required to support ROHCoIPsec. "The RObust Header Compression (ROHC) Framework", Kristofer Sandlund, Ghyslain Pelletier, Lars-Erik Jonsson, 4-Aug-08, The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. 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, 21-Oct-08, 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 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 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, 30-Oct-08, Wireless, low power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these 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 from wired systems. In an industrial environment, low power, high reliability, and easy installation and maintenance are mandatory qualities for wireless devices. The aim of this document is to analyze the requirements for the routing protocol used for Low power and Lossy Networks (LLN) in industrial environments. "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, 17-Oct-08, Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have 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 has novel requirements that existing protocols may not address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to this class of networks. From this survey it examines whether existing protocols as described in RFCs and mature drafts could be used without modification in these networks, or whether further work is necessary. "Terminology in Low power And Lossy Networks", JP Vasseur, 27-Oct-08, 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, 29-Oct-08, 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 Protocol Security Requirements (rpsec) ---------------------------------------------- "BGP Security Requirements", Blaine Christian, Tony Tauber, 3-Nov-08, The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP and the routing information carried within BGP. "BGP Session Security Requirements", Michael Behringer, 10-Jul-08, The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. Reliable Server Pooling (rserpool) ---------------------------------- "Reliable Server Pooling: Management Information Base using SMIv2", Thomas Dreibholz, Jaiwant Mulik, 18-Nov-08, RSerPool [RFC5351] is a framework to provide reliable server pooling. This document defines a SMIv2 compliant Management Information Base (MIB) providing access to managed objects in an RSerPool implementation. Routing Area Working Group (rtgwg) ---------------------------------- "IP Fast Reroute Framework", Mike Shand, Stewart Bryant, 30-Oct-08, This document provides a framework for the development of IP fast- reroute mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. "IP Fast Reroute Using Not-via Addresses", Mike Shand, Stewart Bryant, Stefano Previdi, 30-Oct-08, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. "A Framework for Loop-free Convergence", Mike Shand, Stewart Bryant, 31-Oct-08, 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) ----------------------------------------------- "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 11-Jul-08, This document defines a simple challenge-response authentication mechanism, using a keyed MD5 digest, for use with the Simple Authentication and Security Layer (SASL). "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon Josefsson, 13-Jul-08, 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/GSS-API mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports a SASL-specific notion of channel binding. See for more information. "Moving DIGEST-MD5 to Historic", Alexey Melnikov, 29-Jul-08, This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It recommends that DIGEST-MD5 to be marked as OBSOLETE in the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to Historic status. 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. "Simple Authentication and Security Layer (SASL)", Alexey Melnikov, Kurt Zeilenga, 31-Aug-08, 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]]. 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, 14-Feb-08, 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. "Default Locator-pair selection algorithm for the SHIM6 protocol", Marcelo Bagnulo, 23-Oct-08, In this note, we present a locator-pair selection mechanism for the shim6 protocol. The presented mechanism provides an ordered list of available locator-pairs that can be used for outgoing traffic. "Socket Application Program Interface (API) for Multihoming Shim", Miika Komu, Marcelo Bagnulo, Kristian Slavov, Shinta Sugimoto, 2-Nov-08, 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, 17-Nov-08, 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, 3-Nov-08, This document describes the certificate policy for a PKI used to support improved routing security. 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, e.g., generation of route filters by ISPs. "Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI)", Derrick Kong, Karen Seo, Stephen Kent, 3-Nov-08, This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Resource Public Key Infrastructure (RPKI). "Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI)", Karen Seo, Stephen Kent, Dennis Kong, 3-Nov-08, This document contains a template to be used for creating a Certification Practice Statement (CPS) for a Local Internet Registry (LIR) or Internet Service Provider (ISP) that is part of the Resource Public Key Infrastructure (PKI). "A Profile for Route Origin Authorizations (ROAs)", Matt Lepinski, Stephen Kent, Derrick Kong, 3-Nov-08, This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. "An Infrastructure to Support Secure Internet Routing", Matt Lepinski, Stephen Kent, 3-Nov-08, 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 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-Aug-08, 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. "Manifests for the Resource Public Key Infrastructure", Rob Austein, Geoff Huston, Stephen Kent, Matt Lepinski, 24-Oct-08, This document defines a "manifest" for use in the Resource Public Key Infrastructure. A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential attacks against relying parties of the Resource Public Key Infrastructure, such as a man-in-the middle attack of withholding repository data from relying party access, or replaying stale repository data to a relying party's access request. "Validation of Route Origination in BGP using the Resource Certificate PKI", Geoff Huston, George Michaelson, 5-Oct-08, This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. "A Profile for Bogon Origin Attestations (BOAs)", Geoff Huston, George Michaelson, Terry Manderson, 28-Oct-08, This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA. A BOA also provides a means of verifying that BGP speaker is not using an AS without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of the Border Gateway Protocol. "A Profile for Resource Certificate Repository Structure", Geoff Huston, Robert Loomans, George Michaelson, 4-Oct-08, This document defines a profile for the structure of repository publication points that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Email Filtering: Reject and Extended Reject Extensions", Aaron Stone, Matthew Elvey, Alexey Melnikov, 17-Nov-08, This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028. A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible. The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol level message rejection. "SIEVE Email Filtering: Extension for Notifications", Alexey Melnikov, Barry Leiba, Wolfgang Segmuller, Tim Martin, 24-Dec-07, Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but it is expected that using existing instant messaging infrastructure such as XMPP, or GSM Short Message Service (SMS) messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. "Sieve Notification Mechanism: mailto", Barry Leiba, Michael Haardt, 1-Oct-08, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. "Sieve Notification Mechanism: xmpp", Peter Saint-Andre, Alexey Melnikov, 19-Feb-08, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. "Sieve Email Filtering: 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: Ihave Extension", Ned Freed, 9-Oct-08, This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. "Sieve Email Filtering: Delivery Status Notifications Extension", Ned Freed, 17-Nov-08, This document describes the "dsn-envelope" and "dsn-redirect" extensions to the Sieve email filtering language. The "dsn-envelope" extension provides access to additional envelope information provided by the delivery status notification extension to SMTP defined in RFC 3461. The "dsn-redirect" extension extends Sieve's redirect action to provide control over delivery status notification parameters. "A Protocol for Remotely Managing Sieve Scripts", Alexey Melnikov, Tim Martin, 1-Nov-08, 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. 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. "Instant Message Disposition Notification", Eric Burger, Hisham Khartabil, 19-Oct-08, Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and displayed notifications, for page-mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. "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-Martin, Geir Arne Sandbakken, 30-Oct-08, 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, 31-Oct-08, 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. "Optimizing Federated Presence with View Sharing", Jonathan Rosenberg, Steve Donovan, Kathleen McMurry, 3-Nov-08, Presence federation refers to the exchange of presence information between systems. One of the primary challenges in presence federation is scale. With a large number of watchers in one domain obtaining presence for many presentities in another, the amount of notification traffic is large. This document describes an extension to the Session Initiation Protocol (SIP) event framework, called view sharing. View sharing can substantially reduce the amount of traffic, but requires a certain level of trust between domains. View sharing allows the amount of presence traffic between domains to achieve the theoretical lower bound on information exchange in any presence system. "Models for Intra-Domain Presence and Instant Messaging (IM) Bridging", Jonathan Rosenberg, Avshalom Houri, Colm Smyth, Francois Audet, 3-Nov-08, 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. Session Initiation Protocol (sip) --------------------------------- "Connection Reuse in the Session Initiation Protocol (SIP)", Vijay Gurbani, Rohan Mahy, Brett Tate, 22-Oct-08, 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. From the security perspective, it is bad practice to reuse a single connection for the TCP or SCTP transport between two peers, and this document provides specific insights into why this is the case. As a remedy, it suggests using two TCP connections (or two SCTP associations), each opened pro-actively towards the recipient by the sender. Finally, this document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in 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. "Location Conveyance for the Session Initiation Protocol", James Polk, Brian Rosen, 20-Nov-08, 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. "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Cullen Jennings, Rohan Mahy, 29-Oct-08, 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. "Requesting Answering Modes for the Session Initiation Protocol (SIP)", Dean Willis, Andrew Allen, 28-May-08, This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", Robert Sparks, Scott Lawrence, Alan Hawrylyshen, Byron Campen, 29-Oct-08, This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. "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. "SIP SAML Profile and Binding", Hannes Tschofenig, Jeff Hodges, Jon Peterson, James Polk, Douglas Sicker, 3-Nov-08, 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)". "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 3-Nov-08, The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. "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. "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", Francois Audet, 23-Feb-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. This document also provides a discussion of possible future steps in specification. "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. "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", Aki Niemi, 14-Jul-08, The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they 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. "Addressing Record-Route issues in the Session Initiation Protocol (SIP)", Thomas Froment, Christophe Lebel, Ben Bonnaerens, 6-Oct-08, 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. "Message Body Handling in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 18-Nov-08, 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. "Requirements and Analysis of Media Security Management Protocols", Dan Wing, Steffen Fries, Hannes Tschofenig, Francois Audet, 31-Oct-08, This document describes requirements for a protocol to negotiate a security context for SIP-signaled SRTP media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. "IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces", James Polk, 21-Oct-08, This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", Scott Lawrence, Vijay Gurbani, 6-Oct-08, This memo documents an extended key usage (EKU) X.509 certificate extension for identifying the holder of a certificate as authoritative for a Session Initiation Protocol (SIP) service in the domain named by the DNS name in the certificate. "Domain Certificates in the Session Initiation Protocol (SIP)", Vijay Gurbani, Scott Lawrence, Bell Laboratories, 6-Oct-08, This document describes how to interpret certain information in a X.509 PKIX-compliant certificate used in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to find the right identity for authentication in such certificates and how to use that identity for SIP domain authentication. "Framework for Establishing an SRTP Security Context using DTLS", Jason Fischl, Hannes Tschofenig, Eric Rescorla, 29-Oct-08, 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. "UA-Driven Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 29-Oct-08, This document defines a best current practice for a user agent to generate an anonymous SIP message by utilizing mechanisms such as GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using Relays around NAT) without the need for a privacy service defined in RFC 3323. "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. "Response Code for Indication of Terminated Dialog", Christer Holmberg, 20-Oct-08, This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP entity can use to indicate upstream that an early dialog has been terminated. The response code can be used by a SIP entity to indicate to the UAC that an early dialog has been terminated, before a final response is sent to the UAC. "Session Initiation Protocol (SIP) INFO Method and Package Framework", Eric Burger, Hadriel Kaplan, Christer Holmberg, 4-Nov-08, This document defines the new INFO method and a mechanism for defining, negotiating and exchanging Info Packages that use the INFO method. Applications which 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. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Dan Petrie, Alan Johnston, 16-Apr-08, 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. "Best Current Practices for NAT Traversal for Client-Server SIP", Chris Boulton, Jonathan Rosenberg, Gonzalo Camarillo, Francois Audet, 17-Sep-08, Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding flows. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, Alan Johnston, 15-Oct-08, 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. "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. "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. "A User Agent Profile Data Set for Media Policy", Volker Hilt, Gonzalo Camarillo, Jonathan Rosenberg, 12-Jul-08, 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. "Session Initiation Protocol Package for Voice Quality Reporting Event", Alan Clark, Amy Pendleton, Alan Johnston, Henry Sinnreich, 9-Oct-08, 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. "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. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", Jani Hautakorpi, Gonzalo Camarillo, Bob Penfield, Alan Hawrylyshen, Medhavi Bhatia, 22-Oct-08, 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. "Requirements for Management of Overload in the Session Initiation Protocol", Jonathan Rosenberg, 14-Jul-08, Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. "SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", Paul Kyzivat, 3-Nov-08, 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. "Example calls flows of race conditions in the Session Initiation Protocol (SIP)", Miki Hasebe, Jun Koshiko, Yasushi Suzuki, Tomoyuki Yoshikawa, Paul Kyzivat, 29-Sep-08, This document gives examples call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. "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. "Scaling Requirements for Presence in SIP/SIMPLE", Avshalom Houri, Sriram Parameswar, Edwin Aoki, Vishal Singh, Henning Schulzrinne, 2-Nov-08, The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", John Elwell, 13-Oct-08, 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, PUBLISH and ACK, 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. "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets", Martin Dolly, Sumanth Channabasappa, Sam Ganesan, Volker Hilt, 30-Oct-08, 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. "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Volker Hilt, 22-Oct-08, 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. 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. "Identity-based Encryption Architecture and Supporting Data Structures", Guido Appenzeller, Luther Martin, Mark Schertler, 9-Oct-08, This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. "Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)", Luther Martin, Mark Schertler, 4-Aug-08, This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. "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, 9-Oct-08, his 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. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", Sean Turner, Blake Ramsdell, 6-Oct-08, This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) 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, 6-Oct-08, 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, 10-Jul-08, 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, 22-Oct-08, 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 for key agreement, RFC 3565 and RFC 3370 for key wrap and content encryption, NIST FIPS 180-3 for message digest, and RFC 2104 and RFC 4231 for message authentication code standards. This document will obsolete RFC 3278. Softwires (softwire) -------------------- "Softwire Hub & Spoke Deployment Framework with L2TPv2", Bill Storer, Carlos Pignataro, Maria Santos, Bruno Stevant, Jean-Francois Tremblay, 29-Oct-08, 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, 27-Oct-08, 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, Xing Li, Chris Metz, Eric Rosen, Simon Barber, Pradosh Mohapatra, John Scudder, Intellectual Property, 18-Sep-08, 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. "Advertising an IPv4 NLRI with an IPv6 Next Hop", Francois Le Faucheur, Eric Rosen, 27-Oct-08, MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising an IPv4 Network Layer Reachability Information (NLRI) or a VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. "BGP Traffic Engineering Attribute", Don Fedyk, Yakov Rekhter, Hamid Ould-Brahim, 10-Sep-08, This document defines a new BGP attribute, Traffic Engineering attribute, than enables BGP to carry Traffic Engineering information. The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. "BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute", Pradosh Mohapatra, Eric Rosen, Intellectual Property, 4-Jun-08, In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another, the BGP next hop, requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header. The encapsulation information need not be signaled for all encapsulation types. In the cases where the signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3), Generic Routing Encapsulation (GRE) with key), this draft specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the "Encapsulation Subsequent Address Family Identifier (SAFI)" and IPv4 or IPv6 Address Family Identifier (AFI). In the cases where no encapsulation information needs to be signaled (such as GRE without key), this draft specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes to indicate the encapsulation protocol type to be used. "BGP IPSec Tunnel Encapsulation Attribute", Lou Berger, Russ White, Eric Rosen, 1-May-08, 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 and L2TPv3 tunnel types are defined. This document defines support for IPsec tunnel types. Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Saravanan Shanmugham, Daniel Burnett, 3-Nov-08, The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. Session PEERing for Multimedia INTerconnect (speermint) ------------------------------------------------------- "SPEERMINT Terminology", Daryl Malas, Dave Meyer, 18-Nov-08, This document defines the terminology that is to be used in describing 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", Sohel Khan, 3-Nov-08, 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. Conventions used in this document The key words "must", "must NOT", "REQUIRED", "SHALL", "SHALL NOT", "should", "should NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[1] "SPEERMINT Routing Architecture Message Flows", Hadriel Kaplan, Daryl Malas, Sohel Khan, Reinaldo Penno, Adam Uzelac, 3-Nov-08, 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, 20-Nov-08, The objective of this document is to specify the Best Current Practice (BCP) adopted by a service provider 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. "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, 4-Oct-07, 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 RFC xxxx, "The syslog Protocol". "The syslog Protocol", Rainer Gerhards, 6-Sep-07, This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. This document obsoletes RFC3164. "Transmission of syslog messages over UDP", Anton Okmianski, 5-Sep-07, This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. "TLS Transport Mapping for Syslog", Miao Fuyou, Ma Yuzhi, Joseph Salowey, 1-Oct-08, This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. "Textual Conventions for Syslog Management", Glenn Mansfield, 22-May-08, This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. 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. "TCP User Timeout Option", Lars Eggert, Fernando Gont, 13-Jun-08, The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", Sally Floyd, Intellectual Property, 3-Nov-08, This draft specifies a 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 specifies 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). This document updates RFC 3168. "TCP's Reaction to Soft Errors", Fernando Gont, 23-Apr-08, This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. "ICMP attacks against TCP", Fernando Gont, 27-Oct-08, This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", Pasi Sarolahti, Markku Kojo, Kazunori Yamamoto, Max Hata, Intellectual Property, 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, 3-Nov-08, 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 keying or an external, out-of-band key management mechanism; in either case, TCP-AO also protects connections when using the same key across repeated instances of a connection. 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. "Early Retransmit for TCP and SCTP", Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Ethan Blanton, Per Hurtig, 28-Aug-08, 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. Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Architecture for the Transmission of Timing over Packet Networks", Tim Frost, Greg Dowd, Intellectual Property, 3-Nov-08, This Internet draft proposes an architecture for the transmission of timing over packet networks. It identifies the major functional components, and maps the current solutions onto this framework. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Extensions: Extension Definitions", Donald Eastlake 3rd, 5-Oct-08, This document provides documentation for existing specific 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 Extractors for Transport Layer Security (TLS)", Eric Rescorla, 2-Nov-08, 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. "ECDHE_PSK Ciphersuites for Transport Layer Security (TLS)", Mohamad Badra, 31-Oct-08, This document extends RFC 4279, RFC 4492 and RFC 4785, and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange (ECDH). These cipher suites provide Perfect Forward Secrecy (PFS). "DES and IDEA Cipher Suites for Transport Layer Security (TLS)", Pasi Eronen, 25-Jun-08, TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS 1.2 main specification (RFC 5246). This document specifies these cipher suites for completeness, and discusses reasons why their use is no longer recommended. "Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode", Mohamad Badra, 30-Oct-08, RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes a set of pre-shared key cipher suites for TLS which uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set which uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). "Datagram Transport Layer Security version 1.2", Eric Rescorla, Nagendra Modadugu, 1-Nov-08, 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. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "Rbridges: Base Protocol Specification", Radia Perlman, 3-Nov-08, 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, 29-Sep-08, Current Ethernet (802.1) link layers 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 bridged (802.1) links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. Transport Area Working Group (tsvwg) ------------------------------------ "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Kacheong Poon, Michael Tuexen, Vladislav Yasevich, Peter Lei, 3-Nov-08, 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 Protovol (RSVP) Extensions for Emergency Services", Francois Le Faucheur, James Polk, Ken Carlberg, 17-Oct-08, 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 formed by either a single administrative domain or a set of administrative domains that closely coordinate their network policy and network design. The mechanisms defined in this document can be used for a session whose path spans over such a controlled environment in order to elevate the session establishment probability through the controlled environment (thereby elevating the end to end session establishment probability). "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, Jukka Manner, Ashok Narayanan, Allan Guillou, Le Faucheur, 1-Jul-08, 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, 31-Aug-08, 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 random 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, the described port number randomization 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, 3-Nov-08, 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. "IANA Procedures for the Transport Protocol Port Number Space", Michelle Cotton, Lars Eggert, Allison Mankin, Magnus Westerlund, Joseph Touch, 3-Nov-08, This document defines the IANA procedures for registering port number values for use with the various IETF transport protocols, including TCP, UDP, DCCP, and SCTP. It provides clear procedures for the management of the port number registry, which is important for its long-term management. It updates RFC2780 by obsoleting Sections 8 and 9.1 of that RFC, and it updates the IANA allocation procedures for DCCP as defined in RFC4340. "Byte and Packet Congestion Notification", Bob Briscoe, 7-Aug-08, This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). The primary conclusion is that packet size should be taken into account when transports read congestion indications, not when network equipment writes them. Reducing drop of small packets has some tempting advantages: i) it drops less control packets, which tend to be small and ii) it makes TCP's bit- rate less dependent on packet size. However, there are ways of addressing these issues at the transport layer, rather than reverse engineering network forwarding to fix specific transport problems. Network layer algorithms like the byte-mode packet drop variant of RED should not be used to drop fewer small packets, because that creates a perverse incentive for transports to use tiny segments, consequently also opening up a DoS vulnerability. "Layered Encapsulation of Congestion Notification", Bob Briscoe, 27-Oct-08, This document redefines how the explicit congestion notification (ECN) field of the outer IP header of a tunnel should be constructed. It brings all IP in IP tunnels (v4 or v6) into line with the way IPsec tunnels now construct the ECN field. It includes a thorough analysis of the reasoning for this change and the implications. It also gives guidelines on the encapsulation of IP congestion notification by any outer header, whether encapsulated in an IP tunnel or in a lower layer header. Following these guidelines should help interworking, if the IETF or other standards bodies specify any new encapsulation of congestion notification. "Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, Robin Seggelmann, Eric Rescorla, 22-Oct-08, This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). The user of DTLS over SCTP can take advantage of all features provided by SCTP and its extensions, especially support of o multiple streams to avoid head of line blocking. o multi-homing to provide network level fault tolerance. o unordered delivery. o partially reliable data transfer. 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, 27-Aug-08, 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) ----------------------- "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, Chip Popoviciu, Tim Chown, Olaf Bonness, Christian Hahn, 22-Sep-08, One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 29-Jul-08, 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, 10-Sep-08, 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. "Security Concerns With IP Tunneling", James Hoagland, Suresh Krishnan, Dave Thaler, 14-Oct-08, A number of security concerns with IP tunnels are documented in this document. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness regarding the security issues with IP tunnels as deployed today. vCard and CardDAV (vcarddav) ---------------------------- "vCard Format Specification", Simon Perreault, Pete Resnick, 3-Nov-08, 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, 12-Jul-08, 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. Discussion of this Internet-Draft is taking place on the mailing list . 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, 28-Oct-08, 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.Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . lists all registered issues since draft 02. Centralized Conferencing (xcon) ------------------------------- "Conference Information Data Model for Centralized Conferencing (XCON)", Oscar Novo, Gonzalo Camarillo, David Morgan, Roni Even, Jari Urpalainen, 28-Oct-08, 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, 3-Nov-08, 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.